I've actually had problems on systems due to _running out of entropy_.
Picture this— a lightly loaded multiuser shell system that does a little SSL webserving. Incoming SSH connections intermittently hang for a second or so.
The problem: sshd is using /dev/random, the kernel has a fixed size* random number pool of only four kilobits, and every SSL request eats a few hundred. On many headless systems the 100hz timer is the only source of entropy for the pool, because paranoia called for the removal of random contributions from most network drivers (because an external party controls them).
Modifying ssh to use urandom would have broken the distribution packages an inhibited adding security updates in the future.
The solution was to toss haveged on the system, it does a good job keeping the pool full, but it should would be nice if the kernel had a pool which wasn't so insanely small.
*The size used to be variable, but there was an exploit(!) related to this capability... so it was fixed. But that was back when just about every driver contributed to the pool, so the small size wasn't quite so crazy.
Posted Apr 5, 2012 20:19 UTC (Thu) by dlang (✭ supporter ✭, #313)
[Link]
that is a case where the application should really be using /dev/urandom, not /dev/random
the administrator has the choice of either recompiling the package, adding additional randomness source, or tricking the application by renaming /dev/random to something else and making /dev/random be a link to /dev/urandom