lkml.org 
[lkml]   [2004]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PROPOSAL/PATCH] Fortuna PRNG in /dev/random
On Mon, Sep 27, 2004 at 10:23:52AM -0400, Theodore Ts'o wrote:
> On Mon, Sep 27, 2004 at 12:50:33AM -0000, linux@horizon.com wrote:
> > > And the ring-buffer system which delays the expensive mixing stages untill a
> > > a sort interrupt does a great job (current and my fortuna-patch). Difference
> > > being, fortuna-patch appears to be 2x faster.
> >
> > Ooh, cool! Must play with to steal the speed benefits. Thank you!
>
> This is somewhat fundamental to the philosophical question of whether
> you store a large amount of entropy, taking advantage of the fact that
> the kernel has easy access to hardware-generated entropy, or use tiny
> pools and put a greater faith in crypto primitives.

Tiny in that at most you can only pull out 256bits of entropy from one pool,
you are correct. SHA-256 buffers 64 bytes at time. The transform requires
512 bytes for its mixing. The mixing of the 512 byte W[] array is done
serially.

random_state->pool is POOLBYTES in size. Which is poolwords*4, which is
DEFAULT'd to 512 bytes. The "5 tap" LFSR reaches all over that 512byte
memory for its mixing.

If page sizes get big enough and we page-align the pool[] member, the
standard RNG will get faster.

JLC
-
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:0.072 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site