On Sun, 23 Jul 2000, Mark Murray wrote:
> > 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! :-)
The paper I was referring to was:
http://www.counterpane.com/pseudorandom_number.html
Cryptlib is described here:
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/
> > 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?
Inasmuch as the hash function has no timing attacks (data-dependent code
paths, etc) I don't see a weakness there. Chosen input attacks can be
mitigated by using a hash function which provides strong mixing (e.g.
SHA1), so there is no correlation between partially-known input and
output. Yarrow of course takes it a step further by using a very heavy
mixing function to regenerate the key, although it seems to me from the
design rationale that this is to remove correlations between the Yarrow
key before and after reseeding, which doesn't affect an unkeyed PRNG which
doesnt maintain state.
> > > 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.
Well, all of the others can be mitigated by resource limits. It's
something which needs to be revisited.
> 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.
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.
Kris
--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
