Re: entropy bikesheds
> Can we decide this, please - do we want secure startup (which will > take some effort to achieve), or can we say "screw it" and start > insecure like the old system? Can we have both? Ie; by default we are insecure until some point we call an ioctl() that says 'no more, you must get real randomness now'. So, that way we can do the stuff that doesn't require real randomness (like mounting disks and such), and then once that's over with, the system forces it into 'secure' mode, at which time it's up to the user to supply some randomness for it. If that happens, a user could decide comment out the 'real secure' thing, and /dev/random would never block. You can all laugh at me now. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy bikesheds
> Start some kind of hardware-managed timer at the earliest possible > opportunity (perhaps start it in the boot loader!), then when you need to > pick up your first seed, read the timer's value and seed your random > generator from that. I have some much more sophisticated code (written by JHB) that does effectively this. It does it by hooking interrupt randomness, and by using the interrupts from your disk controllers (SCSI and IDE/ATA), a nicely fast reseed is gained. I'll happily commit it now, but I'd prefer a code review first, and is suspect that this will be better received once Jake's preemptive ithread code is committed. > The idea is to catch that timer at an unknown condition, and certainly the > computer is not going to boot in the exact same amount of time, every time > it's restarted. This would be especially true if the boot sequence gets > interrupted (to load another kernel perhaps) or the user forces the > machine into single-user mode while it's booting. All entropy harvesting uses some kind of harvesting. On i386, (Pentium and better) it is the TSC register. 80386 and 80486 use nanotime(9) and other CPUs have a TSC-like register. > In my hobby platform, it's common to start the timer, then grab a value > from it after the user hits a key after viewing some introduction screen. > The value grabbed is often used as the actual random number, but it could > be just as useful if used to seed a random generator. SOP :-) > If you're particularly paranoid, you set both timers for 32-bit mode, > start one first thing at startup, and the other when the user hits the > key, then read both of them the first time a random number is needed. > Seed your random generator from that, along with any other sources you can > (such as the video raster counter and the sound device's readable > oscillator, set to generate a noise waveform). Slight overkill, when the TSC register is already used and deliberately underestimated to improve randomness quality. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy bikesheds
Mark Murray <[EMAIL PROTECTED]> wrote: > Can we decide this, please - do we want secure startup (which will > take some effort to achieve), or can we say "screw it" and start > insecure like the old system? > > I'm happy to accomodate folks, but the constant lack of concensus > combined with extreme positions is wearing a bit thin. Although I'm not a coder on this platform, I do have an idea that we sometimes use on my hobby platform, maybe this might help... Start some kind of hardware-managed timer at the earliest possible opportunity (perhaps start it in the boot loader!), then when you need to pick up your first seed, read the timer's value and seed your random generator from that. The idea is to catch that timer at an unknown condition, and certainly the computer is not going to boot in the exact same amount of time, every time it's restarted. This would be especially true if the boot sequence gets interrupted (to load another kernel perhaps) or the user forces the machine into single-user mode while it's booting. In my hobby platform, it's common to start the timer, then grab a value from it after the user hits a key after viewing some introduction screen. The value grabbed is often used as the actual random number, but it could be just as useful if used to seed a random generator. If you're particularly paranoid, you set both timers for 32-bit mode, start one first thing at startup, and the other when the user hits the key, then read both of them the first time a random number is needed. Seed your random generator from that, along with any other sources you can (such as the video raster counter and the sound device's readable oscillator, set to generate a noise waveform). Just my two cents. -- ___ _ _ | _///@@@| | | [EMAIL PROTECTED] /'//ZZ@@| | | |'''/|'/@7 | | http://home.kscable.com/natedac |`'| `~~' | | | `| .--. | | C64/C128 - What's *YOUR* hobby? | `\|___\ | | \_ | | |___ \_| _| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy bikesheds
Doug Barton said: > Since this post actually has some content I'm moving it to > -current. Cool! > > Our /var isn't persistant accross boots, btw. It is a mfs file > > system. Having a requirement that /var contain persistant data would > > likely lead to problems. > > It's precisely for these, and other hairy examples that I haven't > put the thing in /var yet. Even a diskless workstation can read files from > a RO root that the host writes out periodically, but there is no guarantee > that there will be a /var filesystem that we can read from at boot time. I > actually started to write some code to handle some obvious cases and got a > major headache just thinking about it. What is needed is some form of persistant storage to stash the Yarrow state over a reboot or a crash. There are a number of people saying "Over my dead body can you put it ${HERE}!!", without coming up with alternatives that are useful. At BSDCon, the concept of using the first swap partition was discussed, and I think it is a great idea, but the volunteer has yet to offer any code. > > I'm still not sure why we can't do something like: > > > > date > /dev/random > > cat /bin/ls > /dev/random > > fsck > > mount the file systems > > read in the entropy file > > > > Eg, toss some bone to the random pool. Sure, it will be highly > > preditable, but for the mount commands it doesn't matter. We fix > > before anything interesting happens. Just as usable is "echo 'sekrit password' > /dev/random". Might as well not bother. There is no usable randomness here, so rather than pretending, it is better to simply admit to ourselves that the entropy generator is giving crap numbers at this point. I originally put a block-at-startup in precicesly because of this complaint. Remember that on a brand-new system, at first boot, the sshd is going to use /dev/random to make keys. How insecure do you want that? Can we decide this, please - do we want secure startup (which will take some effort to achieve), or can we say "screw it" and start insecure like the old system? I'm happy to accomodate folks, but the constant lack of concensus combined with extreme positions is wearing a bit thin. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy bikesheds
On Thu, 11 Jan 2001, David O'Brien wrote: > On Thu, Jan 11, 2001 at 03:00:35PM -0800, Doug Barton wrote: > > Since this post actually has some content I'm moving it to > > -current. > > > > On Thu, 11 Jan 2001, Warner Losh wrote: > > > > > I agree. RO / is absoultely *REQUIRED* for our application. > > > > As stated, all concerned are sympathetic to that. This is why it's > > configurable. > > > Not really -- specifying /var as the home of these files will not work > very well (as you even show why below). So things *appear* to be > configurable, but aren't. We're talking about the defaults only. There is nothing to prevent you from putting the entropy files in /my/blue/pony if that's where you really want them. I still need to splatter test the really obscure cases in /etc/rc, but our ultimate goal is for total configurability. Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy bikesheds
On Thu, Jan 11, 2001 at 03:00:35PM -0800, Doug Barton wrote: > Since this post actually has some content I'm moving it to > -current. > > On Thu, 11 Jan 2001, Warner Losh wrote: > > > I agree. RO / is absoultely *REQUIRED* for our application. > > As stated, all concerned are sympathetic to that. This is why it's > configurable. Not really -- specifying /var as the home of these files will not work very well (as you even show why below). So things *appear* to be configurable, but aren't. > The good thing about this ridiculous thread is that the next time > someone asks me if I've read the code, I can simply respond with, "No one > reads the code for my projects, even when I include the cvsweb links in my > head's up mail, so why should I be bothered?" I *did* read the diff you committed. So don't use that on me. ;-) > Do YOU Yahoo!? Yep! -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
entropy bikesheds
Since this post actually has some content I'm moving it to -current. On Thu, 11 Jan 2001, Warner Losh wrote: > I agree. RO / is absoultely *REQUIRED* for our application. As stated, all concerned are sympathetic to that. This is why it's configurable. > we have > a small, writable partition that we can use to store the random > entropy files. Any attempts to force / to be writable will be met > with extreme resistance. The good thing about this ridiculous thread is that the next time someone asks me if I've read the code, I can simply respond with, "No one reads the code for my projects, even when I include the cvsweb links in my head's up mail, so why should I be bothered?" > Our /var isn't persistant accross boots, btw. It is a mfs file > system. Having a requirement that /var contain persistant data would > likely lead to problems. It's precisely for these, and other hairy examples that I haven't put the thing in /var yet. Even a diskless workstation can read files from a RO root that the host writes out periodically, but there is no guarantee that there will be a /var filesystem that we can read from at boot time. I actually started to write some code to handle some obvious cases and got a major headache just thinking about it. > I'm still not sure why we can't do something like: > > date > /dev/random > cat /bin/ls > /dev/random > fsck > mount the file systems > read in the entropy file > > Eg, toss some bone to the random pool. Sure, it will be highly > preditable, but for the mount commands it doesn't matter. We fix > before anything interesting happens. I have a lot of sympathy for this idea, but I don't know if it would work for yarrow. Mark will have to weigh in on it first. FYI, the things rc does first (as needed) are below. / is already mounted RO at this point. 1. rc.diskless 2. source the *rc.conf* files 3. try seeding from /entropy 4. ccdconfig 5. vinum start 6. fsck 7. mount root RW (exit if this fails) 8. umount -a 9. mount -a -t nonfs For my money that's a fairly large number of things that could potentially break if I fooled around with the mount'ing order, so I felt that putting the default in /.entropy was a good way to get started with the minimum amount of real pain. Bikeshed pain I can deal with. One way to deal with this is to introduce a new variable that specifies the filesystem mount point that needs to be mounted to read the seed files. That way we could mount that fs RO, do the seeding, then unmount it and proceed with the rest of the steps from 4. on. I would need some advice on potential pitfalls here though, which is why I haven't acted on it yet. The one that leaps immediately to mind is am I getting myself into trouble by mounting a potentially dirty filesystem, even though it's RO? I know this is done with /, but I'd like someone with more fs experience to confirm that I won't be digging a hole for someone if they have some sort of funky /var/foo fs that I haven't heard of. Doug -- "The most difficult thing in the world is to know how to do a thing and to watch someone else do it wrong without comment." -- Theodore H. White Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message