We all know that random numbers might not be very random unless you are very careful. Indeed, as the (now old) Debian OpenSSL debacle, a not-enough-random random number generator can be a huge breach in your defences. The other problem is that if you want really random numbers you need a big pool of entropy otherwise code requiring a huge chunk of random bytes would stall until enough data is available.
Luckily there are a number of ways to deal with this; one is to use the EntropyKey while other involves either internal sources of entropy (which is what timer_entropyd and haveged do), or external ones (audio_entropyd, but a number of custom circuitry and software exist as well). These fill in the entropy pool, hopefully at a higher rate than it is depleted, providing random data that is still of high quality (there are other options such as prngd, but as far as I can tell those are slightly worse in term of quality).
So, the other day I was speaking with Jaervosz, who’s also an EntropyKey user, and we were reflecting on whether, if there is not enough entropy during crypto operations, the process would stall or cause the generation to be less secure. In most cases, this shouldn’t be a problem: any half-decent crypto software will make sure not to process pseudo-random numbers (this is why OpenSSL key generation tells you to move your mouse or something).
What we ended up wondering about, was how much software uses /dev/urandom (that re-uses the entropy when it’s starving) rather than /dev/random (which blocks on entropy starvation). Turns out there are quite a few. For instance on my systems, I know that Samba uses /dev/urandom, and so does netatalk — neither of which make me very happy.
A few ebuilds allow you to choose which one you want to use through the (enabled-by-default) urandom USE flag… but these I noted above aren’t among those. I suppose, one thing we could be doing would be going over a few ebuilds and see if we can make it configurable which one to use.. for those of us who make sure to have a stable source of entropy, this change should be a very good way to be safe.
Are you wondering if any of your mission-critical services are using /dev/urandom ? Try this:
# fuser -v /dev/{,u}random
USER PID ACCESS COMMAND
/dev/random: root 12527 F.... ekey-egd-linux
/dev/urandom: root 10129 f.... smbd
root 10141 f.... smbd
root 10166 f.... afpd
flame 12356 f.... afpd
Also, if you want to make sure that any given service is started only after the entropy services, you can simply make it depend on the virtual service entropy (provided by haveged, or ekeyd if set to kernel output, or ekey-egd-linux if set to EGD output). A quick way to do so without having to edit the init script yourself, is to add the following line to /etc/conf.d/$SERVICENAME:
rc_after="entropy"
There exist very few scenarios in which using /dev/random over a well-seeded PRNG like /dev/urandom would lead to an actual increase in security.
In particular – as far as I know – samba does not use it for key generation, but for authentication.It seems to me being able to predict future numbers (since they come from a PRNG) doesn’t help you all that much for attacking an authentication scheme.Or in short: predictability is what kills key generation, too small number sequence space is what kills authentication. The latter is not such a big deal with a good PRNG if you get at least a bit of new randomness once in a while and have a not too small internal state.
I’ve wondered off and on if there was a way to set the kernel to keep more “entropy”. I never think of this question when in “make menuconfig” to find out.If increasing the size by 50% keeps it from bottoming out, then refilling at a slower than desired rate isn’t as much a problem.
here are some daemons that use urandomnginx postfix puppet ssh php-fpm bind
Hey, who says the number 4 isn’t random? You just have to re-define randomness. 😉
For YaVerOtSee man 4 randomIt might help your situation to increase the value in /proc/sys/kernel/random/write_wakeup_thresholdThis could cause the entropy refill to start sooner before the entropy pool gets as low.