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.
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)
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 :-)
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.
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:
Does it work, i.e. does it produce entropy? Yes, it does:
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:
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):
- 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
.
Thank you to the guys at Simtec for their help on this. (And if I’d RTFM …)
Further reading: