[42809] in Cypherpunks
Re: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
daemon@ATHENA.MIT.EDU (Scott Brickner)
Fri Nov 3 13:20:51 1995
To: tomw@cthulhu.engr.sgi.com
Cc: cypherpunks@toad.com
In-Reply-To: (Your message of Thu, 02 Nov 1995 09:47:18 PST.)
<199511021747.JAA08919@orac.engr.sgi.com>
Date: Fri, 03 Nov 1995 12:05:46 -0600
From: Scott Brickner <sjb@universe.digex.net>
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.
