On Tue, Oct 05, 2004 at 11:27:05 +0200,
Marco Colombo <marco@esi.it> wrote:
> On Mon, 4 Oct 2004, Bruno Wolff III wrote:
>
> >You don't want to use /dev/random. You aren't going to get better random
> >numbers that way and blocking reads is a big problem.
>
> Sure you are. As far as the entropy pool isn't empty, /dev/random
> won't block, and thus there's no difference in behaviour.
/dev/random blocking is a huge problem.
> When you're short of random bits, /dev/random blocks, /dev/urandom
> falls back to a PRNG + hash (I think SHA1). Under these conditions,
> /dev/urandom output has 0 "entropy" at all: an attacker can predict
> the output after short observation provided that he can break SHA1.
We aren't worried about an attacker breaking SHA1 in this case because
we are just generating a seed for srandom which isn't cryptographically
secure. What you have to worry about is using so many values that
the nonrandomness is appearant. This will generally become appearant
after roughly 2^(number of bits in state / 2) samples. That isn't going
to happen when the /dev/urandom is being used to generate a seed.
> That is, anything that uses /dev/urandom (when the kernel pool is
> empty) is just as safe as SHA1 is.
SHA1 is pretty safe for this purpose. The recent weaknesses of related
hashes isn't going to be of much help in predicting the output of
/dev/urandom. If SHA1 were to be broken that badly /dev/random would
also be broken.
The reason to add in entropy is protect against your state having been
leaked once and having an attacker be able to always be able to know
what the next output is going to be without having further access to
the state. I don't believe the way linux mixes in entropy protects
against this attack. If you mix in too little entropy between output
values you can figure what entropy was added by going through all
possible entropy values and seeing which one gives the expected output.
(This assumes that you have gotten a copy of the internal state at
some point.) My memory of looking at the /dev/[u]random code is that
there is just one entropy pool and entropy is added to it as it is
obtained. So that if values are obtained from /dev/[u]random at a high
enough rate the above attack is practical.
So the only case where you might want to use /dev/random over /dev/urandom
is where the internal state is vunerable, the attacker has access to a large
fraction of the output values and where there are at least some gaps between
samples where large amounts of entropy are collected.
