1992-11-20 - Some proposals to consider

Header Data

From: crunch@netcom.com (John Draper)
To: cypherpunks@toad.com
Message Hash: 044ed99453f6e40f6051398fd93422bc72d6ed685a8571c2ebd11fafda0edc93
Message ID: <9211200059.AA27380@netcom2.netcom.com>
Reply To: N/A
UTC Datetime: 1992-11-20 03:33:56 UTC
Raw Date: Thu, 19 Nov 92 19:33:56 PST

Raw message

From: crunch@netcom.com (John Draper)
Date: Thu, 19 Nov 92 19:33:56 PST
To: cypherpunks@toad.com
Subject: Some proposals to consider
Message-ID: <9211200059.AA27380@netcom2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


Greetings fellow cypherpunks:

   A lot has happened since I got on here last Friday.   My previous
message contains my public key,   Pse use it if you want to send me 
private mail.

   I bet the NSA boys are tearing the hair out of their heads by
now,   but it's about time we do something to preserve our privacy.

   It is my plan to help "organize" the Mac implementation of PGP,
by putting together a Mac Implementation team of programmers to 
beef up MacPGP,  by added better GUI,  such as cutting and pasting
of keys DIRECTLY into key rings without having to go through a
file (makes for added security).

   My plans also call for tight coordination with the other platform
development teams.   

   I've been getting good support for my ideas on implementing machine
independent modules or "Libraries" of PGP routines that don't include
I/O portions,   but after looking at the code,   I see this is going to
take a lot of work,   both in organizing the effort,   and in implementing
the code.    Just how this is going to be done,  I'm not sure,   but this
is what cypherpunks is all about.    To hash these things over,  flame on
each other's ideas,  etc.

   So far,  the Mac inplementaion team consists of the following individuals,
and are (or soon will be) working closly with Eric Hughs,  Phil Zimmerman,
and the other PGP folks

Mac PGP team:

  Richard Outerbridge [71755.204]
  Jim Clausing internet: jac@cis.ohio-state.edu
  Zbigniew Fiedorowicz internet: fiedorow@function.mps.ohio-state.edu
  INTERNET:crunch@netcom.com INTERNET:crunch@netcom.com
  Doug McNaught internet: doug@midget.towson.edu
  Philip Zimmermann internet: prz@sage.cgd.ucar.edu
  
  I talked with another individual last evening who also wants to be added
to the team,   but the others haven't yet been introduced to him yet.

  It is my plan to propose this idea to the PGP meeting at Sygnus this
upcoming Saturday at noon.   Then,   I'll report to those that couldn't
make it,  due to their location.    

  The progress on the Rander box is as follows:    I am currently evaluating
several proposed designs,  and have sent out queries for data sheets on
devices I plan on checking out for use,  prices,  etc.

  I have been studying the PGP code,   and can see it's going to take a
lot of work to get it into a form where true machine portability can
be realized.   As  a Mac purist,  a abhore the idea if translating Mac
GUI actions into ascii text and sending it to the current PGP "engine".

  Although it would take a lot of work,   I propose that we develop PGP
to have the following form.

  a) Encryption engine library - Main set of routines currently in the
     PGP program dealing with encryption of data.   These would be
     a set of "support" routines that would permit encryption of
     data in files,  as well as data in memory.   These would be
     totally machine independent,  and only ONE set of sources should
     exist and contain compiler options for platform specific code.
     These functions would then return error codes instead of console
     output.   Needed "key phrases" can be passed in as "char *",
     and sucessful operations would return NULL or if error,  an
     appropriate code be returned.  Other routines would be necessary,
     such as telling it where the random ring buffer is located,  and
     how long it is.   These routines would maintain their own
     pointers into this buffer.   This library would call routines
     in the Random number manager and pass information such as where
     the buffer is located.   See below:
     
  b) Key management library - Main set of routines that know how to 
     manage the keyring files,  it would have functions designed to
     extract keys,  add and remove them,  and work on the keyring
     files directly.   Again,  these would be machine independent
     routines.   This would also call routines in the Random number
     manager below.
     
  c) Random number management - Main set of routines to manage a
     "circular buffer" of random numbers used to generate keys.  This
     would work with both software and hardware random number generators,
     and would provide externally machine independent functions,  but
     internally they would be machine specific.
     
  d) GUI's for the various PGP application programs.   Mail management,
     file management,  network applications,  etc,  all calling the
     routines in a,b, and  c.   Also includes Hypercard Xcmds,  etc.
     
  Items a and b should have only ONE set of source code,  and be 
maintained and managed by existing people.    Items c would also
be same source code,   but have conditional compiler statements 
to "switch in" the machine dependent portions as apppropriate.

  I think it's possible to design the code in a and b to have very few
machine dependent conditional compiler #ifdef statements,  by forming
the main PGP guts portion to operate on textual input in the form
of "char *" instead of console input,  and let the calling code
pass "char *" to PGP library routines.

  Machine dependent stuff is in (d) and might include existing UNIX
PGP "main()",  Mac PGP main application,  and lower level "utilities"
such as Hypercar XCMD's etc.    In fact,  it is even possible to 
build these libraries to use NO global variables,  and use structures
instead.    But me,  being Mac biased,  will probably get a lot of
resistance to this proposal,  but it is just that,  a PROPOSAL.

  At any rate,   I think that portability issues would be better solved
if we were to adopt C code portability and to assume that not ALL
platforms work well with console type input,  and that Console
I/O should be "factored out" of the machine independent portions of the
existing PGP code.

  So,  what way folks,  has anyone got a better idea or proposal?
  
Cheers
JD





Thread