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.

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

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