OneRNG on Arch Linux

If your a Linux Crypto guy you probably care about your entropy.  If you don’t, you problably should.

I recently purchased a OneRNG device from the kickstarter project.  Unfortunately it didn’t work out of the box with Arch Linux.  This blog post documents what I hit and how I overcame some of the issues to get my OneRNG working.

First thing I did was install the prerequisites:

yaourt -S at python-gnupg rng-tools
sudo systemctl enable atd.service
sudo systemctl start atd.service

as per the instructions at http://onerng.info/onerng/.  Note that we do NOT enable/start rngd.service as the daemon management is done from the udev stuff.

I then downloaded the tar file from https://github.com/OneRNG/onerng.github.io/blob/master/sw/onerng_3.4.orig.tar.gz?raw=true, verified the md5sum and the sha256 sum, and installed it with slightly tweaked instructions:

tar -xvzf onerng_3.4.orig.tar.gz
cd onerng_3.4
sudo make install
sudo udevadm control --reload-rules

I now plugged in my OneRNG with my fingers crossed.  At this point it died.  I did some brief reverse engineering and ended up figuring out how the /sbin/onerng.sh worked.  I then tried to run it manually and got:

$ sudo bash -ax /sbin/onerng.sh daemon ttyACM0
[snip]
Exception in thread Thread-7:
Traceback (most recent call last):
File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
self.run()
File "/usr/lib/python3.4/threading.py", line 868, in run
self._target(*self._args, **self._kwargs)
File "/usr/lib/python3.4/site-packages/gnupg.py", line 753, in _read_response
result.handle_status(keyword, value)
File "/usr/lib/python3.4/site-packages/gnupg.py", line 284, in handle_status
raise ValueError("Unknown status message: %r" % key)
ValueError: Unknown status message: 'NEWSIG'
[snip]

This issue is logged upstream against python-gnupg and has been fixed but the current release doesn’t have it active. See the patch file at https://bitbucket.org/vinay.sajip/python-gnupg/commits/1337e6ce364f.

I manually applied the patch to /usr/lib/python3.4/site-packages/gnupg.py because I didn’t feel like rebuilding the package with the patch included.

Now when I unplugged the OneRNG and plugged it back in I noticed rngd successfully started in the background:

rngd -f -n 1 -d 1 -p /var/lock/LCK..ttyACM0 -r /dev/stdin

It is reading from stdin since there is an openssl pipe for aes whitening in front of it.  Unfortunately, removal didn’t result in the rngd process being killed. My udev foo is a little lacking so I hacked the onerng.sh script as follows:

--- /sbin/onerng.sh.orig        2015-06-20 21:27:33.000000000 -0700
+++ /sbin/onerng.sh     2015-07-04 16:31:45.478019740 -0700
@@ -158,7 +158,10 @@
 #      when something is removed kill the daemon
 #
 if [ "$1" = "kill" ]; then
-       if [ -e /var/lock/LCK..$2 ]
+       if [ -e /var/lock/LCK..ttyACM0 ]
+       then
+               kill -9 `cat /var/lock/LCK..ttyACM0`
+       elif [ -e /var/lock/LCK..$2 ]
        then
                kill -9 `cat /var/lock/LCK..$2`
        else

This enabled my pull of the OneRNG to kill the rngd process. Unfortunately this is a hack since if anything else used the OpenMoko ttyACM stuff it would kill it but I don’t have such things.  At this point I hit the “good enough for me” wall.

I verifed running

cat /dev/random > /dev/null

dimmed the LED on the OneRNG and I was good to go.  Time to regenerate my ssh hostkeys 😉