Feeding /dev/random entropy pool?
Which way of additionally feeding
/dev/randomentropy pool would you suggest for producing random passwords? Or, is there maybe a better way to locally create fully random passwords?
You can feed it with white noise from your sound chip, if present. See this article: http://www.linuxfromscratch.org/hints/downloads/files/entropy.txt
You *could* do that, I suppose, but why bother? There is no reason to. It's unnecessary. The kernel already feeds /dev/random and /dev/urandom with sufficient entropy for these purposes. Save your time for something that will actually improve security. Or, to put it another way, the question asked whether we would suggest adding extra entropy. The best answer is: No, there's no need to add extra entropy. Just go ahead and use /dev/urandom as is.
@D.W. from my experience with VPS servers, where there is no real external entropy source like keyboard, mouse etc, the entropy pool gets very low and it seems to affect things like SSL. It might still work but it feels like things are running slower. After installing haveged (see another answer below), things were running much more smoothly. Perhaps there was something else I could have fixed, or did something wrong, but I'm not sure you can always rely on your kernel as your entropy source...
If I remember correctly, a few of the major entropy sources are CPU registers that get modified very frequently to reasonably random values. Unfortunately, virtualisation negatively impacts the randomness of those registers due to more predictable scheduling of threads. A solution is to have a HRNG on the bare metal server, then make it available to the VMs.
@YoavAner, the reason you are having problems is probably because you are using `/dev/random`. Don't do that. You should use `/dev/urandom`. Then you won't have those problems -- and it will be secure. See Feeding /dev/random entropy pool?, Is a rand from /dev/urandom secure for a login key?, Pseudo Random Generator is not initialized from the (entropy pool)?. Short version: use /dev/urandom, not /dev/random.
Thanks @D.W. I know that urandom should solve this, but I'm not sure all components on my system use it necessarily. For example, it must be some component of lighttpd web server, or openssl or who-knows-what that were getting funny.
Thanks, @YoavAner. I set up a separate question to try to identify any configuration changes needed to avoid this situation: What do I need to configure, to make sure my software uses /dev/urandom?.