One-Time-Pad generation from audio device

Over the weekend I hacked up a one-time-pad generator from the random 
number code I've been writing for Privtool, which uses noise from the 
audio device to generate random numbers.

The code basically reads in a 512-byte block from /dev/audio, then takes
the MD5 of that block to generate 16 bytes of the OTP. The raw audio data
I'm getting is not particularly random and will compress by 3:1 using gzip
or compress, so I'm assuming that using a 32:1 ratio here via MD5 will
give a truly random output (it's certainly uncompressible).

Before I release the source code to the Net, can anyone give me any good
reasons to believe that this won't produce physically random output, or
make suggestions on how to test, or improve, the generated output ? There's
a #define which can be used to easily increase the amount of data fed into
the MD5, but at the moment it will only generate about 1 MB per hour on a
Sparcstation (limited by the audio input rate), so I don't want to
increase that if I don't have to. 

	Mark

On Mon, 2 Oct 1995, Rev. Mark Grant wrote:

> 
> Over the weekend I hacked up a one-time-pad generator from the random 
> number code I've been writing for Privtool, which uses noise from the 
> audio device to generate random numbers.
> 
> The code basically reads in a 512-byte block from /dev/audio, then takes
> the MD5 of that block to generate 16 bytes of the OTP. The raw audio data
> I'm getting is not particularly random and will compress by 3:1 using gzip
> or compress, so I'm assuming that using a 32:1 ratio here via MD5 will
> give a truly random output (it's certainly uncompressible).

I wouldn't bet on it. I did a similar hack with perl, with a much more
conservative 5 seconds to 32 bytes. That didn't cut it, when I ent'ed the
result it gave 6 bits of entropy / 8 bits of output.
I do recall posting it here.

> 
> Before I release the source code to the Net, can anyone give me any good
> reasons to believe that this won't produce physically random output, or
> make suggestions on how to test, or improve, the generated output ? There's
> a #define which can be used to easily increase the amount of data fed into
> the MD5, but at the moment it will only generate about 1 MB per hour on a
> Sparcstation (limited by the audio input rate), so I don't want to
> increase that if I don't have to. 

Um.. I would try to generate bits quickly, then securely, so for example
you get a 2k buffer and do it 5 sec / 128 bits. Then slow down and overwrite
the buffer and give warnings if the user wants to use the bits too early.

> 
> 	Mark
> 
> 
> 

+---- Yih-Chun Hu (finger:yihchun@cs.washington.edu) ----------------------+
| http://www.cs.washington.edu/homes/yihchun     yihchun@cs.washington.edu |
| http://weber.u.washington.edu/~yihchun         yihchun@u.washington.edu  |
+--------------------------------------------------------------------------+

On Mon, 2 Oct 1995, Yih-Chun Hu wrote:

> I wouldn't bet on it. I did a similar hack with perl, with a much more
> conservative 5 seconds to 32 bytes. That didn't cut it, when I ent'ed the
> result it gave 6 bits of entropy / 8 bits of output.

How did you measure the entropy of the output ?

> Um.. I would try to generate bits quickly, then securely, so for example
> you get a 2k buffer and do it 5 sec / 128 bits. Then slow down and overwrite
> the buffer and give warnings if the user wants to use the bits too early.

Ah, well the idea is that they can just generate a OTP when they have a 
few spare hours, not that they'd be generating it in real-time. The 
Privtool code does use realtime generation of random numbers, but it has 
a lot of input data other than the audio (e.g. mouse movements, MD5 
hashes, etc).

		Mark

If there is no microphone plugged into the audio port, the
random numbers tend to be of very poor quality.  (At least on a sun,
visual inspection of the output shows how poor the numbers are.)  I
suspect a few quick tests, followed by warnings to the user to turn on
the microphone, would be quite useful.

Adam


% head /dev/audio | od | head
0000000  077776 077777 077377 177577 177777 177377 177576 077776
0000020  077776 177577 077376 077376 077577 177576 177177 077376
0000040  077576 077776 077377 177777 177576 177377 077377 077377
0000060  077576 177775 077576 177776 177576 177377 177176 177177


| The code basically reads in a 512-byte block from /dev/audio, then takes
| the MD5 of that block to generate 16 bytes of the OTP. The raw audio data
| I'm getting is not particularly random and will compress by 3:1 using gzip
| or compress, so I'm assuming that using a 32:1 ratio here via MD5 will
| give a truly random output (it's certainly uncompressible).
| 
| Before I release the source code to the Net, can anyone give me any good
| reasons to believe that this won't produce physically random output, or
| make suggestions on how to test, or improve, the generated output ? There's
| a #define which can be used to easily increase the amount of data fed into
| the MD5, but at the moment it will only generate about 1 MB per hour on a
| Sparcstation (limited by the audio input rate), so I don't want to
| increase that if I don't have to. 



-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume