On 2025-03-15 at 02:49:18, Ramsay Jones wrote:
>
> Commit 05cd988dce ("wrapper: add a helper to generate numbers from a
> CSPRNG", 2022-01-17) added a csprng_bytes() function which used one
> of several interfaces to provide a source of cryptographically secure
> pseudorandom numbers. The CSPRNG_METHOD make variable was provided to
> determine the choice of available 'backends' for the source of random
> bytes.
>
> Commit 05cd988dce did not set CSPRNG_METHOD in the Linux section of
> the config.mak.uname file, so it defaults to using '/dev/urandom' as
> the source of random bytes. The 'backend' values which could be used
> on Linux, in order of preference, are 'arc4random', 'getrandom' or
> 'getentropy' ('openssl' is an option, but seems to be discouraged).
>
> The arc4random routines (ar4random_buf() is the one actually used) were
> added to glibc in version 2.36, while both getrandom() and getentropy()
> were included in 2.25. So, some of the more up-to-date distributions of
> Linux (eg Debian 12, Ubuntu 24.04) would be able to use the preferred
> 'arc4random' setting.
>
> If the meson build system is used on a newer platform, then they will be
> configured to use 'arc4random', whereas the make build will currently
> default to using '/dev/urandom'. Add a note to the config.mak.uname file,
> in the Linux section, to prompt make users to override CSPRNG_METHOD in
> the config.mak file, if appropriate.
arc4random operates differently on Linux than it does on the BSDs, and
the right choice on Linux is `getrandom`.
The reason is that on the BSDs, a userspace ChaCha20 which is seeded
from the kernel is used, along with an integer representing whether it's
inititalize, and this state is stored in a page that is zeroed on fork,
so that it automatically becomes uninitialized then (and is hence
reseeded). Because it is in userspace, it avoids the overhead of a
syscall, and is thus usually faster. arc4random has also been around
longer than getrandom or getentropy on the BSDs and is widely supported
there, and so it's generally the right choice (and hence, the default).
When arc4random was added to glibc, the Linux kernel CSPRNG maintainer
argued that it was not a secure approach (I disagree), and convinced the
glibc maintainers to just make it a wrapper around the Linux kernel
CSPRNG, which it now is. So there's no actual benefit to calling
arc4random versus getrandom, and since it's newer and less commonly
available than getrandom, as well as slightly slower (because of an
extra function call), getrandom should be preferred.
All Linux distros within our current support window have glibc 2.25 or
newer (RHEL 8 being the oldest one), so we may want to just default to
getrandom on Linux.
--
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
