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

Jean-Luc Cooke
2004-09-29T20:31:58Z

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.