Is it bad to have a low entropy in /dev/random?

Question

I wonder whether for the average Linux user it is considered as bad -from a point of view of security or any other relevant viewpoints- to have no or almost no entropy left in /dev/random.

Edit: I don't need to generate random numbers (I would use /dev/urandom for that and even for password generation and disk encryption). Just for the fun of it, I have a bash script that generates strings of random characters out of /dev/random and of course, after playing a bit with it, I am left without entropy in /dev/random and it blocks. On IRC I was told it's "bad" to do so, but I wasn't given any reason. Is it bad because the average Linux user automatically generates random things using /dev/random? If so, which program(s) is/are involved?

I also understand that having no entropy left in /dev/random makes the generation of numbers deterministic. But again, is my computer (the average Linux user) in need of truly random numbers?

Edit 2: I've just monitored the entropy level every second in /dev/random during about 3 minutes, where I launched my bash script that uses entropy to generate a string of random character around the beginning of the monitoring. I've made a plot. We can see that indeed, the entropy level oscillates somehow, so some program(s) on my computer are using /dev/random to generate stuff. Is there a way I can list all programs using the file /dev/random?

We can also see that it takes less than a minute to yield "acceptable levels" of entropy once the entropy pool has been emptied.

Answer 1

Entropy is fed into /dev/random at a rather slow rate, so if you use any program that uses /dev/random, it's pretty common for the entropy to be low.

Even if you believe in Linux's definition of entropy, low entropy isn't a security problem. /dev/random blocks until it's satisfied that it has enough entropy. With low entropy, you'll get applications sitting around waiting for you to wiggle the mouse, but not a loss of randomness.

In fact Linux's definition of entropy is flawed: it's an extremely conservative definition which strives to achieve a theoretical level of randomness that's useless in practice. In fact, entropy does not wear out — once you have enough, you have enough. Unfortunately, Linux only has two interfaces to get random numbers: /dev/random, which blocks when it shouldn't, and /dev/urandom, which never blocks. Fortunately, in practice, /dev/urandom is almost always correct, because a system quickly gathers enough entropy, after which point /dev/urandom is ok forever (including uses such as generating cryptographic keys).

The only time when /dev/urandom is problematic is when a system doesn't have enough entropy yet, for example on the first boot of a fresh installation, after booting a live CD, or after cloning a virtual machine. In such situations, wait until /proc/sys/kernel/random/entropy_avail reaches 200 or so. After that, you can use /dev/urandom as much as you like.

Answer 2

Having no entropy left and knowing that makes /dev/random deterministic. This enable other processes (including those started by malicious users) to be able to "predict" the future output from (i.e. the bytes read from) /dev/random.

On one hand, a good Linux programmer in need of "true" randomness would have carefully read random(4) so would read(2) from /dev/random which would block if no entropy is available. This could annoy processes reading from it. See also (as commented by the OP) the myths about urandom page.

On the other hand, some programmers prefer to read from /dev/urandom which is almost always good enough and does not block. AFAIK, the C++11 standard library from GCC is doing that for std::random_device.

Obviously, randomness matters slightly more on servers than on ordinary desktops.

If your question is becoming "are Linux programmers using /dev/random good enough to be aware of these issues", it is becoming a matter of opinion, or a poll, and then it could be off-topic here.

My opinion is that programmers should be expected to have read random(4).

Recent Intel processors have the RDRAND machine instruction, and /dev/random is using it (and some other things) as random source. So I guess that lack of entropy on /dev/random don't affect (i.e. never happens for) them.

So in short, I don't care about low entropy in /dev/random. But I am not coding software (e.g. poker sites, some banking systems) where randomness is critically important (to the point of costing lives, or millions of € or $). I guess that such systems can afford getting a better random source (IIRC, a hardware random generator with a megabit/second bandwidth costs a few hundred euros), and they should have (or buy consultancy for) expertise on randomness & probabilities.

Perhaps, you should simply mention, in the README and the documentation of your software, that you are using /dev/random and/or /dev/urandom, for what purpose, and explicitly document the importance, for your own code, of randomness.