Tom Weinstein writes:
In article <DHEtE6.FB6@sgi.sgi.com>, Mark Murray <mark@grondar.za> writes:
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.
You need a similar "mind bending". "Feeding in non-random data" doesn't lead to the driver thinking it has "plenty of randomness" left, since it doesn't increase the entropy level to counteract the decrease from the entropy-sucker. The hard part would be having the driver figure out how much entropy it's getting from the input. "Non-random" implies some sort of correlation between the bits. I can't think of any way of measuring that which doesn't make some sort of "horizon" that a malicious user can confuse. The simple mechanism would be to assume that input from untrusted users adds no entropy, forcing entropy estimates to represent a lower bound.