Enzo Michelangeli wrote:
> Sorry folks, but I can't understand where the problem is supposed to be. The
> entropy of a pool is a measure of the information about its internal state
> that we don't know: which is why in thermodynamics the same name is given to
> the logarithm of the number of (invisible) microstates corresponding to an
> (observed) macrostate. Now: if we extract bits from the generator, we cannot
> gain insight over the internal state and its evolution, because on the path of
> a well-designed RNG there is a one-way function whose inversion is not
> computationally feasible. If we can't increase our knowledge of the internal
> state, the entropy of the pool is not depleted at all; in particular, we don't
> gain any information about the bits that the next requestor (i.e., the victim
> of the attack) will get.
>
> Am I missing something?
I think what you're missing is the (arguably appropriate) level of paranoia
that requires the design remain plausibly secure even if the one-way
function used is broken.
/dev/random uses SHA or MD5, so a complete break appears highly unlikely.
But a special-case break, say in circumstances where the input entropy is
temporarily exhausted so the attacker gets a look at N successive results
where the pool does not change, the only difference is the intial value
of the hash's internal variables? I don't think that's likely either,
but I've much less confidence that it is impossible.
If you want the thing to stand when the output hash breaks, you need
enough input entropy and a good mixing function.
