I'm sorry -- my comment was to David Schwartz (I realized both of you were named David, but failed to realize that you also had a surname that started with S).
-Kyle H On Thu, Aug 7, 2008 at 11:44 AM, David Shambroom <[EMAIL PROTECTED]> wrote: > Kyle, > > I didn't say that /dev/urandom was safe to use for cryptographic purposes. > It isn't, and I didn't then and don't now advise its use. I said it never > blocks. It doesn't. So what was incorrect? > > Kyle Hamilton wrote: >> >> 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 openssl-dev@openssl.org >>> Automated List Manager [EMAIL PROTECTED] >>> >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> Development Mailing List openssl-dev@openssl.org >> Automated List Manager [EMAIL PROTECTED] > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
