1random(7) Miscellaneous Information Manual random(7)
2
6 random - overview of interfaces for obtaining randomness
7
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 The following interfaces provide access to output from the kernel
15 CSPRNG:
16 • 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 • 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 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 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 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 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 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 ┌──────────────┬──────────────┬────────────────┬────────────────────┐
66 │Interface │ 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 ├──────────────┼──────────────┼────────────────┼────────────────────┤
82 │getrandom() │ Same as │ Does not block │ Blocks until pool │
83 │ │ /dev/urandom │ once is pool │ ready │
84 │ │ │ ready │ │
85 ├──────────────┼──────────────┼────────────────┼────────────────────┤
86 │getrandom() │ Same as │ If entropy too │ Blocks until pool │
87 │GRND_RANDOM │ /dev/random │ low, blocks │ ready │
88 │ │ │ until there is │ │
89 │ │ │ enough entropy │ │
90 │ │ │ again │ │
91 ├──────────────┼──────────────┼────────────────┼────────────────────┤
92 │getrandom() │ Same as │ Does not block │ EAGAIN │
93 │GRND_NONBLOCK │ /dev/urandom │ once is pool │ │
94 │ │ │ ready │ │
95 ├──────────────┼──────────────┼────────────────┼────────────────────┤
96 │getrandom() │ Same as │ EAGAIN if not │ EAGAIN │
97 │GRND_RANDOM + │ /dev/random │ enough entropy │ │
98 │GRND_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 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
116 getrandom(2), getauxval(3), getentropy(3), random(4), urandom(4), sig‐
117 nal(7)
118Linux man-pages 6.05 2023-02-10 random(7)