Provided by: manpages_6.03-1_all 
NAME
random - overview of interfaces for obtaining randomness
DESCRIPTION
The kernel random-number generator relies on entropy gathered from device drivers and
other sources of environmental noise to seed a cryptographically secure pseudorandom
number generator (CSPRNG). It is designed for security, rather than speed.
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).)
Initialization of the entropy pool
The kernel collects bits of entropy from the environment. When a sufficient number of
random bits has been collected, the entropy pool is considered to be initialized.
Choice of random source
Unless you are doing long-term key generation (and most likely not even then), you
probably shouldn't be reading from the /dev/random device or employing getrandom(2) with
the GRND_RANDOM flag. Instead, either read from the /dev/urandom device or employ
getrandom(2) without the GRND_RANDOM flag. The cryptographic algorithms used for the
urandom source are quite conservative, and so should be sufficient for all purposes.
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.
Monte Carlo and other probabilistic sampling applications
Using these interfaces to provide large quantities of data for Monte Carlo simulations or
other programs/algorithms which are doing probabilistic sampling will be slow.
Furthermore, it is unnecessary, because such applications do not need cryptographically
secure random numbers. Instead, use the interfaces described in this page to obtain a
small amount of data to seed a user-space pseudorandom number generator for use by such
applications.
Comparison between getrandom, /dev/urandom, and /dev/random
The following table summarizes the behavior of the various interfaces that can be used to
obtain randomness. GRND_NONBLOCK is a flag that can be used to control the blocking
behavior of getrandom(2). The final column of the table considers the case that can occur
in early boot time when the entropy pool is not yet initialized.
┌──────────────┬──────────────┬────────────────┬────────────────────┐
│Interface │ Pool │ Blocking │ Behavior when pool │
│ │ │ behavior │ is not yet ready │
├──────────────┼──────────────┼────────────────┼────────────────────┤
│/dev/random │ Blocking │ If entropy too │ Blocks until │
│ │ pool │ low, blocks │ enough entropy │
│ │ │ until there is │ gathered │
│ │ │ enough entropy │ │
│ │ │ again │ │
├──────────────┼──────────────┼────────────────┼────────────────────┤
│/dev/urandom │ CSPRNG │ Never blocks │ Returns output │
│ │ output │ │ from uninitialized │
│ │ │ │ CSPRNG (may be low │
│ │ │ │ entropy and │
│ │ │ │ unsuitable for │
│ │ │ │ cryptography) │
├──────────────┼──────────────┼────────────────┼────────────────────┤
│getrandom() │ Same as │ Does not block │ Blocks until pool │
│ │ /dev/urandom │ once is pool │ ready │
│ │ │ ready │ │
├──────────────┼──────────────┼────────────────┼────────────────────┤
│getrandom() │ Same as │ If entropy too │ Blocks until pool │
│GRND_RANDOM │ /dev/random │ low, blocks │ ready │
│ │ │ until there is │ │
│ │ │ enough entropy │ │
│ │ │ again │ │
├──────────────┼──────────────┼────────────────┼────────────────────┤
│getrandom() │ Same as │ Does not block │ EAGAIN │
│GRND_NONBLOCK │ /dev/urandom │ once is pool │ │
│ │ │ ready │ │
├──────────────┼──────────────┼────────────────┼────────────────────┤
│getrandom() │ Same as │ EAGAIN if not │ EAGAIN │
│GRND_RANDOM + │ /dev/random │ enough entropy │ │
│GRND_NONBLOCK │ │ available │ │
└──────────────┴──────────────┴────────────────┴────────────────────┘
Generating cryptographic keys
The amount of seed material required to generate a cryptographic key equals the effective
key size of the key. For example, a 3072-bit RSA or Diffie-Hellman private key has an
effective key size of 128 bits (it requires about 2^128 operations to break) so a key
generator needs only 128 bits (16 bytes) of seed material from /dev/random.
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.
SEE ALSO
getrandom(2), getauxval(3), getentropy(3), random(4), urandom(4), signal(7)