Increase entropy on a 2.6 kernel linux box
Mon, 2008-10-13 16:35 — chris
A good source of entropy is needed for random number generation. This affects services that go via SSL amongst other things.
However - in 2.6.x kernels the entropy sources of a system were reduced - as far as I can see it now is only affected by keyboard, mouse and some IRQ interrupts.
Why is this important? Well - there are two random number sources on linux - /dev/random and /dev/urandom. /dev/random will block if there is nothing left in the entropy bit bucket. /dev/urandom uses the same bucket - but will not block (it can reuse the pool of bits).
You can see how many bits entropy you have available by looking in /proc/sys/kernel/random/entropy_avail (just cat it like a normal text file).
I had normally between 100 and 200 - way way too low for many SSL processes to work efficiently.
My server has no keyboard and no mouse and I have no idea if the IRQ calls for my network driver pass the required flag to be considered.
So - what to do?
Most suggestions are around hardware generators or listening to ambient noise.
However - I have found that the tools rng-tools that are used for dealing with hardware random number generators can be pressed into a somewhat hacked service by making the system take /dev/urandom (the non-blocking one) as a hardware source to feed the bucket.
Process for debian etch:
apt-get install rng-tools- Edit
/etc/default/rng-tools - Set
HRNGDEVICE=/dev/urandom - Run
/etc/init.d/rng-tools start
This immediately gave me an entropy bucket averaging around 2000 and maxing up over 4000.
This has meant that many services that were slow or were timing out are now working.
Note - I make no comment on how secure this is (some dislike the idea of /dev/urandom), or if it is a good idea - all I can say is that I can now use services that were blocking before.
Technorati Tags:
Comments
Great post
I've done this in a more manual way.
rngd -r /dev/urandom -o /dev/random -f -t 1It also gives a higher value in /proc/sys/kernel/random/entropy_avail. I guess this is more or less the same as what's described in the post.
--
Kjetil
entropy testing?
so did you do any entrophy testing of this before and after?
oak
Somewhat
Before I had a regular 100-200 bits in the entropy bucket.
After I see between 2000-4000.
SSH login is much faster, LDAPS now actually works, StartTLS for mail no longer times out.
One useful command for watching the size of the bit bucket is
watch -n 1 cat /proc/sys/kernel/random/entropy_availwhich will cat the file to the TTY once per second (-n 1). You can use this on most short text files that change (I also find it useful to watch md raid rebuilds by watching the /proc/mdstat file).
But what about the entropy quality?
Sorry for beeing unclear - did you try running an entropy test of the bucket?
As you're apparently not adding any actual entropy, just squesing more bits out of the existing the quality should be going down as the amount of data goes up.
Have you tried to get entropy from the sound card? probably the fastest way to get hw entropy.
http://www.vanheusden.com/aed/
(just googled it, have no idea how suitable it actually is to do)
The ultimate Irony is that our corporate Finjan web gateway won't let me access your create account page as it refused to trust your certificate...
OA
btw
E&R and my wife E says Hi
Ref certificate
As a hobby site - I haven't bothered spending money to get a certificate. More available on Certificate Authority (CA) with OpenSSL and this post
However - if it is the gateway - then I have no idea how to make it work - sorry.
No card to listen to
My biggest issue is that this is a 1U rack mount server in a remote location (not even the same country).
I have no sound card to use, no ability to add hardware, no video card to use - nothing that the rng-tools supports is available to me.
I am aware that the entropy quality might drop - but - right now I haven't found any other solution :(
Post new comment