{"id":2500,"date":"2012-10-17T21:34:40","date_gmt":"2012-10-17T21:34:40","guid":{"rendered":"http:\/\/really.zonky.org\/?p=2500"},"modified":"2012-10-22T18:12:19","modified_gmt":"2012-10-22T18:12:19","slug":"debian-adding-entropy-to-devrandom","status":"publish","type":"post","link":"https:\/\/really.zonky.org\/?p=2500","title":{"rendered":"Debian: Adding Entropy to \/dev\/random"},"content":{"rendered":"

I have recently become interested in the amount of entropy<\/a> available in Linux and decided to spend some time poking around on my Debian workstation. Specifically looking to increase the amount of entropy available to improve the speed of random number generation. There are a variety of different ways of accomplishing this including hardware devices (some of which cost rather too much for a simple experiment).<\/p>\n

Eh?<\/h2>\n

Linux has a device (\/dev\/random<\/em>) which makes available random numbers to software packages that\u00a0really<\/em> need access to a high quality source of random numbers. Any decently written cryptographic software will use\u00a0\/dev\/random<\/em> (and not\u00a0\/dev\/urandom<\/em> which does not generate “proper” random numbers of quality) to implement encryption.<\/p>\n

Using poor quality random numbers can potentially result in encryption not being secure. Or perhaps more realistically,\u00a0<\/em>because Linux waits until there is sufficient entropy available before releasing numbers through\u00a0<\/em>\/dev\/random<\/em>, software reading from that device may be subject to random stalling. Not necessarily long enough to cause a\u00a0major<\/em> problem, but perhaps enough to have an effect on performance.<\/p>\n

Especially for a server in a virtualised environment!<\/p>\n

Adding Entropy The Software Way (haveged)<\/h2>\n

HAVEGED<\/a> is a way of using processor flutter to add entropy to the Linux\u00a0\/dev\/random<\/em> device. It can be installed relatively easily with :-<\/p>\n

apt-get install haveged\r\n\/etc\/init.d\/haveged start<\/pre>\n
As soon as this was running the amount of entropy available (cat \/proc\/sys\/kernel\/random\/entropy_avail<\/em>) jumped from several hundred to close to 4,000.<\/p>\n
Now does this increased entropy have an effect on performance? Copying a CD-sized ISO image file using ssh :-<\/p>\n\n\n\n\n
Default entropy<\/th>\n29.496<\/td>\n<\/tr>\n
With HAVEGED<\/th>\n28.636<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
A 2% improvement in performance is hardly a dramatic improvement, but every little bit helps and it may well have a more dramatic effect on a server which regularly exhausts entropy.<\/p>\n
Checking The Randomness<\/h2>\n
But hang on … more important than performance is the randomness of the numbers generated. And you cannot mess with the generation of random numbers without checking the results. The first part of checking the randomness is making sure you have the right tools installed :-<\/p>\n
apt-get install rng-tools<\/pre>\n
Once installed you can test the current set of random numbers :-<\/p>\n
dd if=\/dev\/random bs=1k count=32768 iflag=fullblock| rngtest<\/pre>\n
This produces a whole bunch of output, but the key bits of output are the “FIPS 140-2 failures” and “FIPS 140-2 successes”; if you have too many failures something is wrong. For the record my failure rate is 0.05% with\u00a0haveged<\/em> running (without: tests ongoing).<\/p>\n
Links<\/h2>\n
… to more information.<\/p>\n