On Sat, Sep 06, 2003 at 08:14:40PM +0100, David Laight wrote:
> My gut feel is that the SHA based PRNG in rnd(8) is open to certain types of
> attack (because it feeds the hash output back into the data to be hashed).

What kinds of attack? I can guess you're worried about two possibilities.

1) the user can learn something about what is stirred back into
the pool from what they read from /dev/random

The data given to the user is xor-folded in half before being
returned, and so the user doesn't learn anything useful about the
unfolded hash we stirred back in, and in any case the stirring
depends on other unknown bits in the pool.

2) The data being stirred into the pool reflects the pool contents
only, and so some sort of cycle could emerge.

I had thought that we stirred a timestamp back in each time, too,
but I just checked and this only happens when we don't yet have
initial entropy.  It might be worth considering putting one in this
loop.  In either case, such cycles would be long, and the random vs
urandom distinction is there for when you worry about such
possibilities.

> Interestingly, if the code just added in another 512 bytes of non-random
> data into the hash, then the new output would be secure!

Even if this data were fixed or known?  I don't see this buying
much *over what we do now*, but it gives me a clue that your gut feel
was about case 1, above. It's a different way of making the returned
data be different to what was stirred back in, but that's already
covered.

> After all, given the SHA hash it is compuationally infeasible to create
> the original data - so it doesn't matter what you add.
> This actually means that once the generator has enough entropy, it cannot
> actually start generating non-random numbers.

Yes, that's the basic argument, but the estimator is there for
those who don't choose to trust that argument.

> Of course, if you can read /dev/mem you can find the current state.

Yeah :-(

--
Dan.