Re: RS-232 random number generator

Mack wrote:
> On 8 Jan 2006 16:18:33 -0800, "Terry Ritter"
> <ritter@xxxxxxxxxxxxxxxxxxx> 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.

If you think a design "works" because a few
constructed examples work, you have a naive
view of electronic design.

All electronic components can take on a range
of values. We know what that range is from the
specifications published by the manufacturer.
When extreme part values--still within spec--can
cause malfunction, the design is normally
thought to be faulty. That may seem overly rough
to you, but is in fact at the heart of modern
production, and, thus, correct electronic design..


> >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.

I have shown evidence on my pages for over 6 years
now that taking the difference between noise samples
does indeed make a dramatic, obvious and quantitative
improvement in autocorrelation.

Take a look at the characterization of the ZENER1
source, near the top of:
http://www.ciphersbyritter.com/NOISE/NOISCHAR.HTM
Of course, if you do not measure autocorrelation
on your raw samples, you are not going to see
autocorrelation problems, even if you have them.

I note that my autocorrelation is computed before any
CRC operations, and therefore exposes issues that
would be hidden by CRC.


>My approach was to used paired channels and
> take the difference between channels which tends to
> eliminate all common mode interference.

That statement seems so confused as to be beyond
wrong. The only thing I see "in common" to two
different noise channels is the single power source.
If you have power problems, you should be fixing
those before thinking about the noise signal. If you
are picking up substantial hum in the connecting
cables, something is very wrong. In particular,
the noise signal should not be so weak as to make
hum pickup an issue.

In my case, all of my noise sources were battery
operated (which I would have expected in your case
as well). Since one or more FFT's was computed
for each of my noise sources after digitization, we
know that none had significant common-mode hum.


>Common mode
> interference seemed to be the primary source of excessive
> low frequency energy.

That statement makes no sense to me. As far as I
can see, the only thing "common" about two different
noise source channels is the power supplied to both.
So if you are seeing correlation between those signals
(and that is what "common mode" is all about),
something is wrong with your equipment. Two
different noise sources should be completely
uncorrelated. That would seem to be the whole point.
If you have something else, you should know that
something is wrong.

My argument about correlation between samples
extends to *any* amount of low-frequency energy.
As long as an FFT shows energy at a low frequency,
we know that energy will persist similarly across many
samples. That is inherent in the definition of frequency.
By implication adjacent sample correlation must exist.

Knowing that the source of at least some of the
autocorrelation is correlated frequency energy, it
should be obvious that we can improve the situation
by taking the difference of adjacent samples. However,
the autocorrelation graphs in my work seem to indicate
that, to fully avoid autocorrelation effects, we may have
to let time pass between samples, or at least between
the samples we use. To not do that is to have less
"entropy" in the original noise signal than the entropy
computation indicates.


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

A classic "entropy" computation is not a good
measure of the "unknowability" of the information
being processed. It is easy for a sequence to be
completely predictable and yet have a good
entropy value. But in this application we demand
unpredictability, which will always be less, and
sometimes much less, then the entropy computation
shows.

In addition to the supposed quality of the result, it
is also necessary to prevent reconstruction of the
input signal from the output. We know that requires
at least twice as much input as output used.


> 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.

That seems like an odd way to put it. Software is not
the source of computation, hardware is that source.
Whenever software "runs," it does so on hardware, and
then there is no software there, just memory, wires
and gates. Whatever can be thought of in software can
be built to function in hardware, but software cannot
function at all without hardware. OF COURSE the
entropy computation could be made in pure hardware,
which is just what a microcontroller is.

"Entropy" in noise is not an unknown quantity that
needs measure, unless the distribution of noise values
is unknown, which means one has not done one's
homework. Entropy is also not particularly sensitive to
noise problems, which makes it a poor measure of
noise quality.

Instead, the noise value distribution should be collected
and compared to the ideal normal model. That is far
more revealing of noise source quality than any mere
entropy computation. I note that I have done that in
the "Normal Graph" part of no fewer than 25 noise
characterization pages which have been on the web
for more than 6 years. When the noise source is close
to ideal, the entropy is automatically known.

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

.

Quantcast