> Well, it depends on what you mean by "freeze the pool". If you mean
> somehow make all writes to the memory silently fail, then you're right,
> you'll get constant output from /dev/random. But every time you read
> from /dev/random, it adds the current time to the pool, hashes the pool
> to produce some output, adds the outpuyt back into the pool, and
> returns half of the hash output. (Repeat as often as necessary to fill the
> number of bytes requested in the read.) Thus, reading alters the pool.
> The expected cycle length is something on the order of 2^2048, so
> the "periodic" part isn't a big concern.
if by 'current time' you mean the cycle counter, the value of it is pretty
much predictable. It adds no real entropy to the pool. Thus you over and
over again sample the pool, thus you will be able to follow it's state
more or less reliably.
the basic problem is that attackers are allowed to sample the pool at
unlimited speed. Provided that even a mediocre P5 can handle thousands of
read() requests per second, the information 'flux' should not be
underestimated.
This is just like those timing based DES attacks (delta-attacks), even
(limited!) timing information gives away too much of internal state. Such
unlimited output IMO basically gives away the whole internal pool.
> Not at all. First of all, notice what I said... just reading the pool is
> completely *harmless* unless you *do* something with the data that is read.
oh yes, an attacker does.
> All that someone can do is gather information to help them predict the
> future output, i.e. to guess what it's going to be. You have to read
> /dev/urandom and then put in a lot of hard thinking.
it's not 'reading once an MD5 hash'. It's 'reading it unlimited times'. Do
you consider this safe, especially as victims use the very same interface
to get 'random data' as well?
-- mingo