From: tomw@orac.engr.sgi.com (Tom Weinstein)
Date: Fri, 3 Nov 1995 03:10:50 +0800
To: cypherpunks@toad.com
Subject: Re: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
In-Reply-To: <DHEtE6.FB6@sgi.sgi.com>
Message-ID: <199511021747.JAA08919@orac.engr.sgi.com>
MIME-Version: 1.0
Content-Type: text/plain


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