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.

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