RANDOM(7)                 (2017-03-13)                  RANDOM(7)

     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 suf-
          ficient 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 read-
          ing from /dev/random increases code complexity.

        Monte Carlo and other probabilistic sampling

     Page 1                        Linux             (printed 5/21/22)

     RANDOM(7)                 (2017-03-13)                  RANDOM(7)

          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.  Fur-
          thermore, 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 gen-
          erator 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.  allbox; lbw13
          lbw12 lbw14 lbw18 l l l l.  Interface Pool T{ Blocking
          behavior T}   T{ Behavior when pool is not yet ready T} T{
          /dev/random T}   T{ Blocking pool T}   T{ If entropy too
          low, blocks until there is enough entropy again T}   T{
          Blocks until enough entropy gathered T} T{ /dev/urandom
          T}   T{ CSPRNG output T}   T{ Never blocks T}   T{ Returns
          output from uninitialized CSPRNG (may be low entropy and
          unsuitable for cryptography) T} T{ getrandom() T}   T{ Same
          as /dev/urandom T}   T{ Does not block once is pool ready
          T}   T{ Blocks until pool ready T} T{ getrandom()
          GRND_RANDOM T}   T{ Same as /dev/random T}   T{ If entropy
          too low, blocks until there is enough entropy again T}   T{
          Blocks until pool ready T} T{ getrandom() GRND_NONBLOCK
          T}   T{ Same as /dev/urandom T}   T{ Does not block once is
          pool ready T}   T{ EAGAIN T} T{ getrandom() GRND_RANDOM +
          GRND_NONBLOCK T}   T{ Same as /dev/random T}   T{ EAGAIN if
          not enough entropy available T}   T{ EAGAIN T}

        Generating cryptographic keys
          The amount of seed material required to generate  a  crypto-
          graphic  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 crypto-
          graphic 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  invoca-
          tion,  or  per reasonable reseed interval (not less than one
          minute), that should be taken as a sign that its  cryptogra-
          phy is not skillfully implemented.

     SEE ALSO

     Page 2                        Linux             (printed 5/21/22)

     RANDOM(7)                 (2017-03-13)                  RANDOM(7)

          getrandom(2),   getauxval(3),   getentropy(3),    random(4),
          urandom(4), signal(7)

     COLOPHON
          This page is part of release 5.10  of  the  Linux  man-pages
          project.   A  description  of the project, information about
          reporting bugs, and the latest version of this page, can  be
          found at https://www.kernel.org/doc/man-pages/.

     Page 3                        Linux             (printed 5/21/22)