> > The acknowlegment that I am looking for is that the old, simple "gather
> > entropy, stir with hash, serve" model is inadequate IMO, and I have not
> > seen any alternatives.
>
> 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).
Do you have copies of the articles concerned? I'd surely appreciate
a photocopy of the relevant pages if you don't mind! :-)
> > 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.
Hmm. Timing attacks? Known-input attacks?
> > 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). However I think that in practice this will
> be too heavy on the CPU (unless we weaken the reseed operation) and make
> dd if=/dev/urandom of=/dev/null a very effective local user DoS :-(
The dd if=/dev/urandom of=/dev/null is _already_ a doozy of a dos. Likewise
a fork-bomb, a /tmp-filler, likewise a whole bunch of things much worse.
Heck, you can hurt your system with cat /dev/zero > /dev/null.
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.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
