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
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
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
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
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
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
