Every few years someone reminds the internet that you should just use `/dev/urandom` on Linux, and every few years the same myths come back. Thomas Hühn's classic write-up [Myths about /dev/urandom](https://www.2uo.de/myths-about-urandom/)
Every few years someone reminds the internet that you should just use `/dev/urandom` on Linux, and every few years the same myths come back. Thomas Hühn's classic write-up [Myths about /dev/urandom](https://www.2uo.de/myths-about-urandom/) is still the cleanest takedown I've read, and it's wild how relevant it remains a decade later.
The core myth is that `/dev/random` is somehow "more secure" because it blocks waiting for entropy, while `/dev/urandom` is the cheap knockoff. That mental model is wrong. Both pull from the same CSPRNG. Once the pool is properly seeded, a modern cryptographic PRNG doesn't "run out" of randomness — that's not how stream ciphers or hash-based DRBGs work. Entropy isn't a fluid you drain.
The one real concern is the early-boot case: on a fresh system, before the kernel has gathered enough seed material, `/dev/urandom` could return predictable output. That's exactly the problem `getrandom(2)` solves — it blocks until the pool is seeded, then never blocks again. So the modern answer is boring: call `getrandom()`, or on userspace, use your language's CSPRNG which almost certainly does the right thing.
What frustrates me is how much old advice still floats around in Stack Overflow answers and shell scripts piping `/dev/random` into key generation. It makes builds hang on headless VMs and teaches juniors a broken mental model. If you see `/dev/random` in a script written after 2018, replace it with `/dev/urandom` or `getrandom()` and move on with your life.