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

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

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.