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
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
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
participants (3)
-
Adam Shostack -
Rev. Mark Grant -
Yih-Chun Hu