[lkml]   [2004]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH]
On Sun, Aug 08, 2004 at 11:38:46AM -0400, Jean-Luc Cooke wrote:
> In our paper (I'm testing the patch now) we'll be proposing using the Fortuna
> PRNG inplace of the current design. It only uses SHA256 and AES256 (or any
> message digest & block cipher combo). The primary advantages of this design
> would be:
> - It's simpler
> - It's faster
> - It doesn't "rool your own" crypto

SHA is not going to be faster than the cut-down MD4 --- and you can't
use a pure random sequence number for the initial TCP sequence number,
lest a packet from a previous TCP connection get mistaken as belong to
the newly created TCP stream. See Bellovin's recommendations for
secure TCP sequnce number genreation for a discussion of the

> If you pass all input data into a Yarrow-type PRNG - like the Fortuna PRNG
> we're going to propose - you will never care about this since the current
> state of the pools are always based on all the previous input.

The Yarrow-type PRNG suffers from the problem that the entropy pool is
pathetically small. It fundamentally assumes that the crypto checksum
is secure, and it is really much more of a *P*RNG than anything else.
The scheme used in the current /dev/random design is much closer to
that used by GPG, and relies on a large pool so that we can collect as
much entropy as possible from the hardware sources available to the
kernel. I'm not familiar with the Fortuna PRNG that you're going to
propose, but my guess is that it will have a similar, much heavier
dependence on the crypto algorithms in terms of its assumptions.

- Ted
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [W:0.045 / U:0.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site