Entropy is important for many security features like TCP sequence numbers and cryptographic key/parameter generation. My understanding is that the entropy pool is drained by an operation as simple as cat /dev/random which could be hidden in an malicious or poorly written script. This could also be done by an attacker who's taken over an unprivileged local account and is trying to get deeper into the system.

Since most systems use a cryptographically secure pseudo-number generator (/dev/urandom) instead of /dev/random, I'm wondering if a drained entropy pool has any security consequences. To give an example: would it be easier to guess the private key of a newly generated SSL certificate if the entropy pool was low during the generation? I read man 4 random but I'm still unsure on how entropy is handled by the system.

  • 2
    Please read 2uo.de/myths-about-urandom for some (well-written) myth-busting about /dev/random and /dev/urandom. – roaima Feb 29 '16 at 17:44
  • @roaima well, that answered it. Thanks for the hint. I'm not sure, should this question be deleted or is it somewhat useful and should be (self-)answered? – tarleb Feb 29 '16 at 18:00
  • A clever site might monitor /proc/sys/kernel/random/entropy_avail and thus note if entropy took a dive for some reason. – thrig Feb 29 '16 at 18:16
  • @roaima, the first "fact" is wrong, the second completely off.-base. Yes, /dev/random and dev/urandom use the same PRNG, but the first one uses "real" randomness (timing of disk responses, keypresses, mouse movements, ...) as long as it is available. Stopped reading right there. – vonbrand Feb 29 '16 at 20:58
  • @vonbrand Whereas the second one uses "real" randomness (timing of disk responses, keypresses, mouse movements, ...) as soon as it is available. That article is correct. Ask any competent cryptographer, for example Thomas Pornin. – Gilles 'SO- stop being evil' Feb 29 '16 at 23:07

The fallacy in this question is that there is no such thing as “draining entropy”. (Not in any sense where you'd run out of entropy before the universe runs out of a lack of entropy to let you live in it.)

Any random generator designed for cryptography needs two elements: an entropy source, and a way to “smooth out” the entropy source. Entropy sources are not sources of random bits, they have biases that need to be kinked out. An unconditioned entropy source is no good for cryptography. Conditioning, i.e. turning an entropy source into a source of uniformly random bits, is done by a cryptographically secure pseudorandom number generator (CSPRNG for short). Once a CSPRNG has been seeded with enough entropy, it's good to go for at least a few lifetimes of the universe¹.

Linux's /dev/urandom uses a CSPRNG which is periodically reseeded with extra entropy. The periodic reseeding helps in case of a partial compromise of the machine that somehow leaks the internal state of the random generator.

Linux's /dev/random uses a CSPRNG which is periodically reseeded with extra entropy. (Sounds familiar?) Linux maintains an internal calculation that assumes that the CSPRNG algorithm is badly broken and leaks entropy at a rapid rate and blocks /dev/random. But if you don't trust the crypto behind the CSPRNG, you can't trust even what /dev/random gave you in the first place, or pretty much any other crypto that you'd be using.

So no, draining the entropy does not make your system more vulnerable in any way.

The only risk with Linux's /dev/urandom is that it happily gives you predictable output before it's been properly seeded. This isn't a concern for day-to-day use on a “normal” desktop or server computer because they save the entropy pool on disk. It is a concern if you have a freshly installed system, or a live system that boots from read-only media. (A live system is a bad place to generate long-term keys!) Once the system has enough entropy, that's forever.

If you want a professional cryptographer's take on this issue, you can read Thomas Pornin's or Thomas Hühn's.

¹ N bits of entropy take 2N calculations to figure out. If you generate a billion bits per second, and you start with a decent security level of 128 bits, 1 universe-life gives you time to generate about one sextillion bits, which is 296, comfortably below the limit.


No, constantly reading random bits from /dev/{u,}random} would not make it easier to attack other parts of the system. (That is, unless the attacker can predict the internal state of the generator from its output. But it's considered unlikely that anybody can.)

There will always be enough "randomness" available once the random number generator behind /dev/{,u}random (they are basically the same thing) has been seeded. Reading lots of random bits from the devices doesn't alter the internal state of the system's pseudo-number generator in a way that would decrease the quality of the generated number.

Quoting http://2uo.de/myths-about-urandom which was mentioned by @roaima in the comments:

What about entropy running low?

It doesn't matter.

The underlying cryptographic building blocks are designed such that an attacker cannot predict the outcome, as long as there was enough randomness (a.k.a. entropy) in the beginning. A usual lower limit for “enough” may be 256 bits. No more.

  • 1
    For the terminally paranoid (i.e., cryptographers and security buffs) "it is considered unlikely" is far from enough. – vonbrand Feb 29 '16 at 23:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.