lkml.org 
[lkml]   [2004]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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    [W:1.534 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site