On Mon, 2014-01-20 at 08:50 -0500, Jeffrey Walton wrote:
> 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.
Calling functions without reading what they do, then complaining that
they didn't meet your expectations, is passing the buck, weakening
security, and hurting users. (See I can play that game too.)
> To play devil's advocate: how can Debian ensure that bytes are
> available under most use cases?
I don't think that phrase means what you think it means.
> 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?
(a) *and* (d). You *must* *always* check for short reads.
Ben.
--
Ben Hutchings
One of the nice things about standards is that there are so many of them.
Attachment:
signature.asc
Description: This is a digitally signed message part