On Mon, 2014-01-20 at 08:50 -0500, Jeffrey Walton wrote:
> On Mon, Jan 20, 2014 at 8:33 AM, Ben Hutchings <b...@decadent.org.uk> wrote:
> > noloa...@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.
signature.asc
Description: This is a digitally signed message part
