On Fri, Aug 22, 2003 at 07:43:45AM -0400, Greg Troxel wrote:
> I would also suggest reading the Yarrow paper:
> 
>   http://www.counterpane.com/yarrow.html
> 
> I haven't gone over this in painful detail, but the arguments about
> iterative guessing attacks deserve serious consideration; I think
> rnd(4) does not address those at the moment.

It's been a while since I read it, especially from the point of
view of looking at the threats.   Several people have looked at
yarrow, however noone has yet done the work to implement it.

Another, related, idea was to use something like yarrow or arc4random
as the generator for /dev/urandom, periodically reseeding from the
pool as necessary. This was mostly for speed and to prevent the
estimator deciding the pool was "empty" so often, when you have a
high rate consumer of non-critical randomness. Again, noone has
yet done that work.

> rnd(4) seems a bit schizophrenic about whether it trusts things like
> hash functions or not.

How so, other than the estimator? (which is hopelessly bogus, but
at least can't be any less paranoid than a user asking for /dev/random
data).

> Producing more PRNG bits than input entropy
> can be reasonable if the hash or other cryptographic construction is
> sound.  This might be less problematic than the typing-rate attacks or
> problems due to running out of entropy.

The typing rate attacks don't really apply to NetBSD rnd(4); samples
aren't stirred into the pool immediately (in device interrupt
context); rather they're queued and added in batches later. So
users can't watch the entorpy estimator and infer information about
typing.

> If SHA-1 and AES are no good,
> most users of rnd(4) will be deeply scrod anyway.

Oh yes, and for reasons that have more to do with their use of
those algorithms in places other than rnd(4).

--
Dan.