Linux – Is it wrong to link /dev/random to /dev/urandom on Linux

linuxrandomSecurity

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?

Best Answer

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.

Related Solutions

Is /dev/random data a psuedo-random AES cypher, and where does the entropy come from

Linux has two random number generators available to userspace, /dev/random and /dev/urandom.

/dev/random is a source of "true" randomness - i.e. it is not generated by a pseudo-random number generator. Entropy is fed into this by the input driver and the interrupt handler, through the functions add_input_randomness and add_interrupt_randomness. Processes reading this device will block if the entropy runs out.

/dev/urandom is a pseudo-random number generator. It is fed by the same entropy pool as /dev/random, but when that runs out, it switches to a cryptographically strong generator.

Userspace applications can feed into the entropy pool by writing to /dev/{,u}random.

Have a read of the random(4) manual page, and the file drivers/char/random.c in the kernel source tree. It is well commented and most of what you ask is explained there.

FreeBSD's /dev/random by default is a pseudo-random number generator using the Yarrow algorithm (but can point to a hardware RNG if one is connected). The software generator takes entropy from Ethernet and serial connections and hardware interrupts (changeable through sysctl kern.random). The Yarrow algorithm is believed to be secure as long as the internal state is unknown, therefore /dev/random should always output high-quality data without blocking. See random(4).

On NetBSD, /dev/random provides random data based only on entropy collected (from disks, network, input devices, and/or tape drives; adjustable using rndctl), while /dev/urandom falls back to a PRNG when the entropy pool is empty, similar to Linux. See random(4), rndctl(8), rnd(9).

OpenBSD has four generators: /dev/random is a hardware generator, /dev/srandom is a secure random data generator (using MD5 on the entropy pool: "disk and network device interrupts and such"), /dev/urandom is similar but falls back to a PRNG when the entropy pool is empty. The fourth, /dev/arandom, is also a PRNG but using RC4. See random(4), arc4random(3).

Mac OS X also uses the Yarrow algorithm for /dev/random, but has an identically working /dev/urandom for compatibility. "Additional entropy is fed to the generator regularly by the SecurityServer daemon from random jitter measurements of the kernel." See random(4).

RSA 2048 keypair generation: via openssl 0.5s via gpg 30s, why the difference

GnuPG consumes several bytes from /dev/random for each random byte it actually uses. You can easily check that with this command:

start cmd:> strace -e trace=open,read gpg --armor --gen-random 2 16 2>&1 | tail
open("/etc/gcrypt/rngseed", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("/dev/urandom", O_RDONLY)          = 3
read(3, "\\\224F\33p\314j\235\7\200F9\306V\3108", 16) = 16
open("/dev/random", O_RDONLY)           = 4
read(4, "/\311\342\377...265\213I"..., 300) = 128
read(4, "\325\3\2161+1...302@\202"..., 172) = 128
read(4, "\5[\372l\16?\...6iY\363z"..., 44) = 44
open("/home/hl/.gnupg/random_seed", O_WRONLY|O_CREAT, 0600) = 5
cCVg2XuvdjzYiV0RE1uzGQ==
+++ exited with 0 +++

In order to output 16 bytes of high-quality entropy GnuPG reads 300 bytes from /dev/random.

This is explained here: Random-Number Subsystem Architecture

Linux stores a maximum of 4096 bytes (see cat /proc/sys/kernel/random/poolsize) of entropy. If a process needs more than available (see cat /proc/sys/kernel/random/entropy_avail) then the CPU usage becomes more or less irrelevant as the feeding speed of the kernel's entropy pool becomes the relevant factor.

Best Answer

Related Solutions

Is /dev/random data a psuedo-random AES cypher, and where does the entropy come from

RSA 2048 keypair generation: via openssl 0.5s via gpg 30s, why the difference

Related Question