Entropy matters

Summary: your system needs lots of entropy. It may not have it. You might be able to fix this.

your system needs lots of entropy

This page is meant to provide some helpful hints about Entropy. It is not meant to be exhaustive or definitive.

All modern cryptography depends on a supply of random numbers. Truly random numbers are quite hard to come by in computers.

Most computer languages have a function to yield a random number. Technically these are "pseudo-random numbers": ones generated by a deterministic function that has some nice properties shared with true random numbers (nice distribution, lack of correlation, etc.). What they lack is unpredictability. If a number is predictable it is useless and dangerous for cryptography.

True random numbers can be produced by coin tosses, lava lamps, measuring radioactive decay, and a number of other processes. But most of us don't want to build the apparatus to provide these measurements to our computers.

The normal approach is to have some sources of entropy feed into a mixing and stretching process to generate lots of random numbers starting with a modest source of entropy (true randomness).

your system might not have enough entropy

As a crude monitor, run this shell command:

 while sleep 3 ; do cat /proc/sys/kernel/random/entropy_avail ; done

On a server that ran into entropy scarcity, Hugh got a sequence of one or two digit numbers. After enabling TPM as an entropy source, numbers just above 3000 were normal.

sources of entropy on normal Linux systems

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/char/random.c

timing keyboard and mouse events

This is great when these events are available. But servers don't generally have this activity and even workstations may not have this activity when entropy is needed.

timing disk operations

It isn't obvious that these are random enough. Especially now that spinning disks are being replaced by solid state drives.

timing network packet arrival

This is the kind of thing that an opponent might actually control.

hardware Random Number Generators provided by CPU

Recent Intel and AMD processors provide RdRand hardware. Some other processors have similar facilities. (Some suspect that these may have been compromised by design and there is no way to know.)

You can tell if you have the Intel or AMD generator by looking for "rdrand" in /proc/cpuinfo.

Other CPUs might have hardware random number generators. For example, the Raspberry Pi does.

hardware Random Number Generator provided by TPM

Some computers come with a TPM unit https://en.wikipedia.org/wiki/Trusted_Platform_Module

One of the functions of a TPM is providing entropy. (A TPM RNG might well have been compromised by design and there is no way to know.)

Unlike the previously mentioned sources, TPM is not by default used as an entropy source by Linux

other sources

A lot of projects and companies produce peripheral that are intended to supply entropy. We have no experience with these but some are probably a good idea. The simpler and the more transparent, the easier it is to build trust.

It's not clear how much entropy is really produced by [[1]]. There are packages available for many distros.

plumbing entropy

In most Linux distros, the random number infrastructure is already configured reasonably. But it is confusing.

/dev/random and /dev/urandom provide random bytes to programs, from the kernel.

rngd (a daemon) gathers entropy and feeds it to the kernel.

/dev/hwrng is a collection of hardware entropy that provides entropy to rngd.

/dev/tpm0 is the TPM device. Although rngd has code to access it, it doesn't work on many systems because /dev/tpm0 only allows one program to use it and /dev/tpm0 is used by the tcsd daemon.

Kernel module tpm_rng is a kernel module that shovels entropy from the TPM to /dev/hwrng. This module may not be loaded by default.

using TPM entropy on Fedora 23

Not all machines have a TPM. This assumes that you have one.

If your machine does not have RdRand, the rngd daemon probably failed on boot. Check with "systemctl status rngd".

The TPM device must be configured.

• (optional) check how much entropy your system has
• in the firmware setup screen, enable the TPM
• in Linux, install packages trousers, tpm-tools, and rng-tools
• run the command tpm_takeownership. If you don't want to do anything but use it for entropy, it is probably safe to use degenerate passwords via the -x and -y flags. Otherwise, figure out what you do want.
• echo "tpm-rng" >>/etc/modules-load.d/tpm-rng.conf
• reboot
• check that rngd is running and happy: systemctl status rngd
• (optional) check how much entropy your system has

references

http://lwn.net/Articles/525459/ LWN: LCE: Don't play dice with random numbers

https://en.wikipedia.org/wiki/RdRand description of the x86 random number hardware

https://outflux.net/blog/archives/2009/10/22/tpm-as-rng/ early experience with TPM as entropy source for Linux. Outdated.

http://blog.pcfe.net/octopress/blog/2011/11/04/tpm-to-feed-random-number-generator/ TPM as entropy for Linux. Useful but outdated.

https://bugzilla.redhat.com/show_bug.cgi?id=921122 old bug about tcsd and rgnd both trying to use /dev/tpm0 (not possible)

https://sourceforge.net/projects/gkernel/ where rngd lives

https://bugzilla.redhat.com/show_bug.cgi?id=892178 bug report (and fix) with rngd being run by systemd

https://sourceforge.net/projects/trousers/ TrouSerS project

http://www.chronox.de/lrng/doc/lrng.pdf proposal for changes to Linux's RNG