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]
