Re: Blowfish still good enough?
Well I was contemplating the error of my ways on this thread. I realized that I was wrong. Blowfish's implementation is secure and efficient... from a programmer's point of view. A few hundred years ago everybody knew the Earth was the center of the universe. Then we knew that the most basic form of stuff (what we now know as atoms) resembled chocolate chip cookies. A hundred years ago, putting a man on the moon was inconcieveable. The Nazis thought their Enigma machine was perfect. The password file on *nix systems back in the day used to be world-readable. DES used to be considered strong crypto. The USA's National Bureau of Standards standardized it. The National Institute of Standards and Technology, which formerly was the NBS--the guys who decided DES was good--also say that AES is safe now, too. Imagine what we will know tomorrow. Just think about it, in a few hundred years mankind may be able to zip around the universe at will. It will never happen, you say. Science says it can't. I can't recall how many sciences were later debunked. What makes ours any better? So what does this have to do with keeping your secrets safe? Well, it occured to me that no crypto is perfect, as I hope everyone feels. To keep those secrets safe, we don't need stronger crypto--we need more of it. Imagine a large (as in quantity) homogenous crop that a populated country depends on to eat. If one virus comes along and kills off that crop, then those people will suffer greatly. But, if those people diversify their agriculture and have three crops, then that one virus will not cause famine. This can be applied to cryptography, and for my practical purposes, cryptographic disks. Imagine the efficacy of taking at least three radically different (from one another) forms of crypto and superimposing those cryptographies on one another. So, for instance you have the secret which you crypt with A, then crypt it with sceme B, and finally C. If weaknesses are found in one of those cryptographies (I'm confident of this, it's what history teaches us) then scheme A and C are still protecting that data. Sure, it's slow, inefficient. But if you have need of storing data securely, you should be able to sleep at night, knowing that you're as protected as humanly possible. It's also really paranoid, a simpler implementation which can be found everywhere will generally protect you against say, laptop thieves. Yet, if it is worth doing, it is worth doing right. Doing it right involves obfusgating your data so that any attemts at brute-forcing it would result in more meaningful data that could be produced by a monkey on a typewriter typing for epoch or so (they say that the monkey would eventually write Shakespere.) Yes, I am _exaggerating_, but it's to prove my point. There is no value in the second kick of a mule. Look at history, we need to drop our arrogance that our cryptographies are strong. Then we need to do the best job as humanly possible (if you wonder what this route is, just remember--tinfoil hat paranoia) to keep information secret, which I believe involves using different cryptographies for the same set of data. At the very least, the idea of diversification is good... the details can be worked out later. I'm not a programmer nor a cryptographer, I'm a historian and philosopher, among a few other things. That's why you should listen, since if you only speak to the aforementioned types of people, your view of the world will remain narrow--a narrow view of things is dangerous. Travers K. Buda
Re: Blowfish still good enough?
Somebody please correct me if I'm wrong. Blowfish has been extensively analyzed since 1993. It is believed to be secure. As far as the 64 bit blocks go: most solid encryption programs generally use a block chaining mode, to group multiple blocks together. Encrypt one block, XOR it with the next, etc. Even if collisions were found in the ciphertext, the most the attacker could deduce is that they represent the same plaintext block. If the attacker didn't previously know what that ciphertext block meant, it wouldn't really do them any good. I think Blowfish is a great choice for the encryption algorithm. Besides, factor this into the mix: Blowfish uses a key up to 448 bits. Twofish goes up to 256 bits, as does AES. AES may or may not have been broken based on the XSL attack. So the key size is an atvantage over Twofish, and the years of review makes for an advantage over AES. Just $16.99/mo. or less. dsl.yahoo.com
ifstated.conf documentation problem?
man 5 ifstated.conf says:
"The init block is used
to initialise the state and is executed each time the
state is entered."
But this does not seem to be true if you use 'init-state'
to enter the state. Or maybe there's something else
wrong with my config below, or with ifstated when there's
no body. Or something.
Odd things happen with the following ifstated.conf.
It just hangs out in the state "starting".
(Starting the daemon by hand after booting.)
Things go back in sync after a state change on
carp0. (carp0 starts out in MASTER. Unpugging
the cable sends it into BACKUP. At that time
ifstated first changes state to 'master', and
then immediately to 'not_master'.)
OTOH, the given config works just fine if
you remove the "init {" and "}" from the "starting"
state, leaving the action as the body of the "starting".
I would expect the opposite, that without "init" the state would
stay in "starting" and have to wait for a state
change before the body was evaluated.
So, it seems that ifstated with "init-state" executes
the body of the inital state on startup, and ignores the
"init" block.
/etc/ifstated.conf:
# Reconfigures daemons based on whether we're master or not.
# We want to startup
init-state starting
# net.inet.carp.preempt must be enabled (set to 1)
# for this to work correctly.
carp_up = "carp0.link.up"
state starting {
init {
# Here we boot the box.
if $carp_up
set-state master
if ! $carp_up
set-state not_master
}
}
state not_master {
init {
run "rm /tmp/am_master"
}
if $carp_up
set-state master
}
state master {
init {
run "touch /tmp/am_master"
}
if ! $carp_up
set-state not_master
}
Karl <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Dead switch, a quick carp failover question
Hi, Sorry, but I just can't seem to get (all of) net.inet.carp.preempt from the man pages. I could set this up and test it, but I know that somebody's done it already and a quick search of the list archives fails me. Suppose I have 2 firewalls, one failing over to the other with carp. (net.inet.carp.preempt=1 on both firewalls.) Each has 3 interfaces, internet, lan, and dmz. The dmz has, say, a webserver. Now to connect the 2 firewalls to the webserver an additional switch/hub is required in the physical topology. Suppose the switch dies. (I'm thinking the link goes down on both firewalls' dmz interface, but I suppose there are other more spectacular ways the switch could fail.) What is the state of all the carp interfaces on the firewalls? If the dmz interfaces go down, then does this not shut off all the carp interfaces on both firewalls as a group, turning off the parts of both firewalls that are still functioning? Is the solution to this to use ifstated to check the opposite firewall and see if it's master, and if not then shut down the dmz carp interface? (If this is the answer it'd be nice to have ifstated be able to examine interfaces on other hosts, not just on the local host.) TIA. Karl <[EMAIL PROTECTED]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Re: Reason for -p option in useradd
On Sat, 31 Dec 2005 12:19:38 -0500, Nick Holland <[EMAIL PROTECTED]> wrote: >Virtually every feature has risk associated with it of SOME kind. ^ Congratulations Nick! -In the final hours you have succeeded in having the best/worst punn of 2005. ;-) JCR
Re: Reason for -p option in useradd
Adam Gleave wrote: > I've searched the archives and (re)read the man page of useradd, but I > can't understand why the -p option exists. To me, I can see no way of > using it safely (securely) as it can display on the process listing. > > Admittedly, there might be some use for it that I haven't thought of - > but in it's current form it seems far to easy to reveal a passwd hash; > the only application I can think of is when no one other than trusted > users have access to the process listing. you mean...like maybe no one other than a system administrator is logged into the machine? Not every system has non-administrative users getting shell access. Not every system has someone seeing a process listing for a fraction of the right second as the biggest security risk. > Despite that, I think it would be better - although less clean - to have > the pasword passwed on stdin. > > So, my question is: why is it like it currently is? > > Thanks Case where I used this option: initial setup of user accounts on a school's mail server. No one but one teacher and I had shell access on the mail server. To minimize the headaches, all students initially had the same password anyway. Even if someone was watching and saw the hashed password, they learned something difficult to use they could have learned in a much easier way through other means. Yes, giving everyone the same initial PW is "wrong", but I can assure you, AS IT WAS, it took the teacher an ENTIRE CLASS PERIOD to get the students logged in the first time and changing their PWs. This wasn't the most computer savvy group in the world. I can't imagine how long it would have taken if she had to help EACH student, one-by-one, change unique PWs. And you know, if one or two of them figured out that they could get into someone else's e-mail account this way, I'd call that a GOOD thing -- they were thinking, and maybe they understand what the teacher said about "don't trust e-mail, you don't really know who sent something to you". If I helped people distrust a non-authenticated form of communications, great. OpenBSD isn't about disabling things that could possibly be improperly used. Virtually every feature has risk associated with it of SOME kind. Nick.
Re: Debugging pxeboot on WRAP
On Tue, 27 Dec 2005 13:29:17 +0100, Rolf Sommerhalder <[EMAIL PROTECTED]> wrote: >Good news - my WRAPs now pxeboot OpenBSD as expected! The culprit was >not pxeboot, but the etherboot PXE code 5.3.12 in BIOS 1.08 and 1.10, >as supplied by PCengines. > Seems you were lucky but if you had to dig into the code yourself and debug things, the list of required knowledge posted by Tom Cosgrove is important. Though I haven't tested the code presented, the article linked below covers part of the required knowledge that Tom mentioned, namely, the Protected Mode to Real Mode switching. http://www.sudleyplace.com/pmtorm.html kind regards, jcr
Re: problem fsckin' a usb disk on boot
--- Tom Cosgrove <[EMAIL PROTECTED]> wrote: > >>> b h 31-Dec-05 04:05 >>> > : > > then, when I press RETURN and attempt to > > > > # fsck_ffs /dev/rsd0a > > ** /dev/rsd0a > > cannot alloc 36537985 bytes for typemap > > # > > > > while dmesg also says I have: > > > > real mem = 1072472064 (1047336K) > > avail mem = 972025756 (949244K) > > This message comes from setup() in > /usr/src/sbin/fsck_ffs/setup.c, > after it has performed a lot of other allocations. > > How big is the partition on this disk? How full is > it? You probably > do need to put more memory in the machine to fsck > this disk. > > See FAQ 14.7 > (http://www.openbsd.org/faq/faq14.html#LargeDrive), > under > "fsck(8) time and memory requirements". > > Thanks > > Tom > Hi Tom, thanks for the reply. I'm sorry I didn't attach disklabel. It is one partition. So it's advertised as a 300GB usb drive, the partition is roughly that size. But I have 1GB of memory in the machine (and it looks like it's all being detected as described earlier in dmesg). And I had read the time and memory requirements, and the rule of thumb is 1MB (of available) RAM for 1GB of disk, which I believe I have covered a few times over. I made sure of this when I created the obscenely large partition a year ago. I do believe it is fairly full. sd0a is the only partition that is not coming up clean as also described before. I don't mind waiting for really long fsck times, therefore I thought I could get away with the large partitions. Any other ideas/analysis? thanks I'll type in a copy of my fstab /dev/wd0a / ffs rw 1 1 /dev/wd0h /home ffs rw,nodev,nosuid 1 2 /dev/wd0d /tmp ffs rw,nodev,nosuid 1 2 /dev/wd0g /usr ffs rw,nodev 1 2 /dev/wd0e /var ffs rw,nodev,nosuid 1 2 /dev/wd0i /data ffs rw,nodev,nosuid 1 2 /dev/wd1a /mnt/data1 ffs rw,nodev,nosuid 1 2 /dev/wd2a /mnt/data2 ffs rw,nodev,nosuid 1 2 /dev/wd3a /mnt/data3 ffs rw,nodev,nosuid 1 2 /dev/sd0a /mnt/data4 ffs rw,nodev,nosuid 1 2 and the disklabel on sd0a says (pardon any typo mistakes pls) type: SCSI disk: SCSI disk label: OneTouch II flags: byles/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 286188 total sectors: 586114704 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 #size offset fstype [fsize bsize cpg] a: 586112992 32 4.2BSD2048 16384 323 # Cyl 0*-286187 c: 586114704 0 unused 0 0 # Cyl 0 -286188* Just $16.99/mo. or less. dsl.yahoo.com
Re: Reason for -p option in useradd
On Sat, Dec 31, 2005 at 01:51:53PM +, Adam Gleave wrote: > I've searched the archives and (re)read the man page of useradd, but I > can't understand why the -p option exists. To me, I can see no way of > using it safely (securely) as it can display on the process listing. > > Admittedly, there might be some use for it that I haven't thought of - > but in it's current form it seems far to easy to reveal a passwd hash; > the only application I can think of is when no one other than trusted > users have access to the process listing. > > Despite that, I think it would be better - although less clean - to have > the pasword passwed on stdin. > > So, my question is: why is it like it currently is? I wouldn't be all that surprised if this was in the POSIX specs. Joachim
Reason for -p option in useradd
I've searched the archives and (re)read the man page of useradd, but I can't understand why the -p option exists. To me, I can see no way of using it safely (securely) as it can display on the process listing. Admittedly, there might be some use for it that I haven't thought of - but in it's current form it seems far to easy to reveal a passwd hash; the only application I can think of is when no one other than trusted users have access to the process listing. Despite that, I think it would be better - although less clean - to have the pasword passwed on stdin. So, my question is: why is it like it currently is? Thanks
Re: Two internet connections, one intranet server.
On Sat, 31 Dec 2005 01:29:16 +0100 Gilles LAMIRAL <[EMAIL PROTECTED]> wrote: > I have 2 internet connections. > Each one is handled by an Openbsd system. > Each one has an intERnet address. > Each one is doing NAT for the intRAnet hosts. > I have a smtp server (not openbsd) inside the intRAnet, > its ip address is for example 192.168.35.3. > I want the smtp server be contacted by both > public adresses on the internet. > What can I do ? You should consider getting more public IP addresses as you need three public addresses on each external connection, ideally. > I want c1 be able to connect "directly" to the smtp1 host > via ob1 or via ob2 depending on the ip used (ob1 or ob2). > > ++ ++ > | c1 |__|Internet| > ++ ++ >| | >| | +--+ | carp if | +--+ >| | > +-++-+ > | ob1 || ob2 | > +-++-+ | | +--+ | carp if | +--+ > |__| >| > +---+ > | smtp1 | > +---+ You could look at the pf I posted a couple of days ago, there is one slight problem with it and sending existing states, but everything else appears ok. http://archives.neohapsis.com/archives/openbsd/2005-12/1829.html You will also need to publish the address of the SMTP server on two different DNS server IPS, one reachable on the first connection, and one reachable on the second. This will ensure that when one connection fails you are still reachable. -- Regards, Ed http://www.usenix.org.uk - http://irc.is-cool.net :%s/Open Source/Free Software/g
Re: UDF - where are we ?
On Fri, Dec 30, 2005 at 08:37:30PM +0800, Uwe Dippel wrote: > file larger than 2 GB will show with wrong content and a negative size. This was fixed in 8/11, and made the stable tree on 1/12. -p.
piixpm0: timeout, status 0x1 AND iic0: addr 0x48 00=17 01=00 ... ...
Hello,
just FYI: I'm running -current on a dual-CPU HP Kayak-XAs 750 MT
with a ral PCI card and regularly get these 2 messages:
Dec 31 00:32:17 gate /bsd: Data modified on freelist: word 4 of
object 0xd151560
0 size 0x100 previous type devbuf (0xdeadbeee != 0xdeadbeef)
(is that coming from the ral card because I only have pci rev. 2.1 ?)
and (the Kayak's pcn is used for pppoe):
Dec 29 10:30:01 gate /bsd: pcn0: framing error
Dec 29 10:30:01 gate /bsd: pcn0: CRC error
But today (after a kernel update) I've also got
a lot of messages about "piixpm0: timeout":
Dec 26 20:49:28 gate /bsd: OpenBSD 3.8-current (GENERIC.MP) #7: Mon Dec 26
10:50
:42 CET 2005
Dec 26 20:49:28 gate /bsd:
[EMAIL PROTECTED]:/sys/arch/i386/compile/GEN
ERIC.MP
Dec 26 20:49:28 gate /bsd: cpu0: Intel Pentium III ("GenuineIntel" 686-class,
51
2KB L2 cache) 499 MHz
Dec 26 20:49:28 gate /bsd: cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTR
R,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
Dec 26 20:49:28 gate /bsd: real mem = 402227200 (392800K)
Dec 26 20:49:28 gate /bsd: avail mem = 359739392 (351308K)
Dec 26 20:49:28 gate /bsd: using 4278 buffers containing 20213760 bytes
(19740K)
of memory
Dec 26 20:49:28 gate /bsd: mainbus0 (root)
Dec 26 20:49:28 gate /bsd: bios0 at mainbus0: AT/286+(0f) BIOS, date 04/03/00,
B
IOS32 rev. 0 @ 0xfd7ac
Dec 26 20:49:28 gate /bsd: apm0 at bios0: Power Management spec V1.2
Dec 26 20:49:28 gate /bsd: apm0: AC on, battery charge unknown
Dec 26 20:49:28 gate /bsd: apm0: flags 30102 dobusy 0 doidle 1
Dec 26 20:49:29 gate /bsd: pcibios0 at bios0: rev 2.1 @ 0xfd720/0x8e0
Dec 26 20:49:29 gate /bsd: pcibios0: PCI IRQ Routing Table rev 1.0 @
0xfdf30/176
(9 entries)
Dec 26 20:49:29 gate /bsd: pcibios0: PCI Interrupt Router at 000:07:0 ("Intel
82
371FB ISA" rev 0x00)
Dec 26 20:49:29 gate /bsd: pcibios0: PCI bus #2 is the last bus
Dec 26 20:49:29 gate /bsd: bios0: ROM list: 0xc/0x8000 0xc8000/0x3800
0xcb80
0/0x4000
Dec 26 20:49:29 gate /bsd: ipmi at mainbus0 not configured
Dec 26 20:49:29 gate /bsd: mainbus0: Intel MP Specification (Version 1.4) (HP
XU/XW )
Dec 26 20:49:29 gate /bsd: cpu0 at mainbus0: apid 1 (boot processor)
Dec 26 20:49:29 gate /bsd: cpu0: apic clock running at 99 MHz
Dec 26 20:49:29 gate /bsd: cpu1 at mainbus0: apid 0 (application processor)
...skipping...
Dec 31 10:49:39 gate /bsd: pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4
I
SA" rev 0x02
Dec 31 10:49:39 gate /bsd: pciide0 at pci0 dev 7 function 1 "Intel 82371AB
IDE"
rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to
compatibilit
y
Dec 31 10:49:39 gate /bsd: pciide0: channel 0 disabled (no drives)
Dec 31 10:49:39 gate /bsd: atapiscsi0 at pciide0 channel 1 drive 0
Dec 31 10:49:39 gate /bsd: scsibus0 at atapiscsi0: 2 targets
Dec 31 10:49:39 gate /bsd: cd0 at scsibus0 targ 0 lun 0: SCSI0 5/cdrom removable
Dec 31 10:49:39 gate /bsd: cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
Dec 31 10:49:40 gate /bsd: uhci0 at pci0 dev 7 function 2 "Intel 82371AB USB"
re
v 0x01: apic 2 int 19 (irq 11)
Dec 31 10:49:40 gate /bsd: usb0 at uhci0: USB revision 1.0
Dec 31 10:49:40 gate /bsd: uhub0 at usb0
Dec 31 10:49:40 gate /bsd: uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1
Dec 31 10:49:40 gate /bsd: uhub0: 2 ports with 2 removable, self powered
Dec 31 10:49:40 gate /bsd: piixpm0 at pci0 dev 7 function 3 "Intel 82371AB
Power
" rev 0x02: SMI
Dec 31 10:49:40 gate /bsd: iic0 at piixpm0
Dec 31 10:49:40 gate /bsd: iic0: addr 0x48 00=17 01=00 02=2d 03=32 04=32 05=32
0
6=32 07=32 08=17 09=00 0a=2d 0b=32 0c=32 0d=32 0e=32 0f=32 10=17 11=00 12=2d
13=
32 14=32 15=32 16=17 17=32 18=17 19=00 1a=2d 1b=32 1c=32 1d=32 1e=32 1f=32
20=17
21=00 22=2d 23=32 24=32 25=32 26=32 27=32 28=17 29=00 2a=2d 2b=32 2c=32 2d=32
2
e=32 2f=32 30=17 31=00 32=2d 33=32 34=32 35=32 36=32 37=32 38=17 39=00 3a=2d
3b=
32 3c=32 3d=32 3e=17 3f=32 40=17 41=00 42=2d 43=32 44=32 45=32 46=32 47=32
48=17
49=00 4a=2d 4b=32 4c=32 4d=32 4e=17 4f=17 50=17 51=00 52=2d 53=32 54=32 55=32
5
6=32 57=32 58=17 59=00 5a=2d 5b=32 5c=32 5d=32 5e=32 5f=32 60=17 61=00 62=2d
63=
32 64=32 65=32 66=32 67=32 68=17 69=00 6a=2d 6b=32 6c=32 6d=32 6e=32 6f=32
70=17
71=00 72=2d 73=32 74=32 75=32 76=32 77=32 78=17 79=00 7a=2d 7b=32 7c=32 7d=32
7
e=32 7f=32 80=17 81=00 82=2d 83=32 84=32 85=32 86=32 87=32 88=17 89=00 8a=2d
8b=
32 8c=32 8d=32 8e=32 8f=32 90=17 91=00 92=2d 93=32 94=32 95=32 96=32 97=32
98=17
99=00 9a=2d 9b=32 9c=32 9d=32 9e=32 9f=32 a0=17 a1=00 a2=2d a3=32 a4=32 a5=32
a
6=
Dec 31 10:49:40 gate /bsd: 2 a7=32 a8=17 a9=00 aa=2d ab=32 ac=32 ad=32 ae=32
af=
32 b0=17 b1=00 b2=2d b3=32 b4=32 b5=32 b6=32 b7=32 b8=17 b9=00 ba=2d bb=32
bc=32
bd=32 be=32 bf=32 c0=17 c1=00 c2=2d c3=32 c4=32 c5=32 c6=32 c7=32 c8=17 c9=00
c
a=2d cb=32 cc=32 cd=32 ce=32 cf=32 d0=17 d1=00 d2=2d d3=32 d4=32 d5=32 d6=32
d7=
32 d8=17 d9=00 da=2d db=32 dc=32 dd=32 de=32 df=32 e0=17 e1=00 e2=2d e3=32
e4=32
e5=32 e6=32 e7=32 e8=17 e9=00 ea=2d eb=32 ec=32 ed=32 ee=32 ef=32 f0=17 f1=00
f
2=2d f3=32 f4
Re: problem fsckin' a usb disk on boot
>>> b h 31-Dec-05 04:05 >>> : > then, when I press RETURN and attempt to > > # fsck_ffs /dev/rsd0a > ** /dev/rsd0a > cannot alloc 36537985 bytes for typemap > # > > while dmesg also says I have: > > real mem = 1072472064 (1047336K) > avail mem = 972025756 (949244K) This message comes from setup() in /usr/src/sbin/fsck_ffs/setup.c, after it has performed a lot of other allocations. How big is the partition on this disk? How full is it? You probably do need to put more memory in the machine to fsck this disk. See FAQ 14.7 (http://www.openbsd.org/faq/faq14.html#LargeDrive), under "fsck(8) time and memory requirements". Thanks Tom
Re: UDF - where are we ?
On Fri, 30 Dec 2005 23:23:43 -0800, Jacob Meuser wrote: > but did it not mount the disc? njet. zero. > that's from sys/isofs/udf/udf_vfsops.c, and actually it's udf_mount:... > > that's not a message from a fatal error, it's just "informative". I *did* understand this. It was added for completeness of this report. No, my -t udf didn't mount it. The default mounts it properly, except for large files. It looks exactly like in that cited google post; like jumping to negative numbers at an integer overflow. I could live with the wrong size indication, but the content also is screwed. Anything below 2 GB is perfect. Have you tried with a large file ? I have been using it successfully, only yesterday I wanted to burn some 'dump'-images to DVD when the mess showed at my control mounts after burning. And I expected growisofs initially. Uwe
