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: Bookmark/Search this post with:
Comments
Only spiked up
Good idea, but it didn't give a permanent improvement for me. Entropy was 100-200, and immediately jumped to 2000. But then it fell back and although entropy now spikes to 2000, it still spends most of the time between 100 and 200.
bathmate
I am aware that the entropy quality might drop - but - right now I haven't found any other solution
Bathmate
what about an entropy key
Some british guys solved your problem with a bit of electronic and coding, and they're selling it online for about 40 euros.
http://www.entropykey.co.uk/
Works great but I would need access to the machine
Yes - I saw these discussed on the debian mailing lists.
It is a cute idea that solves the problem quite well.
Had I the box local to me (at home or at work) then I would probably have one already - but - since the machine is in a co-lo in Germany and I'm in Oslo in Norway it doesn't quite work. I believe I could send it to them - but - if I understood the pricing - such custom changes would add a fair bit to the monthly charge.
Still - I do agree - now that these are available then they are probably a better solution for people with access to the hardware (I'd like to say definitely - the idea seems much more elegant - but I can't say that without testing it).
great!
great little tip.
i run a fairly high traffic site that has an ssl side...
during peak times, i could see the available entropy drop to very low numbers... im using munin to track this.
using this little trick, entropy is nice and high regardless of peak time or not :)
im using centos, it includes a package rng-utils... no init.d script tho, so i just added:
/sbin/rngd -r /dev/urandom -o /dev/random -t 1 &
to my rc.local.
thanks for the tip!
other ideas
I've run into this on my servers too, i'm investigating using a video_entropyd or audio_entropyd on a local machine, and then sending random data across the network to the ssl server in question ....
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