random(7)

✨ random(7) ✨

okay bestie, gather round, because this one is the main character of the manual pages — it's random(7), the overview of interfaces for obtaining randomness. 💖 yes, randomness. the lore. the vibes. the actual cryptographic tea. let's get into it.

---

🌸 NAME 🌸

random — overview of interfaces for obtaining randomness

---

🦋 DESCRIPTION 🦋

so, the kernel random-number generator? it's not just vibing and making up numbers. it relies on entropy gathered from device drivers and other sources of environmental noise to seed a cryptographically secure pseudorandom number generator (CSPRNG). and the way it's designed? it's giving security, not speed. periodt. 👑

the following interfaces give you 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 they're also available on many other systems. iconic behavior honestly. ✨
• the Linux-specific getrandom(2) system call, available since Linux 3.17. this syscall gives you 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. (and the getentropy(3) function provides a slightly more portable interface on top of getrandom(2), so slay for portability. 🫶)

🌱 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. it's like the CSPRNG finishing its morning routine — it's just not ready to serve until it's had its coffee. ☕

🎀 Choice of random source

unless you're 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, so they should be sufficient for all purposes. no cap, it ate. 💅

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. like, it's giving unnecessary drama. 🙈

🧚 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. lil seed, big output. that's the move. 🌈

⭐ 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.

since we're in a group chat and not a spreadsheet, here's the table as a little love letter per interface, with every single column intact. 💜

• /dev/random
  • Pool: Blocking pool
  • Blocking behavior: If entropy too low, blocks until there is enough entropy again
  • Behavior when pool is not yet ready: Blocks until enough entropy gathered
• /dev/urandom
  • Pool: CSPRNG output
  • Blocking behavior: Never blocks
  • Behavior when pool is not yet ready: Returns output from uninitialized CSPRNG (may be low entropy and unsuitable for cryptography)
• getrandom()
  • Pool: Same as /dev/urandom
  • Blocking behavior: Does not block once pool is ready
  • Behavior when pool is not yet ready: Blocks until pool ready
• getrandom() GRND_RANDOM
  • Pool: Same as /dev/random
  • Blocking behavior: If entropy too low, blocks until there is enough entropy again
  • Behavior when pool is not yet ready: Blocks until pool ready
• getrandom() GRND_NONBLOCK
  • Pool: Same as /dev/urandom
  • Blocking behavior: Does not block once pool is ready
  • Behavior when pool is not yet ready: EAGAIN
• getrandom() GRND_RANDOM + GRND_NONBLOCK
  • Pool: Same as /dev/random
  • Blocking behavior: EAGAIN if not enough entropy available
  • Behavior when pool is not yet ready: EAGAIN

not the uninitialized-CSPRNG output possibly being low entropy and unsuitable for cryptography 😭 that's the early-boot jumpscare. respect it.

🔐 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. 🚩 bestie that's a red flag, not a flex.

---

👑 SEE ALSO 👑

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

http://www.2uo.de/myths-about-urandom/

---

and that's the whole page, babes. 🎀 this was served to you straight from Linux man-pages 6.20, dated 2026-02-08, and yes that's random(7) signing off — stay unpredictable out there, but like, cryptographically unpredictable. 💖✨🦋