> * Using the output to seed MD5 for the next block exposes that part of the > state of the RNG. Might be better to use half the MD5 output as seed for the > next block, and the other half as output data.
The RNG takes most of its input (except the initial seeding) from the external source of de-facto-impossible-to-predict-accurately data. However, it's a good comment; the program should allow to switch on this mode, trading added entropy for output stream rate (the program was originally intended as moderate-bandwidth, to produce a CD worth of random data in no more than few hours). > * Your RNG takes input from an attackable source. The input - the TV tuner card audio device - was chosen on the basis of being available without me having to leave my chair when I got the idea; I am aware about this risk, though I don't expect an active attack of this kind ot be feasible against an offline OTP generator. However, I was playing with the idea of using a just-slightly-modified program to continually feed the entropy pool. Then the risk of active attack becomes more real. Also, vast majority of my computers don't have a tuner card in, so they will be dependent on an external noise source. Here a "real" noise generator has to come to play. Looking for something simple, powered from +5V. At this moment, I am pondering to design a small analog noise generator for the microphone input of a sound card (as most of my servers which could need this toy have an onboard soundcard). The mike input is designed for the electret microphone, which needs a power supply; the input is AC-coupled with a capacitor and connected to the power supply through a resistor. So there is a miliamp or two on few volts that I can use for the noise generator. Its usability as a power supply is likely to depend on the board/soundcard; I measured available voltages being 0.7V on a motherboard-integrated card, 2.5V on my POS laptop, and 4.8V on a PCI128 soundcard. With a simple noise-generator circuit (possibly a 1458 opamp fed with something like a Zener diode noise or anything similar suitable), it could be a very cheap and simple random noise generator (the whitening of the signal through a hash function is a must here, though, as the desired simplicity of the circuit will likely result in an uneven spectral distribution of the output, thus lower-than-optimal entropy). Even if the soundcard mike input won't offer high enough voltage, we can borrow +5V from keyboard, mouse, joystick, or USB port, for the cost of another connector and another piece of wire (which then turns an elegant neat clean sleek single-plug design into a wirey mess, but on the other hand allows us to put it all inside the server's case - then we can even take advantage of +12V available from the HDD power supply connector, and feed the signal into the CD-IN on the onboard sound card; using two independent noise generators and feeding their outputs to left and right channel could neatly double the input bandwidth). The point of this device isn't to have an absolutely-bulletproof system, but to provide good-enough-for-nearly-everyone el-cheapo HW RNG for under $10-15. > be attackable - it would depend on how well I could manipulate the /dev/dsp > output via my transmitter. You could eg. get the system to receive a continuous clean sine wave, or - more likely - feed it with high-amplitude impulses. Until I'll talk myself into putting together the hardware RNG from the previous paragraph. > The present check only requires that some pair of bytes differ by >16 > - something that might be relatively easy to cause with a transmitter. Yes. The intention of the check in this version was to prevent operator blunders like feeding the program from a switched-off signal source. Better statistical check would be a good thing, though; however, my math-fu isn't good enough yet to come up with something simple. > Of course, reading 128 bytes buys you a lot of entropy even just > from marginal noise, so you may still be okay. This was what I hoped for. :)
