Greg Hudson wrote:
> As for the second threat, at least on Linux, /dev/random output still
> comes from the PRNG. It just keeps an internal counter and blocks when
> the PRNG has "run out of" its guess at estimated input entropy. (This
> is exceedingly silly, because a PRNG doesn't "use up" input entropy as
> it generates results; either it has unguessable internal state or it
> doesn't.)
Why would that be? When someone dumps in 20 bits of data from a
strong, in-hardware, random number source, even if the PRNG is utterly
stupid, it can have an unguessable 20 bits of internal state. After
reading enough random numbers, I will have enough information to guess
the seed and learn what comes next.
A good PRNG helps mitigate that somewhat, of course (especially if
unfriendly people doesn't have access to the entire random number
stream and information about when it was seeded).
More practically speaking, the benefit of /dev/random's entropy
accounting on Linux is to annoy people enough to get them to find a
good source of random data. When I am generating a PGP key, I am
grateful for the notification. Less so when picking a nonce for svn
access. Another downside of using either /dev/random or /dev/urandom
is that it involves revealing information about the random number
state, which could hurt the security of other applications if there is
not enough entropy.
Received on 2011-11-03 22:11:34 CET