Mark Murray wrote:
> > > Asynchonous reseeding _improves_ the situation; the attacker cannot force
> > > it to any degree of accuracy, and if he has the odds stacked heavily against
> > > him that each 256-bits of output will have an associated reseed, it makes
> > > his job pretty damn difficult.

This is not correct for a variety of reasons. But that's all 
fairly theoretical and ... not relevant for the discussion at 

> > What I meant with that point is that the user may get, say an extra few
> > hundred bits out of it with no new entropy before the scheduled reseed
> > task kicks in.
> How does he know which bits are which? His analysis task just got a whole
> lot more difficult.

Again, not entirely correct but not relevant either...

Kris is simply right in that the /dev/random semantics change 
and that more bits can be output by Yarrow than there is entropy 
gathered. *In theory* the complexity of an attack on our Yarrow 
has an upper bound of 2^256 and *in theory* this is less than 
the complexity of an attack on our current /dev/random. This is 
a hard fact, no way around that.

However, the big question here is not about theory but about
*practicality*. Is Yarrow less secure than /dev/random in 
practice? How does our /dev/random hold up under attack? How 
does Yarrow compare? I think we need to evaluate these practical
questions instead of deep theoretical issues as Yarrow is all 
about practicality.

At a more fundamental level we will need to answer the question:
"Do we need to preserve the current /dev/random semantics or 
can we decide to change 'em? [1]". And how will this affect our
applications *in practice*.

So let's concentrate this discussion on the practical issues
and explain why you think backing /dev/random with Yarrow and
changing the semantics is justifyable or even a good thing.


[1] And, should we decide not to change /dev/random semantics,
    can we still back /dev/random with a modified 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