Creating DNSSEC keys requires a lot of random data. If you run dnssec-keygen and it appears to hang (particularly when on a virtual machine), the program is actually waiting for entropy (i.e. “randomness”) to be made available in /dev/random. (For dnssec-keygen this can actually be faked, by passing the program a file from which it should consume the random data, but I certainly don’t recommend you do that.)

As a solution to the lack of entropy on a machine, I frequently use a small program called haveged, and this also works very nicely on virtual environments. (At least on KVM and VMware; I couldn’t get it to work in OpenVZ containers.) It

attempts to provide an easy-to-use, unpredictable random number generator based upon an adaptation of the HAVEGE algorithm.

Nevertheless, I wanted to experiment with a true random number generator, and had heard that the Entropy Key is quite affordable, so I ordered one. Delivery took almost four weeks to the day (!), and it arrived in a DVD box which contains a leaflet, a CD, a Master Key Card, and the USB hardware device itself.

Entropy Key delivered

The key generates high-quality random numbers. It is not a PRNG, but a true random number generator.

Before starting, I checked that the available entropy was almost non-existent (which it often is)

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

$ dd if=/dev/random of=/dev/null bs=1k count=1
0+1 records in
0+1 records out
8 bytes (8 B) copied, 0.457535 s, 0.0 kB/s

In addition to that, I ran a dnssec-keygen command, which immediately blocked waiting for entropy; this proves I have no other source of randomness filling /dev/random.

I followed the easy instructions on the leaflet and installed the software on a current Ubuntu 11.10, and plugged the key into a spare USB slot, and checked that the key had been recognized the by the ekeyd daemon. (This all really is terribly easy, as Lars Wirzenius amusingly describes :-)

# ekeydctl list
1,NO,Long-Term-Key is bad,/dev/entropykey/M_pb8733NzEjViFD,M/pb8733NzEjViFD

The “NO” means the key isn’t ready for use, because I have to initialize it with a so-called Long Term Key which is printed on the Master Key Card provided with the key. I’m also informed I should not loose this card: it’s the only copy and the manufacturer cannot replace it.

# ekey-rekey 'M/pb8733NzEjViFD' 'Sb/d aev0 ejZk oFf8 1hqE YnkL jWcy RgEb T2wc 5zwT HFMH'
Specified Entropy Key Serial: M/pb8733NzEjViFD

# ekeydctl  list
1,YES,Running OK,/dev/entropykey/M_pb8733NzEjViFD,M/pb8733NzEjViFD

The Long Term Key appears to have been accepted: the device is now ready (“YES”). I can also look at some statistics on the USB key, including its current temperature:

# ekeydctl  stats 1
KeyEnglishBadness=No failure

Does it work, i.e. does it produce entropy? Yes, it does:

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

Running several incantations of dnssec-keygen xxx don’t purge the pool of random data, so as far as I can tell, the device is working.

I do note however, that consuming this randomness from /dev/random is slower with the Entropy Key than when using haveged, and I have no idea why that is so. The following two commands I ran first with haveged running, then with the Entropy Key:

$ time dd if=/dev/random of=rnd2 bs=1M count=1 iflag=fullblock
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.698756 s, 1.5 MB/s

real	0m0.703s
user	0m0.000s
sys	0m0.680s

$ time dd if=/dev/random of=rnd bs=1M count=1 iflag=fullblock
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 278.005 s, 3.8 kB/s

real	4m38.011s
user	0m0.020s
sys	0m1.852s

For those wanting support for EGD, the TCP protocol defined by the Entropy Gathering Daemon, the ekeyd package also includes ekeyd-egd-linux. To use that, with the Entropy Key, I

  • modify the /etc/entropykey/ekeyd.conf file (which, by the way, is a Lua fragment):
-- SetOutputToKernel(7)
EGDTCPSocket(8888, "" )
  • Launch ekeyd which now reads the key and provides the EGD socket
  • Launch ekeyd-egd-linux, the beast which reads from the EGD socket and populates /dev/random
  • I can use other EGD clients on the network, taking into account that the entropy is passed around unencrypted. (Which is what the Entropy Key is trying to avoid in the first place…)

Update 2012-05-02:

I had some trouble getting ekeyd-egd-linux to actually push entropy into /dev/random after moving my setup (Entropy Key and configuration) to a Centos 6.2 box. I asked for help on the Entropy Key mailing-list and it turns out ekeyd-egd-linux uses watermarks to decide when to request entropy from the server. The solution consists of adding the following line to /etc/sysctl.conf.

kernel.random.write_wakeup_threshold = 1024

Thank you to the guys at Simtec for their help on this. (And if I’d RTFM …)

Further reading:

DNSSEC, keygen, and entropy :: 24 Jan 2012 :: e-mail