David S: to my knowledge you're at least somewhat incorrect, and part of your advice is rather dangerous to rely upon (from a cryptographic theory perspective).
/dev/urandom will never, under normal circumstances, block -- its output is generated algorithmically by the random/urandom device driver. (It's akin to reading from /dev/null or /dev/zero, in that the read is always handled by the kernel driver without having to wait for anything.) /dev/urandom will not block. /dev/random will block if there isn't enough entropy stirred into it. And yes, it is possible to "run out" the entropy pool. The amount of chaos that you stir in is the amount of chaos that you can pull out -- everything else is deterministic, and as the man page says there may be a theoretical way that the pseudorandom number generator can be attacked (though one is currently not known in the nonclassified literature) with the result that the keys generated will be predictable. If the pool is never seeded, the "randomness" won't ever be really random. If the pool is seeded once, the "randomness" will be random for as long as the amount of entropy in the seed holds out. After this, the numbers generated won't really be random. If the pool is continually re-seeded, the "randomness" will be random for as long as the amount of entropy in the seeds fed into it holds out. After this, the numbers generated won't really be random, until more entropy is stirred in -- and even then, that will be exhausted in the same way. The only way to guarantee that your numbers are truly cryptographically secure is to use /dev/random and deal with the fact that it will block until there's been enough entropy seeded into the randomness pool. Otherwise, many random number generators use a linear-feedback shift register with a periodicity of 2**56. That's approximately the same amount of keyspace as DES, and the output over multiple successions of readings of 2**56 bytes will repeat and not be suitably random. (If an attacker can figure out the state of your PRNG, the attacker can figure out your next-generated "secret" randomness. This is why the Debian debacle was so serious, and why only a few thousand possible keys were generated by the vulnerable implementations -- the randomness wasn't.) I'd certainly like to see references to the contrary, if they exist -- my references are the Handbook of Applied Cryptography and Applied Cryptography 2nd Ed. -Kyle H On Thu, Aug 7, 2008 at 2:13 AM, David Schwartz <[EMAIL PROTECTED]> wrote: > > David Shambroom wrote: > >> You're right: You are completely wrong. /dev/urandom never blocks. >> See the man page. > > Is this is the excerpt from the man page you are referring to? > > A read from the /dev/urandom device will not block waiting for > more > entropy. As a result, if there is not sufficient entropy in > the > entropy pool, the returned values are theoretically vulnerable to > a > cryptographic attack on the algorithms used by the driver. > Knowledge > of how to do this is not available in the current non-classified > liter- > ature, but it is theoretically possible that such an attack may > exist. > If this is a concern in your application, use /dev/random instead. > > If so, this doesn't say that /dev/urandom never blocks. It just says that it > will not block waiting for more entropy. In fact, this paragraph is horribly > misleading, because it suggests that the worst thing /dev/urandom can do is > return random values with a theoretical vulnerability. Alas, this is not > true. The /dev/urandom interface will happily return entirely predictable > values if the pool was never seeded. > > If the entropy pool was ever seeded, then it can produce > cryptographically-strong entropy forever. You cannot run it out of entropy. > However, if it was *never* seeded, it cannot produce even a single byte of > crypotgraphically-strong entropy. > > Reading back over the post you are responding to, I realize that it reads to > mean the complete opposite of what I was trying to say. I'm not sure how I > managed to do that. I was very sloppy with my terms. > > What I was trying to address was the case where the pool was never seeded, > not the case where the pool runs out of entropy. However, reading my words, > it seems I somehow said the exact opposite of what I was thinking! > > Sadly, Linux suffers from a three bears problem. The /dev/random > implementation will block even if cryptographically-strong randomness is > available. The /dev/urandom implementation will happilly hand you numbers > that are not cryptograhically-strong. There is no "just right" interface > that will tell you whether or not cryptographically-strong randomness is > available and let you block waiting for it if you choose to. > > DS > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
