header

Torsten Curdt’s weblog

Not enough entropy?

While for Andrew this happened with httpd I’ve already run into this a couple of times with exim for my SMTPS relay. Exim just gets stuck during the TLS/SSL authentication and does not even say a thing at all. You want to send a mail – but nothing happens. You can’t even see anything from the logs. If you experience similar problems first thing to do (under Linux) is to check there is enough entropy available.


cat /proc/sys/kernel/random/entropy_avail

If the number is below 1000 that might be the problem. Essentially it means that your system does not generate enough randomness for cryptographically secure communications – and waits until there is. Indeed an easy (but bad) work around is to only use the pseudo random generator.


mv /dev/random /dev/random.old ; ln -s /dev/urandom /dev/random

But by definition those (pseudo) random numbers cannot be really random. Several sources provide suggestions and scripts to work around this by generating disk activity and have the disk interrupts generate the badly needed entropy. Unfortunately for me this never was really enough. (Maybe because it’s VServer?) Since I don’t have anything insanely sensitive to protect I just went with the hack as well. If someone has some wise words how to fix this in a better way – let me know. So far I found two daemons that are responsible for generating entropy. The EGD and the PRNGD. Feels a bit crazy to install a daemon just for that though.

Maybe finally a reason to have a mouse connected to a server. (generates a lot of entropy) …it only needs to become part of the hoster’s SLA to move them around from time to time. :-p

  • Thanks , will be useful to my work
  • Have you considered trying video-entropyd or audio-entropyd?

    http://www.vanheusden.com/ved/

    http://www.vanheusden.com/aed/

    But then again, putting your server to play some background music just to generate randomness can be a bit silly, too. :-)
  • Well, a daemon collecting semi-random data is exactly what you want even if it sounds weird :) That way you can control in user space which data you deem to be random enough to use as a secure source.

    But the problem with EGD (and the successor PRNGD) is that they don't feed randomness back to /dev/random (and increase the entropy count) but provide their own sockets with a special protocol. Applications explicitly have to access those sockets. Current versions of OpenSSL will use those sockets automatically if they are found in certain places but eg. OpenSSH has to be recompiled to use them.

    Actually, even if those daemons could increase the entropy count, it probably won't work on a vServer. Because even though you can feed back data into /dev/random, you need to use the ioctl RNDADDENTROPY to increase the entropy count and I somewhat doubt that this is available on a vServer.

    Well... why did I write this? Because I've got the same problem with one of my vServer. In my case I know the host admin and I hope we'll work something out to fix that (like adding the ioctl to PRNGD). Christmas holidas are near so I hope to have some time then :)
blog comments powered by Disqus