Kris Kennaway wrote:
>
> On Sun, 23 Jul 2000, Mark Murray wrote:
>
> > > > > This design tradeoff is discussed in section 4.1 of the paper.
> > > >
> > > > Tweakable.
> > >
> > > Doing a reseed operation with every output is going to be *very*
> > > computationally expensive.
> >
> > Tradeoff. What do you want? Lightning fast? Excessive security? Balance
> > it out.
>
> Thinking about it further, I dont think Yarrow can even do this (introduce
> entropy into every output value) without bypassing the block cipher.
Why not?
> And
> if you reseed with every 256 bits of output then you're vulnerable to an
> iterative guessing attack because the fast pool won't have much in it.
You would block until the pool is filled with entropy.
[...]
> There are two other models which rate "pretty well-designed" in the Yarrow
> paper: the cryptlib and PGP PRNGs. I don't know what their properties are
> right now (the cryptlib one is described in the paper on PRNG
> cryptanalysis).
Fortunately you don't need them :-)
> > I'll relent somewhat if a secure entropy distilling algorithm could be
> > found; one which stands up to crypanalysis.
>
> Well, a simple scheme which doesn't seem to suffer from any of the
> vulnerabilities discussed in the schneier papers is to accumulate entropy
> in a pool, and only return output when the pool is full. i.e. the PRNG
> would either block or return 0 bytes of data, or a full pool's worth.
And you can make Yarrow do just that. Not very practical but
you can do it. You effectively set Pg to 1/(2^(k/3)).
> > Will you relent a step or two if I can get the entropy harvesting _rate_
> > high enough? :-)
>
> If we get the entropy pools filling fast enough that the reseed is
> triggering close to every 256 bits of output then it becomes much less of
> a concern (but it's still there, because reseeding happens asynchronously
> with respect to PRNG output).
Reseeds do not *have* to happen asynchronously as pointed out
above. What is of importance is that you *cannot* forcibly
trigger a reseed without there being enough entropy in the
pools. There is nothing against having /dev/random block
until the pools have accumulated enough entropy.
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
