On Wednesday, 19 September 2012 at 21:46, RW wrote: > extra bits may make the difference between secure and insecure I'm sorry, this may be a bit pedantic, but I have to object to the terms "secure" and "insecure" used without qualification. :) Perhaps you mean "predictable" and "unpredictable"? Believe it or not, this is a serious point rather than just nit-picking: there are all kinds of things that we might want to do with "random" numbers during boot, but not all of them require unpredictability in the face of an adaptive adversary. When generating a random MAC address (sys/arm/at91/if_ate.c:305), we don't need unpredictability, we just need per-machine uniqueness. When using a random delay to prevent things happening in cyclical lockstep (sys/kern/kern_synch.c:563), we don't even need that: we just need *some* things to get different delay values. So while cryptographic ("secure") randomness is always sufficient, it's not always necessary, especially in very simple machines that have a hard time harvesting entropy early in the boot process. This is part of why I'd like to see us move to a more descriptive API: - fuzz_value(range) - unique_value(range) - unpredictable_value(range) or something like that, instead of committing to particular algorithms (arc4random) or (in userspace) telling /dev/random to "get me some random, whatever that happens to mean". The implementation of each of these functions could start with "if I have a properly-initialised PRNG, use that", but for code that doesn't require true unpredictability, it might be good to just carry on booting with only-slightly-random numbers rather than wait for entropy estimates to hit the cryptographic threshold. But that's a discussion for another (future) thread. :) Jon -- Jonathan Anderson [email protected] (mailto:[email protected]) _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"