// COMPLETE THREAD

My responses regarding random generator.

3 expanded posts ยท every known parent and child

NODE 563b09a2My responses regarding random generator.
In response to everyones comments:

   I am overwhelmed with all this response that came though
during the times I was absent from the Nets.

   At this time,  I am evaluating other approaches to this 
problem then using the Newbridge system's inflated pricey
hybred circuit.

   It is clear that a simple reversed diode circuit may not be 
enough to produce truly random data bits unless care is taken
to prevent periodic signals from being "injected" into the circuit.

   Although I don't have access to a "clean lab",  I do have
access to Techtronix scopes,  and a general HW lab,  but not sure 
if that is adequate to completly test out the circuit to determine
that things are truly random.

   An easy test I often devise is to generate a pair of random
bytes,  and display them as X, Y pairs and plot them on the
screen as pixels.    First,  I start with a clean screen,  then
plot the dots as they come in.     As these dots are plotted
on the screen,   the dots should be evenly distributed over the
screen without "bunching" or "patterns" developing.

   I know that this is not the best way to determine true 
randomness,   but it is cheap and inexpensive to do.  

   I also agree that we should all check out and determine if
there are other random generators currently available,  and
we should compile a list of them to share with the group as
proposed by Tim May.    Although I haven't yet visited the
crypt newsgroups,  I suspect that I should post a query there
to see if any such puppie exists.

   Then,  there is the speed of generating these random numbers,
and how we will want to deal with the possibility of inadequate
speed.     I suspect that serial transmission at 9500 baud might
be easily obtained,   but going much faster withoug "drift" might 
be problematic as Tim May pointed out.

   At this point,   I would now like to get some other feedback
from the group on what Zener noise source to use,   and kick 
around some design ideas.    It would be nice to be able to exchange
schematic diagrams and pass them around.  I have a Mac,   but
not everyone in this group uses them.    So what mechasim can we
imploy to send schematics around?

   My next visit to the Nets will be this weekend,   so if anyone
wants to contact me,  they can try me at (510) 769-1268,  and
it will refer to the number where I'm staying at that time.
I still have NO permenent home (after long period of unemployment),
so getting on the Nets daily will be problematic for me.

   I usually hang out in South San Jose,  at my friends VCR Repair
lab (where this hardware equipment is located),  but have no computer
set up there until we can set up proper physical security.   That
number is (408) 377-2382.   I am usually there early in the week,
because I can make calls to find work from there on Mondays.

   As I converge into a workable design and if the lab results
are encouraging,   and acceptable to the group,   I would like to
build 2 or 3 prototypes and pass them around to volunteers for
Beta testing before making them available to the group as a whole.

   I can get PC boards made via Douglas Electronics fairly 
inexpensivly,   and plan on making them as orders come in,  and
initial setup costs would be about $350.     I already have
people set up to invest this much already.

   Perhaps it would be prudent to set up a group of other HW
designers and meet physically somewhere to hammer out a design
and make this a group effort.   Do I have any volunteers?
I think only one meeting would be necessary to determine a rough
approach to take.

John D.
NODE c0c75d42My responses regarding random generator.
>From: crunch@netcom.com (John Draper)

>   Then,  there is the speed of generating these random numbers,
>and how we will want to deal with the possibility of inadequate
>speed.     I suspect that serial transmission at 9500 baud might
>be easily obtained,   but going much faster withoug "drift" might 
>be problematic as Tim May pointed out.

I'd like to point out that higher data rates are very very desirable.
One would like to be able to cut a pair of CD's for use as one time
pads in a reasonable amount of time -- at 9600 baud its going to take
a LONG time to do. You can always run multiple units in parallel, but
its probably good to get the cost/bitrate ratio as low as possible.

Perry
NODE b0599885random generator
>I'd like to point out that higher data rates are very very desirable.

And higher data rates are more expensive.  If you're making one time
pads, you need high bit rates, but otherwise you don't.  10Kbps is
overcapacity for personal use.

Let's do an estimate.  Suppose all you use your random numbers for is
to create session keys for socket connections.  Now lets say you need
to open a socket about once a minute.  Since you need, say, 500 bits
for a DH key exchange, that's a bit rate of about 10 bits per second.

One can cache bits coming in from the random number generator in a
ring buffer.  You can make this ring buffer arbitarily large, or even
virtualize it to disk and make it appear as infinite in size.  Then
you could run your generator continuously and always have enough bits
available for use.

If you're using a generator for making session keys, then you just
don't need that high a bandwidth.  

Now the $/bps for the Newbridge chip is much lower, but for personal
use you throw away too many of its bits to make it worthwhile.  This
higher bandwidth chip would be useful in a server of some sort, where
you are making session keys more than once per second.

Proposal: Make this random number generator operate at 100 bps.  If
higher bit rates are the same price, fine.  But a specific design
criterion of 100 bps should be a practical and economical goal.

Eric