How bad it is to feed /dev/random with /dev/urandom?

Question

I have seen many blog posts, or blog comments which recommends to feed /dev/random entropy using output from /dev/urandom.

I'm not a crypto expert, but it looks like a good way to replace hard-to-predict numbers with much less random numbers. But is there any insight about how worse is it effectively?

If I ever find a server with such a configuration, do I need to invalidate tls certificates, ssh and gpg keys right know, like with the infamous debian bug CVE-2008-0166 ? Or is it more like a state-sponsored attacker may find my private key given a few billion euros?

Answer 1

I am assuming a Linux system here, on some OS like FreeBSD and Mac OS there isn't any difference between /dev/random and /dev/urandom, and yet others don't have those devices

Both /dev/random and /dev/urandom use the same entropy pool. The difference is that /dev/random "counts" how many bytes have been extracted, estimating the entropy left in the pool. If at one point it considers there's not enough entropy for what it is being asked, it will block, whereas /dev/urandom will provide the requested bytes.

The fact is, just /dev/urandom would have been perfectly fine (except shortly after boot up). Feeding /dev/random with /dev/urandom is a way of cheating, but shouldn't really break the security.

do I need to invalidate tls certificates, ssh and gpg keys right know, like with the infamous debian bug CVE-2008-0166 ?

Not at all.

Or is it more like a state-sponsored attacker may find my private key given a few billion euros

Even for a state-sponsored attacker, I don't think it wouldn't be tratable to figure out the random bytes that were extracted from the random pool on a normal system.

The exception are embedded devices, such as routers, where they too often are found to generate a random key (eg. for https or ssh) shortly after boot-up, where they actually have a quite deterministic state.

Still, for longterm keys like those you mention, you may prefer nonetheless to feed from /dev/random knowing that it will take longer, and just sidestep the usage of /dev/urandom. And that's fine, too.

Answer 2

It is a stupid thing to do, but it is not dangerous.

The reason is that Linux is conservative and treats the data you feed into /dev/random as deterministic, thus not increasing its estimated internal entropy.

From the man page:

Writing to /dev/random or /dev/urandom will update the entropy pool with the data written, but this will not result in a higher entropy count. This means that it will impact the contents read from both files, but it will not make reads from /dev/random faster.

So, copying bytes from /dev/urandom to /dev/random only wastes CPU but it is not dangerous. If you see this being done on a server, you need not be worried about it per se. The most disturbing thing about it is probably that it is a clue that the server was set up by a person that either believes in snake oil for security or, worse, tries to bypass security features that were put in place for a reason. Although the latter wouldn't have worked in this case.¹ So maybe check whether there are other things done on the server that might be less benign.

On the other hand, reading from /dev/random might actually be useful in a startup script because it will block until the system has gathered enough entropy in its internal pool to make /dev/urandom safe to use.

---

¹ If you really want to be mean and make /dev/random non-blocking even if the kernel has estimated that it is low on entropy, you could simply make it an alias for /dev/urandom.

# rm -f /dev/random
# mknod -m 0666 /dev/random c 1 9

See the man page for mknod and look at the output of

$ stat /dev/random /dev/urandom

if you're confused about what is going on here. (The stat command is safe to execute.)

I strongly recommend against nasty tricks like this, of course.

Answer 3

I will try to answer a simplified question: does there exist a feasible attack on a true CSPRNG (cryptographically secure random number generator)? And then, what if it is not a perfect CSPRNG?

case 1)

To make things simple, assume no entropy is added after the initialization setup of a deterministic true CSPRNG . Also, assume no leak of information in the initialization.

From wikipedia the definition of a CSPRNG is as given as follows:

Every CSPRNG should satisfy the next-bit test. That is, given the first k bits of a random sequence, there is no polynomial-time algorithm that can predict the (k+1)th bit with probability of success non-negligibly better than 50%. Andrew Yao proved in 1982 that a generator passing the next-bit test will pass all other polynomial-time statistical tests for randomness.

Every CSPRNG should withstand "state compromise extensions". In the event that part or all of its state has been revealed (or guessed correctly), it should be impossible to reconstruct the stream of random numbers prior to the revelation. Additionally, if there is an entropy input while running, it should be infeasible to use knowledge of the input's state to predict future conditions of the CSPRNG state.

That says even if some of the random output sequence is leaked, the parts of the sequence before and after that leaked part cannot be determined.

In that case you are completely safe using /dev/urandom, even if there is a leak of the random sequence data and even if no external random data is ever added to the sequence after initialization.

case 2)

Suppose that it turns out that the so-called CSPRNG is actually broken. Just for the sale of argument suppose that given a partial leak of the sequence, both past and future parts of sequence "close enough" to the leak are severly compromised.

In such a broken-CSPRNG case, the added entropy will add safety to the system. If 256 true bits of entropy separate the leak and a random number X used for a critical purpose, then the search space for an attack on X is enlarged by 2^256 - and it is therefore totally secure.

So case 2 is a risk under the following 2 conditions:

1. There is a leak of the random sequence state.
2. The PRNG is not a perfect CSPRNG.

But ensuring sufficient entropy can perfectly mitigate the risk.

Concerning condition (1): the possibility of a data leak. Some Java implementations provide access to the underlying /dev/random data. It says so in the Java documentation.

That's great for choosing random numbers in Java, but it could be used by Java-based malware to leak information on your random sequence. Besides Java, every time you create a random password with your software and pass it out to an external website, that could feasibly leak some information about your random sequence state.

Concerning condition (2): while it may be possible to a prove that a particular PRNG is not a CSPRNG, it is not possible to prove that a particular PRNG is a CSPRNG. You just have to hope that the CSPRNG has not been disproven without you knowing about it. There are also shades of grey: a particular attack only opens a narrow window of vulnerability before and after a leak, and it would require huge resources to exploit it. Evaluating the risk of an unknown (to you) attack with a concrete number is difficult or impossible, but to treat the risk as an unknown variable and examine the cost of mitigation vs. consequences as the risk is varied is a meaningful exercise.

Note: There is a layman's question: If the PRNG is deterministic, how can the next bit not be predictable if a leak occurs? The answer is that although the overall random sequence algorithm itself is publicly known, the function used to transtion from one (value, state) pair to the next (value, state) pair is initially chosen from a large family of functions, e.g., one of 2^256 such functions. Then another 256 bits can be used to seed the chosen function. (Actually only 128 bits are required to intialize the /dev/random sequence).