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
> defended).
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
in practice)?
> 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?
Cheers,
Jeroen
--
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
