Re: [PROPOSAL/PATCH 2] Fortuna PRNG in /dev/random

[Jean-Luc Cooke <jlcooke@certainkey.com>]

Why would we want to miss that when so much effort was made to meet the
requirements of the traditional /dev/random?  So...

Here's patch v2.1.2 that waits at least 0.1 sec before reseeding for
non-blocking reads to alleviate Ted's concern wrt waiting for reseeds.



When reading nbytes from /dev/{u}random, Legacy /dev/random would:
 - Mix nbytes of data from primary pool into secondary pool
 - Then generate nbytes from secondary pool

When reading nbytes from /dev/{u}random, Fortuna-patch /dev/random would:
 - Mix ??? of data from input pools into the AES key for output generation
 - Then generate nbytes from AES256-CTR

Perhaps I miss the subtlety of the difference in terms of security.  If
nbytes >= size of both pools - wouldn't Legacy also be vulnerable to the
same attack?

JLC

On Wed, Sep 29, 2004 at 03:31:17PM -0400, Theodore Ts'o wrote:
> While addition of the entropy estimator helps protect the Fortuna
> Random number generator against a state extension attack, /dev/urandom
> is using the same entropy extraction routine as /dev/random, and so
> Fortuna is still vulernable to state extension attacks.  This is
> because a key aspect of the Fortuna design has been ignored in JLC's
> implementation.