lkml.org 
[lkml]   [2004]   [Sep]   [29]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateWed, 29 Sep 2004 16:27:07 -0400
FromJean-Luc Cooke <>
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:06    [from the cache]
©2003-2008