Reading from `/dev/random` (true randomness) will block if there is insufficient system entropy available. You can read the currently available amount via `cat /proc/sys/kernel/random/entropy_avail`.
If you have an SLA that guarantees true randomness, and a certain response time or availability, you cannot really afford to block indefinitely while Linux builds up more entropy via its natural mechanisms.
Augmenting with haveged is pretty common, all it does is add more sources of randomness. I was hoping that jitter entropy (which seems kinda like the same thing) would alleviate the need to install one more package in these cases, but it's not clear. I will have to try it out sometime.
/dev/random and /dev/urandom provide the same kind of randomness. The difference is that, for 99.999% of developers, /dev/random blocks for no good reason.
All haveged does is pollute the kernel entropy pool to make /dev/random less unstable in production.
No, it's not. The old man page was incredibly confusing and misleading and has created a weird culture of fear around a simple issue.
What you care about is whether the RNG is securely seeded or not. Once it is, you don't care anymore. Think of an RNG like a stream cipher (which is what many of them are under the hood). Key AES-CTR with a 128 bit random key and run it to generate all the "random bytes" you will ever realistically use in any usage scenario. AES never "runs out of key". In the same way, a CSPRNG never "runs out of entropy".
We regularly re-key the system CSPRNG (by updating it, in the kernel, with "more entropy"), but not because entropy is depleted; rather, because it provides a measure of future security: if our machine is compromised, but only briefly, we don't want attackers to permanently predict the outputs of the RNG.
What you want are random/urandom interfaces that block at system startup until the RNG is seeded, and never again. What you do not want are userland CSPRNGs and CPSRNG "helpers"; those aren't solving real problems, have in the past introduced horrible security vulnerabilities, and perpetuate confusion about the security properties we're looking for.
Sign one X.509 certificate or ten million of them; the same initial secure dose of "entropy" will do just fine.
An archived email to a mailing list from one person in 2013 that can never be corrected or amended isn't the most reliable way to spread information about cryptography engineering.
What does Gutmann say in 2019 about /dev/urandom vs /dev/random?
Which of the two do JP Aumasson (author of Serious Cryptography and inventor of several cryptography algorithms used today, including BLAKE2 and SipHash), Dan Bernstein (Salsa20, ChaCha20, Poly1305, Curve25519, Ed25519, etc.), Matthew Green (professor associated with the TrueCrypt audit), et al. prefer in their own designs?
I can promise you the answer is /dev/urandom. Why do they prefer /dev/urandom? Because of the reasons outlined in the article I linked (which, unlike the mailing list post you linked, is occasionally updated with corrections).
It's not really that complicated: Use /dev/urandom.
If you're on an ancient Linux kernel, you can poll /dev/random until it's available if you're uncertain whether or not /dev/urandom has ever been seeded. Once /dev/random is available, don't use /dev/random, use /dev/urandom. This side-steps the "/dev/urandom never blocks" concern that people love to cite in their fearmongering. This is essentially what getrandom(2) does.
If you're on a recent Linux kernel, you can say "just use getrandom(2)" instead of "just use /dev/urandom", but the premise of the discussion is whether to use /dev/random or /dev/urandom not which of all possible options should be used.
It's worth maybe providing some detail as to why, so I will do so.
Entropy is a measure of unexpectedness present in a system. It is not a property of the data you have, but the physical system that generates some signal, called information content. In other words, a given password doesn't have entropy, but the process that generates it does. What this measures is how unexpected an outcome is on average. If it produces the same outcome every single time, it has no entropy because you know exactly what it will do. The best you can do is a 50% chance any bit will be 0 r 1 - you can't get more unexpected than this. Failure to achieve something close to this is called having biais and the result is that you must go directly to the NSA. Do not pass go, do not collect 200 dollars.
Then you have functions called deterministic random bit generators. These are deterministic - they behave the same way for a given set of input parameters. They also produce a stream of output that is sufficiently random-looking for cryptographic use. They can produce very large volumes of this - up to 2^44 blocks of entropy for example from NIST's CTR_DRBG before you have to abandon this stream and start again.
The entire sequence of random bits has exactly the same entropy as the seed that started it. I said data doesn't have entropy and I stick by it: the process has expanded beyond "sample environmental data" to "sample environmental data and shove it through a function good enough for cryptographic pseudorandomness then generate a nice big 2^44 128-bit blocks of data from that". The _entire output_ has the same entropy, as it is part of the same process.
I'm not saying the linux kernel does this exactly, more using it as a simple explanation for what I'm about to say - once you've got some entropy up to some nice amount like 256 bits you can use this as a seed for a deterministic random bit generator. What you get is a huge stream of randomness, almost certainly unique to you never to ever be seen again. And you only needed a very small amount of real entropy from hardware to get so much you will never run out.
Of course, there is nothing stopping you from "reseeding". You constantly have more entropy available and there's no harm mixing more into what you're generating (more entropy available comes from doing some more sampling of the environment and throwing this in).
Entropy is never used up. The randomness you get from /dev/random is not better. The randomness from a €1000 euro quantum random number generator is not better. Randomness doesn't rot like eggs and it is not known to the state of california to cause cancer. In fact, if you generate a key, it isn't random. It's known. It's static. What you get is some data that was generated with a certain amount of "surprisingness" in the process involved in getting it. If you repeat the process, you get more. There are obviously limits to the amount you get depending on the amount of data you ask for, because there are only finite possible outcomes, so it can only be on average so surprising. So you ask for enough that there are sufficiently many outcomes that if you could enumerate them all, you could also bruteforce AES by trying every possible key (we would not have enough energy to do this if we converted the entire mass of the earth to energy to power a classical quantum computer, let alone to do it before the heat death of the universe) - approximately speaking this will have more than enough entropy.
Throwing away those generated seeds because a single application has used them is extraordinarily wasteful and stupid because there is no need to wait. You can use that seed and the massive amount of "permutations" it generates in the DRBG for pretty much ever - I mean, unless of course you happen to need 2^44 or so 128-bit AES keys (that's over 2500 aes keys for everyone on earth). In that case, you can basically start generating them while you wait for another seed in your own time. You can probably nip to the beach or leisurely read a book. You'll still have enough time for your random process to give you another seed generated with a process of suitable entropy about a billion times over and then you've got so much cryptographic-quality random material it's like leaking out of your computer all over the floor!!!! Bits! Bits everywhere? Have you ever spilt rice? Kinda like that!
I endorse the above answer by Scott entirely, especially the bit about using /dev/urandom. This applies to any desktop or laptop computer system and probably most smartphones. The only time you can have problems is in getting the initial seed in the first place, and this only happens in embedded contexts with little variation in their runtime and no way to observe environmental noise and in this case /dev/urandom is preferred because getting more seeds is hard work and basically requires more time waiting for data to be seen. So /dev/urandom is objectively the better choice.
Perhaps you don't care, but OpenSSL's new random number generator is based on NIST's CTR_DRBG. It samples entropy from the environment using the approximations I have glossed overhere (it matches the NIST Special Publication's entropy estimation methods). They then generate a master source CTR_DRBG for the application context. Every SSL context object gets its own CTR_DRBG seeded from the master one, which is also valid to do! I told you! Randomness all over the kitchen floor like the bag of rice I just dropped so much of it you can't even vacuum it all up again how did it get in my washing exactly!!!????
If you have an SLA that guarantees true randomness, and a certain response time or availability, you cannot really afford to block indefinitely while Linux builds up more entropy via its natural mechanisms.
Augmenting with haveged is pretty common, all it does is add more sources of randomness. I was hoping that jitter entropy (which seems kinda like the same thing) would alleviate the need to install one more package in these cases, but it's not clear. I will have to try it out sometime.