I'm currently testing gpg --genkey on a Linux VM. Unfortunately, this software seems to rely on /dev/random to gather entropy and politely asks the user to manually type screens after screens of cryptographically random input so it may eventually end-up with generating a key, and I've found no command-line parameter to tell it to use another file as entropy source (the guy on this video encounters the very same issue...).

However, the user should be free to choose to use /dev/urandom instead since there is nothing wrong with it. It is there mainly as a reminiscence of older PRNG algorithms which were weaker from a cryptographic point of view. For instance, while NetBSD manpage grants that the distinction may still be useful at very early booting stage, it describes such distinction as "folklore" and an "imaginary theory that defends only against fantasy threat models". Not anybody agrees with either the amount of entropy required by this command nor the fact that entropy is something which is actually actually consumed as stated in GPG manpage ("PLEASE, don't use this command unless you know what you are doing, it may remove precious entropy from the system!").

I've read about people installing the rngd daemon and configure it to use /dev/urandom as entropy source to feed /dev/random, but I find such practice heavily dirty.

I tried to workaround the problem in the FreeBSD way by removing /dev/random and linking it to /dev/urandom instead:

rm /dev/random
ln -s /dev/urandom /dev/random

I see this as a setting telling "I trust /dev/urandom as entropy source".

I feared I would encounter some error of some kind, but this seems to provide the expected result since the command now returns successfully immediately.

My question is: is there any known, practical and wrong side-effect of linking /dev/random to /dev/urandom on Linux systems as done by default on FreeBSD systems? Or could one envisage to set this permanently (in a script at the end of the boot process for instance) in case of repetitive issues due to /dev/random locking some service?


See Myths about urandom, there is no known attack on /dev/urandom that would not also be an attack on /dev/random. The main problem that a Linux system has is when it cloned and run as several VMs without resetting the saved entropy pool after the cloning. That is a corner case that tangential to what you want.


Well one thing different about /dev/random is that it stops output after the entropy pool is used. try this:

$ cat /dev/random
(a few short lines of gibberish)^C

/dev/urandom however will reuse the same pool to continue output. as shown here:

$ cat /dev/urandom
(tons of gibberish fills the screen)^C

(When you try to cat these special devices, your prompt might be messed up. Just type reset and enter, your terminal will be back to normal)

Use /dev/urandom when you just need to fill up something with a constant flow of "randomish" bits. Use /dev/random for keys that you need to be absolutely random.

  • 3
    The question of the OP was: is there any known, practical and wrong side-effect of linking /dev/random to /dev/urandom on Linux systems as done by default on FreeBSD systems? – countermode Oct 9 '16 at 20:13
  • Interesting, if the difference is this pronounced then they should not be linked. Most other discussions eventually reach consensus of no difference after boot up but this behaviour might indicate a longer lasting difference. – KalleMP Nov 19 '16 at 19:44

In Linux, /dev/random gives high quality random bits. They are derived from sources that are not predictable and not repeatable, external to the machine. In contrast, /dev/urandom uses the same random data as /dev/random (if available), if there is none, it uses a pseudo-random number generator, which is deterministic. For most purposes, it is unpredictable enough, but not for very demanding applications like cryptography, and much less for creating long-lived keys like for GPG.

  • 6
    This is wrong. /dev/urandom is fine for cryptography. – Gilles Feb 12 '16 at 21:52
  • @Gilles that depends on your degree of paranoia. For GPG, everybody is affected by your key (indirectly). – vonbrand Feb 12 '16 at 22:17
  • 5
    If you don't trust /dev/urandom, you have no reason to trust GPG either. – Gilles Feb 12 '16 at 22:24
  • 3
    @vonbrand: Depending on my degree of paranoia, if I have to choose between a mathematically checked PRNG to generate randomness or a user forced to type a full screen of garbage "asdfghasdfghasdfgh", I would by far choose the software PRNG. I understand your point that a computer is not good at generating randomness, but humans are even worse at it. Nevertheless, to come back to my question, except from the urandom vs. random debate, do you confirm that replacing the /dev/random file by a link should have no other side-effect and be a viable alternative to the rngd trick I mentionned? – WhiteWinterWolf Feb 13 '16 at 10:50
  • 2
    This is wrong. They use the SAME RNG, but random blocks if it guesses that there's not enough entropy. – Duncan X Simpson Aug 21 '16 at 3:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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