[Gllug] entropykey: why did nobody ever mention this thing before?

[Nix]

[not quite OT: the makers of this thing are very Linux-friendly,
 more specifically Debian-friendly ;) and it seems like the sort
 of thing Linux people might well need; also it's so nifty I have
 to rave about it]

I just bought an Entropy Key (from <http://www.entropykey.co.uk/>. Why
did nobody mention the existence of this thing before? Why is nobody
shouting about it from the rooftops? It's very rare I find a device that
plainly does everything *right*, with interface software I can't
complain about at all (free software, nice coding style, very good
documentation for both the hardware and software, easy network
export/import of entropy, flexible enough to do everything I can imagine
and easy to extend thanks to using a Lua-based inner loop, you name it).
The hardware design appears to be pleasantly paranoid, and the device
itself is plainly not made out of thin tinfoil as some of these things
are (dropping it on the floor isn't going to smash it).

And it fixes a real problem: headless boxes and VMs ending up with
sod-all entropy because pretty much nothing other than keyboard and
mouse input is considered an acceptable entropy source these days:
notably network cards aren't. Disk I/O patterns and interrupt patterns
are, but these do not provide much entropy at *all*, particularly not if
you've got a lot of memory so you hardly need to touch the disk in
normal operation, or if you're using a solid-state disk so have had to
stop the system collecting randomness from the disk timings entirely.
This tends to mean that all your headless servers end up almost devoid
of entropy, which is not good. Your VMs have even less chance of getting
meaningful entropy.


For comparison, I got a hardware random number source for a system at
work last year. It did generate a lot more randomness (far more than we
needed), but it cost about 800 quid, the client software only worked on
*one patchlevel* of Windows 2003 Server, it ate huge amounts of CPU time
even when nothing we could tell was calling upon randomness, it gave us
no statistical information at all (not even how much randomness it was
providing), it could not provide entropy to VM hosts or over the
network, the insides of the key were 'proprietary secrets' so as far as
I could tell it might as well be getting 'randomness' from a microphone
or something stupid like that... by comparison this is a breath of fresh
air.


There is one annoying bug, though: a tuning error in currently-released
versions of ekeyd causes lua to spend *all* its time in the garbage
collector, with every lua opcall causing multiple pointless GC
passes. This will doubtless be fixed shortly, but for now, for any ekeyd
users who might be here, here's a tiny patch, giving a >90% CPU time
reduction and knocking GC off the perf profiles entirely:

Index: 1.1.2/daemon/control.lua
===================================================================
--- 1.1.2.orig/daemon/control.lua	2010-08-01 23:57:16.000000000 +0100
+++ 1.1.2/daemon/control.lua	2010-08-02 00:19:50.385666250 +0100
@@ -819,6 +819,3 @@
 end
 
 debug.sethook(hookfunc, "", 100)
-
-gc("setpause", 50)
-gc("setstepmul", 500)
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug