Recently, I purchased 5 entropy keys from http://entropykey.co.uk. They are hardware true random number generators using reverse bias P-N junctions. Basically, they time when electrons jump a depeltion zone in the junction, where a voltage is applied to the point of near breakdown. Basically, taking advantage of the random characteristics of quantum mechanics.
There are a lot of really interesting things about the keys that brought me to purchase them. First, is the fact that they use two junctions along with the XOR function to test for corellations. If corellations exist, then the keys shutdown. Second, they use skein 256 internally as an encryption mechanism to deliver the random bits to the kernel, where they are decrypted. The bits are encrypted to ensure that an attacker on the box cannot manipulate the bits. Third, the keys are protected physically against tampering. If the temperature is outside of operating range, the keys will shut down, and if the keys are opened, epoxy will spill out on the board, shorting the board, preventing operation.
Tollef Fog Heen is seeing about 4 KBps with his key. I hooked my keys up to my Raspberry Pi, and I'm only seeing about 2 KBps per key. However, when connected to my T61, or other computers, I see about 3.5-4 KBps. Installing haveged along side with the entropy keys on my Raspberry Pi, and I have a total throughput of about 150 KBps of random data.
To setup the entropy key, you will receive a package with a DVD, the entropy key, and a paper for the master password to decrypt the bits from the key. To get the keys setup, you will need to match the key ID "EKXXXXX" with the same ID on the paper, if you have multiple keys. Then, in Debian/Ubuntu, you can install the daemon to talk to the keys:
sudo aptitude install ekeyd
You will now have the userspace utility to talk to the keys. As you plugin each key into your computer, the ekeyd daemon will setup a device in /dev/entropykey/. My five keys show me:
$ ls -l /dev/entropykey/ total 0 lrwxrwxrwx 1 root root 10 Oct 4 07:04 Sf9sBkiDUkkSGBSH -> ../ttyACM0 lrwxrwxrwx 1 root root 10 Oct 4 07:04 Sf9sBkiDUkkTJRSH -> ../ttyACM4 lrwxrwxrwx 1 root root 10 Oct 4 07:04 Sf9tBkiDUkkHNBWH -> ../ttyACM1 lrwxrwxrwx 1 root root 10 Oct 4 07:04 Sf9tBkiDUkkJOBWH -> ../ttyACM2 lrwxrwxrwx 1 root root 10 Oct 4 07:04 Sf9vBkiDUkkTNBSH -> ../ttyACM3
Further, when using the ekeydctl userspace utility, you can see the status of each key:
$ ekeydctl list NR,OK,Status,Path,SerialNo 1,NO,Long-Term-Key is bad,/dev/entropykey/Sf9sBkiDUkkSGBSH,Sf9sBkiDUkkSGBSH 2,NO,Long-Term-Key is bad,/dev/entropykey/Sf9tBkiDUkkHNBWH,Sf9tBkiDUkkHNBWH 3,NO,Long-Term-Key is bad,/dev/entropykey/Sf9tBkiDUkkJOBWH,Sf9tBkiDUkkJOBWH 4,NO,Long-Term-Key is bad,/dev/entropykey/Sf9vBkiDUkkTNBSH,Sf9vBkiDUkkTNBSH 5,NO,Long-Term-Key is bad,/dev/entropykey/Sf9sBkiDUkkTJRSH,Sf9sBkiDUkkTJRSH
So, we need to setup the keys, and make them live, so we can start using the entropy that comes from them. By using the ekey-rekey userspace utility, I can setup each key with the master psasword sent on my card:
# ekey-rekey 'Sf9sBkiDUkkSGBSH' 'ajx1 b52m cHvd d51n e4tS fYPs g2p3 xDAZ IeYf jCYM kqWi'
Of course, I changed my master key in the example above. I only wish to show that the spaces are important when setting up your keys. Do this for each of your keys, and you should see something to the effect:
NR,OK,Status,Path,SerialNo 1,YES,RUNNING OK,/dev/entropykey/Sf9sBkiDUkkSGBSH,Sf9sBkiDUkkSGBSH 2,YES,RUNNING OK,/dev/entropykey/Sf9tBkiDUkkHNBWH,Sf9tBkiDUkkHNBWH 3,YES,RUNNING OK,/dev/entropykey/Sf9tBkiDUkkJOBWH,Sf9tBkiDUkkJOBWH 4,YES,RUNNING OK,/dev/entropykey/Sf9vBkiDUkkTNBSH,Sf9vBkiDUkkTNBSH 5,YES,RUNNING OK,/dev/entropykey/Sf9sBkiDUkkTJRSH,Sf9sBkiDUkkTJRSH
Your entropy pool is now being filled with real, true, random numbers. You can test this by looking at the raw random data, and when exhausting the pool, you can see how quickly it fills:
$ dd if=/dev/random count=1 | xxd
0+1 records in
0+1 records out
128 bytes (128 B) copied, 8.6482e-05 s, 1.5 MB/s
0000000: d932 fc37 089e 4229 81cd d433 4e62 472a .2.7..B)...3NbG*
0000010: 3383 1f64 9b33 5797 f001 aa9a b15d 6581 3..d.3W......]e.
0000020: 758f cb1c a797 a39a 37c8 db67 ae0b ff19 u.......7..g....
0000030: bf0e 891d 702e 2f58 cfd8 963d e499 13db ....p./X...=....
0000040: 5f48 f7d3 cdcc 2e52 e2fc 4685 ad38 68bd _H.....R..F..8h.
0000050: 6de3 917b 4627 4695 3371 3335 9304 0f7a m..{F'F.3q35...z
0000060: a540 62aa 01a6 1006 84b2 1cb5 23ce 790e .@b.........#.y.
0000070: 12fb 8edc 78a2 13bf 1780 eb7e 1fbf a400 ....x......~....
$ pv -a < /dev/random > /dev/null
[18.5 kB/s]
Lastly, it's probably a good idea to test the quality of bias existing in the random stream using the dieharder suite of tests, or the FIPS 140-2 tests with rngtest. I have run both. The tests are slow, so let them run for a while to collect a lot of data. However, after about 3-4 minutes, here is the output from rngtest. You will certainly want to let it run longer, like an hour or so:
# rngtest < /dev/random rngtest 2-unofficial-mt.14 Copyright (c) 2004 by Henrique de Moraes Holschuh This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. rngtest: starting FIPS tests... ^Crngtest: bits received from input: 27814504 rngtest: FIPS 140-2 successes: 1389 rngtest: FIPS 140-2 failures: 1 rngtest: FIPS 140-2(2001-10-10) Monobit: 0 rngtest: FIPS 140-2(2001-10-10) Poker: 0 rngtest: FIPS 140-2(2001-10-10) Runs: 1 rngtest: FIPS 140-2(2001-10-10) Long run: 0 rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 rngtest: input channel speed: (min=34.735; avg=79.156; max=675.401)Kibits/s rngtest: FIPS tests speed: (min=968.716; avg=4301.815; max=5622.121)Kibits/s rngtest: Program run time: 349417245 microsecond
{ 7 } Comments