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?
Enzo
>===== Original Message From Ben Laurie <[EMAIL PROTECTED]> =====
>David Honig wrote:
>>
>> At 04:45 PM 7/17/99 -0400, John Denker wrote:
>> >Hi Folks --
>> >
>> >I have a question about various scenarios for an attack against IPsec by
way
>> >of the random number generator. The people on the linux-ipsec mailing
list
>> >suggested I bring it up here.
>>
>> >>..worries that /dev/random exhaustion -> DoS, and /dev/urandom -> PRNG
after
>> exhaustion..
>>
>> You are correct. There is no way around this, except to add a true RNG
>> to your server. With an open source OS, you can add this to the existing
>> /dev/[u]random code
>
>That isn't a way around it, that just gives you higher speed randomness.
>
>The obvious way to solve the underlying problem, as I've already said,
>is to use hashcash.
>
>Cheers,
>
>Ben.
>
>--
>http://www.apache-ssl.org/ben.html
>
>"My grandfather once told me that there are two kinds of people: those
>who work and those who take the credit. He told me to try to be in the
>first group; there was less competition there."
> - Indira Gandhi
