Hoping that this is the right forum for this question.

Trying to figure out some method of generating large amounts of entropy in Debian etch. I've heard of people using the mic-in to generate entropy via electronic noise on the line, or from ambient sound. Is there a way to actually do this? Package or source, either is fine, though a package is preferred. Or just point me in the right direction.

Any help at all would be awesome. Thanks!

You probably don't need any actual software to create a large file of random data. You could just cat the microphone into a file for awhile and combine that with some other quasi-random data.

But there are daemons that do it all for you, such as aed. I don't know if it is available in the Debian repositories though.

Oh, no, I'm not trying to feed this out to a file. I just want a constant, high-quality entropy source for the kernel - The server in question does a ridiculous amount of cryptographic operations, and we've started having problems with /dev/random blocking lately.

And the Powers That Be have deemed /dev/urandom to be insecure for the tasks that this machine performs. I've tried to convince them otherwise, but no dice. So I've got to figure out a way to generate lots of entropy, all the time.

Did a quick search for "audio entropy daemon for Debian" on Google, and got the "randomsound" package in lenny/sid. Exactly what I was looking for. Thanks much.

Lesson: Googling works REALLY well when you know what to search for. Kinda like "42." The answer eludes you until you know the right question.

You'd probably be better off with the video entropy daemon linked to from that site - it should provide a lot more entropy that just audio - stick in a TV card and connect it to a very poor aerial on an untuned station.

It depends on the audio source. If you are loading it up with trance music with a constant beat for 20 minutes, then you are not getting ideal entropy, no. On the other hand, if you have it hooked up to a un-tuned FM radio, I don't see that there would be much difference between it and the video variant; static is static after all.

The way both applications work is by periodically comparing two samples (on the sound card, it is the two channels; on the video device it is two screen grabs that are a random time apart) and then hashing the difference between those two samples. It is an identical principle, so assuming you are using the ideal input (in the case of either video or audio) you should get similar results.

However, I would theorize that you might get better results with the audio version if you had the left and right channels connected to different sources. You have to keep in mind that you want the two samples to be as different as possible; so for example, video feed of fish swimming in a tank would not work well since the background won't move. On the other hand, if you had the left channel of your soundcard connected to a radio tuned to talk, and the right channel connected to a microphone outside, the differences between the samples would be vast.

It is really a matter of having two sources versus one. With video, you can only have one video feed that has to be compared to itself while with the sound card version, you have two sources which can be completely isolated from each other.