|RANDOM(7)||Linux Programmer's Manual||RANDOM(7)|
The following interfaces provide access to output from the kernel CSPRNG:
- The /dev/urandom and /dev/random devices, both described in random(4). These devices have been present on Linux since early times, and are also available on many other systems.
- The Linux-specific getrandom(2) system call, available since Linux 3.17. This system call provides access either to the same source as /dev/urandom (called the urandom source in this page) or to the same source as /dev/random (called the random source in this page). The default is the urandom source; the random source is selected by specifying the GRND_RANDOM flag to the system call. (The getentropy(3) function provides a slightly more portable interface on top of getrandom(2).)
The disadvantage of GRND_RANDOM and reads from /dev/random is that the operation can block for an indefinite period of time. Furthermore, dealing with the partially fulfilled requests that can occur when using GRND_RANDOM or when reading from /dev/random increases code complexity.
|Interface||Pool||Blocking behavior||Behavior when pool is not yet ready|
|/dev/random||Blocking pool||If entropy too low, blocks until there is enough entropy again||Blocks until enough entropy gathered|
|/dev/urandom||CSPRNG output||Never blocks||Returns output from uninitialized CSPRNG (may be low entropy and unsuitable for cryptography)|
|getrandom ()||Same as /dev/urandom||Does not block once is pool ready||Blocks until pool ready|
|getrandom () GRND_RANDOM||Same as /dev/random||If entropy too low, blocks until there is enough entropy again||Blocks until pool ready|
|getrandom () GRND_NONBLOCK||Same as /dev/urandom||Does not block once is pool ready||EAGAIN|
|getrandom () GRND_RANDOM + GRND_NONBLOCK||Same as /dev/random||EAGAIN if not enough entropy available||EAGAIN|
While some safety margin above that minimum is reasonable, as a guard against flaws in the CSPRNG algorithm, no cryptographic primitive available today can hope to promise more than 256 bits of security, so if any program reads more than 256 bits (32 bytes) from the kernel random pool per invocation, or per reasonable reseed interval (not less than one minute), that should be taken as a sign that its cryptography is not skillfully implemented.