Image of the glider from the Game of Life by John Conway
Skip to content

Haveged - A True Random Number Generator

I admit that my last post sucked. I've been working on a few things that I want to blog about, but it's going to take time to get all my ducks in a row. So, that post was mostly "filler". Read as "I haven't blogged in a while, and should probably put something up".


However, I finally have something you can sink your teeth into: true random number generation. Consider the following scenario: you wish to generate a long-term cryptographic key. Maybe an OpenPGP key, an SSH key, an SSL key, OTR, whatever. What sucks, is some utilities rely on the Linux kernel software device /dev/random as a source of randomness to get their seed or numbers. However, /dev/random will block, or stop responding, when the system's entropy estimate is low or exhausted. So, you sit and wait, maybe moving your mouse around and mashing your keyboard, to generate more entropy for the system.

I personally keep an encrypted file with all the passwords for all the servers, web sites, and accounts that I login to. On a regular basis, I'll rotate through the passwords. So, I typically will use my Password Card as a source for these passwords. But, suppose I wanted to use a password generator instead. The "apg" tool is a good solution.

On your system, run the following:

$ for i in {1..100}; do apg -a 0 -m 12 -x 16 -n 1; done

This will generate 100 passwords of varying length between 12 and 16 characters. Further, it will use a new seed for each of the newly generated passwords. Compare this to passing the '-n 100' switch, which will use a single seed for all 100.

You'll likely notice that the generation is slow. If you walk away from your computer, this could take 15 minutes, at least, probably much longer. If you babysit the process, you could probably get it finished in a minute or two. Regardless, it sucks.

We are draining our entropy pool faster than we can keep it filled. So, we must use external, unpredictable events, such as mouse movements, to generate entropy faster. Now, there are hardware true random number generators we could deploy, such as the Entropy Key from Simtec Electronics in the United Kingdom. However, there is a software daemon we can start that can use our existing hardware as a source of true randomness.

That software is haveged. I won't go into the nitty-gritty about haveged. However, I have run this against a slew of random number tests, and it has passed with flying colors every time. And, as you can write to the /dev/random device, haveged can keep the pool filled. So, the question is, how full can the pool be?

$ cat /proc/sys/kernel/random/poolsize
$ cat /proc/sys/kernel/random/entropy_avail

So, by default, the entropy poolsize is 4096 bits, and I only have 109 bits available to the system. Not much. Haveged can fix this:

$ sudo aptitude install haveged
$ cat /proc/sys/kernel/random/entropy_avail

Much better. Now, how quickly will my previous command of generating 100 password execute? With haveged running, it took about 2 seconds. And, our entropy remains filled.

Try doing this with generating a 4096-bit RSA GnuPG keypair. Without something keeping the entropy pool filled, this can take hours. With haveged running, I can generate it in a minute flat on this wimpy netbook.

Now, if you're skeptical of haveged, and you should be, you can test it against dieharder. However, it will take a while to run. I walked away and did other things while it was running. When comming back, I see that every test passed, except one, which came back as "WEAK". So, from my perspective, haveged produced very high quality random bits.

Now, what are the benefits? Do you run a lot of SSH connections to a single server? How about doing regular backups with rsync over SSH? Maybe you have a busy VPN or HTTPS server. It's not uncommon for these real world, common scenarios to produce timeouts or hang, because the entropy pool has been exhausted, the system must wait for more before continuing. Using haveged fixes this without issue. Even better, haveged barely uses system resources. Your idle ssh connection is likely adding more to the load than haveged. And it's true random bits.

{ 10 } Comments