On Mon, Feb 20, 2012 at 12:42 PM, Solar Designer <[email protected]> wrote: > On Sun, Feb 19, 2012 at 05:57:37PM +0000, Ben Laurie wrote: >> In any case, I think the design of urandom in Linux is flawed and >> should be fixed. > > Do you have specific suggestions? > > Short of making it block, I can think of the following: > > 1. More distros may follow the suggestion in the "Ensuring > unpredictability at system startup" comment in drivers/char/random.c > (save previously accumulated entropy in a file on shutdown, restore it > from the file on bootup). > > 2. The kernel may mix in hardware serial numbers, MAC addresses, etc. > into the initial entropy pool. Drawback: if this turns out to be > insufficient entropy anyway (such as if some of it is correctly guessed > by an attacker), these numbers may then be inferred back from the > "random" numbers. BTW, this same risk currently applies to system time > at bootup and even to further stuff added to the pool (even keystroke > timings and keystrokes themselves), but perhaps we're assuming that > either there's sufficient entropy that those won't be inferred or if the > system time is the only entropy, then having it inferred is not the > biggest of our worries. > > These tradeoffs are not really specific to Linux. Sure, you can make > urandom block, but that's also a tradeoff.
In FreeBSD random (and hence urandom) blocks at startup, but never again. One thing I'd really like to know is whether it would have ever unblocked on these devices - and if it does, whether it ends up with good entropy... _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
