Section : 7 Updated : 2023-02-10 Source : Linux man-pages 6.03 NAMErandom − overview of interfaces for obtaining randomness DESCRIPTIONThe 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 poolThe 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 sourceUnless 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 applicationsUsing 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/randomThe 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.