Random Hiss from Mac mike
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. My question is, how many bytes get fed into the hash? Obviously, enough bytes so that I have 128 bits of entropy. Preliminary tests give me a max entropy of about .65 bits per sample byte. That's not very much, but if I can sample at ~20 KHz, that's 1625 bytes per second. That's estimated by recording the length of runs and computing the entropy over the entire sample: i.e. the sum (for k = 1 to 120) of -(fraction of runs of length k * log2 of that fraction). That works out to about 3.3 bits per run with an average run of 5.1 bytes. I suspect there's much less entropy in that signal than even this estimate, but I don't have any way to conduct tests with pure 50 cycle power and uniform ambient temperature. Or whatever else biases the signal. For all I know, every time someone in this building starts his microwave it biases the signal. Does anybody have any experience/advice in this area? -- Thank you VERY much! You'll be getting a Handsome Simulfax Copy of your OWN words in the mail soon (and My Reply). <Andrew.Spring@ping.be> PGP Print: 0529 C9AF 613E 9E49 378E 54CD E232 DF96 Thank you for question, exit left to Funway.
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
Andrew Spring writes:
I've been looking at using the Mac's Sound Input Manager for hardware RNG. [...] 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. [...] Does anybody have any experience/advice in this area?
Yeah, I played with this idea a while ago and eventually gave up on it, exactly because of those long runs of 0x80's and 0x7f's. I'm not sure how you estimate 0.65 bits of entropy per byte sampled when you have long strings of repeating bytes like that. The thing is that event timings (the Time Manager allows you microsecond resolution) and mouse position measurements give you so much more entropy than the sound port that it's hardly worth it, IMO. -- Will
participants (3)
-
Adam Shostack -
Andrew.Spring@ping.be -
W. Kinney