In article <DHEtE6.FB6@sgi.sgi.com>, Mark Murray <mark@grondar.za> writes:

...

? "Gut feel" suggests to me that large ammounts of "predicted" input might be worse than the normal sort of system noise you have been using.

But keep in mind that what we're doing is XOR'ing the input data into the pool. (Actually, it's a bit more complicated than that. The input is XOR'ed in with a CRC-like function, generated by taking an irreducible polynomial in GF(2**128). But for the purposes of this argument, you can think of it as XOR.) So since you don't know what the input state of the pool is, you won't know what the output state of the pool.

I chatted with a colleague at work, and he helped bend my mind right. I had the mistaken notion that adding lots of data would "overflow" and "dilute" the entropy to an attackable state.

I think the problem is not merely flooding the device with non-random input data. If you coordinate sucking out entropy with feeding in non-random data you can suck the real entropy in the system down to zero while making the driver think it has plenty of randomness. While it's not clear to me how this would lead to an attack, it would be worrisome. -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw@engr.sgi.com