[PATCH]

[Jean-Luc Cooke]

Glad to have you join the discussion Ted!

On Sat, Aug 07, 2004 at 06:26:34PM -0400, Theodore Ts'o wrote:
> On Fri, Aug 06, 2004 at 08:54:27AM -0400, Jean-Luc Cooke wrote:
> > That and it's not endian-correct.  There are other issues with random.c (lack
> > for forward secrecy in the case of seed discovery, use of the insecure MD4 in
> > creating syn and seq# for tcp, the use of halfMD4 and twothridsMD4 is
> > madness
> > (what is 2/3's of 16!?!), 
> 
> This was deliberate becasue sequence number generation could not be
> slow for some workloads.  The sequence number attacks that MD4
> protects against are tcp hijacking attacks where the attacker is on
> the network path ---- if you really want security you'd be using real
> crypto for encryption and for integrity protection at the application
> layer.

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

> > the use of LFSRs for "mixing" when they're linear,
> > the polymonials used are not even primitive, 
> 
> The basic idea here is that you can mix in arbitrary amounts of zero
> data without destroying the randomness of the pool.  This is
> important, and was an explicit design goal.

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 ability for root to wipe-out
> > the random pool, the ability for root to access the random seed directly, the
> > paper I'm co-authoring will explain all of this).
> 
> Yawn.  Root has access to /dev/mem.  Your point?

I guess the point I was trying to make was:
 - You never want to wipe out the pool
 - You never want to let people (not even yourself) get access to the pool
   The closest thing you can do (and the paper will explain this) is hash
   a counter and the data from each of your pools though a message digest
   and concatenate it together.

I'm really putting the horse infront of the cart here.  We'll put a paper up
for lkml to read by the end of the month which will fully explain:
 - Our reasoning
 - Our goals
 - Our results

Cheers,

JLC