On Linux, most programs should call getrandom() or read /dev/urandom, and in practice use their language's secure random function, which does that for them. The Linux manual says the urandom algorithms are conservative enough for nearly all purposes. The one real caveat is very early boot, before the pool is initialized.
What the manual says
The Linux random(7) page states that /dev/urandom reads CSPRNG output and never blocks. /dev/random draws from a blocking pool and can wait for entropy. The getrandom() call uses the urandom source by default.
For most programs it advises /dev/urandom or getrandom() without the GRND_RANDOM flag.
Why the old advice persists
Many guides said /dev/random is "more secure" because it blocks when entropy is low. That idea mixed up two things. Once a CSPRNG is properly seeded, it can produce a very large amount of output safely. Blocking again later adds outages without adding protection for typical uses.
The early boot caveat
The same manual notes that early in boot, before the pool is initialized, /dev/urandom can return output that may be low entropy and unsuitable for cryptography. getrandom() without flags blocks until the pool is ready and then does not block. With GRND_NONBLOCK it returns EAGAIN instead of blocking.
This matters for things that run at startup: generating a host key on first boot, creating a certificate on a fresh image, or seeding something in an initialization script. Prefer getrandom() there, and handle the wait.
Containers and virtual machines
Containers use the host kernel's generator. A virtual machine has its own kernel, and a cloned or restored snapshot can start with repeated state in some setups. If you build images that generate keys during the build, you may copy that key to every instance. Generate keys at first run on the target, not in the image.
Also do not seed your own generator from the clock or process ID.
What this means for developers
- Use the platform call: Python
secretsoros.urandom, Nodecrypto.randomBytes, JavaSecureRandom, Gocrypto/rand. - Do not build a custom generator or read raw device files unless you must.
- Do not fall back to a weaker generator if the secure one errors. Fail loudly.
- Never use math-style generators for tokens or keys. See how long a token should be.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each result names the exact place to fix.
Quick check
Can /dev/urandom run out of entropy?
Not in the way the old guides described. After initialization it keeps producing output without blocking.
Should I read /dev/random for long-term keys?
The manual advises most programs against it. Use getrandom() or the language secure random function.
Sources
Last reviewed: 19 October 2026.
