Re: Fortuna

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

On Fri, Apr 15, 2005 at 10:42:16AM -0400, Theodore Ts'o wrote:
> > Just to be clear, I don't remember it ever throwing entropy away, but
> > it hoards some for years, thereby making it effectively unavailable.
> > Any catastrophic reseeding solution has to hold back entropy for some
> > time.
> 
> It depends on how often you reseed, but my recollection was that it
> was far more than years; it was *centuries*.  And as far as I'm
> concerned, that's equivalent to throwing it away, especially given the
> pathetically small size of the Fortuna pools.

"pathetically" is an interesting term to call it.  256 bits is the most any
one of the 32 pools can hold, true.  And the n-th pool is used only once
every 2^n times (where the first pool is the 0-th pool, hence it's used
everytime).

2^31 * 0.1s reseeds, mean the 31st (aka. last) pool will be drawn from once
every 6.8 years.

And the argument that "random.c doesn't rely on the strength of crypto
primitives" is kinda lame, though I see where you're coming from.  random.c's
entropy mixing and output depends on the (endian incorrect) SHA-1
implementation hard coded in that file to be pre-image resistant.  If that
fails (and a few other things) then it's broken.

Fortuna depends on known cipher-text attacks on the cipher in use (in this
case AES-256) and the digest algo in use (in this case SHA-256) to be
pre-image resistant.  Cryptographers like reducing things to known
quantities, it may be flaw.

Once I set some personal things sorted out I'll take another crack at making
/dev/fortuna with it's claws in random.c to feed it some of that entropy as 
linux@horizon.com suggested.

JLC