Entropy-supplying system calls

Traditionally, Unix-like operating systems supply random data through two pseudo-devices: /dev/random and /dev/urandom. However, safely and reliably reading random data from these devices can be difficult and complicated. For example, an attacker could interfere with a process's access to the pseudo-devices by opening all available file descriptors, or through a similar form of resource exhaustion attack. The use of these devices also interferes with privilege revocation. Unprivileged processes are often denied the ability to open and read files and devices, and the randomness devices are not even visible to chrooted processes.

The difficulty of using randomness pseudo-devices often leads developers to use standard library functions instead. Some of these, such as the C programming language's rand(), POSIX's random(), and drand48(), are very unsafe when used for cryptography or similar applications, because these algorithms are actually deterministic, having been intentionally crippled to satisfy seed-reuse requirements through the interfaces srand(), srandom(), and srand48().

A significant difference exists between these calls: getentropy() guarantees that random numbers will be returned immediately, without any blocking. It requires operating support which guarantees random data stream initialization at the earliest opportunity. To encourage other operating systems follow this model, getentropy() cannot indicate errors to the application. Other calls described here may return errors instead, or block indeterminately. Such blocking semantics have been implicated in significant problems.[6]

As security becomes a more widespread priority in software development, quality randomness is used more often and in more contexts. Because of this, providing quality randomness is increasingly considered a core responsibility of the kernel. System calls are the traditional interface through which a process uses core kernel services, and kernels are therefore supporting accessing randomness through system calls.

Because it is faster and adds another layer of entropy mixing, it is usually suggested that processes use these syscalls' data through a userspace cryptographically secure pseudorandom number generator (CSPRNG) rather than assigning the retrieved data directly to variables. For this purpose, OpenBSD's C standard library includes the function arc4random, which programs are expected to call when they need random data.[1] Like getentropy, arc4random also may not block nor return an error.

This approach allows a program to fetch less entropy from the kernel without reducing the strength of its random data. The getentropy system call is designed based on this assumption, supplying no more than 256 bytes per call.[1][7]

• Random number generation

• A system call for random numbers: getrandom(), LWN.net, 23 July 2014, by Jake Edge