Take a look at RFC 1750. It discusses randmoness. If your input to MD5 consists of two long strings of constants, your output from MD5 only has really a very few bits of entropy (I think you end up with 7, or possibly 14 if there are two transitions. Not a lot of entropy at all.) | I've been looking at using the Mac's Sound Input Manager for hardware RNG. | The advantage of it is that (1) most macs have a microphone port these | days, (2) it doesn't involve any user interaction, (3) the API is easy. | | What I don't know, is how secure it is. Or more precisely, I don't know | how much entropy is contained in the signal. | | In the simplest case, where the microphone is not attached, the signal | consists of long runs of '0x80's alternating with '0x7f's. Now, I have no | problem transforming this into uniformly distributed RN's : just hash the | buffer with MD5. Again, the output of a hash is only as good as its input. If you input 40 random bits, and 88 known bits, we only need to search the 40 known bits. If you input a string of the form 00000011, with 2 runs of some length, we don't have to search 11100111 as a possibility. There are only 8 strings which match if your constraints are 8 bits, starting with 0, and only a single transition to a different state. So, by knowing those rules, we only have to search 2^3 strings instead of 2^8. If there isn't a microphone, and the OS gives you a steady stream, then the sound port is a bad source of randomness, even with a hash. Use mouse movement, keyboard input, or the parity of long strings of either of those. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume