1992-11-13 - Rander box and other stuff

Header Data

From: crunch@netcom.com (John Draper)
To: cypherpunks@toad.com
Message Hash: 46345b81d284865b9910032cc6ce9e25cc1a389e84d39604a39d1f70dd55a333
Message ID: <9211130757.AA27092@netcom2.netcom.com>
Reply To: N/A
UTC Datetime: 1992-11-13 08:00:51 UTC
Raw Date: Fri, 13 Nov 92 00:00:51 PST

Raw message

From: crunch@netcom.com (John Draper)
Date: Fri, 13 Nov 92 00:00:51 PST
To: cypherpunks@toad.com
Subject: Rander box and other stuff
Message-ID: <9211130757.AA27092@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


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.





Thread