Messages in this thread | | | Date | Wed, 29 Sep 2004 16:27:07 -0400 | From | Jean-Luc Cooke <> | Subject | Re: [PROPOSAL/PATCH 2] Fortuna PRNG in /dev/random |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |