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
hand.
> > 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.
Cheers,
Jeroen
[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
