Put simply, cryptography involves scrambling a message in some pre-determined fa shion known to the sender and the recipient.

The message, once scrambled, is unrecogni sable; hence if an enemy intercepts it he or she will not be able to read it. It should be very difficult or unfeasible for the enemy to unscramble the message without knowing a particular aspect of how it was scrambled. This knowledge can be termed the key , which may be thought of as the initial state of the scrambling system. With mode rn encryption systems, simply knowing the sequence of operations, or the algorithm used, is not enough indeed, the source code for most modern encryption algorithms is publ icly available. Algorithms of which the details are secret are mistrusted by cryptogr aphers for good reason; security through obscurity is bad security [Schneier 1996 p3]. Ma ny of the cipher systems used by the copyright protection industry fall into this c ategory, and many have already been broken. Two classic examples of this follow. Firstly, the Content Scrambling System (CSS), used on DVD media to prevent digital copying, which was broken by a teenage hacker who was annoyed that he couldn t watch DVDs on his Lin ux machine [DeCSS]. Secondly, the system used by Adobe to secure their eBook format , which was cracked by Russian programmer Dmitry Skylarov, who was promptly prosecuted by Adobe [www.freeskylarov.org]. US copyright law, which practically makes it a criminal offence to publish any detail of the algorithms used, makes this situation worse. Three encryption algorithms One is an asymmetric algorithm and the other two are symmetric algorithms. Asymmetric algorithms have two keys a public key and a private (or secret) key. To use one, you make your public key known to the world, but keep your private key secr et. When someone wants to send you a secret message, they encrypt it with your publi c key. Only the corresponding secret key can then decrypt the message, and (if you ve kep t this key properly secret) that means only you can decrypt the message. If you want to send a secret message to someone else, you have to have their public key. These are oft en made available via the Internet. Symmetric algorithms, on the other hand, are more li ke traditional ciphers in that they have only one key, which must be kept secret

As RSA is the asymmetric algorithm

The RSA algorithm is based on the fact that factoring large numbers that are the product of two primes is very difficult. It is conjectured, but unproven, that any metho d of cracking RSA is as difficult as factoring. There exist RSA variants for which br eaking the code has been proven to be as difficult as factoring, and an example is given in [Welsh 1988 p188]. If someone develops a wonderfully fast factoring method, then the se curity of RSA and its variants will be compromised. The organisation most likely to hav e done so is the NSA. However, this is considered to be unlikely since mathematicians h ave been trying to find fast factoring methods for thousands of years [Singh 1999 p277-27 8] with little success. Also it is necessary to create new keys using bigger numbers to keep pace with advances in technology which have allowed increasingly large numbers to be factored using distributed computing and other novel techniques [Schneier 1996 p 158165]. [Welsh 1988 p180] gives the following description of the encryption and decrypti on procedures of RSA: I. Find two large primes p and q, and define n by n = pq II. Find a large random integer d that is relatively prime to the integer ( p -1)(q -1) III. Compute the unique integer e in the range 1 = e = ( p -1)(q -1) from the formula ed = 1(mod(p -1)(q -1)) IV. Make known the public key, which consists of the pair of integers (e,n). V. Represent M, the message to be transmitted, as an integer in the range {1, ,n}; break M into blocks if it is too big. VI. Encrypt M into a cryptogram C by the rule C= ?e (mod?) VII. Decrypt by using the private key d and the formula D = Cd (mod?)

Chapter 2. Specification and Design The necessary functionality of the system will be described below. 2.1 Arbitrary-length key generation and management The system will allow the user to generate RSA key pairs of arbitrary length. Th ough the system will suggest a recommended length as a default (this will be capable of u pdating), the user will be able to generate keys of any length, including those which are too long to make encryption/decryption computationally feasible and those which are too shor t to provide adequate security. There will be an option, where feasible, to allow war

ning messages to be sent somewhere if the user tries to do this. The system will allow the writing of keys to key files. These files will include data such as checksums and some means of ensuring that the files are valid. Public key fil es will be optimised for easy sharing (i.e. small file sizes). Private key files may be loc ated on fixed media (not recommended) or on removeable media such as floppies or CDs. The syst em may support some means of authenticating the user to the key file however, this is not essential if keys are stored on removeable media which is kept securely. The sys tem will allow the reading of keys from key files and will take all reasonable precaution s to ensure that sensitive data does not leak . 2.2 RSA Encryption and Decryption The system will, on being given a file containing data to be encrypted, and a ke y file containing a public key, encrypt the said data and write the encrypted data to m emory or a file. The system will conversely decrypt data that has previously been encrypt ed. The system will identify situations where the user has tried to decrypt data with th e wrong key (see below). The system will be able to cope with any binary file. 2.3 Error handling There is much scope for errors for example, if, given key pairs P(a,b) and Q(c,d ) (where the first of the 2 keys in each pair is the public key and the second the privat e key associated with it) you try to decrypt a message encrypted with public key a usi ng private key q. Since the mathematics wouldn't show any problem here, there must be some method for determining whose public key has been used to encrypt a given file of encrypted data. Keys must therefore have unique identifiers associated with them , and errors must be returned if the identifiers from an encrypted data file and a dec ryption key do not match. 2.4 Symmetric Encryption It is anticipated that the system will support one or more symmetric encryption algorithms such as IDEA. This would be to allow the system to be used in a simil ar way to the popular encryption product PGP[PGP], which uses asymmetric encrypt ion for keyexchange only, and actually encrypts data using a faster symmetric algorithm 2.5 Test and Timing Functions These functions will allow the system to return metrics about the environment th at it is currently running on. These tests will work by encrypting a given amount of data using either type of encryption with any key length, and measuring the time taken. Bas ed on

theoretical algorithm speeds, it will be able to estimate average encryption tim es for given key sizes, and therefore be able to assist users in selecting a key size. 2.6 Encoding and Integrity Checking In order to make it easier to send enciphered files via email or via similar mea ns, it is anticipated that the system will encode output files using Base64 encoding. In a ddition, methods such as cyclic redundancy checking will be used to detect any corruption . Checking will be performed at several levels to ensure that any errors are detec ted. 2.7 Digital Signatures and secure hashes The system will provide the necessary functionality for digital signatures to be implemented. This will include message-digest and secure hash algorithms which c an obviously also be used in their own right. Whether or not digital signatures are actually implemented will depend on time constraints.

3.2 Project goals A statement of the goals of the project will now follow. It was felt important t o produce a program that not only demonstrated encryption and decryption using RSA, but also had actual potential for use as a real program (as opposed to a demonstration one). The program would therefore have to - Implement encryption and decryption in RSA. - Allow the generation of RSA key pairs having a user-specified modulus length. - Implement encryption and decryption using symmetric algorithms, both for timing comparisons with RSA and to allow a hybrid mode of operation similar to that used by the PGP program and similar products. - Hide most of the complexity and technical details from the user. - Have a standard Microsoft Windows look and feel . - Be relatively straightforward to use, without a user needing any special knowledge. - Provide some form of help facility.