I recently bought a Simtec Entropy Key.
It's a hardware randomness generator encapsulated as a USB device, the
size of a flash drive. It's good for any host or cluster that uses
a lot of kernel-provided random numbers (/dev/random), or does things
that cause the kernel to use a lot of random numbers. Opening a lot
of network connections, or generating session keys for public key
encryption. That kind of stuff. If the kernel has too little entropy
available to generate good random numbers, things will stall until it
gets some more.
The ekey gives you real random bits, not just software-produced pseudo-random numbers. In other words, it's some kind of magic.
I got the device in a DVD box, with a leaflet explaining how to install stuff, a CD with the software, an envelope with a secret key, and the actual device itself.
I read the leaflet, which said to install the ekeyd daemon first. I ignored the CD, since a) my laptop has no optical drive and b) the software is in Debian stable (squeeze) anyway, so apt-getting it is easier and faster.
I was utterly disappointed with the software. I didn't have to edit a single hard disk sector, or do a BIOS upgrade, or anything. Utterly, totally, boring. I had reserved an afternoon and evening for this, but I had to find something else to do instead.
After plugging in the device in a spare USB port, I opened the envelope and ran a command to specify the secret key. The key and host processors use encryption to make sure nobody can eavesdrop on the randomness -- that would give them an edge in cracking SSL and GPG encryption, I guess.
Here's an example of how it works. Before I plug in the device, the kernel has some, but not too much entropy available:
liw@havelock$ cat /proc/sys/kernel/random/entropy_avail
1053
A few seconds after the ekey is inserted:
liw@havelock$ cat /proc/sys/kernel/random/entropy_avail
3968
And here's the kicker: pretty much regardless of what I do, the entropy stays at about 4 kilounits (I don't know if it's bits or bytes, and I'm too lazy to check).
In the end, the only thing I can really complain about is the typography and layout of the leaflet. The text is clear enough, but it's laid out too densely. It needs more whitespace. Some pictures of bunnies or kittens would be nice, too.
The kernel has a maximum poolsize which is 4096 by default.
might help you see if that is the setting on your system too.
can be used to set it to other values.
.. and looking at the source, I think it's 0444 for everybody using the mainline kernel. https://github.com/torvalds/linux/blob/master/drivers/char/random.c#L1255
I think the idea of having a personal entropy source is a neat one. I've built one from scratch which can produce more than 100kB/s of bits; happily, it passes the DIEHARDER random number testing suite, and can also serve as an entropy source for linux. (hint: write the data to /dev/random and then ioctl RNDADDTOENTCT to say how many bits of entropy you estimate were in the data you wrote) Design files and python source: http://emergent.unpy.net/01257868826
The idea of using a shared secret to secure communication between the PC and the RNG dongle is one that hadn't crossed my mind. I could potentially add this to my design, but it would negatively impact the throughput (the AVR is pretty taxed already with the rudimentary whitening algorithm that I implemented, let alone doing robust secret-key crypto!)
Hi,
the unit is bits. The size of the pool has been constant for quite a while.
In recent kernels (not 2.6.18 / etch, but newer ones) spawning new processes also eats up entropy, for example for ASLR (Address Space Layout Randomisation).
And yes, I’ve been happy with my eKey for quite a loooong while now.