This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add getrandom implementation [BZ #17252]
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Florian Weimer <fweimer at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Sat, 11 Jun 2016 13:10:12 -0700
- Subject: Re: [PATCH] Add getrandom implementation [BZ #17252]
- Authentication-results: sourceware.org; auth=none
- References: <20160610210303 dot 6CE3E40141175 at oldenburg dot str dot redhat dot com> <alpine dot DEB dot 2 dot 20 dot 1606102115300 dot 20503 at digraph dot polyomino dot org dot uk> <c176ad09-538f-697c-e1e7-a745364f059e at redhat dot com>
On 06/11/2016 04:13 AM, Florian Weimer wrote:
programmers do not check for error returns from random number
generators. Based on that, I concluded it was important to provide an
implementation which cannot fail.
Yes, as an app developer I prefer primitives like OpenBSD arc4random_buf
that are always successful. In contrast, Linux getrandom (BUF, LEN, 0)
is guaranteed to succeed only when called with LEN <= 256, which is good
enough for hash nonces but not for general-purpose use.
Implementing arc4random has both libc aspects (providing thread safety
and invalidating the internal state around clone/fork) and
cryptographic aspects (for performance reasons, it has to be a
deterministic random bit generator, and use the kernel for seeding
only). I think the cryptographic aspect dominates, which is why it is
difficult to implement arc4random as part of glibc.
Sorry, I don't understand. What's the difficulty? Why can't glibc
implement the cryptographic aspect of arc4random_buf via an internal
deterministic random bit generator? Can't glibc borrow a bit generator
from Internet RFC 7539, or from GNU Coreutils, or whatever?