I'm going to attempt to summarize everything I learned about this subject, thanks to the information and references provided by previous answers, as well as the research they spawned.
Ultimately, the logic behind the warning is twofold (and mostly specific to Linux -- see "Another NOTE" below):
The main crux of the issue stems from the way the Linux operating system in particular implements it's /dev/random
pseudorandom number generator (PNG) as a "blocking device". A "blocking device" means it will not give you any output if the entropy pool is depleted, which can be a serious problem if your system is relying on output from that device (see below for explanation of Linux entropy pool). Your server could lock up and stop replying to page requests until the pool is replenished, which could be a very long time on "headless", diskless systems (like servers) because they have very few external sources of entropy.
The second issue is that this function pulls directly from /dev/random
, and it is implemented in such a way that it draws a significant amount of entropy, particularly when set to use the quality level of 2. An email cited in a previous question implies that using a quality level of 2 draws 19x more bits of entropy than commanded from /dev/random
. Therefore, it can cause your system to deplete its entropy pool very quickly, causing /dev/random
to block, and causing /dev/urandom
to output not-so-random numbers.
So, ignoring this warning can be like doing a DoS attack on yourself.
The Linux Entropy Pool and /dev/(u)random
:
(For another great explanation on this subject, read this)
In Linux, you have two cryptographically-secure PNGs: /dev/random
and /dev/urandom
. Both of them draw from the "entropy pool", which gets "filled" by things considered random for all intents and purposes: system events, mouse clicks, device drivers, and other environmental noise. The pool is "emptied" when it is used to create pseudorandom numbers. An estimator keeps track of how much entropy is in this pool. Here's an analogy that might help: the system events and environmental noise are sort of like rolling a pair of dice, and the entropy pool is where you write down the numbers you rolled. The estimator is sort of like a count of how many times you've rolled the dice. From there, both /dev/random
and /dev/urandom
use hashing functions and other functions to "stretch" the entropy in the pool to be able to generate a lot more numbers than what is actually in the pool. (see @JohnDeters post where he explains the "sponge function").
NOTE: The term "entropy" here is being used somewhat loosely compared to the theoretical idea of "true" randomness/entropy, which is probably only found in quantum physics. For the purposes of computing, "entropy" tends to refer to things that seem random, and are extremely hard to predict. A closed software environment (i.e. the Linux operating system) must rely on things like environmental noise to "feed randomness" into the closed system. These environmental events are very hard for an attacker to observe, let alone predict, so they are considered sufficently "random" to fill the entropy pool. The closest thing to pure randomness for computers comes from a hardware random number generator. It uses measurements of things like electrostatic noise and even radioactive decay to seed your entropy pool.
The difference between the two devices is that /dev/random
is considered theoretically stronger because it will not let you get any output if there is no entropy stored in the system. In contrast, /dev/urandom
will use a hash function (SHA1, seeded from /dev/random
) to continue to generate pseudorandom numbers even after it has depleted the pool, and there is no warning when the pool is empty. At that point, you are relying on the security of the hash function to prevent attackers from being able to reverse engineer the last random seed, and thus be able to predict the next pseudorandom number. However, they can only accomplish this if they can keep the pool exhausted until the next number is generated. In practice, using /dev/random
is often viewed as overkill, although this is a hot-button issue.
Another NOTE: This construct (having /dev/random
as a blocking device) is specific to Linux. BSD and Mac OS X both feature implementations that don't allow it to block. In those implementations, /dev/random
is basically the same thing as dev/urandom
, with some other special algorithmic features that keep it secure as long as it continues to be seeded somewhat regularly. So use whatever makes you happy, because it's the same either way. The developers of those systems are obviously of the camp that their implementation of the entropy pool is secure enough for all applications, present and future, and it's not worth the cost of dealing with the denial of service caused by blocking.
Bottom Line: Heed the warning when using the gpg --gen-random
function, particularly if you are on a Linux system that relies on cryptographic security for other users. Furthermore, it's best to use /dev/urandom
for almost everything with the exception of initial seeding of a fresh installation of the Linux kernel, and maybe cryptographic keys being used to guard national secrets for decades.