Rander box and other stuff

To Cypherpunks:

   I think I have a rough description of the hardware serial random
generator I want to build.    I want to call it the "Rander box" for
lack of a better name.

   It will have two serial connectors,   one an input,  and other the
output,   and connect to a modem or serial port.   Physically,  it should
have dip switch to select baud rate,   and an on-off switch.

   When switched on,   and a "cr" (or some other character) is sent to it,
random bytes will stream out continiously.   Another "cr" will stop the
byte stream.    At least this is ONE approach.   If anyone can think of
a better way,  Pse speak up.

   Next week,  I plan on consulting with another hardware guru and
formulate an initial design.    I already know what components need
to go into it,   and now I want to try and eliminate an extra UART if
I can figure out how to turn on and off the random stream via software.

   The internal code of PGP (I am told) uses an internal buffer to hold
the random bytes,  generated my environmental changes such as key strokes,
mouse movements,  or other external actions.

   Some of the Mac implementors are discussing the feasability of not
maintaining 100% portability.   I suggested that we break up the PGP
program into four parts.

  a) Incryption engine
  b) Key management engine.  
  c) GUI interface  (DOS, MacOS, UNIX, Windows,  etc) 
  d) Random number generator (machine dependent,  possibly hardware)

  Parts (a) and (b) are the "portable" parts,  and (c) and (d) are the
machine dependent parts.   Because the Mac is not multi-tasking,  we can
get around that problem by implementing a random number generator as a
driver.   Mac drivers provide for "periodic" code to be called as often
as possible,   and there are plenty of places where this driver can "look
for" environmental changes to generate random numbers using the hashing
stuff that Phil implemented.    Naturally,  the IBM-PC and UNIX versions
of software random number generation would be different.   But as far as
the Incryption and Key generators are concerned,  all they need to do,  is
to look into the random "seed" buffer.    Implementing the random number
generation as a driver also affords the possibility of having total 
independence of a hardware device,   and if one is desired,  no changes
to the code will be necessary to have one.   We just drop an appropriate
INIT into the system folder which will contain the appropriate driver.
This is the Mac way of doing things.

   One other problem I am having in participating in this group is the
extra phone expenses I will have.    I cannot get on Netcom's local lines
from here anymore because they are always busy,  and there is a lot of
other unconsiderate people that hog up all the local lines for many hours
at a time,   so mail responses to and from me,  may take days.    For
instance,  I cannot participate in any IRC chats unless I get local access,
as I am unemployed and cannot afford to call out of my area.  So please
excuse any slow responses you might get from me.

John D.

>   It will have two serial connectors,   one an input,  and other the
>output,   and connect to a modem or serial port.   Physically,  it should
>have dip switch to select baud rate,   and an on-off switch.

Some simplifications I might suggest:

I only think you need an output connector.  See below.

If you can power it off the RS-232 line, you won't need a power
switch.  You should be able to draw enough power off, say, the DTR
line to power a simple thing like this.

For a dedicated random number generator with low bandwidth, there's
not much reason for variable baud rate.  I'd use a fixed baud rate of,
say 1200, or even 300.  If you make it low enough you could just
kludge together a serial interface, but with the low cost of UART's,
it's probably not worth it.  You might also consider using a PIC, which
has built-in serial.

>   When switched on,   and a "cr" (or some other character) is sent to it,
>random bytes will stream out continiously.   

I'd just make the thing spew continuously.  It's not like you're
losing real, er, information if you ignore a few random bits.  This
way you don't need the added circuitry for switching on and off.

The actual use of this thing is going to require a device driver to
buffer up random bits for later use.  So all the flow control to the
higher layer happens there anyway.  And if the UART buffer overflows,
so what?

Eric

>From: Eric Hughes <hughes@soda.berkeley.edu>

>Some simplifications I might suggest:

>For a dedicated random number generator with low bandwidth, there's
>not much reason for variable baud rate.  I'd use a fixed baud rate of,
>say 1200, or even 300.

I strongly disagree -- you really want to be able to do as high a
bandwidth as possible. You might think we don't need one time pads
ever anymore, but they are still the one and only provably absolutely
secure method out there -- thus, sources of large numbers of random
bits are going to be of use.

>>   When switched on,   and a "cr" (or some other character) is sent to it,
>>random bytes will stream out continiously.   

>I'd just make the thing spew continuously.  It's not like you're
>losing real, er, information if you ignore a few random bits.  This
>way you don't need the added circuitry for switching on and off.

Bad idea. If I hooked it up to my workstation, I'd end up spending
lots of CPU on the thing and possibly get nasty problems with buffers
filling. Not everything on earth is a PC that will ignore the
interrupts if the port isn't in use, you know.

Perry

Perry on random bit rates:
>I strongly disagree -- you really want to be able to do as high a
>bandwidth as possible. 

Cryptography is all economics.

The economics here is that John Draper is going to try to market this
thing, not play with it in the lab.  I don't know what experience you
have with electronic design, so pardon me if I condescend.  You don't
sell features that most people don't need.  You don't add parts when
only a few people are going to use the feature.  You make another
version if there is sufficient demand for higher performance.

One-time pads are expensive to make relative to other forms of
security.  Period.  No argument.  George Gleason and I had a long
conversation via email over a period of weeks about this.  He was
convinced.  If you don't believe me, ask him.

The largest need for random bits right now is for key material. If you
want to use one-time pads, fine.  They are secure, no problem.  The
random number generator we are discussing here is not suitable for
making one-time pads.  If you want one, build it.  It's not what most
people need right now.

In fact, if one-time pads are economical to use, then surely there is
a market for one-time pad systems.  Of course, if such a market does
not exist, then one-time pads don't provide economical protection for
the market as a whole.  Which do you think?

Re: continuous spewing of bits.

Perry thinks this is a bad idea because it won't work with
workstations well with respect to interrupts.  

In my previous post, I mentioned powering the device from DTR.  DTR,
for those of you not familiar with RS-232, is a device control line
which is separately assertable.  To turn the device off, toggle DTR.
Presto!  No more power, no more bits.  Simple, when you know what DTR
does.

My original point remains, though: you don't need a power switch.

Eric

>From: crunch@netcom.com (John Draper)

>   I think I have a rough description of the hardware serial random
>generator I want to build.    I want to call it the "Rander box" for
>lack of a better name.

>   It will have two serial connectors,   one an input,  and other the
>output,   and connect to a modem or serial port.   Physically,  it should
>have dip switch to select baud rate,   and an on-off switch.

>   When switched on,   and a "cr" (or some other character) is sent to it,
>random bytes will stream out continiously.   Another "cr" will stop the
>byte stream.    At least this is ONE approach.   If anyone can think of
>a better way,  Pse speak up.

Why two serial connectors? RS232 is bidirectional, so you could send
control signals down the same pipe the output comes off of. Also, why
bother decoding the CRs? Seems like overkill. You could just have
CTS/RTS or other lines on the connector control whether bits are
clocked out or not. 

Perry

>    Some of the Mac implementors are discussing the feasability of not
> maintaining 100% portability.

If portability was a problem, the Mac would certainly be an answer.

Howabout actually trying to be Real Programmers and writing Real Software,
like the folks who did all the work that you are now benefiting from?
Instead of writing dead-end software that will only live on one platform?
I know it isn't the Macintosh Way, but you might learn something.

The last thing PGP needs is an installed base of Mac users who are
always stuck three revs back because they forked off their own wierd
version and couldn't upgrade when the rest of us do.

	John Gilmore