1random(7)              Miscellaneous Information Manual              random(7)
2
3
4

NAME

6       random - overview of interfaces for obtaining randomness
7

DESCRIPTION

9       The  kernel random-number generator relies on entropy gathered from de‐
10       vice drivers and other sources of environmental noise to seed a crypto‐
11       graphically  secure  pseudorandom number generator (CSPRNG).  It is de‐
12       signed for security, rather than speed.
13
14       The following interfaces provide  access  to  output  from  the  kernel
15       CSPRNG:
16
17       •  The  /dev/urandom  and  /dev/random  devices, both described in ran‐
18          dom(4).  These devices have been present on Linux since early times,
19          and are also available on many other systems.
20
21       •  The  Linux-specific  getrandom(2) system call, available since Linux
22          3.17.  This system call provides access either to the same source as
23          /dev/urandom (called the urandom source in this page) or to the same
24          source as /dev/random (called the random source in this page).   The
25          default  is  the  urandom  source;  the random source is selected by
26          specifying the GRND_RANDOM flag to the  system  call.   (The  geten‐
27          tropy(3) function provides a slightly more portable interface on top
28          of getrandom(2).)
29
30   Initialization of the entropy pool
31       The kernel collects bits of entropy from the environment.  When a  suf‐
32       ficient  number  of random bits has been collected, the entropy pool is
33       considered to be initialized.
34
35   Choice of random source
36       Unless you are doing long-term key generation (and most likely not even
37       then), you probably shouldn't be reading from the /dev/random device or
38       employing getrandom(2) with the GRND_RANDOM flag.  Instead, either read
39       from  the  /dev/urandom  device  or  employ  getrandom(2)  without  the
40       GRND_RANDOM flag.  The cryptographic algorithms used  for  the  urandom
41       source are quite conservative, and so should be sufficient for all pur‐
42       poses.
43
44       The disadvantage of GRND_RANDOM and reads from /dev/random is that  the
45       operation  can  block  for  an indefinite period of time.  Furthermore,
46       dealing with the partially fulfilled requests that can occur when using
47       GRND_RANDOM or when reading from /dev/random increases code complexity.
48
49   Monte Carlo and other probabilistic sampling applications
50       Using  these  interfaces  to provide large quantities of data for Monte
51       Carlo simulations or other programs/algorithms which are  doing  proba‐
52       bilistic  sampling  will  be slow.  Furthermore, it is unnecessary, be‐
53       cause such applications do not  need  cryptographically  secure  random
54       numbers.   Instead, use the interfaces described in this page to obtain
55       a small amount of data to seed a user-space pseudorandom number genera‐
56       tor for use by such applications.
57
58   Comparison between getrandom, /dev/urandom, and /dev/random
59       The  following  table summarizes the behavior of the various interfaces
60       that can be used to obtain randomness.  GRND_NONBLOCK is  a  flag  that
61       can  be used to control the blocking behavior of getrandom(2).  The fi‐
62       nal column of the table considers the case that can occur in early boot
63       time when the entropy pool is not yet initialized.
64
65       ┌──────────────┬──────────────┬────────────────┬────────────────────┐
66Interface     Pool         Blocking       Behavior when pool 
67       │              │              │ behavior       is not yet ready   
68       ├──────────────┼──────────────┼────────────────┼────────────────────┤
69/dev/random   │ Blocking     │ If entropy too │ Blocks until       │
70       │              │ pool         │ low, blocks    │ enough entropy     │
71       │              │              │ until there is │ gathered           │
72       │              │              │ enough entropy │                    │
73       │              │              │ again          │                    │
74       ├──────────────┼──────────────┼────────────────┼────────────────────┤
75/dev/urandom  │ CSPRNG out‐  │ Never blocks   │ Returns output     │
76       │              │ put          │                │ from uninitialized │
77       │              │              │                │ CSPRNG (may be low │
78       │              │              │                │ entropy and un‐    │
79       │              │              │                │ suitable for cryp‐ │
80       │              │              │                │ tography)          │
81       ├──────────────┼──────────────┼────────────────┼────────────────────┤
82getrandom()   │ Same as      │ Does not block │ Blocks until pool  │
83       │              │ /dev/urandom │ once is pool   │ ready              │
84       │              │              │ ready          │                    │
85       ├──────────────┼──────────────┼────────────────┼────────────────────┤
86getrandom()   │ Same as      │ If entropy too │ Blocks until pool  │
87GRND_RANDOM   /dev/random  │ low, blocks    │ ready              │
88       │              │              │ until there is │                    │
89       │              │              │ enough entropy │                    │
90       │              │              │ again          │                    │
91       ├──────────────┼──────────────┼────────────────┼────────────────────┤
92getrandom()   │ Same as      │ Does not block │ EAGAIN             
93GRND_NONBLOCK /dev/urandom │ once is pool   │                    │
94       │              │              │ ready          │                    │
95       ├──────────────┼──────────────┼────────────────┼────────────────────┤
96getrandom()   │ Same as      │ EAGAIN if not  │ EAGAIN             
97GRND_RANDOM + │ /dev/random  │ enough entropy │                    │
98GRND_NONBLOCK │              │ available      │                    │
99       └──────────────┴──────────────┴────────────────┴────────────────────┘
100   Generating cryptographic keys
101       The amount of seed material required to generate  a  cryptographic  key
102       equals  the effective key size of the key.  For example, a 3072-bit RSA
103       or Diffie-Hellman private key has an effective key size of 128 bits (it
104       requires about 2^128 operations to break) so a key generator needs only
105       128 bits (16 bytes) of seed material from /dev/random.
106
107       While some safety margin above that minimum is reasonable, as  a  guard
108       against  flaws  in  the  CSPRNG  algorithm,  no cryptographic primitive
109       available today can hope to promise more than 256 bits of security,  so
110       if any program reads more than 256 bits (32 bytes) from the kernel ran‐
111       dom pool per invocation, or per reasonable reseed  interval  (not  less
112       than  one minute), that should be taken as a sign that its cryptography
113       is not skillfully implemented.
114

SEE ALSO

116       getrandom(2), getauxval(3), getentropy(3), random(4), urandom(4),  sig‐
117       nal(7)
118
119
120
121Linux man-pages 6.05              2023-02-10                         random(7)
Impressum