IMPLEMENTING AN RSA CRYPTOGRAPHY SYSTEM FOR WINDOWS. Joseph Rabaiotti Student No: Department of Computer Science Cardiff University

Transcription

1 IMPLEMENTING AN RSA CRYPTOGRAPHY SYSTEM FOR WINDOWS Joseph Rabaiotti Student No: Department of Computer Science Cardiff University Project Supervisor: Professor Antonia Jones Report Completion Date: 23 rd April 2003

2 IMPLEMENTING A RSA CRYPTOGRAPHY SYSTEM FOR WINDOWS Joseph Rabaiotti Department of Computer Science Cardiff University Version: 28/06/03 ii

3 Acknowledgements I would like to thank Professor Antonia Jones for her excellent supervision, assistance and encouragement throughout the project. iii

4 Abstract This report describes the implementation of a RSA cryptography system for Windows. The system was designed to allow key lengths to be chosen by the user at the time of key generation. The system was also designed to be easy to use and to hide complexity in such a way that the user need not have particular knowledge about encryption. The functionality provided by the system is described in detail, together with some of the specific difficulties that arose during implementation and how these difficulties were surmounted. The system was also tested for speed, and the results of these tests are given. iv

5 Table of Contents Chapter 1. Introduction Introduction Background... 1 Chapter 2. Specification and Design Arbitrary-length key generation and management RSA Encryption and Decryption Error handling Symmetric Encryption Test and Timing Functions Encoding and Integrity Checking Digital Signatures and secure hashes Chapter 3. Design Design principles Project goals Development strategy Design issues particular to RSA Testing Chapter 4. Implementation The Main Program The Cryptographic Modules The General Form of an Encryption Function RSA Encryption The General Form of a Decryption Function The RSA Decryption Function Composite Encryption and Decryption The RSA Source Code File The Tools Module Tools Data Structures Conversion Functions Reading and Writing Data Structures Testing and Verification Wrapping, Unwrapping, and Base 64 Encoding and Decoding Error and Message Decoding Test File Generation The Windows I/O Module Output Functions The Progress Bar and the Status Window Open and Save Dialog Boxes Miscellaneous Functions Chapter 5. Results and Evaluation Tests and Results Evaluation Future Work Conclusion REFERENCES APPENDIX A Why use encryption? APPENDIX B Performance graphs v

6 List of Figures Figure 3-1 Logical sub-systems and information flow...13 Figure 3-2 Basic conversions processes in RSA encryption...16 Figure 3-3 "Onion skin" diagram of ciphertext file structure...19 Figure 3-4 "Onion" diagram of the structure of a composite ciphertext file...21 vi

7 Chapter 1. Introduction 1.1 Introduction This project aimed to develop a cryptography system for Microsoft Windows which implemented the RSA cryptographic algorithm. The key aim was to allow arbitrarylength key generation that is, to allow the user to specify how long a key should be. The project also aimed to produce a useful system that could be used by people without extensive prior knowledge of cryptography. The development process involved a certain amount of research, followed by the implementation of various prototype programs for testing purposes. Once testing of prototype implementations was complete, the Windows program was developed. A strictly modular approach was taken each area of functionality was developed as far as possible as a self-contained unit that interacted with other units via well specified interface functions. In this report, it is assumed that the reader has knowledge of the C and C++ programming languages and of the standard C library functions. It is also assumed that the reader is familiar with the basic idea of cryptography (if not see [Singh 2000]). Specific knowledge of the operation of the cryptographic algorithms used is not assumed, nor is familiarity with the Windows application programming interface (API). However, the reader is expected to be familiar with Windows from the point of view of a user. 1.2 Background It will be assumed that the reader is familiar with the basics of cryptography if not they are referred to Simon Singh s The Code Book [Singh 1999] for a simple but informative description covering cryptographic history up to the present day, or to Schneier s Applied Cryptography [Schneier 1996] for a technical description of modern cryptographic algorithms. Put simply, cryptography involves scrambling a message in some pre-determined fashion known to the sender and the recipient. The message, once scrambled, is unrecognisable; 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 modern 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 publicly available. Algorithms of which the details are secret are mistrusted by cryptographers for good reason; security through obscurity is bad security [Schneier 1996 p3]. Many of the cipher systems used by the copyright protection industry fall into this category, 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 1

8 broken by a teenage hacker who was annoyed that he couldn t watch DVDs on his Linux 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 [ US copyright law, which practically makes it a criminal offence to publish any detail of the algorithms used, makes this situation worse. Open-source algorithms and those where the methods are publicly known, however, are good for security [Schneier 1996 p3]. Not only can we then be sure that the security of the encryption does not depend on the algorithm (and therefore if an enemy learns the algorithm he or she is no better off), but the algorithms can also be peer-reviewed by expert cryptographers and have their weaknesses analysed. Most encryption algorithms commonly used today are of this type. Unlike former times, when encryption had to be applied by hand or (later) with a mechanical or electro-mechanical cipher machine, modern encryption is almost exclusively done using computers, although many algorithms are implemented in special-purpose hardware rather than in software. Three encryption algorithms were used in this project. 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 secret. When someone wants to send you a secret message, they encrypt it with your public key. Only the corresponding secret key can then decrypt the message, and (if you ve kept 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 often made available via the Internet. Symmetric algorithms, on the other hand, are more like traditional ciphers in that they have only one key, which must be kept secret. Asymmetric algorithms tend to be slower in operation than symmetric ones, and for this reason they are commonly used together in a sort of hybrid or composite approach. The message is encrypted with a symmetric session key, which is generated at random. The session key is then encrypted with an asymmetric cipher using the message recipient s public key. The encrypted session key and the encrypted message are concatenated together and sent as one message. When the recipient receives the message, the session key is decrypted with the recipient s secret key, and she then uses it to decrypt the message with whatever symmetric algorithm has been used. This approach combines the convenience of asymmetric cryptography with the speed of symmetric cryptography. Here, asymmetric cryptography is actually being used to solve an age-old problem known as key exchange. Asymmetric cryptography was only invented in the mid-to-late twentieth century before that all ciphers were symmetric. This meant that the sender and recipient of a secret message had to exchange a symmetric key before they could send any messages. This process of key-exchange was the most vulnerable stage, as the key could be intercepted by an enemy, who would then be able to read all the messages sent using that key. Various protocols were devised to make key-exchange as secure as possible, but the essential problem remained: no matter how many stages you went through, keys still had to be sent from A to B. Key-exchange problems with enemy 2

9 ciphers arguably led to many of history s cryptanalytic breakthroughs, including the breaking of the WW2 German Enigma. Asymmetric cryptography was discovered concurrently in the 1970s by a number of researchers, the work of some of whom was classified. The concept was actually developed before any practical algorithms were invented to implement it. Ronald Rivest, Adi Shamir, and Leonard Adleman, researchers at the Massachusetts Institute of Technology, invented the first practical asymmetric algorithm around 1977 [Singh 1999 p ]. The system became known as RSA (from their initials). It is now known that British researchers at GCHQ also discovered asymmetric cryptography and devised a similar system at around the same time but of course, all their work was classified. It is not known whether the NSA had done any work in this field by this time, although they certainly took an immediate interest in the work of the early pioneers. RSA was patented in 1977, but the patent has now expired. Since then, many other asymmetric algorithms have been invented, some of which are similar to RSA and others of which use considerably different ideas. As RSA is the asymmetric algorithm that was used in this project, a discussion will be given of how it works. 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 method of cracking RSA is as difficult as factoring. There exist RSA variants for which breaking 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 security of RSA and its variants will be compromised. The organisation most likely to have done so is the NSA. However, this is considered to be unlikely since mathematicians have been trying to find fast factoring methods for thousands of years [Singh 1999 p ] 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 ]. [Welsh 1988 p180] gives the following description of the encryption and decryption 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 e C = Μ (mod Ν) 3

10 VII. Decrypt by using the private key d and the formula d D = C (mod Ν) Welsh then goes on to prove that this works, but this is beyond the scope of this document. Interested readers are referred to Welsh s book (see above reference). As previously mentioned, asymmetric algorithms tend to be slower than symmetric algorithms. This is especially true of RSA, and the speed decreases as the value of N increases. So in a sense there is a trade-off between security and speed; a value of N should be chosen that is large enough to be secure, and yet not so large as to make encryption and decryption unfeasibly slow. Schneier discusses this at length [Schneier 1996 p158 and also p469]. In addition, one can use the hybrid approach of using symmetric session keys to make encryption and decryption faster. It is this approach that is used by Philip Zimmerman s popular encryption program PGP [Singh 1999 p293], although it is not known whether it was he who originated the method. If the hybrid approach is used, then a cryptosystem that uses RSA needs to use a symmetric algorithm as well. The next part of the discussion will therefore be devoted to such algorithms. For many years the predominant symmetric algorithm in use was the Data Encryption Standard (DES). IBM developed this algorithm in response to a request for proposals from the US National Bureau of Standards (NBS). There was also a certain degree of collaboration with the NSA, who evaluated the algorithm (and later regretted this see [Schneier 1996 p267]). Though there was much speculation as to whether the NSA had intentionally weakened DES, it was discovered many years later that they had in fact optimised certain features of the algorithm in order to resist a certain type of cryptanalysis then unknown outside the field of classified research [Schneier 1996 p290]. So, in a sense, NSA actually improved the algorithm. DES was adopted as a federal standard on November 23, 1976 [Schneier 1996 p267]. As time went on it was discovered that DES had weaknesses and would not remain secure for much longer. However, it remained the US standard encryption algorithm for over 20 years. At about the time of DES s 20 th birthday, a replacement for DES was sought, to be known as AES (Advanced Encryption Standard). In September 1997, the National Institute of Standards and Technology (the successor of the NBS) put out a request for algorithms to be considered for the standard. The request stipulated that the algorithms should be unclassified, publicly disclosed, and available royalty-free anywhere in the world. There were also requirements regarding the type of algorithm (it had to be a symmetric block cipher) and on the block and key sizes it had to support [AES-NIST]. Several candidate algorithms were proposed, and eventually these were narrowed down, first to fifteen and then to five. On October 2, 2000, NIST announced their selection an algorithm called Rijndael. Rijndael was designed by two Flemish academics called Joan Daemen and Vincent Rijmen hence the name, which is a combination of their surnames [Rijmen]. 4

11 The best published description of Rijndael which is currently accessible is given by [Welschenbach 2001 p363], and it shall be paraphrased here. Rijndael is a symmetric block algorithm with variable block and key lengths. Blocks can be 128, 192 or 256 bits in length, as can keys. This corresponds to the AES guidelines. Each plaintext block is encrypted several times with a repeating sequence of various functions (i.e. in several rounds). Each round consists of four steps: substitution, permutation, diffusion and round key addition. In substitution, each byte of a block is replaced by application of a S-Box. Permutation and diffusion involve the mixing up of rows and columns respectively (where the data block is thought of as a 2D matrix). Round key addition involves the XOR of the current round key with the data block. Each round has its own round key, and these are generated by an expansion of the user s secret key. The total number of rounds thus depends on the block and key lengths. Unlike DES, Rijndael/AES has only one S- Box. For further details of how AES works, consult [Welschenbach 2001], where a full description of the S-Box and the various operations is given. For the purposes of this project an implementation of AES in C was used one which has been developed by Dr Brian Gladman [Gladman] and placed in the public domain. AES is still a very new algorithm, and people may still be somewhat wary about using it compared to an algorithm that has been around for longer and hence has had more opportunity for study and cryptanalysis. One such algorithm is IDEA, which was developed by Xuejia Lai and James Massey in 1992, building on previous algorithms they had developed. IDEA is the symmetric algorithm used by PGP [Schneier 1996 p320], and in 1996 Schneier described it as the best and most secure block algorithm available to the public at this time. [Schneier 1996 p319] The IDEA algorithm is described in detail by Schneier, who also gives source code. For this project, similar source code was used, which has been modified by a succession of people from code developed by IDEA s authors. IDEA is (or was) patented, but requires no licence for noncommercial applications. IDEA uses a 64-bit data block and a 128-bit key. Schneier s description of the IDEA algorithm runs as follows. Firstly, the 64-bit data block is divided into four 16-bit sub-blocks, which Schneier denotes X 1 -X 4. The key is divided into six 16-bit subkeys. These become the input to the first round of the algorithm. In each of the eight rounds the four sub-blocks are XORed, added and multiplied with one another and with the subkeys. Between rounds, the second and third sub-blocks are swapped. Finally, the four sub-blocks are combined with four subkeys in an output transformation. Schneier also gives the following step-by-step description of what happens in a round of IDEA: 1. Multiply X 1 and the first subkey. 2. Add X 2 and the second subkey. 3. Add X 3 and the third subkey. 4. Multiply X 4 and the fourth subkey. 5. XOR the results of steps (1) and (3). 6. XOR the results of steps (2) and (4). 5

12 7. Multiply the results of step (5) with the fifth subkey. 8. Add the results of steps (6) and (7). 9. Multiply the results of step (8) with the sixth subkey. 10. Add the results of steps (7) and (9). 11. XOR the results of steps (1) and (9). 12. XOR the results of steps (3) and (9). 13. XOR the results of steps (2) and (10). 14. XOR the results of steps (4) and (10). The output is the four sub-blocks that are the results of steps (11), (12), (13) and (14). To form the input to the next round, the two inner blocks are swapped (except for the last round). The final output transformation is as follows: 1. Multiply X 1 and the first subkey. 2. Add X 2 and the second subkey. 3. Add X 3 and the third subkey. 4. Multiply X 4 and the fourth subkey. The ciphertext is formed from these final four sub-blocks concatenated together. Decryption is the same as encryption, except that the subkeys used are either the additive or the multiplicative inverses of the encryption subkeys. For more on IDEA, see [Schneier 1996 p322] and the source code in the appendices. So the three encryption algorithms that were used have now been described. As mentioned, the project implemented RSA itself, but used existing implementations of AES and IDEA. The reason for this is that the primary aim involved RSA encryption, and the other algorithms were included to extend the functionality and provide a reference for making speed comparisons. The advantages of not having to implement the algorithms were sufficiently large to outweigh the disadvantages. These disadvantages, namely that one could not be sure of the veracity or accuracy of the source code, were minimised via the use of well-attested source code from reliable sources. In order to implement RSA it is necessary to have some way of handling very large integers. For this purpose the NTL arbitrary-length arithmetic library was used. This was developed by Victor Shoup [NTL] and is available for use under the GNU General Public License. Previous projects in this area [Newing 2001] have also used this library, although it has subsequently been updated. The NTL library provides for all arithmetic operations on large arbitrary-length integers, as well as several useful functions for generating prime numbers and testing primality. It is written in C++ and can be compiled for both UNIX and Windows, though [Newing 2001] used UNIX alone. The intention throughout was to develop for the Microsoft Windows operating system, since a certain amount of previous experience in writing programs for this system was available. It is therefore necessary to mention something about the Windows operating system, its interface, how programs are written for it, and how programs run, as certain aspects are highly distinctive and show considerable difference to programs written for 6

13 command line operating systems. The definitive text on Windows programming is Petzold s Programming Windows [Petzold 1999] although as this book is published by Microsoft, it is quite heavily biased towards Microsoft development products (i.e. Microsoft s Visual C++ compiler), something which can cause problems if you do not use Microsoft development products (A Borland C++ compiler was used for this project). Windows, like UNIX, is a multitasking operating system (though this has not always been the case). Its name is taken from the way in which its graphical user interface works. Most readers will already be familiar with the basic look and feel of Windows, and so this document will not describe more than is necessary to illustrate the programming differences. Just as in certain Object-Oriented Programming languages everything is an object, so in Windows almost everything that is displayed on the screen is a window, whether it is a button, a text control, an edit box, a dialog box, a message box or anything else. Users can interact with the windows on the screen by clicking on them with the mouse, or by certain combinations of keystrokes. Although many windows can be displayed, only one of them is usually active at a time. A window becomes active when the user clicks on it with the mouse. Programs that interact with the user (as distinct from programs which run in the background such as device drivers and parts of the operating system) display at least one main window. In a command-line type interface such as UNIX, MS-DOS, or the Windows NT/2000 command interpreter, only one program is able to interact with the user at any one time, and before switching to another program the first must usually be terminated. Under graphical environments such as Windows several programs can be used at once, and switching between them is easy, so an operation such as cutting some text from one program and pasting it into another is trivial to accomplish. However, programs written for such environments have a different structure to traditional programs written for DOS or UNIX-like environments. The basic building blocks of a Windows program are already provided for the programmer windows and so forth are created using relatively simple function calls via the Application Programming Interface (API). Thus, the programmer does not have to worry about drawing windows on the screen, detecting when the mouse pointer is over a window, or anything like that. Because Windows provides all the user interface implementation already, it needs to have some way of informing programs when certain user interactions have taken place. Therefore, unlike command-line programs, communication between the Windows operating system and a Windows application program is a two-way process. This is necessary, because the program may be being run concurrently with several other programs, and must be prepared to wait for indeterminate lengths of time between user interactions. Windows communicates with a program by sending it messages. A message is a predefined data structure. Every window a program displays has an associated window procedure. When the operating system wants to send a message to that window, it calls this window procedure. The window procedure looks at the message and decides what action to take on that basis. See also [Petzold 1999 p42]. 7

14 The windows used by a program can be of several types. All are based on a window class that defines them. This window class can either be predefined, as in the case of control windows such as buttons, statics, edit boxes, message boxes etc, or it can be customised (this approach is used for main windows). For predefined window classes such as the controls mentioned above, there is no need for the programmer to specify a window procedure as a default one already exists. For customised windows such as main windows and dialog boxes, the programmer must write a window procedure that processes messages sent to that window. Windows within a program also communicate by sending each other messages. So, for example, if a program has a button on its main window, the button will send a message to the main window when it is clicked, and the window procedure of the main window will contain the code that is to execute when the button is clicked. As already mentioned, Windows programs consist of at least one main window. This usually has a menu bar [Petzold 1999 p417], which allows users to select program functions. Menu bar functionality is provided by Windows, and menu items send messages to the program when the user selects them. In the window procedure, the program identifies which menu item sent the message and invokes the function associated with that menu item. The same process occurs for any buttons or other controls in the main window. Such controls are child windows [Petzold 1999 p357], and their parent is usually the main window. Child windows are defined as follows: In the program code, windows are manipulated using window handles. When creating a window using an API call such as CreateWindow(), one can specify the handle of the parent window. If a handle is specified, the window created by the API call will be considered a child of the window whose handle was specified as its parent. Dialog boxes are child windows that could be described as being halfway between predefined windows and programmerdefined windows. Dialog boxes have a predefined window class, but what they look like is specified by a template in a resource file [29]. Dialog boxes generally serve the purpose of getting some input from the user. For a discussion of dialog boxes see [Petzold 1999 p483]. So, it remains to describe how a Windows program actually runs. When the user runs the program, it initialises its window classes, creates all its initially visible windows, and performs any other tasks. It then enters a message loop [Petzold 1999 p60]. Windows maintains a message queue for each running program, and the message loop is responsible for checking to see if any messages are in the queue, and dispatching messages to the appropriate window procedure. The code of the message loop looks like this: while (GetMessage(&msg,NULL,0,0)) TranslateMessage(&msg); DispatchMessage(&msg); 8

15 Three API calls are involved here. GetMessage() gets a message from the application s message queue. TranslateMessage() is not important for the purposes of this discussion, so we will move on to DispatchMessage(), which sends the message to the window procedure to which it was directed, whether this is the program s main window or one of its children. A Windows program will spend nearly all of its time in the message loop, and so it could be said to form the heart of all Windows programs. For more details of Windows programming, see the implementation section, the source code in the appendix and also [Petzold 1999]. The Windows API also provides functions for input and output to files or printers, and for managing devices. 9

16 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. Though the system will suggest a recommended length as a default (this will be capable of updating), 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 short to provide adequate security. There will be an option, where feasible, to allow warning 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 files will be optimised for easy sharing (i.e. small file sizes). Private key files may be located on fixed media (not recommended) or on removeable media such as floppies or CDs. The system 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 system will allow the reading of keys from key files and will take all reasonable precautions 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 key file containing a public key, encrypt the said data and write the encrypted data to memory or a file. The system will conversely decrypt data that has previously been encrypted. The system will identify situations where the user has tried to decrypt data with the 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 private key associated with it) you try to decrypt a message encrypted with public key a using 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 decryption 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 similar way 10

17 to the popular encryption product PGP[PGP], which uses asymmetric encryption 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 that 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. Based on theoretical algorithm speeds, it will be able to estimate average encryption times 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 or via similar means, it is anticipated that the system will encode output files using Base64 encoding. In addition, 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 detected. 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 can obviously also be used in their own right. Whether or not digital signatures are actually implemented will depend on time constraints. 11

18 Chapter 3. Design 3.1 Design principles The design and development principles used will now be stated. For coding, the C programming language and the Borland C++ compiler were used. The NTL library is written in C++, and so the project needed to be compiled with a C++ compiler. However, no object-oriented features of C++ were used in the project code, so it is in effect written in C code not C++ code. The decision to produce a Microsoft Windows application (program) as opposed to a command-based one was made for several reasons, the main one being that some experience in writing Windows programs had already been gained. In addition, Windows is, for all its shortcomings, the predominant PC operating system. Many users now expect graphical interfaces, and they are considered to be easier to use than command-line ones. Windows, like UNIX, does still support a command line interface, but programs that use it are considered the exception rather than the norm. This differs from UNIX, where only a (growing) minority of programs require a windowing system such as X-Windows. When one thinks of a UNIX program there is almost an expectation that it will be command-based. Prototyping of certain aspects of the program may well be done using command-based interfaces before moving to a Windows interface later on. 3.2 Project goals A statement of the goals of the project will now follow. It was felt important to 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. Initially, consideration was given to implementing the project as a dynamically linked library (DLL), but it was later realised that this would be unfeasible due to the complicated nature of such libraries. See the implementation section for more details on this. 12

19 3.3 Development strategy The development strategy was bottom up in the sense that the process started by developing small procedures and routines for doing low-level tasks, and then gradually built up from there. Structured programming techniques were used throughout. There were fairly obvious logical divisions between the different modules, though these do not always correspond to actual divisions between, say, different source code files. The intention throughout was to provide clearly defined interfaces between modules, so that if it was necessary, say, to replace the primitive command-line interface module with a more sophisticated Windows one, this could be done with the minimum of modification to other modules. Figure 3-1 shows the logical divisions and how they communicate. Figure 3-1 Logical sub-systems and information flow Figure 3-1 shows the various logical subsystems and the way in which information flows between them. The main program co-ordinates the flow of information between each subsystem. Each cryptographic algorithm was to be treated as a subsystem in its own right accessible through a layer of cryptography routines that took as arguments the names of plaintext and ciphertext files and keys. Thus, to use a particular algorithm the program would call one of these routines, which would take the same sort of arguments as would the other routines for an encryption routine, the name of the plaintext file, a name for the resultant ciphertext file, and the name of the key (stored in a file) with which the plaintext should be encrypted. The I/O routines are shown as separate because they were designed to be as modular as possible. This was so that the simplistic command-based I/O module that was to be used for early development could be replaced with a more sophisticated Windows I/O 13

20 module which would have the same or a similar interface. For functions not directly visible to the user such as file handling, it was decided to use standard C library routines wherever possible. These work equally well under Windows as they do under DOS or UNIX, and so it meant a minimum of adjustment. Substituting one I/O module for another was designed to involve as small a number of changes to other modules as possible. Modularity was thus a key design criterion because this would allow the greatest degree of flexibility, and if one module was working incorrectly it could be debugged more easily. Though C++/object oriented programming techniques were not used, it was decided to make extensive use of data structures, particularly for storing and retrieving data from files. Data structures provide a convenient method for doing this see the section on file headers. The design of the cryptographic modules was based around the idea that only one such module would be implemented from scratch; the others would be based around third party public domain source code. As previously mentioned, this decision was made because well-attested source code for the two symmetric algorithms is widely available (and therefore re-implementing them would only really be re-inventing the wheel), and also because this project was meant to deal primarily with RSA, and that it was felt that time would be better spent concentrating on RSA than on developing IDEA and AES algorithms as well. Therefore, the majority of design decisions involved the implementation of the RSA algorithm the only issues arising from implementing the two symmetric ciphers was how to integrate them and provide modular interfaces. It was decided to make the interfaces (i.e. the encryption and decryption functions) for the symmetric algorithms as similar as possible to those for the RSA algorithm. The first design issue with RSA was finding a way to do arithmetic with large integers. It was decided to use the NTL arbitrary-length arithmetic library [NTL] for the following reasons: - It is free and in the public domain, under the terms of the GNU General Public Licence - It provides all the functionality necessary to do arithmetic with arbitrary-length integers, and also some other very useful functions for generating cryptographically-strong prime numbers. - It has been used successfully in prior work in this area [Newing 2001]. - It is compatible with Windows It would be fairly trivial, therefore, to implement those parts of RSA which were purely arithmetic. The disadvantages of NTL are that it does not provide very many useful conversion functions. It does provide functions to convert C/C++ numerical types to NTL large integers, and also to convert strings of digits i.e to such large integers. However, it provides no easy way to convert NTL large integers back to more primitive types. It was therefore decided to implement a module containing functions that handled conversion between NTL s large integer class (the ZZ class) and binary data or C 14

21 strings. Shown in the diagram above as the tools module, this would also contain any necessary functionality that did not really fit into any of the other modules. 3.4 Design issues particular to RSA It now becomes possible to describe in detail the other design issues associated with implementing the RSA algorithm as a practical encryption module, before going on to discuss general issues concerning encryption in general. To encrypt a file using RSA, the following steps have to be performed. 1. Split the plaintext file into blocks. Read in one block at a time. 2. Convert the block read in into a ZZ object. 3. Perform the arithmetic encryption function on the ZZ object (i.e. raise it to the e th power modulo N where e and N are the public key). 4. Convert the result back to a binary format. 5. Write the ciphertext block to a file. For decryption, all except step 3 are practically the same. This process must be repeated for each block. It would be possible to do everything in memory (assuming that only small files are to be encrypted), but this would be somewhat limiting. Rather than make assumptions about the amount of memory a user has, or limit the size of files that they are able to encrypt or decrypt, it was decided to do things one block at a time. Since the calculation already takes a substantial amount of time, any time saved by fewer disk accesses would not make that much difference to the speed at which files are processed. The process of splitting into blocks is not as trivial as it sounds. Very few files are going to be an exact multiple of the block length, so it is necessary to take this into account. The last block is almost certainly going to be shorter than the previous blocks, and most systems get around this by padding the last block with zeros. It is necessary to know the length of the last block when decrypting, and if it were not padded, this length would somehow have to be stored. It was decided therefore that the code would pad the last block with zeros in order to guarantee that all blocks were the same length. This also has a bearing on the leading zeros issue see below. After a block has been read in, it must be converted to a number. We are dealing here with binary data, so bytes could have any value between 0 and 255 (this also has a bearing on the leading zeros issue). The first ideas considered for converting bytes to numbers involved writing low-level conversion routines involving pointers and dynamic memory allocation. Basically, bytes read in from a file would be stored in a buffer, and each value in the buffer converted to a number between 0 and 255 in a character string. The character string was then converted to a ZZ object via the built-in conversion function. It was decided, for reasons given fully in the Implementation section, to alter this approach after finding it problematic. Prior work [Newing 2001] had used C++ String objects to hold data in the process of being converted to or from ZZ objects. This has various practical advantages (see Implementation) and was the approach eventually adopted. The conversion diagram Figure 3-2 shows the different stages data passes through as it gets encrypted or decrypted. 15

22 Figure 3-2 Basic conversions processes in RSA encryption The leading zeros issue is as follows. If a number has leading zeros, they are generally suppressed in calculations for example 0003 x 0004 = 12 not This is perfectly correct when dealing with numbers. However, the numbers we are dealing with here represent something the bytes of the plaintext or ciphertext files. Take for example a string of four bytes representing four bytes having the value 65, or ASCII A. Imagine we put this through the encryption function as a number and it emerges as When we come to decrypt, we put this number through the decryption function and the result is as expected, the leading zero has been suppressed. So far, no problems. But when we come to convert the number back into bytes, how do we read it? As before, we split it up into groups of three and get ? nonsense, as 650 is too big to be represented by one byte. The easiest apparent solution to this problem is to check at key stages whether the number of digits is divisible by three and to add one or two leading zeros if it is not. This is the approach taken in [Newing 2001], where only text data was being dealt with (text data generally does not contain zero bytes). Unfortunately, it was impossible to solve the whole problem with this approach as the bytes of the data being dealt with could have any value, including zero. Using the above approach, if the first byte in the block was zero, it would be dropped entirely. For example, if one were to encrypt the string [NULL]ABCD, where NULL = 000, A = 065, B = 066, C = 067 and D = 068, then one might convert the string into the number On encryption and decryption, this would 16

23 become The number of digits is not divisible by three, so we add a leading zero to get ABCD. The null character has vanished, and thus the deciphered plaintext is corrupt. This problem was solved by deciding to use a ciphertext file header (see below for general issues concerning file headers) in which the block size used to split up the plaintext would be stored. When the ciphertext is decrypted, the size of the plaintext block produced can then be compared with the block size from the file header. If it is smaller, leading zeros can be added until it is the right size. For example, suppose in the example above we knew that the encryption block size was 5 (there are five bytes in the string). On encryption and decryption, we see that there are only four bytes in the (corrected) string. We can therefore deduce that there was a zero byte at the beginning of the block, and add one accordingly. This approach does require that each plaintext block is guaranteed to be of the block length, and so padding is definitely necessary. There are also issues involving ciphertext blocks, as described by [Newing 2001]. It is necessary for the length of these to be known, and [Newing 2001] solved that problem by padding them with leading zeros to the size of the key modulus N before writing them to the output file. Since it is necessary to have the decryption key to decrypt the file, and if you have the key you know N, the block length information is then easily available, and the leading zeros have no effect on the decryption calculation. Of course, when the plaintext is decrypted, the padding bytes will still be attached to the last block. For this reason, and to resolve the issue, it was decided to store the original file size in the ciphertext file header. A truncation function would then be used to remove the padding from the decrypted plaintext by truncating it back to its original file size. Design issues that affect all three encryption algorithms will now be discussed. Firstly, it is necessary to provide data structures that describe files, and these will be termed file headers. C data structures were used for this purpose because they are easy to write and read from files using the standard library functions fread() and fwrite(). Files generated by the program (ciphertext and keys) will include headers to store information about the data contained in the file what algorithm is used, what key is used, how many blocks, and various information pertaining to error checking. One problem of encrypting data files of all types is knowing what type a file is when it is decrypted. This is trivial for text files, but not for other types. Unlike some platforms such as the Apple Macintosh, in Windows filename extensions are used to indicate what type a file is. A filename extension or wildcard is a full stop character followed (originally) by three letters. For example, executable files under Windows have the extension.exe whereas JPEG image files have the extension.jpg. This is used to determine what program Windows should use when the user clicks on a file - Windows has no other way to determine file type. It might be possible to store the plaintext file name in the ciphertext file header, but this would weaken security by alerting interceptors to the contents of an encrypted file. It was decided to solve this problem by wrapping files before encrypting them. Wrapping involves appending a file header to the file containing the original file name (and the extension). When the file was 17

24 decrypted, it would be unwrapped the header would be removed. The information from the header is then used during decryption to determine what name and extension to give the output file. It was also decided that ciphertext output files produced by the system would be further encoded using Base64 encoding in order to make them easy to transmit in the body of messages. PGP [PGP] uses this form of encoding. It was eventually decided not to use this encoding for key files. All the modules that implemented cryptographic algorithms would also implement functions for generating keys. For the two symmetric algorithms, these functions would have to be implemented from scratch, as the third-party source code did not include them. It was planned that keys would be stored as individual key files, having a file header that contained information about the key. Thus, key generation functions would take arguments such as a name to use for the file, a modulus length (in the case of RSA) and some form of identifier to identify the owner of the key. Generating AES and IDEA keys simply involves getting some random data which is of the right size (128 or 256 bits symmetric key lengths are fixed), whereas generating RSA keys involves generating prime numbers, as explained in the Background section. Luckily, the NTL library already provides functions for generating cryptographically strong prime numbers. Key identifiers would be used to label ciphertext as having been encrypted with a particular key. This would allow the system to ensure that the correct key was used to decrypt it, and for decryption to fail if an incorrect key was used. It was decided not to force the user to take precautions with regard to key storage (such as requiring that keys be stored on removable media) but this will be advised in any contextual help provided. The user interface would be the same as commonly found in Windows programs and would conform to the Windows look and feel. An important part of this is indicating to the user the progress of operations that might take some time to complete which applies to most of the operations performed by the program. It was decided therefore to use both a progress bar and some sort of status indicator that could be used to inform the user exactly what the program was doing at a given time, and when tasks were complete, or whether they were aborted due to errors. On the subject of error handling, the decision was to use a form of structured error-handling where errors generated by low-level functions were passed up to the functions that called them and so on, until they reached a level at which they could be dealt with gracefully. For details of this, see the implementation section. User interactions with the program would use either the menu bar or various dialog boxes. It was decided to give each key generation function its own dialog box to collect the necessary information for generating the key. To guard against the possibility of corruption occurring or having occurred in the transmission of ciphertext or the encryption or decryption procedures, error checking would be implemented at both the plaintext and the ciphertext level. All file headers would therefore contain error-checking information that could be used to determine whether errors had occurred. The error checking methods it was decided to use were the commonly used Cyclic Redundancy Check (CRC) and also the RSA Data Security Inc. Message Digest Checksum (MD5). Both of these were found as public-domain source code. 18