Self-Hosted Linux Hardware Entropy Management: haveged vs rng-tools vs jitterentropy-rngd

Linux systems depend on a steady supply of high-quality randomness for cryptographic operations — TLS handshakes, SSH key generation, GPG encryption, and secure token creation all draw from the kernel’s entropy pool. On virtual machines, embedded devices, and headless servers, the traditional entropy sources (keyboard, mouse, disk I/O) are often insufficient, leading to blocked reads from /dev/random and degraded system performance.

This guide compares three open-source entropy daemons — haveged, rng-tools, and jitterentropy-rngd — that feed additional randomness into the kernel pool, ensuring your self-hosted infrastructure never starves for entropy.

Understanding Linux Entropy

The Linux kernel maintains two character devices for random number generation: /dev/random and /dev/urandom. Historically, /dev/random would block when the kernel’s entropy estimate dropped too low, while /dev/urandom would continue generating output using its internal CSPRNG (Cryptographically Secure Pseudorandom Number Generator).

Modern Linux kernels (5.6+) have unified these — /dev/random no longer blocks after the initial CRNG (Cryptographic Random Number Generator) is seeded. However, early-boot entropy and virtual machine entropy remain real concerns. On a fresh VM boot, the CRNG may take seconds to initialize, delaying SSH key generation, TLS certificate creation, and other security-critical operations.

Entropy daemons solve this by providing additional, unpredictable input to the kernel’s entropy pool through the RNDADDENTROPY ioctl on /dev/random. Each tool uses a different method to gather randomness:

haveged: CPU Cache Timing-Based Entropy

haveged (HArdware Volatile Entropy Gathering and Expansion) exploits the inherent unpredictability of CPU cache behavior to generate entropy. It uses the HAVEGE (HArdware Volatile Entropy Gathering and Expansion) algorithm, which measures the variation in CPU execution timing caused by cache misses — a source of entropy that exists on virtually all modern processors.

Key Characteristics

• No hardware requirements: Works on any x86, ARM, or MIPS CPU
• High throughput: Can generate entropy at rates exceeding 1 MB/s
• Lightweight: Minimal CPU and memory footprint (~2 MB RAM)
• Well-tested: Included in many Linux distributions by default
• Docker image: docker.io/ghcr.io/jirka-h/haveged:latest

Installation and Configuration

1
2
3
4
5
6
7
8

# Debian/Ubuntu
sudo apt install haveged

# RHEL/CentOS/Fedora
sudo dnf install haveged

# Arch Linux
sudo pacman -S haveged

Docker Compose deployment:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

version: "3.8"
services:
  haveged:
    image: ghcr.io/jirka-h/haveged:latest
    container_name: haveged
    restart: unless-stopped
    privileged: true
    pid: host
    environment:
      - WATERMARK=1024
      - POOL_SIZE=8192
    volumes:
      - /dev:/dev

Configuration via /etc/default/haveged:

1
2
3

DAEMON_ARGS="-w 1024"
# -w: Watermark level (bits of entropy before daemon stops feeding)
# -n: Number of threads (default: 1)

Verifying Entropy Quality

1
2
3
4
5
6
7
8
9

# Check available entropy bits
cat /proc/sys/kernel/random/entropy_avail
# Should show values consistently above 1024

# Monitor entropy in real-time
watch -n 1 cat /proc/sys/kernel/random/entropy_avail

# Check haveged stats
sudo cat /proc/sys/kernel/random/write_wakeup_threshold

rng-tools: Hardware RNG Daemon

rng-tools interfaces with hardware random number generators (HWRNG) exposed by the kernel through /dev/hwrng. It reads entropy from dedicated hardware sources (Intel RDRAND, AMD RDRAND, TPM chips, or external HWRNG devices) and feeds it into the kernel pool.

Key Characteristics

• Hardware-dependent: Requires a hardware RNG source (most modern CPUs have one)
• Cryptographically validated: Uses certified hardware entropy sources
• Configurable quality testing: Runs FIPS 140-2 statistical tests on input
• Multiple source support: Falls back to /dev/urandom if no HWRNG detected
• Docker image: docker.io/linuxserver/rng-tools

Available Hardware Entropy Sources

1
2
3
4
5
6
7
8

# List available HWRNG devices
cat /sys/class/misc/hw_random/rng_available

# Check which HWRNG is currently active
cat /sys/class/misc/hw_random/rng_current

# Check HWRNG quality (0-1000 scale, 1000 = true hardware)
cat /sys/class/misc/hw_random/rng_quality

Installation and Configuration

1
2
3
4
5

# Debian/Ubuntu
sudo apt install rng-tools

# RHEL/CentOS/Fedora
sudo dnf install rng-tools

Docker Compose deployment:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

version: "3.8"
services:
  rng-tools:
    image: lscr.io/linuxserver/rng-tools:latest
    container_name: rng-tools
    restart: unless-stopped
    privileged: true
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=UTC
    volumes:
      - /dev:/dev
      - ./rngd.conf:/etc/rng-tools.d/rngd.conf:ro

Configuration via /etc/default/rng-tools:

1
2
3
4
5
6
7

HRNGDEVICE=/dev/hwrng
# Options for rngd
RNGD_OPTS="-o /dev/random -r /dev/hwrng -f"
# -o: Output device (kernel entropy pool)
# -r: Input RNG device
# -f: Run in foreground (for containers)
# -t: Interval between fills (default: 60s)

Quality Testing

1
2
3
4
5
6
7

# Run rngtest on raw entropy data
sudo dd if=/dev/hwrng bs=1 count=1024 | rngtest

# Expected output: no failed FIPS tests
# rngtest: bits received from input: 8192
# rngtest: FIPS 140-2 successes: 409
# rngtest: FIPS 140-2 failures: 0

jitterentropy-rngd: CPU Execution Jitter Entropy

jitterentropy-rngd is the daemon front-end for the jitterentropy library, which measures CPU execution timing jitter as an entropy source. Unlike haveged (which measures cache timing), jitterentropy focuses on the variation in execution time of carefully crafted CPU instruction sequences — a source of entropy that is independent of cache architecture.

Key Characteristics

• NIST SP 800-90B certified: The jitterentropy library has undergone formal entropy source validation
• FIPS 140-2 compliant: Suitable for regulated environments
• Hardware-independent: Works on any CPU architecture (x86, ARM, RISC-V)
• Lower throughput: ~100 KB/s vs haveged’s ~1 MB/s (but sufficient for most use cases)
• Active development: Maintained by a cryptographic engineer (Stephan Mueller)
• Docker image: Available via community images

Installation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Debian/Ubuntu (Debian 11+)
sudo apt install jitterentropy-rngd

# RHEL/CentOS 8+
sudo dnf install jitterentropy-rngd

# From source
git clone https://github.com/smuellerDD/jitterentropy-rngd.git
cd jitterentropy-rngd
make
sudo make install

Docker Compose deployment:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

version: "3.8"
services:
  jitterentropy:
    image: docker.io/library/debian:bookworm-slim
    container_name: jitterentropy-rngd
    restart: unless-stopped
    privileged: true
    command: >
      bash -c "
        apt-get update && apt-get install -y jitterentropy-rngd &&
        exec rngd --rng jitterentropy_rng --foreground
      "
    volumes:
      - /dev:/dev

Configuration

1
2
3
4
5
6
7
8
9

# /etc/default/jitterentropy-rngd
DAEMON_ARGS="--rng jitterentropy_rng --foreground"

# Or via systemd override
# /etc/systemd/system/jitterentropy-rngd.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/rngd --rng jitterentropy_rng --foreground
TimeoutStartSec=0

Performance Comparison

We benchmarked all three tools on a 4-core VM (Intel Xeon, 8 GB RAM) using cat /proc/sys/kernel/random/entropy_avail over a 60-second period:

Choosing the Right Entropy Daemon

Use haveged when:

• Running on virtual machines or cloud instances without hardware RNG
• You need maximum entropy throughput (high-concurrency TLS servers)
• Your CPU does not support RDRAND instruction

Use rng-tools when:

• Your hardware has a built-in RNG (Intel RDRAND, AMD RDRAND, TPM 2.0)
• You need cryptographically certified entropy for compliance
• Running on bare-metal servers with HWRNG devices

Use jitterentropy-rngd when:

• You need NIST SP 800-90B certified entropy source
• Operating in a regulated environment (FIPS 140-2 requirements)
• Running on ARM or RISC-V devices without hardware RNG

Why Self-Host Your Entropy Daemon?

Running your own entropy daemon ensures that every server in your infrastructure has reliable, high-quality randomness available from boot. This is critical for:

Data ownership and cryptographic integrity: When you control the entropy source, you control the foundation of all cryptographic operations on your servers. TLS certificates, SSH keys, encrypted databases, and secure tokens all depend on unpredictable random values. If entropy is insufficient, cryptographic keys may be generated with reduced randomness — a well-documented attack vector in embedded and virtualized environments.

Cost savings and operational simplicity: Rather than purchasing external hardware RNG devices for each server, software-based entropy daemons (haveged, jitterentropy-rngd) provide comparable entropy quality at zero additional cost. For most self-hosted deployments, the entropy generated by these daemons is more than sufficient for all cryptographic needs.

No vendor lock-in: All three tools discussed are open-source and available in standard Linux distribution repositories. There are no licensing fees, no cloud dependencies, and no vendor-imposed limitations on usage or throughput.

Compliance and auditability: For regulated environments, jitterentropy-rngd’s NIST SP 800-90B certification provides documented entropy source validation. rng-tools with hardware RNG provides FIPS 140-2 compliant entropy input. Both are suitable for security audits and compliance reviews.

For related reading on Linux security hardening, see our Linux security auditing tools comparison. If you’re interested in kernel-level security, check our Linux MAC frameworks guide. For TLS and certificate management, our TLS certificate automation guide covers automated certificate lifecycle management.

FAQ

What happens if a Linux server runs out of entropy?

When the kernel entropy pool is depleted, reads from /dev/random will block until sufficient entropy is gathered. This causes delays in SSH key generation, TLS handshake, GPG key creation, and any application that reads from /dev/random. On virtual machines, this can add 10-30 seconds to boot time. Modern kernels (5.6+) have mitigated this by making /dev/random non-blocking after initial CRNG seeding, but early-boot entropy starvation remains a concern.

Can I run multiple entropy daemons simultaneously?

Yes, running multiple entropy daemons (e.g., haveged + jitterentropy-rngd) is safe and can provide additional entropy. The kernel accepts entropy input from multiple sources via RNDADDENTROPY. However, for most use cases, a single well-configured daemon is sufficient. Running multiple daemons may slightly increase CPU usage without proportional entropy gains.

Is haveged’s entropy source cryptographically secure?

haveged’s HAVEGE algorithm has been analyzed by cryptographers and is considered suitable for general-purpose entropy feeding. It does not claim formal NIST or FIPS certification, but practical testing shows it produces output that passes standard statistical randomness tests (dieharder, NIST STS). For environments requiring formal certification, jitterentropy-rngd (NIST SP 800-90B) or rng-tools with certified hardware RNG is preferred.

How do I verify that my entropy daemon is working correctly?

Check /proc/sys/kernel/random/entropy_avail — it should consistently show values above 1024 bits. You can also use rngtest to analyze entropy quality: sudo dd if=/dev/random bs=1 count=512 | rngtest. A working daemon will show near-zero FIPS test failures. Additionally, dmesg | grep -i random will show CRNG initialization messages and any entropy-related warnings.

Do Docker containers need their own entropy daemon?

Containers share the host kernel’s entropy pool, so a properly configured host-level entropy daemon is sufficient for all containers. However, if you run containers on a host without an entropy daemon (e.g., a bare-metal host without HWRNG), running an entropy daemon inside a privileged container can help. The Docker Compose configurations above use privileged: true and mount /dev to access the kernel’s random devices.

What is the difference between /dev/random and /dev/urandom?

Historically, /dev/random blocked when entropy was low, while /dev/urandom did not. Since Linux 5.6, both devices use the same CRNG and neither blocks after initial seeding. For most applications, /dev/urandom (or the getrandom() syscall) is the correct choice. Entropy daemons primarily help with early-boot entropy, ensuring the CRNG initializes quickly even on entropy-starved systems like VMs and embedded devices.