> Mark already stated that in *practicality*, Yarrow-BF-cbc-256 1.0
> (I guess that's the proper name for this :-) is complex enough and
> generates good enough ouput.  If you /really/ want to make the attack
> on it much harder, how about this: if you're going to read 1024 bits
> of entropy from Yarrow on /dev/random, you will request it all at once
> and block just as the old random(4) used to block; the blocking can
> occur at 256 bit intervals and sleep until there is a reseed.  Waiting
> to reseed for each read will ensure a much larger amount of "real"
> entropy than it "maybe" happening at random times.

This is a reversion to the count-entropy-and-block model which I have
been fiercely resisting (and which argument I thought I had sucessfully

My solution is to get the entropy gathering at a high enough rate that
this is not necessary.

I also agreed to _maybe_ look at a re-engineer of the "old" code in a
secure way if a decent algorithm could be found (I am reading some
papers about this ATM).

Mark Murray
Join the anti-SPAM movement: http://www.cauce.org

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to