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?

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

Reply via email to