Problem with /dev/random ?

[DetunizedGravity]

Hello all,

I had an issue, when setting a DNS server on my plug, with rndc-config that just hung up in the air doing nothing. It behaved as if blocked on an I/O.
So I had a shot at lsof...

xavier@majipoor:~$ rndc-confgen & lsof | grep rndc
[1] 1930
rndc-conf 1930 xavier  cwd       DIR  253,1     600 41339 /home/xavier
rndc-conf 1930 xavier  rtd       DIR  253,1    1312     1 /
rndc-conf 1930 xavier  txt       REG  253,1   13912 41845 /usr/sbin/rndc-confgen
rndc-conf 1930 xavier  mem       REG  253,1  121628  1140 /lib/ld-2.9.so
rndc-conf 1930 xavier  mem       REG  253,1 1251072 41787 /usr/lib/libdns.so.45.0.4
rndc-conf 1930 xavier  mem       REG  253,1  146496  1914 /usr/lib/libgssapi_krb5.so.2.2
rndc-conf 1930 xavier  mem       REG  253,1 1210776 17449 /lib/libcrypto.so.0.9.8
rndc-conf 1930 xavier  mem       REG  253,1  305628 41805 /usr/lib/libisc.so.45.0.3
rndc-conf 1930 xavier  mem       REG  253,1   13800  1224 /lib/libcap.so.2.11
rndc-conf 1930 xavier  mem       REG  253,1   75664  1431 /lib/libnsl-2.9.so
rndc-conf 1930 xavier  mem       REG  253,1  114725  1314 /lib/libpthread-2.9.so
rndc-conf 1930 xavier  mem       REG  253,1 1200748 19669 /usr/lib/libxml2.so.2.6.32
rndc-conf 1930 xavier  mem       REG  253,1 1201672  1322 /lib/libc-2.9.so
rndc-conf 1930 xavier  mem       REG  253,1   50816  1231 /lib/libgcc_s.so.1
rndc-conf 1930 xavier  mem       REG  253,1  498400  1864 /usr/lib/libkrb5.so.3.3
rndc-conf 1930 xavier  mem       REG  253,1  149116  1948 /usr/lib/libk5crypto.so.3.1
rndc-conf 1930 xavier  mem       REG  253,1    9648  1327 /lib/libcom_err.so.2.1
rndc-conf 1930 xavier  mem       REG  253,1   26360  1548 /usr/lib/libkrb5support.so.0.1
rndc-conf 1930 xavier  mem       REG  253,1    9744  1219 /lib/libdl-2.9.so
rndc-conf 1930 xavier  mem       REG  253,1    4948  1138 /lib/libkeyutils-1.2.so
rndc-conf 1930 xavier  mem       REG  253,1   71460  1311 /lib/libresolv-2.9.so
rndc-conf 1930 xavier  mem       REG  253,1   83612  1417 /lib/libz.so.1.2.3.3
rndc-conf 1930 xavier  mem       REG  253,1   13520  1220 /lib/libattr.so.1.1.0
rndc-conf 1930 xavier  mem       REG  253,1  673316  1335 /lib/libm-2.9.so
rndc-conf 1930 xavier    0u      CHR   4,64           498 /dev/ttyS0
rndc-conf 1930 xavier    1u      CHR   4,64           498 /dev/ttyS0
rndc-conf 1930 xavier    2u      CHR   4,64           498 /dev/ttyS0
rndc-conf 1930 xavier    3r      CHR    1,8           816 /dev/random

From what I could see, the obvious suspect was /dev/random, so I tried a simple cat /dev/random , which dave nothing. /dev/random does not output anything. I am not an expert of the /dev/random* devices but I can see that /dev/random DOES output random characters on my linux workstation. Moreover, asking rndc-confgen to use keyboard input to generate cryptographic keys made it work like a charm, what confirm what I thought.

The plug has been upgraded to kernel 2.6.30-rc6 / ubuntu 9.04 through the alpha 6 installer, and been kept up to date since using aptitude. I did not try using rndc before that so I cannot tell whether the stock kernel shows the same behaviour. I just upgraded to 2.6.30.3 (found on these fora) and the result is the same.

/dev/urandom seems to be working fine, curiously.

Any idea to fix/work around this, anyone?

[DetunizedGravity]

xavier@majipoor:/# cat /proc/sys/kernel/random/entropy_avail
0

Well, this does explain a lot. I read a bit about the functiong of /dev/random since posting, and I am not surprised that it blocks if its entropy store is empty.

Now, the next questions are why is it empty, and how can I change that?..

[birdman]

Now, the next questions are why is it empty, and how can I change that?..

You could try using /dev/urandom, which won't block (but won't be "as random" if not being fed enough randomness.

[DetunizedGravity]

Unfortunately, the fact that /dev/urandom always spit out as many bytes as it is asked does not mean that it works correctly. I had thought about that after I started reading about /dev/random and /dev/urandom, but as a matter of fact it is not a real solution: no entropy means the output of /dev/urandom would be anything but random. It would not be merely inferior to /dev/random, it would be theorically useless.

Further reading suggests that my setup (more precisely named) burns its entropy bits faster than it produces them. And that it may be a recurrent issue with such embedded systems. As it is, it may only rely on network activity for its entropy source: no keyboard, no mouse, etc... And I am not even sure that it does tap network. I also found a package adding the sound card as an entropy source. I might do just that, eventually: a USB sound card with a mic somewhere near the kitchen appliances...

But since it is a well known issuer, I trust people to give me pointers to the well known solutions

[dattaway]

Not cheap, because they aren't popular enough to mass produce:

http://www.araneus.fi/products-alea-eng.html

Its just a reverse biased diode read by a A/D.  But can be made for $1 on the board if you are handy with a soldering iron and several lines of code.

Some people have taken a simple smoke detector setup to count the time period between alpha particle emissions.

[DetunizedGravity]

Wow! Not cheap, indeed... And maybe a bit overkill. Isn't there really any compromise between no randomness and tripling the price of the hardware?!

I mean, this will become a real issue for this kind of embedded devices, since I predict a massive growth in the use of encryption technology by Joe Average, due to the arrival of IPv6 (IPSec, DNSSEC...) and of a bunch of upcoming braindead laws that mistake the knife (P2P) with the criminal.

At least, could someone explain to me how I can find whether this situation is due to a lack of network activity or a random device badly configured by default?

[birdman]

There is this Entropy Gathering Daemon, which might enable you to gather sufficient randomness?

[DetunizedGravity]

Thanks for the suggestion. I still see two problems with, though: the overhead (perl) and the need to patch/recompile/reconfigure any application in need of entropy. I had found other similar projects since yesterday, that almost all had the same issues. Some were interesting, though.

I think I have found a nice solution, in the form of a small daemon that directly feeds the system driver with entropy bits. They are generated from small variations in timing measures. It is written in C, has a very small memory footprint, and seems to work well. The same guy also proposes similar drivers using audio or video data as input, but since I'd rather not add hardware to the setup...

Main site: http://www.vanheusden.com
Timer based daemon: http://www.vanheusden.com/te/  << the winner
Audio based daemon: http://www.vanheusden.com/aed/
Video based daemon: http://www.vanheusden.com/ved/

So, as far as I am concerned, I have found a solution to my problem. The underlying issue of a stock kernel driver not being fit for embedded systems remains, though...

[birdman]

Your problem is not unique.
This just showed up on slashdot (haven't read any of it beyond the intro, yet...)

http://it.slashdot.org/story/09/08/03/2151225/Entropy-Problems-For-Linux-In-the-Cloud

[DamonHD]

Hi,

I built the code behind random.hd.org (downloadable from the site) to gather entropy in Java, in the first instance to an app that was generating secure/random transaction IDs, but it could be fed into the kernel if you wished.  It is based on the Entropy-Gathering Daemon.

You can also draw down some bits from random.hd.org if you wish, for example to help seed your kernel's /dev/random.

(I will be running one instance of random.hd.org on my plug, BTW, when it is going, as one of my public services!)

Rgds

Damon

[247electrical]

Nice informative post as enlightened me with my problem.

[mrsteveman1]

Hi everyone, I had this same problem so I wrote a little program that solves it completely. However, you need a cheap USB smart card that works in linux with OpenSC. I suggest an Aladdin eToken Pro 32k/64k from eBay, they're about $20 give or take.

Smart cards usually have a true random number generator in them, so it's just a matter of getting the card to spit that data out for you and then feeding it into the kernel using a kernel interface (RNDADDENTROPY ioctl).

Here is the code: http://xercestech.googlecode.com/files/cardrand.c

And here are instructions and more info if you need help: http://xercestech.com/smart-card-random-data-linux.geek

Essentially what this does is run in a loop, read random data out of the smart card (128 bytes / 1024 bits per second) and feed it into the kernel random pool so it is available from /dev/random. In my tests on a sheevaplug it keeps the kernel pool full most of the time, but you can check by running "cat /proc/sys/kernel/random/entropy_avail", on a stock plug that will show zero because there is no entropy, after running cardrand it should remain full most of the time and programs that need random data won't block anymore.