Client Contract ( Revised )

General Description

Modern cryptography is a remarkable field. It manages to solve problems that
one might guess to be unsolvable, to define goals that one might assume to be
undefinable, and to prove theorems that one might think to be unprovable.
Cryptography deals with very human concerns---issues of privacy, authenticity,
and trust---but it does so in a way that is concrete and mathematical.
The word cryptography comes from the Latin crypt, meaning
secret, and graphia, meaning writing. So cryptography is literally secret writing: the study of
how to obscure what you write so as to render it unintelligible to those who should
not read it. Nowadays cryptography entails a lot more than finding good ways for
keeping your communications secret.
 

Contractor Agreement

The members of the CYPHER team: John Jemsek, Amarish Khopkar, Joon Ohh, Steve Park,
Rob Whitehurst, and Philip Ong hereby known as the contractors agree to provide fully
functional software that meets the specifications defined under Primary Requirements.
This software will be available to the Client no later than May 4th, 2000.
The contractors also agree that if time permits, there is a possibility of the software
containing added features outlined in sections Secondary Requirements and Tertiary Requirements,
however the contractors hold no responsibility for these requirements be met in the
final product. The contractors also agree to provide documentation and updated progress
reports for this project on the CYPHER web page.
 

Primary Requirements

• Implement statistical methods described in The Code Book, by Simon Singh as tools to aid in solving encoded messages
• Create a friendly but simple interface for using these tools
• Use of C++ for base algorithm coding
• Use of FLTK for interface
• Use on Unix
• Reverse algorithms for encoding ASCII messages

1.  The user will be presented with a scrollable window containing the source message to be decrypted.
     A second window will display the corresponding decrypted text.  Replacing a letter or string in the second
    window (perhaps by the mouse-based "select and replace" method) will result in all similar text being replaced,
    at least in the case of substitution ciphers.

2.  A capability for dynamically specifying the alphabet will be provided.

3.  The kind of decryption to be performed will be selectable. These will be usable in succession, to handle
    messages encrypted by multi-step methods.

4.  Displays of various statistics will be provided, including the 1 letter and 2 - 4 letter-group histograms of
    the messages. These histograms will be presented in both tabular and graphical form (although not necessarily
    in both forms simultaneously).

5. At least partial dictionary look up of decrypted text will be implemented. It will be automatic and work
    for both full and partial (i.e. likely) words.  When matches are found, they will be visually marked so that
    they pop out to the user.  Partial matches will not display exactly the same as full matches.

6.  The handling of transposition cyphers will allow the text to be "re-blocked" arbitrarily.  Thus, the messages
    will be able to be arranged as a matrix of arbitrary dimensions for transposition.  Note that this may sometimes
    require addition or removal of padding characters. This case will be possible but not automatically selected,
    unless the existence of padding is detected.

Secondary Requirements

• Compatibility for use on a PC OS
• Implementation of brute force algorithms as a secondary method for aid in decryption
• Encryption/Decryption by packing and unpacking binary data bits

1.  The system will be able to handle messages with various character sizes.  For example, encryption of an
    alphabet having only 26 letters, space, and a few punctuation symbols, will only require storing 6 bits per message.
    Thus the initial data to be decrypted will have to be unpacked.

2.  For enigma-type cyphers, the design of the enigma machine must be defined by the user, and then the
    decryption could be done by brute force. Specifically, the UNIX crypt(3) function is an example of an
    enigma machine.  It should be possible to crack passwords using the product, if the proper model of crypt
    is specified.
 

Tertiary Requirements

• Networking to allow splitting of one problem among multiple computers

Alfred Graham Gash, hereby referred to as the Client, agrees to provide the contractors with the necessary
computing resources beyond those available to the contractors. Specifically, the client will act as a liaison
between the contractors and the Computer Science Department at UNC-Chapel Hill when the need arises.
If the client is unable to meet this requirement, thorough testig will be limited. Furthermore, the client agrees
to make himself available to respond to questions and comments in a timely fashion.
 

Risks

• Algorithms given by book may be insufficient for solving complex encrypted messages
• The program may be so revolutionary in the field of breaking codes that the government hunts us down and accuses us of being Canadian spies!
• Algorithms may not be implementable

Signatures

Alfred Graham Gash ( Client )    ____________________________________

David Stotts ( Boss )    ___________________________________________

John Jemsek ( Producer )    ________________________________________

Philip Ong ( Technical Director )    ___________________________________

Amarish Khopkar ( Contractor )    ___________________________________

Stephen Park ( Contractor )    ______________________________________

Robert Whitehurst ( Contractor )    __________________________________

Joon Ohh ( Contractor )    ________________________________________