[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: /dev/random for FreeBSD [was: Re: /dev/random for Linux]

Tom Weinstein writes:
>In article <[email protected]>, Mark Murray <[email protected]> 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.