Server Entropy

The source material this page replaces recommends installing haveged and pollinate to ensure sufficient random data for cryptographic operations. This was sound advice in 2014. In 2024, the situation has changed enough that following the original guidance without understanding the current context would install unnecessary software and potentially create a false sense of security.

This page explains what actually changed, what the current recommendations are, and what, if anything, needs to be done on the February server.

What changed in Linux 5.6

Before kernel 5.6 (released March 2020), /dev/random and /dev/urandom behaved differently. /dev/random would block if the kernel’s entropy pool was considered insufficiently full. /dev/urandom never blocked but was considered less secure. Cryptographic software that needed high-quality randomness used /dev/random, which caused visible slowdowns on freshly booted servers with limited entropy sources.

From kernel 5.6 onward, this distinction was removed. The kernel’s random number generator was fundamentally redesigned. /dev/random no longer blocks. Both /dev/random and /dev/urandom now use the same CSPRNG (cryptographically secure pseudorandom number generator), which is seeded from multiple entropy sources at boot and remains cryptographically strong throughout the system’s lifetime.

The kernel still gathers entropy from hardware events, hardware RNGs, and other sources, but the blocking behaviour that made entropy a practical concern for servers is gone. Ubuntu 24.04 runs on kernel 6.8 or later. The blocking entropy problem does not exist on this server.

Hardware RNG on the Ryzen 7 5700X

The Ryzen 7 5700X includes a hardware random number generator accessible via the RDRAND and RDSEED CPU instructions. The Linux kernel uses this automatically as one of its entropy sources. On modern AMD and Intel hardware, there is a constant stream of hardware-generated randomness feeding the kernel’s entropy pool.

Verify the hardware RNG is available:

# Check if RDRAND is supported
grep rdrand /proc/cpuinfo | head -1

# Check current entropy pool size
cat /proc/sys/kernel/random/entropy_avail

# Check pool size
cat /proc/sys/kernel/random/poolsize

On a modern kernel with RDRAND available, entropy_avail will typically show values close to poolsize consistently. This is normal and expected.

haveged: no longer recommended

haveged works by using CPU timing jitter as an additional entropy source. It was useful before kernel 5.6 when /dev/random could block. On modern kernels it adds marginal benefit at best, and there have been concerns in the cryptographic community about whether HAVEGE-generated randomness is of sufficient quality for all use cases.

The consensus among Linux kernel developers and security researchers since kernel 5.6 is that haveged is unnecessary on modern hardware. The kernel’s own entropy gathering is sufficient.

Do not install haveged on the February server or in containers. It is not needed and is not installed in the base container template.

pollinate: still useful, for a different reason

pollinate connects to a Pollen server on first boot and retrieves random data to seed the system’s entropy pool. The original rationale was to ensure enough entropy was available before blocking operations. The current rationale is subtly different.

On a virtual machine or LXC container, the hardware RNG may not be available (depending on whether it is passed through from the host), and the initial boot state of a container cloned from a template is somewhat predictable. pollinate adds external randomness from a trusted source during the first boot, which is a reasonable security measure even though /dev/random no longer blocks.

Install pollinate in the base container template:

sudo apt install -y pollinate

pollinate runs once on first boot. It does not need to run continuously.

To manually invoke it:

sudo pollinate -r

The -r flag reseed the entropy pool from the Pollen server.

For the Proxmox host (bare metal), pollinate is less important since the hardware RNG provides continuous entropy. Including it does no harm.

jitterentropy: kernel-level supplement

The jitterentropy_rng kernel module uses CPU timing jitter as an entropy source, similar in principle to haveged but implemented at the kernel level and considered cryptographically sound. It is compiled into or available as a module in modern Ubuntu kernels.

Load it if it is not already active:

modprobe jitterentropy_rng

Make it permanent:

echo jitterentropy_rng | sudo tee /etc/modules-load.d/jitterentropy.conf

Check if it is contributing to entropy:

cat /sys/devices/virtual/misc/hw_random/rng_available
cat /sys/devices/virtual/misc/hw_random/rng_current

rng-tools: optional for VMs and containers

For LXC containers where RDRAND is not passed through from the host, rng-tools configures the kernel to use available hardware RNG sources and can feed the /dev/random pool with data from /dev/hwrng:

sudo apt install -y rng-tools

Configure it to use the hardware RNG:

tee /etc/default/rng-tools-debian << 'EOF'
# Use the hardware RNG if available, fall back to jitterentropy
HRNGDEVICE=/dev/hwrng
RNGDOPTIONS="--hrng=hwrng --fill-watermark=90%"
EOF

sudo systemctl enable --now rng-tools

This is optional on physical hardware with RDRAND. On containers and VMs where the hardware RNG is not available, it provides a useful additional entropy source.

Regenerating SSH host keys after cloning

The base container template cleanup process removed SSH host keys, which are generated fresh for each container during first boot. When a container is cloned and started for the first time, SSH host keys are generated automatically. On a modern kernel with adequate entropy sources, these keys are generated with high-quality randomness.

Verify the SSH host keys were generated:

ls -la /etc/ssh/ssh_host_*

If the container was started before SSH host keys were regenerated (for example, if the cleanup step was skipped), regenerate them manually:

sudo ssh-keygen -A
sudo systemctl restart ssh

Verifying entropy quality

To verify the current entropy state of the system:

# Current entropy available
cat /proc/sys/kernel/random/entropy_avail

# Which hardware RNG is in use
cat /sys/devices/virtual/misc/hw_random/rng_current

# Entropy pool statistics
cat /proc/sys/kernel/random/read_wakeup_threshold

# Quick test of /dev/urandom performance
dd if=/dev/urandom bs=1M count=100 2>&1 | tail -1

On a Ryzen 7 5700X with kernel 6.8, you should see consistent entropy_avail values and /dev/urandom producing random data at hundreds of MB/s.

Summary for the February server

The entropy problem that the source material addresses was real in 2014. On kernel 6.8 with a Ryzen 7 5700X, it is not a practical concern. Understanding why it is not a concern is more useful than blindly following 10-year-old guidance that installs software designed for a problem that no longer exists.