Feeding /dev/random entropy pool?

You should use /dev/urandom, not /dev/random. The two differences between /dev/random and /dev/urandom are (I am talking about Linux here):

• /dev/random might be theoretically better in the context of an information-theoretically secure algorithm. This is the kind of algorithm which is secure against today's technology, and also tomorrow's technology, and technology used by aliens, and God's own iPad as well. Information-theoretically secure algorithm are secure against infinite computing power. Needless to say, such algorithms are pretty rare and if you were using one, you would know it. Also, this is a "might": internally, /dev/random uses conventional hash functions, so chances are that it would have weaknesses anyway if attacked with infinite power (nothing to worry about for Earth-based attackers, though).

• /dev/urandom will not block, while /dev/random may do so. /dev/random maintains a counter of "how much entropy it still has" under the assumption that any bits it has produced is a lost entropy bit. Blocking induces very real issues, e.g. a server which fails to boot after an automated install because it is stalling on its SSH server key creation (yes, I have seen that). /dev/urandom uses a cryptographically strong pseudo-random number generator so it will not block, ever.

So you want to use /dev/urandom and stop to worry about this entropy business.

Now you may want to worry about entropy if you are writing the Linux installer. The trick is that /dev/urandom never blocks, ever, even when it should: /dev/urandom is secure as long as it has received enough bytes of "initial entropy" since the last boot (32 random bytes are enough). A normal Linux installation will create a random seed (from /dev/random) upon installation, and save it on the disk. Upon each reboot, the seed will be read, fed into /dev/urandom, and a new seed immediately generated (from /dev/urandom) to replace it. Thus, this guarantees that /dev/urandom will always have enough initial entropy to produce cryptographically strong alea, perfectly sufficient for any mundane cryptographic job, including password generation. The only critical point is during installation: the installer must get some entropy from /dev/random, which may block. This issue also occurs with live CD and other variants with no read-write permanent storage area. In these situations, you may want to find some source of entropy to ensure that /dev/random will be well-fed, and will not block.

The operating system itself, and more precisely the kernel, is at the right place to gather entropy from hardware event, since it handles the hardware. So there is relatively little that you can use for entropy that the kernel does not already use. One of those remaining sources is Webcam data: a webcam, even facing a blank wall, will output data with thermal noise, and since it outputs lots of data, it is a good entropy gatherer. So just grab a few frames from the webcam, hash them with a secure hash function (SHA-256), and write that into /dev/urandom. This is still big overkill.

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

I know of audio entropy daemon and havege which is used by haveged daemon, try them out.