3 ms·
> under load a system using /dev/random might block The most interesting thing I've learned from this discussion is a comment of Dan Bernstein's, quoted by the
by ScottBurson 13y ago
> under load a system using /dev/random might block
The most interesting thing I've learned from this discussion is a comment of Dan Bernstein's, quoted by the OP:
> Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that
> (1) we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but
> (2) we _can_ figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.).
> For a cryptographer this doesn't even pass the laugh test.
If I understand this correctly, what DJB is saying is that the idea that reading random numbers from /dev/[u]random decreases the amount of entropy in the pool is ludicrous. So the real bug here is that: once the pool reaches a threshold level of entropy, even /dev/random should never block again, because the entropy in the pool is not decreasing.
- tptacek 13y agoYes, this is correct.
- ScottBurson 13y agoGreat! Let's follow it to its logical conclusion: () There should be only one kernel PRNG device () It should be seeded from keyboard presses, mouse movements, etc. (i.e. real entropy sources) at OS installation time (if there's a persistence mechanism) or at boot time (if there isn't) () If called before being seeded, it should hang, but in practice this should never happen () It should never hang thereafter () If we accept DJB's argument that adding entropy later can be harmful (and since we've already agreed it's unnecessary), we shouldn't do it () There should be a standard protocol by which a freshly cloned VM can be told it needs to reseed So, how do we convince the kernel devs of this, and put an end to this whole argument?
- tptacek 13y agoI don't think that's the only logical conclusion one can come to after reading DJB. Periodically rekeying has the beneficial effect of adding some forward secrecy to your RNG, so losing the state once doesn't necessarily permanently bone you. People are working on a better Linux random driver.
- dlitz 13y agoThank you for being sane about this. Do you know if those folks are working on making /dev/random faster*? I'd really like to see even traditionally "non-cryptographic" RNG's (e.g. rand()) just use the kernel's CSPRNG.