Mark Murray wrote:
> > 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
You argued successfully against using the old PRNG mechanism
but not against the blocking bit. What is your rationale for
not doing the blocking when the client actually wants a
guarantee that entropy is not being re-used?
> My solution is to get the entropy gathering at a high enough rate that
> this is not necessary.
What if you cannot guarantee that (and you cannot guarantee that
> 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).
Why would you if you can provide blocking with Yarrow?
Jeroen C. van Gelderen o _ _ _
[EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_)
_< \_ _>(_) (_)/<_ \_| \ _|/' \/
(_)>(_) (_) (_) (_) (_)' _\o_
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message