> Date: Thu, 04 Sep 1997 15:17:22 -0400 > From: Andrew G Williams > Subject: REAL random noise > > I'll shortly need to use a 16F84 to generate a series of random pulses (truly > random, not generated by a pseudo-random algorithm). Does anyone know a > straightforward way of doing this? You say ``pulses'' and you don't mention cryptography; are you trying to do something cryptographic, which requires ``unpredictability'' against a determined or antagonistic adversary, or is your randomness requirement more related to uniform distribution and absence of patterns or repetitions? In the former case, a cryptographically secure pseudo-random number generator (CSPRNG) is required; in the latter case, you might simply need a good PRNG with adequately long cycle length. More fundamental: how many random bits per second do you need? > I suppose the usual approach is to pass a low current through a diode, > amplify the noisy output and then produce pulses from a comparator (but > please correct me if that's wrong). I was wondering if the PIC itself > contains any inherent noisy or random signals, or can be persuaded to. If so, > genuine random pulses could perhaps be generated without any extra > components. > > Then again, I could use one with a built-in ADC or comparator. If I did that, > would the noisy signal need amplifying before being input to the PIC? I can't > find anything in the application notes about these things, so any advice > would be appreciated. Dr. George Marsaglia has documented that some ``true'' (physical source) random ``white noise'' generators actually fail some tests for randomness that any good pseudo-random number generator (PRNG) should easily pass. See his battery of tests at stat.fsu.edu/pub/diehard (pun intended, I'm sure). There is a simpler set of tests at www.fourmilab.ch/random; you might use this to screen out weak results before you run DIEHARD, which takes much longer. So don't assume ``true'' will be better than ``pseudo''. A good source of randomness (or ``entropy'') is timing, if humans are involved. If your device is in any way used on demand by a real person, then the interval between keypresses, services requests, etc., is essentially unpredictable: so run a good PRNG continuously while waiting for events. (This approach mail fail for cryptographic purposes if the adversary has the opportunity to operate your device with exactly counted clock cycles; but in such a context, almost any approach is vulnerable). Another very important idea, especially for the `84: reseed the PRNG from non-volatile memory, and change that seed, at every reset. (I have an article about an electronic gambling machine, poker I think, which always produced an identical winning hand at a certain fixed time after it was powered up. This guy watched and learned the maintenance schedules ...). Anyway, in-chip NVM is a great plus for this problem! If you don't have NVM available, a nice clock/calendar plus a hash algorithm can be used to diversify your PRNG at every reset. Just take all the bits of the date and time, grind it through SHA or MD2 or whatever (a single bit changed in the input produces many unpredictable bits changed in the output), and reseed with the hash value. > Andy W. Peter F. Klammer, Racom Systems Inc. PKlammer@ACM.Org 6080 Greenwood Plaza Boulevard (303)773-7411 Englewood, CO 80111 FAX:(303)771-4708 Peter F. Klammer, Racom Systems Inc. PKlammer@ACM.Org 6080 Greenwood Plaza Boulevard (303)773-7411 Englewood, CO 80111 FAX:(303)771-4708