Entropy matters

From Libreswan
Revision as of 21:04, 25 July 2022 by Andrew Cagney (talk | contribs) (cut/paste testing entropy section to here)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

Every three seconds, it prints the kernel's estimate of the number of bits of entropy in the pool. If the estimate is accurate, one should be comfortable with values of a few hundred or more.

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.

Install an entory package

Fedora 32 comes with rng-tools pre-installed.

With KVM, a guest systems uses entropy from the host through the kernel module "virtio_rng" in the guest's kernel (set above). This has advantages:

  • entropy only needs to be gathered on one machine (the host) rather than all machines (the host and the guests)
  • the host is in the Real World and thus has more sources of real entropy
  • any hacking to make entropy available need only be done on one machine

To ensure the host has enough randomness, run either rngd or havegd. The old jitterentropy-rngd code has been merged into rng-tools' rngd.

Fedora commands for using rngd:

sudo dnf install rng-tools
sudo systemctl enable rngd
sudo systemctl start rngd

Fedora commands for using havegd:

sudo dnf install haveged
sudo systemctl enable haveged
sudo systemctl start haveged

sources of entropy on normal Linux systems


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.


The havege daemon is another approach to gather entropy from timing interrupts. There are packages available for many distros. It is not clear to us whether this is real entropy in the quantities claimed.

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.

There are also projects to improve entropy collection in Linux from ordinary computer hardware.

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

Note: something changed after Fedora 23. On Fedora 28 there is not tpm-rnd module. Somehow /dev/hwrng can use TPM but we do not know how to configure this.

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 and start tscd daemon
dnf install trousers tpm-tools rng-tools
systemctl start tcsd
systemctl enable tcsd
  • 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 -y and -z flags. Otherwise, figure out what you do want.
  • specify that the tpm-rng kernel model should be loaded on boot
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


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

https://www.certdepot.net/rhel7-get-started-random-number-generator/ RHEL7 and random numbers

https://www.kernel.org/doc/Documentation/hw_random.txt kernel's on documentation about random numbers