pyaed - a python audio entropy daemon
Same game again. Not all my boxes have tv-cards to leach entropy from, so I needed some other source. The soundcard comes into mind quickly, and every box has a soundcard nowadays. The existing audio_entropyd once again wasn’t useful, because what it produced didn’t survive the FIPS-140-2 tests (aka wasn’t really random at all on my box). I then went on reimplementing the exact same algorithm it uses in python with pyaudio to take a closer look on the data. When I dumped the output of this algorithm into a file, I could even see patterns in hexdump of that file. strange. Well, there must be some randomness, so I went on implementing a different algorithm. It also records stereo audio and then looks at the upper bit (0×0001) in the samples. If this bit is different on both channels and the current two stereo samples are different from the last two, it records that as an entropy bit (you can argue about that, though - afaik randomsound uses the same mechanism). To add some more confidence in the entropy, it then XORs 64kbit of entropy into a 4kbit block. This way, it’s getting around 3kbit/s of entropy out of the soundcard.
README:
Python Audio Entropy Daemon v0.0.1 (works on my machine) (c) 2010 by Kai Dietrich Inspired by audio_entropyd by Folker Vanheusden http://www.vanheusden.com/aed/ and randomsound by Daniel Silverstone http://www.digital-scurf.org/software/randomsound This software is Licensed under the GNU General Public License 2.0 or later. System Requirements: -------------------- Python 2.6 PyAudio 0.2.3 a soundcard with line or mic in optional: rng-tools / rngd What it does: ------------- Pyaed records samples from an audio input device, extracts some noise/entropy and writes it to a fifo. Pyaed opens the default audio input device pyaudio finds and records frames (44.1kHz, 16bit, stereo). It looks at the highes bit (0x0001) in the samples from each channel. If these bits differ and the samples are different from the last (to ignore constant signals), a bit of entropy is recorded. To increase the qualitiy of randomness, it then compresses 64kbit of entropy into 4kbit by XORing the bits. It then writes the bits into a fifo. You can then attach rngd from the rnd-tools to this fifo (rngd -f -r entropy.fifo). rngd will test the noise with a FIPS 140-2 test for it's statistical randomness and delivers the bits to the kernel entropy buffer. It does not work, what can I do? -------------------------------- a) read the code (it's not that much) b) fix the code c) Play around with alsamixer to get noise on the default input device, turn up boosts and input levels until you get levels around 50%. If you want to, you can even put in a stereo mic to get noise from the air and not just the electromagnetic noise from the ADC. How can I enhance the code? --------------------------- Just do it. If you like this tool, you can just set up a project somewhere and start collecting improvements. For me this was just some fire-and-forget single-task code.
>, I could even see patterns in hexdump of that file. strange.
Strange? Its sounds (haha) like to much DNL from you ADU (aka Soundcard).
I think this stolen picture explain it the best way:
http://www.itwissen.info/bilder/a-d-wandlung-mit-einer-sampletiefe-von-4-bit.png
Well, considering what the original audioentropyd did, I think it is strange. If I got it right it takes a sample from the L and R channels, then calculates the difference. Now if this difference is different from the difference of the samples before, it takes the least significant bit of the current difference as an entropy bit. Assuming that the A/D converters for the L and R channel are physically equal, all that is left is entropy. DNL is not important here (if I understood it correctly). But I guess the initial assumption that both A/D converters are equal is broken on my hardware.