GnuPG PRNG insecure?

[Stefan Keller]

On Fri, Feb 08, 2002 at 07:10:18PM +1300, Peter Gutmann wrote:

> It's a pretty accurate analysis.  The flaw is worrying, but not fatal, since
> (assuming it accurately implements the design in
> http://www.cryptoapps.com/~peter/06_random.pdf) the output is only taken from
> the mixed input of a significant portion of the pool, ie 640 bits of pool data
> are used for each output block.  

I've just read your excellent paper (wish I had access to it / read it
beforehand).
Mind it to explain why the flaw is not fatal?
As I explained, on non /dev/random (or equivalent) systems there are often *much*
more bytes put into the pool than requested. As soon as 2*POOLSIZE bytes have
been put into the pool, the entropy collected with the first POOLSIZE bytes is
lost. (Things would be different if GnuPG was keeping some state information of
the previous pool mixing operation, such as the last digest computed or the
whole hash buffer.)
So if those last POOLSIZE bytes happen to contain zero entropy (or a very small
amount), it doesn't matter how the output is generated; it will not contain very
much randomness, and thus might be easily guessable by an attacker.
However, I don't know if this does really happen. I don't know how many bytes
e.g. the slow_gatherer in rndw32.c really puts out, but if it happens to be much
more than POOLSIZE, the quality of the PRNG solely depends on the last POOLSIZE
bytes collected.
Unless, of course, I completely misunderstood things.

-- 
Stefan Keller <dres at cs.tu-berlin.de>