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]
