Myths about /dev/urandom

There are a few things about /dev/urandom and /dev/random that are repeated again and again. Still they are false.

/dev/urandom is insecure. Always use /dev/random for cryptographic purposes. Fact: /dev/urandom is the preferred source of cryptographic randomness on UNIX-like systems. /dev/urandom is a pseudo random number generator, a PRNG, while /dev/random is a “true” random number generator. Fact: Both /dev/urandom and /dev/random are using the exact same CSPRNG (a cryptographically secure pseudorandom number generator). They only differ in very few ways that have nothing to do with “true” randomness. /dev/random is unambiguously the better choice for cryptography. Even if /dev/urandom were comparably secure, there’s no reason to choose the latter. Fact: /dev/random has a very nasty problem: it blocks. But that’s good! /dev/random gives out exactly as much randomness as it has entropy in its pool. /dev/urandom will give you insecure random numbers, even though it has long run out of entropy. Fact: No. Even disregarding issues like availability and subsequent manipulation by users, the issue of entropy “running low” is a straw man. About 256 bits of entropy are enough to get computationally secure numbers for a long, long time. And the fun only starts here: how does /dev/random know how much entropy there is available to give out? Stay tuned! But cryptographers always talk about constant re-seeding. Doesn’t that contradict your last point? Fact: You got me! Kind of. It is true, the random number generator is constantly re-seeded using whatever entropy the system can lay its hands on. But that has (partly) other reasons. Look, I don’t claim that injecting entropy is bad. It’s good. I just claim that it’s bad to block when the entropy estimate is low. That’s all good and nice, but even the man page for /dev/(u)random contradicts you! Does anyone who knows about this stuff actually agree with you? Fact: No, it really doesn’t.

It seems to imply that /dev/urandom is insecure for cryptographic use, unless you really understand all that cryptographic jargon. The man page does recommend the use of /dev/random in some cases (it doesn’t hurt, in my opinion, but is not strictly necessary), but it also recommends /dev/urandom as the device to use for “normal” cryptographic use. And while appeal to authority is usually nothing to be proud of, in cryptographic issues you’re generally right to be careful and try to get the opinion of a domain expert. And yes, quite a few experts share my view that /dev/urandom is the go-to solution for your random number needs in a cryptography context on UNIX-like systems. Obviously, their opinions influenced mine, not the other way around. Hard to believe, right? I must certainly be wrong! Well, read on and let me try to convince you. I tried to keep it out, but I fear there are two preliminaries to be taken care of, before we can really tackle all those points. Namely, what is randomness, or better: what kind of randomness am I talking about here? And, even more important, I’m really not being condescending. I have written this document to have a thing to point to, when this discussion comes up again. More than 140 characters. Without repeating myself again and again. Being able to hone the writing and the arguments itself, benefitting many discussions in many venues. And I’m certainly willing to hear differing opinions. I’m just saying that it won’t be enough to state that /dev/urandom is bad. You need to identify the points you’re disagreeing with and engage them. You’re saying I’m stupid! Emphatically no! Actually, I used to believe that /dev/urandom was insecure myself, a few years ago. And it’s something you and I almost had to believe, because all those highly respected people on Usenet, in web forums and today on Twitter told us. Even the man page seems to say so. Who were we to dismiss their convincing argument about “entropy running low”?

This misconception isn’t so rampant because people are stupid, it is because with a little knowledge about cryptography (namely some vague idea what entropy is) it’s very easy to be convinced of it. Intuition almost forces us there. Unfortunately, intuition is often wrong in cryptography. So it is here. True randomness What does it mean for random numbers to be “truly random”? I don’t want to dive into that issue too deep, because it quickly gets philosophical. Discussions have been known to unravel quickly, because everyone can wax about their favorite model of randomness, without paying attention to anyone else. Or even making himself understood. I believe that the “gold standard” for “true randomness” are quantum effects. Observe a photon pass through a semi-transparent mirror. Or not. Observe some radioactive material emit alpha particles. It’s the best idea we have when it comes to randomness in the world. Other people might reasonably believe that those effects aren’t truly random. Or even that there is no randomness in the world at all. Let a million flowers bloom. Cryptographers often circumvent this philosophical debate by disregarding what it means for randomness to be “true”. They care about unpredictability. As long as nobody can get any information about the next random number, we’re fine. And when you’re talking about random numbers as a prerequisite in using cryptography, that’s what you should aim for, in my opinion. Anyway, I don’t care much about those “philosophically secure” random numbers, as I like to think of your “true” random numbers. Two kinds of security, one that matters But let’s assume you’ve obtained those “true” random numbers. What are you going to do with them? You print them out, frame them and hang them on your living-room wall, to revel in the beauty of a quantum universe? That’s great, and I certainly understand. Wait, what? You’re using them? For cryptographic purposes? Well, that spoils everything, because now things get a bit ugly. You see, your truly-random, quantum effect blessed random numbers are put into some less respectable, real-world tarnished algorithms.

Because almost all of the cryptographic algorithms we use do not hold up to information-theoretic security. They can “only” offer computational security. The two exceptions that come to my mind are Shamir’s Secret Sharing and the One-time pad. And while the first one may be a valid counterpoint (if you actually intend to use it), the latter is utterly impractical. But all those algorithms you know about, AES, RSA, Diffie-Hellman, Elliptic curves, and all those crypto packages you’re using, OpenSSL, GnuTLS, Keyczar, your operating system’s crypto API, these are only computationally secure. What’s the difference? While information-theoretically secure algorithms are secure, period, those other algorithms cannot guarantee security against an adversary with unlimited computational power who’s trying all possibilities for keys. We still use them because it would take all the computers in the world taken together longer than the universe has existed, so far. That’s the level of “insecurity” we’re talking about here. Unless some clever guy breaks the algorithm itself, using much less computational power. Even computational power achievable today. That’s the big prize every cryptanalyst dreams about: breaking AES itself, breaking RSA itself and so on. So now we’re at the point where you don’t trust the inner building blocks of the random number generator, insisting on “true randomness” instead of “pseudo randomness”. But then you’re using those “true” random numbers in algorithms that you so despise that you didn’t want them near your random number generator in the first place! Truth is, when state-of-the-art hash algorithms are broken, or when state-of-the-art block ciphers are broken, it doesn’t matter that you get “philosophically insecure” random numbers because of them. You’ve got nothing left to securely use them for anyway. So just use those computationally-secure random numbers for your computationally-secure algorithms. In other words: use /dev/urandom.

Structure of Linux’s random number generator An incorrect view Chances are, your idea of the kernel’s random number generator is something similar to this:

“True randomness”, albeit possibly skewed and biased, enters the system and its entropy is precisely counted and immediately added to an internal entropy counter. After de-biasing and whitening it’s entering the kernel’s entropy pool, where both /dev/random and /dev/urandom get their random numbers from. The “true” random number generator, /dev/random, takes those random numbers straight out of the pool, if the entropy count is sufficient for the number of requested numbers, decreasing the entropy counter, of course. If not, it blocks until new entropy has entered the system. The important thing in this narrative is that /dev/random basically yields the numbers that have been input by those randomness sources outside, after only the necessary whitening. Nothing more, just pure randomness. /dev/urandom, so the story goes, is doing the same thing. Except when there isn’t sufficient entropy in the system. In contrast to /dev/random, it does not block, but gets “low quality random” numbers from a pseudorandom number generator (conceded, a cryptographically secure one) that is running alongside the rest of the random number machinery. This CSPRNG is just seeded once (or maybe every now and then, it doesn’t matter) with “true randomness” from the randomness pool, but you can’t really trust it. In this view, that seems to be in a lot of people’s minds when they’re talking about random numbers on Linux, avoiding /dev/urandom is plausible. Because either there is enough entropy left, then you get the same you’d have gotten from /dev/random. Or there isn’t, then you get those low-quality random numbers from a CSPRNG that almost never saw high-entropy input. Devilish, right? Unfortunately, also utterly wrong. In reality, the internal structure of the random number generator looks like this. A better simplification Before Linux 4.8

See the big difference?