Between Heaven & Hell 2/BetweenHeavenHell.cdr/100/1/crypto.arc/CPUB.DOC

Text File | 1985-11-05 | 18KB | 463 lines

                               CPUB

                    A PUBLIC-KEY CRYPTOSYSTEM

                        INSTRUCTION MANUAL


                        (C) COPYRIGHT 1985
                          ARTHUR MELNICK
                       ALL RIGHTS RESERVED


               THIS SOFTWARE IS USER-SUPPORTED.   IT MAY
          BE  COPIED AND DISTRIBUTED FREELY,  HOWEVER IT
          MAY  NOT BE SOLD.   IT IS COPYRIGHTED  BY  THE
          AUTHOR   AND  HE  HOLDS  ALL  RIGHTS  TO   ITS
          DISTRIBUTION.   WHEN  COPIED,  IT  MAY NOT  BE
          CHANGED OR MODIFIED IN ANY WAY.

               IF  YOU  FIND  THIS  PROGRAM  USEFUL,   A
          DONATION OF $25 IS REQUESTED.
               SEND DONATIONS TO:

                         ALMTEK
                         P.O. BOX 6425
                         SAN RAFAEL, CA. 94903

               IF YOU USE THIS SOFTWARE FOR BUSINESS  OR
          COMMERCIAL  PURPOSES,   THE  DONATION  IS  NOT
          OPTIONAL.

               USERS ALSO SENDING THEIR NAME AND ADDRESS
          WILL  RECEIVE A COLLECTION OF PROGRAMS  CALLED
          THE DATA SECURITY TOOL KIT, WHICH IS DESCRIBED
          AT THE END OF THIS MANUAL.

               THIS SOFTWARE AND MANUAL ARE PROVIDED "AS
          IS"  AND WITHOUT WARRANTIES AS TO  PERFORMANCE
          OR  MERCHANTABILITY OR ANY EXPRESS OR  IMPLIED
          WARRANTIES  WHATSOEVER.   THE USER MUST ASSUME
          THE ENTIRE RISK OF USING THE SOFTWARE.




















I.  WHAT IS A PUBLIC-KEY CRYPTOSYSTEM?

     The  desire  to  send messages in a form which  can  not  be
understood  by  anyone  other  than the  intended  recipient  has
existed  for  centuries.   Codes and ciphers have  been  devised,
used,  and  improved upon throughout history.   In spite of this,
people  have been trying to circumvent the system and  read  each
other's mail anyway for just as long.
     One thing which has remained constant through all of this is
the need for a secret "key" or password, known only to the sender
and intended receiver of the communication,  which is required to
unlock  the hidden message.   Without this key,  an  unauthorized
third  party who happens to gain access to the coded message will
be unable to decipher it.   The need for a key or password  does,
however, create some inconvenience.
     Let  us suppose that Tom wishes to receive a secret  message
from  Nancy  using  some suitable code.   Tom must first  find  a
secure  way  of  communicating to Nancy the key she must  use  to
encode  the  message,  because he must then use the same  key  to
decode  it.   If some third party should gain access to the  key,
then they could decode the message at will.
     If  at  some subsequent time Tom wishes to  receive  another
message from Nancy,  he has two choices.   He may again,  through
some secure means,  communicate another key to her, or he may use
the  first key over again.   The problem with using the same  key
over   again  is  that  if  the  code  has  any  weakness   (i.e.
"breakability")  at  all,  a  potential code breaker has  a  much
better chance of breaking the code if he or she is provided  with
two  samples  of the code in the form of two  different  messages
which have been encoded with the SAME key.
     Now  let us suppose that Tom also wants to receive a  secret
message from LaVerne.   He again must, through some secure means,
communicate a key to LaVerne.
     He can, of course, use the same key he used for his messages
from  Nancy.   There  are two potential problems with this  idea.
The first is the obvious one that Nancy can now read his messages
from  LaVerne.   The other is that now that two people  know  the
key, there is twice as much chance that someone with knowledge of
the   key  will  wittingly  or  unwittingly  divulge  it  to   an
unauthorized party.
     Tom's  problems grow with time as he starts receiving  coded
messages from Shirley and Maxine.   He must either distribute new
keys  through  secure channels to each new correspondent  on  his
list,  or  he must accept the ever increasing risks of using just
one common key for all.
     In the late 1970's two bright gentlemen named Martin Hellman
and  Whitfield Diffie came up with a solution to Tom's  problems.
Their  solution  calls  for  structuring the  code  so  that  two
different keys are used.  The first key is used only for encoding
the message and can not be used for decoding.   The second key is
used  for  decoding  and can not be used  for  encoding.   If  an
unauthorized  person intercepts the coded message,  he or she can
not decode the message even if the are in possession of the first
(encoding) key.
     There  must,  of course,  be some mathematical  relationship


PAGE 1                (c) COPYRIGHT 1985 ARTHUR MELNICK








between between the two keys,  but in a practical system of  this
type,  this relationship is so complex and so well hidden that is
not  possible  with the resources available today to  ferret  out
this relationship and thereby break the code.
     Tom  can  now distribute the same encoding key  to  everyone
without  caring who overhears it.   He need only insure that  the
DECODING  key  remains  secret  and he need not  reveal  that  to
anyone.  Tom could even distribute the key through a newspaper or
by writing it on a wall or any other public means (hence the name
public-key  cryptosystem).   Anyone could send him a message  and
only he could decode it.   Not Nancy.   Not LaVerne.  Not Gloria.
Only him.

II.  AN OVERVIEW OF CPUB

     CPUB  is  a  public-key cryptosystem of the  type  described
above.  It consists of three individual programs:

     CPGN      CPGN  is  used it GeNerate or create the two  keys
           required  to make the system work.   Most  users  will
           only need to run CPGN once,  however it will produce a
           different set of compatible keys each time it is run.

     CPEN      CPEN  is  used to ENcode any file using  a  public
           encoding key produced by CPGN.

     CPDC      CPDC  is used to DeCode,  using a secret  decoding
           key  produced by CPGN,  any file that  has  previously
           been encoded by CPEN.

     All  three of these programs run on an IBM PC or  compatible
using the MS-DOS operating system version 2.0 or later  (higher).
64  K  of  memory is required.   The programs will operate  on  a
system having a monochrome or color monitor and at least one disk
drive is required.  Hard disks are supported.
     The user is expected to possess a basic knowledge of the MS-
DOS  operating  system.   Files  acted on by the  system  may  be
specified by the user with an optional drive, path, and extension
so long as they conform to MS-DOS standards.
     Errors  are trapped.   This means that if a program can  not
proceed for some reason,  it will display a message on the screen
informing the user of what is happening instead of just  aborting
with  no  explanation.   Most error messages are not detailed  in
this  instruction manual,  however they are all self  explanatory
(e.g. "DISK FULL?").

III. CPGN

     CPGN  creates  two  files on the default  drive.   The  file
"CPUB.ENC",  created  by CPGN,  contains the public encoding  key
used to encode files.  The file "CPUB.DEC", also created by CPGN,
contains the secret decoding key needed to decode files.
     Each of these two files is 8192 bytes long.  The user should
assure that there is enough room on his default disk to hold  the
files before he runs the program.


PAGE 2                (c) COPYRIGHT 1985 ARTHUR MELNICK








     The  program  takes from 30 seconds to a minute to  run  and
will  occasionally display "*" characters on the screen to assure
the user that his computer has not died.
     The  program  assigns  a ten letter serial  number  to  each
compatible pair of key files. An example of a serial number might
be "SEKMPOLLQW".  This is NOT the actual key used in the encoding
and decoding calculations but just a random serial number used to
distinguish  one key pair from another.   The user can  determine
the serial number after the files have been created with the  DOS
command  "TYPE  CPUB.ENC".   The computer will then  display  the
message:

                 PUBLIC ENCODING KEY XXXXXXXXXX.

where  XXXXXXXXXX is replaced by the serial number for an  actual
file.  Similarly the DOS command "TYPE CPUB.DEC" will display the
message:

                 SECRET DECODING KEY XXXXXXXXXX.

     The  files  CPUB.ENC and CPUB.DEC can and should be  renamed
after  they have been created.   In this way a user can  use  the
CPUB  system  to send coded information to more than  one  person
since each receiver is likely to have their own public key.   For
example,  two  different  versions of CPUB.ENC might  be  renamed
"LAVERNE.ENC"  and MARSHA.ENC".   The serial numbers of the  keys
can,  of  course,  still be determined after the files have  been
renamed   with   the   "TYPE  FILENAME"   command   (e.g.   "TYPE
LAVERNE.ENC").

IV. CPEN

     CPEN  encodes  a file using a public encoding key which  has
been produced by CPGN.
     CPEN  requires that the user specify three files for  it  to
process:

          INPUT FILE:         INPUT  FILE  is  the  file  to   be
                         encoded.

          OUTPUT FILE:        OUTPUT  FILE is the file which will
                         contain  the encoded  information  after
                         the  program  has run.   If an  existing
                         file  has been specified by the user  as
                         the  OUTPUT FILE,  the program will  ask
                         the  user  if he wants to  overwrite  it
                         before proceeding.   Overwriting a  file
                         destroys its original contents.

          KEY FILE:           The  KEY  FILE  must  be  a  public
                         encoding  key produced by CPGN.   If KEY
                         FILE  is not in the proper  format,  the
                         program  will  not accept  it  and  will
                         prompt the user for another file name.



PAGE 3                (c) COPYRIGHT 1985 ARTHUR MELNICK








     Since  the OUTPUT FILE will be longer than the  INPUT  FILE,
the user may not specify the same file for both.
     The user may enter the names of the three files in either of
two ways.
     First,  he  may start the program by entering "CPEN" on  the
DOS command line.   The program will run and will prompt the user
for  the  names of the three files in turn.   If the user  enters
"CONTROL  BREAK" or "CONTROL C" in response to  any  prompt,  the
program will immediately abort and return to DOS.
     The  second way the user may specify the names of the  three
files  to be processed is to start the program by entering on the
DOS command line:

           CPEN [INPUT FILE] [OUTPUT FILE] [KEY FILE]

where  INPUT FILE,  OUTPUT FILE,  and KEY FILE are as  previously
defined.   Each  file name must be separated from the  proceeding
one by one or more spaces.  If only INPUT FILE or only INPUT FILE
and  OUTPUT FILE are specified on the command line,  the names of
the remaining files will be prompted for when the program runs.
     After  the  program completes its processing  the  user  may
enter  on the DOS command line the command "TYPE filename"  where
filename is replaced by the name of the just created OUTPUT FILE.
The following message will then be displayed:

          ENCODED WITH PUBLIC ENCODING KEY XXXXXXXXXX.

where  XXXXXXXXXX is replaced by the serial number of the  public
encoding  key used to encode the file.   In this way a file which
contains information encoded by the CPUB system can be identified
and the encoding serial number can be determined.

V. CPDC

     CPDC decodes a file which has been encoded by CPEN.
     CPDC  requires  the  user to specify three files for  it  to
process:

          INPUT FILE:         The   INPUT   FILE   contains   the
                         information  which has  previously  been
                         encoded by CPEN.   If the user specified
                         INPUT FILE is not in the proper  format,
                         the  program will not accept it and will
                         prompt for another INPUT FILE.

          OUTPUT FILE:        The  decoded  information  will  be
                         written   to  OUTPUT  FILE.    The  same
                         cautions  that apply to  CPEN  regarding
                         overwriting    the   output   file   and
                         specifying  the  same  input  file   and
                         output file also apply to CPDC.

          KEY FILE:           The  KEY  FILE  must  be  a  secret
                         decoding  key produced by CPGN.  If  the
                         KEY  FILE  is not in the proper  format,


PAGE 4                (c) COPYRIGHT 1985 ARTHUR MELNICK








                         the program will not accept it and  will
                         prompt the user for another file name.

     The encoding serial number of INPUT FILE must be the same as
the  decoding  key serial number of KEY FILE or the program  will
not  accept  that  KEY FILE specification  and  will  prompt  for
another one.
     The  user  may  enter  the names of the three  files  to  be
processed by CPDC in either of the two ways detailed for  program
CPEN.

VI. SECURITY AND SPEED

     When  a file is encoded by CPEN,  extra information is added
to the output file in a random way.  When that file is decoded by
CPDC, the program checks that the same extra information is still
present  in the encoded file.   This is done to  prevent  someone
from  trying  to  "spoof"  the  file  by  modifying  the  encoded
information.   When  CPDC detects that the encoded file has  been
changed, it displays the message

FILE filename HAS BEEN ALTERED!
PROCEED? (Y/N):

     If the user enters an "N", the program will abort.  If a "Y"
is entered, the program will continue until the entire INPUT FILE
has been decoded or another error is detected,  at which time the
same message is repeated.
     The  CPUB public-key cryptosystem is designed to operate  at
high  speed in the personal computer environment.   Files can  be
encoded  and  decoded  at  a rate of 2 to 3  thousand  bytes  per
second.   The mathematical formula (algorithm) used achieves this
speed  by sacrificing some measure of security.   A  person  with
a  strong  background  in the mathematics of  code  breaking  and
access  to a large and powerful computer could,  in  time,  break
this  code.   If the information that the user wishes to  protect
involves  the survival of the free world,  then the author  would
prefer that some other, more secure, code is used.



















PAGE 5                (c) COPYRIGHT 1985 ARTHUR MELNICK








                   THE DATA SECURITY TOOL KIT

     The  Data  Security  Tool Kit is a  collection  of  programs
designed to allow the user to send,  receive,  store and use data
and  program  files  while  denying  access  to  those  files  to
unauthorized personnel.

     The programs include:

     CERA      CERA deletes files from a disk or diskette in such
          a way so that they can not be "undeleted".

     CDES      CDES   encrypts  and  decrypts  files  using   the
          National  Bureau of Standards Data Encryption Standard.
          In addition to the usual "electronic code book" mode of
          operation,  CDES also supports the more secure  "cipher
          block chaining" mode.

     CEX       CEX expands a binary file into an ASCII file which
          may  be  sent  or received by a  communications  program
          which only supports 7 bit ASCII files.

     CMP       CMP compresses ASCII files produced by CEX back to
          their original 8 bit format.

     CX        CX  encrypts and decrypts files using a  key  file
          which  is at least as long as the file to be  encrypted
          or  decrypted.   If an existing program or data file is
          used as a key,  CX produces a "running key" or Vigenere
          cipher.   If a file of random numbers is used as a key,
          CX  produces  a "one time pad" cipher,  the  only  code
          which can be mathematically proven to be unbreakable.

     CGR       CGR,   when  used  in  conjunction  with  an   AST
          RESEARCH,  INC. "SixPak" multifunction card, produces a
          block  of  random numbers in memory.   It does this  by
          using  the  SixPak card's clock to  time  the  interval
          between user key strokes.

     CBR       CBR  writes or appends the block of random numbers
          produced by CGR to a disk file so that they may be used
          as a key file by CX.

     CWR       CWR  writes  a file to a diskette  and  completely
          bypasses  the  diskette's directory.   Since  CWR  also
          scrambles the file, it is very difficult for someone to
          determine that the file is even there.

     CRD       CRD reads files from diskettes written by CWR.

     CFC       CFC  (FastCryp)  is a fast  cryptographic  program
          which  encodes and decodes at better than 4K bytes  per
          second.




PAGE 6                (c) COPYRIGHT 1985 ARTHUR MELNICK