Re: RS-232 random number generator

On 8 Jan 2006 16:18:33 -0800, "Terry Ritter"
<ritter@ciphersbyritter.com> wrote:

>David Eather wrote:
>> [...]
>> (Last year I wasted a fair bit of time arguing with a self-appointed
>> expert who claimed the noise source wouldn't work and he had tested it,
>
>Eather loves to poke the tiger . . . as long as the tiger
>isn't around. Normally I'm not.
>
>With respect to "expertise," I have:
>1) researched the noise literature,
>2) built a number of different noise source devices,
>3) characterized their output, and
>4) discussed random noise on sci.crypt for more than
>a decade.
>
>Much of that is on line:
>http://www.ciphersbyritter.com/RES/NOISE.HTM
>http://www.ciphersbyritter.com/RES/RNGMACH.HTM
>http://www.ciphersbyritter.com/NOISE/NOISRC.HTM
>http://www.ciphersbyritter.com/NOISE/NOISCHAR.HTM
>http://www.ciphersbyritter.com/#UsenetRandomReal
>
>
>> first claiming to have built it, latter claiming to have only
>> simulated it in SPICE - then later admitting that SPICE won't run if a
>> transistor has an unconnected junction as in a transistor noise circuit).
>
>With respect to "wouldn't work," upon analysis of Eather's
>first design it turned out that if one of the transistors he
>specified happened to have high gain (within specs), his
>biasing would fail and his system would not work. The
>output transistor would saturate.
>
>That is an analysis issue, not a building issue, since
>finding that failure requires using a particular high-gain
>device, which is unlikely when testing. It is, however,
>possible when building. Since a range of proper biasing
>techniques are available, any design which does not use
>them and which may not work I call: "not working."
>
>With respect to SPICE, I found that my straightforward
>simulation approach did not provide a good model for
>bipolar Vbe breakdown as the signal source. The
>disturbing result was a model which was self-inconsistent,
>without warning. I have no doubt that someone with more
>SPICE expertise than me could make it work. My
>work-around was to use a battery to represent Vbe,
>thus allowing the model to show the output bias under
>various output transistor gains. That would seem to be
>a reasonable analytic approach. The modified model
>still showed saturation.
>

Having actually built the generator and tested it, I can
say that it works with a variety of components (ie. switching
transistor models within reasonable bounds) and didn't
show any tendency to saturate.

>
>A few comments on sampled noise:
>
>Correlation between samples is a major issue. Thus, I
>am in favor of cutting the frequency response below, say,
>1kHz or even 5kHz. Most noise energy occurs at higher
>frequencies anyway.
>
>I also take the difference between adjacent samples as the
>noise signal. That provides a major reduction in correlation
>between samples. It also can be seen as a form of digital
>high-pass filtering. The resulting amplitude distribution
>can be (but often is not) very close to the expected normal
>curve. Some form of subsequent processing is required
>for the desired flat distribution. I generally use CRC and
>put in at least twice as much information as I take out.
>
>Interpreting noise as a collection of sine wave frequencies
>must imply correlation between samples taken on related
>parts of a noise frequency sinewave. This issue is most
>important for low-frequency energy which persists across
>many samples, but some amount of sample correlation
>seems inherent in using wideband noise as a random
>source. I find that disturbing enough to require testing
>and monitoring.

I did some serious work on the correlation and taking the
difference before feeding it to the crc seemed to make it
worse. My approach was to used paired channels and
take the difference between channels which tends to
eliminate all common mode interference. Common mode
interference seemed to be the primary source of excessive
low frequency energy.

I also advocated the CRC approach and found that a
two to one ratio was about right once an appropriate
entropy estimate was reached.

I also advocate post processing of sampled noise being
done in software rather than hardware. The primary reason
being the ability to estimate entropy in hardware simply
isn't feasible. You have to put in a microcontroller on the
entroy device, then write a software program to do it. At
that point you are just moving the software to the controller.

>
>---
>Terry Ritter 1.4MB Crypto Glossary
>http://www.ciphersbyritter.com/GLOSSARY.HTM

Leslie 'Mack' McBride
remove text between _ marks to respond via e-mail
Received on Thu Jan 19 03:44:29 2006