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

Bug#736126: Processed: Re: Bug#736126: /dev/random entropy depletion on a fresh install



On Mon, Jan 20, 2014 at 8:33 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
> noloader@gmail.com wrote:
>> I installed Debian 7.3 x64 on a Core i5 laptop for some testing (real
>> hardware, not a VM). When testing a program I wrote, I noticed it was
>> not getting the full number of bytes requested from /dev/random:
>>
>>     unsigned char buffer[32];
>>     fd = open("/dev/random", O_RDONLY | O_NONBLOCK);
>>
>>     rc = (int)read(fd, buffer, sizeof(buffer));
>>     assert(rc == sizeof(buffer));
>>
>>     RAND_add(buffer, sizeof(buffer), 1.0f);
>>     OPENSSL_cleanse(buffer, sizeof(buffer));
>>
>> The assert fired on nearly every run, including the first run when no
>> previous calls were made by the test program. The number of bytes
>> returned varied, but they included 7, 12, 16, and 19. That's really
>> bad for a request of 32 bytes, and it would be catastrophic for a
>> request of 128-bytes or 256-bytes for a long term private key.
> [...]
>
> This is catastrophic only if people don't RTFM about read().  Yes, it
> can return a short length.  You must call it again if you want more.
> (This doesn't normally happen with regular files, although it will if
> you specify a length >= (1U << 31).)
The root cause of the failure is the system, not the programmer or
user. Read performed as expected, but the problem was with the device.
The device could not provide a trivial number of bytes at the time of
the request.

Asking the programmer or user to recover from the system's short
comings is simply passing the buck, weakening security, and hurting
users.

To play devil's advocate: how can Debian ensure that bytes are
available under most use cases?

a) provide an entropy gatherer so depletion almost never happens
b) tell the programmer to RTFM and block on the device
c) tell the programmer to RTFM and accept fewer bytes
d) tell the programmer to RTFM and repeatedly call read
e) tell the user to RTFM, audit source code, and reject deficient source code
f) tell the user to RTFM and and install an entropy gatherer so
depletion almost never happens

Which seems like the best choice here?

Jeff


Reply to: