IMPLEMENTATION OF A SECURE MESSAGING APPLICATION USING ELLIPTIC CURVE CRYPTOGRAPHY

IMPLEMENTATION OF A SECURE MESSAGING APPLICATION USING ELLIPTIC CURVE CRYPTOGRAPHY By Abdul-Rahman Mahmood Thesis Submitted to Sir Syed University of Engineering and Technology in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE IN COMPUTER ENGINEERING March, 2004

ABSTRACT In this thesis, an implementation of a secure messaging system based on a hybrid cryptographic scheme is presented. The system is hybrid because it employs public key cryptographic scheme for key exchange and symmetric key cryptographic scheme for encryption. In public key cryptographic scheme, Elliptic Curve Cryptography (ECC) is used. Elliptic curve cryptography provides a methodology for obtaining high-speed, efficient, and scalable implementations of a messaging system. In this research thesis, we have described in detail the working and implementation of elliptic curve cryptographic technique, and the results of our implementation of the elliptic curve cryptography and finally we have compared our results with the rival of ECC i.e., RSA. Elliptic curve cryptosystems were first proposed independently by Victor Miller and Neal Koblitz in 1985 [8]. Elliptic curve cryptography is an emerging public key cryptosystem which provides the same degree of security as used in Secure Socket Layers (SSL) today with approximately one-eighth the key size [7]. This results in bandwidth savings, efficient implementation and compactness in silicon without any effect on security as compared to its rival, RSA. With such attributes, the technology becomes especially useful for mobile devices and other small devices that are limited in the power, CPU performance, memory or bandwidth. Internet is a huge inter-connected network of computers. There are many people with either ill-intension or fun are keen to intercept your messaging. That s why we need a secure messaging system. Secure email messaging allows a company to safely and securely control the flow of incoming and outgoing information via email over the internet. The thesis entails development of cryptographically secure email messaging using ECC. The results generated are indicating that ECC is highly computation intensive as compared with RSA. Moreover we have observed that data size that RSA can process is much lower than ECC. Further to the results it was observed that key the generation time of ECC is almost equal or relatively efficient then RSA. i

TABLE OF CONTENTS ABSTRACT TABLE OF CONTENTS LIST OF FIGURES LIST OF TABLES ACKNOWLEDGMENTS i ii v vi vii Chapter 1 INTRODUCTION 01 1.1 Background to Research 01 1.2 Significance of a secure messaging application 02 1.3 Problem description 03 1.4 Objective 03 1.5 Methodology 04 1.6 Thesis Description with Technical details 04 Chapter 2 CRYPTOGRAPHY AND SECURITY CONCEPTS 06 2.1 Introduction 06 2.2 Classical Cryptography 07 2.3 Classical Cryptographic Techniques 07 2.3.1 Transpositions 07 2.3.2 Caesar Substitution 08 2.3.3 Monoalphabetic Substitution 08 2.4 Key-based Encryption 09 2.5 Cryptographic services 10 2.5.1 User Authentication 10 2.5.2 Data authentication 10 2.5.3 Data integrity 10 2.5.4 Data origin authentication 11 2.5.5 Non-repudiation of origin 11 2.5.6 Data confidentiality 11 2.6 Cryptographic primitives 12 2.7 Encryption primitives 12 2.7.1 Symmetric ciphers 12 2.7.2 Stream ciphers and block ciphers 13 2.7.3 Asymmetric ciphers 13 2.7.4 Symmetric versus asymmetric ciphers 14 2.8 Authentication primitives 14 2.8.1 One-way functions and hash codes 14 2.8.2 Digital signature 15 2.8.3 Hash functions versus digital signatures 15 2.9 Rivest Shamir Adleman (RSA) 16 2.9.1 RSA Example 16 2.10 Details of PGP 17 ii

Chapter 3 EMAIL PROTOCOLS AND ENCODING 19 3.1 Email protocols 19 3.2 SMTP 19 3.2.1 SMTP COMMUNICATION MODEL 20 3.2.2 A Typical SMTP Transaction Scenario 21 3.3 Post Office Protocol version 3 (POP3) 22 3.3.1 POP3 Basic Operation 22 3.3.2 POP3 Security Considerations 24 3.3.3 Example POP3 Session 24 3.4 Encoding and decoding mail messages 25 3.4.1 Requirement of encoding 26 3.4.2 Transfer Encoding 27 3.4.3 UUEncode and UUDecode Overview 27 3.4.4 Need of UUEncode 28 3.4.5 UUEncode Message format 28 Chapter 4 MATHEMATICAL BACKGROUND OF ECC 30 4.1 Elliptic curve 30 4.2 Group 30 4.3 The group Z n 30 4.4 Additive Inverses 31 4.5 Other operations 31 4.6 The group Z p * 31 4.7 Multiplicative Inverses 32 4.8 Abelian Groups 32 4.9 Field 32 4.10 The field F p 33 4.11 m The field F 2 33 4.12 Polynomial Representation 33 4.13 Addition 34 4.14 Subtraction 34 4.15 Multiplication 34 4.16 Exponentiation 34 4.17 Multiplicative Inversion 34 4.18 Example - F 4 2 with Polynomial Representation 34 4.19 Multiplicative Inversion 36 4.20 Use of Elliptic Curve 37 Chapter 5 THE SECURE MESSAGING APPLICATION 38 5.1 Key Generation 38 5.2 ECC Encryption Process 39 5.3 ECC Decryption Process 39 5.4 Importance of compression before encryption 40 Chapter 6 IMPLEMENTATION DETAILS 42 6.1 Libraries used 42 iii

6.2 System Requirements 42 6.3 Source Code 42 6.3.1 OnButtonGenerateKyes function 42 6.3.2 Calculation of Execution time 43 6.3.3 OnButtonEncrypt function 43 6.3.4 OnButtonDecrypt function 49 6.3.5 RSA implementation of Crypto++ 53 Chapter 7 THE FRONT END TO ECC AND RSA 54 7.1 The ECC GUI 54 7.2 The RSA GUI 55 7.3 Opening the attachment in outlook 56 Chapter 8 RESULTS AND OBSERVATIONS 58 8.1 ECC results 58 8.2 RSA results 59 8.3 Comparison of ECC and RSA 62 8.4 Relative cost of equivalent key sizes in RSA and ECC 63 8.5 Important considerations 65 Chapter 9 CONCLUSION AND FUTURE EXTENSIONS 66 9.1 Conclusion 66 9.2 Proposed Future extensions of the application 67 Appendix A TOOLS AND LIBRARIES 68 Appendix B ACRONYMS USED 70 References 72 iv

LIST OF FIGURES Figure 1.1: Secret/Symmetric Key Cryptosystem [26]... 01 Figure 1.2: Public/Asymmetric Key Cryptosystem [26]... 02 Figure 1.3: Pictorial representation of Secure Messaging System... 04 Figure 2.1: Ancient Egyptians cipher [29]... 07 Figure 2.2: Data integrity [10]... 10 Figure 2.3: Data origin authentication [10]... 11 Figure 2.4: Non-repudiation of origin [10]... 11 Figure 2.5: Data confidentiality [10]... 12 Figure 2.6: How PGP encryption works [26]... 18 Figure 2.7: How PGP decryption works [26]... 18 Figure 3.1: SMTP communication model [19]... 20 Figure 3.2: SMTP and POP3 in action [20]... 25 Figure 3.3: Transfer encoding [30]... 27 Figure 5.1: ECC key generation and exchange of public keys.... 38 Figure 5.2: ECC encryption... 39 Figure 5.3: ECC decryption... 40 Figure 7.1: ECC application s main dialog box... 54 Figure 7.2: The ECC dialog box... 55 Figure 7.3: RSA application s main dialog box... 55 Figure 7.4: RSA Key generation... 56 Figure 7.5: RSA encryption - decryption... 56 Figure 7.6: Email in Outlook... 57 Figure 8.1: ECC key generation, encryption and decryption cost... 59 Figure 8.2: RSA encryption and decryption cost... 60 Figure 8.3: RSA key generation cost... 61 Figure 8.4: RSA key generation cost... 62 Figure 8.5: ECC 160 bit vs. RSA 1024 bit... 63 Figure 8.6: Time to break ECC and RSA [18]... 64 Figure A.1: Microsoft Visual C++ 6.0 IDE... 69 v

LIST OF TABLES Table 4.1: 16 vectors for F 4 2 [24]... Table 8.1: ECC key generation, encryption and decryption cost... Table 8.2: RSA encryption and decryption cost... Table 8.3: Comparison of RSA key generation cost... Table 8.4: ECC key generation, encryption and decryption cost (22 bytes)... Table 8.5: RSA key generation, encryption and decryption cost (22 bytes)... Table 8.6: Relative cost equivalent key sizes in RSA and ECC [16]... 34 58 60 61 62 62 63 vi

ACKNOWLEDGEMENTS First of all, I would like to acknowledge Allah and his mercy in every area of my life. I would like to express my gratitude to my supervisor, Dr. Nassar Ikram who has given me invaluable encouragement and support throughout the course of the research, and his assistance in writing proposal, draft and this thesis. A very special thanks goes out to most knowledgeable teacher Mr. Athar Mehboob, whose expertise, understanding, and patience, added considerably to my graduate experience. I appreciate his vast knowledge and skill in areas such as (networks, security, cryptography etc.). I must also acknowledge Mr. Anwar Amjad at SSUET who helped and support me in various aspects. Appreciation also goes out to Mr. Aleem Khalid Alvi for his suggestions, and advice at times of critical need. I would also like to thank my family for the support they provided me through my entire life and in particular, I must acknowledge my parents because without their love and encouragement, I would not have finished this thesis. vii

Chapter 1. Introduction Chapter 1 INTRODUCTION 1.1 Background to Research In practice two types of cryptographic techniques are used namely secret key cryptography (e.g., DES) and public key cryptography (e.g., RSA). In secret key cryptosystems, see Figure 1.1, message is encoded and decoded using same key. Sender and recipient both must share this secret key to encrypt or decrypt information. In case of secret key cryptography, the transmission of key through public or insecure channels (untrusted couriers or network) to the recipient(s) may compromise the overall security of the system. Figure 1.1 Secret/Symmetric Key Cryptosystem In public key cryptosystems, see Figure 1.2, sender encrypts the information with receiver s public key so that only receiver can decrypt the ciphertext with his private key. Public key cryptography is more secure as it resolves the problem of key distribution over insecure channel as faced in private key cryptosystems. 2

Chapter 1. Introduction Figure 1.2 Public/Asymmetric Key Cryptosystem Elliptic Curve cryptography is an emerging public key cryptosystem which provides the same degree of security as systems used in SSL [7] today with approximately one-eighth the key size. This results in bandwidth savings, efficient implementation and compactness in silicon without any effect on security as compared to its rival, RSA [5]. With such attributes, the technology i.e., Elliptic Curve Cryptography becomes especially useful for mobile devices and other small devices that are limited in the power, CPU performance, memory or bandwidth. Elliptic curve cryptosystems were first proposed independently by Victor Miller and Neal Koblitz in 1985 [8]. Since internet is a huge inter-connected network of computer, there are many irresponsible people who are happy to intercept your messaging. That s why we need a secure messaging system. Secure messaging allows a company to safely and securely control the flow of information coming in and going out via e-mail and the Web. The research entails development of cryptographically secure email messaging using Elliptic Curve Cryptography. The application developed will provide security for standards based messaging systems. 1.2 Significance of a Secure Messaging Application a) The implementation of a secure messaging system using ECC is highly significant because of its merits. Pakistan is following unprecedented pace of IT development under which IT infrastructure is fast developing. New 3

Chapter 1. Introduction companies are emerging and more foreign companies are diverting towards it. This is resulting in setting up of more WANs/LANs. With this comes the necessity of securing the infrastructure/lans/wans against malicious designs. Secure messaging system although not a new concept, will provide the means of securing the transmission lines of any company/organization operating its LAN/WAN. This is the essential first step to designing further crypto applications and as such has its importance. b) The application developed is in line with the current trends in the world and needs. Various companies are developing secure messaging systems of different various kinds from email to wireless e-commerce. Information about these can be retrieved from websites of RSA [25] or PGP [26]. 1.3 Problem description Email messaging is one of the oldest applications of internet, and it is still being used by internet users today. Phil Zimmerman [6] added a new dimension to email messaging by enabling a secure message transmission via public key cryptography. PGP is the most widely used secure email application today using RSA. RSA is very secure if the key length is higher. ECC's advantages in comparison to RSA are convincing: less memory requirement and computation time. Key lengths of 160 Bit as in ECC ensure the security of a RSA key of 1024 Bit, which is used as a standard today [9]. With greater key lengths, the advantages of ECC compared to RSA increase intensively. While RSA would have to double its key lengths, ECC only needs a few bits to achieve the same level of security. The RSA procedure currently changes its key length to 2048 Bit. As a result, ECC algorithms only have to increase its key length to 192 Bit. 1.4 Objective Goal of this thesis is to study the working of PGP, implement a secure email messaging system based on ECC, and finally generate results that indicate comparative analysis of the RSA and ECC. 4

Chapter 1. Introduction 1.5 Methodology The development methodology is as under: a) Software based development of system offering the features appropriate to the secure messaging system. These functions are then integrated and results are analyzed primarily for the offered speed and security. b) The system developed is then followed by trials and release of beta version. c) The implementation has been done using a host of available tools and libraries that were easily available meeting the prime requirement of ease of use. 1.6 Thesis Description with Technical details Thesis entails study and development of cryptographically secure email/messaging system. At the heart is an encryption algorithm, which would ensure complete security of data. The GUI is user friendly, which would give options of a range of security classifications and other relevant features. Initially email messaging system is implemented and then it may be extended to instant messaging platform. A pictorial representation of the system is given in the Figure 1.3. The application developed will provide security for standards based messaging systems. Public Keys Graphical User Interface (GUI) Scanned File (TWAIN) OCR Encrypted File Outgoing SMTP email Core Encryption / Decryption Engine. Private Files Incoming POP Email Outgoing instant message Incoming Instant Message Figure 1.3 Pictorial representation of Secure Messaging System 5

Chapter 1. Introduction In the following section, a layout of the chapters is given which shows how chapters are distributed and which chapter deals with what. Chapter 1 describes the objective of the thesis, the methodology that is used in developing the application and also describes the overall working of the application in brief. In Chapter 2, user is introduced by cryptography and basic security concepts. This chapter starts with the history of cryptography where the classical cryptography is explained. Digital signatures and hash functions are also explained and in the end a detailed description of RSA and PGP is given. Simple Mail Transfer Protocol (SMTP) and Post Office Protocol (POP) are explained in Chapter 3, so that user can get familiar with the email protocols and encoding concepts. Mathematical concepts of Elliptic Curves are briefly explained in Chapter 4 so that reader can get a very basic understanding of the mathematics involved. In this chapter mostly concepts like Groups, Fields and mathematical equations about Elliptic Curves are explained with very simple examples. In Chapter 5, the overview of the secure messaging application is presented so that reader can get familiar with important processes of the application that is developed during this research such as Key Generation, Encryption and Decryption. Chapter 6 is all about the implementation details and partial source code of the application is also presented over here. The C++ source code is also commented where necessary to help the programmer understand the underlying logic. The Graphical User Interface (GUI) of the applications that were developed is explained in Chapter 7. Different dialog boxes in the application are explained and the usage of application is also described in detail. In Chapter 8 which is very important chapter, results and observations are presented based on the analysis of the generated data during the simulation of the applications that were developed. Also the comparative analysis of the ECC and RSA is presented In Chapter 9 final conclusion and some future suggestions and extensions to the ECC application are given. Conclusion is based on the actual data generated by simulation. 6

Chapter 2.Cryptography and security concepts Chapter 2 CRYPTOGRAPHY AND SECURITY CONCEPTS 2.1 Introduction Cryptography is the practice and study of encryption and decryption i.e., encoding data so that it can only be decoded by specific/intended individuals only. A system for encrypting and decrypting data is a cryptosystem. This usually involves an algorithm for combining the original data ("plaintext") with one or more "keys" i.e., numbers or strings of characters known only to the sender and/or recipient. The resulting output is known as "ciphertext". The origin of the word cryptology lies in ancient Greek. The word cryptology is made up of two components: "kryptos", which means hidden and "logos" which means word. Cryptology is as old as writing itself, and has been used for thousands of years to safeguard military and diplomatic communications. For example, the famous Roman emperor Julius Caesar used a cipher to protect the messages to his troops. Within the field of cryptology one can see two separate divisions: cryptography and cryptanalysis. The cryptographer seeks methods to ensure the safety and security of conversations while the cryptanalyst tries to undo the former's work by breaking his systems [10]. The main goals of modern cryptography can be seen as: user authentication, data authentication (data integrity and data origin authentication), non-repudiation of origin, and data confidentiality. In the following section we will elaborate more on these services. Subsequently we will explain how these services can be realized using cryptographic primitives. These are mainly two categories of cryptography: a) Classical cryptography. b) Key based cryptography. 7

Chapter 2.Cryptography and security concepts 2.2 Classical Cryptography Classical cryptography is the oldest branch of cryptography. It has a history of at least 4000 years [29]. Ancient Egyptians enciphered some of their pictogram writing on monuments as shown in the Figure 2.1: Figure 2.1 Ancient Egyptians cipher. 2.3 Classical Cryptographic Techniques There are two basic components of classical ciphers: substitution and transposition. In substitution ciphers letters are replaced by other letters and in transposition ciphers the letters are arranged in a different order, these ciphers may be: monoalphabetic - only one substitution / transposition is used, or polyalphabetic - where several substitutions / transpositions are used. Several such ciphers may be concatenated together to form a product cipher. 2.3.1 Transpositions Transposition is not really a full-fledged method of cipher in its own, but it can form and usually is used in a stage of more complex cryptosystems (such as in applying key-based encryption). Transposition is simply moving the relative positions of letters within a message. We will discuss a columnar transposition below, so called because the text is arranged into columns and the columns are transposed. When performing a columnar transposition, a keyword is first needed. The message is then written into rows beneath the keyword. The example message which we'll use will be "SECRET MESSAGES". e n c r y p t 2 3 1 5 7 4 6 S E C R E T M E S S A G E S Adding some numbers beneath the keyword, the numbers refer to the relative positions of the keyword letters in the alphabet. Having formed the table we can read 8

Chapter 2.Cryptography and security concepts back the message in the order of the keyword letters. This message becomes CSETRME SESEASG. The spaces have been included for clarity, although in practice this will not happen. Transpositions are often used as part of a more complex system. If a transposition is used in conjunction with a monoalphabetic substitution then the transposition as above may be solved, after having first worked out the plaintext letters of the substitution by looking at letter frequencies. 2.3.2 Caesar Substitution The Caesar Cipher is one of the simplest monoalphabetic substitutions one may use, and it is also one of the easiest to break. It is said that Julius Caesar wrote to his friends using a simple substitution cipher, where the plaintext letter was replaced by the ciphertext three places down the alphabet, so that the letter M is replaced by P and so on. The Caesar cipher may be summarized in a table, shown below. It is now the case that any cipher whose cipher alphabet consists of the letters in their normal order is called a Caesar cipher. PLAINTEXT abcdefghijklmnopqrstuvwxyz CIPHERTEXT DEFGHIJKLMNOPQRSTUVWXYZABC As there are only 26 Caesar alphabets it is trivial to solve a Caesar cipher by exhaustive search. This is can be done by listing the alphabet under each letter of a section of the ciphertext. The line which contains legible plaintext is the correct one. PLAINTEXT this is a simple cipher CIPHERTEXT vjku ku c ukorng ekrjgt v j k u k u c u k o r n g e k r j g t ------------------------------------- v j k u k u c u k o r n g e k r j g t u i j t j t b t j n q m p d j q i f s t h i s i s a s i m p l e c i p h e r 2.3.3 Monoalphabetic Substitution A monoalphabetic substitution is one where a letter of plaintext always produces the same letter of ciphertext. The operation is very similar to the Caesar Cipher, with the exception that the cipher alphabet does not have the order which it 9

Chapter 2.Cryptography and security concepts had in the previous examples (which are just special cases of monoalphabetic substitutions). An example of a monoalphabetic substitution is shown below. PLAINTEXT abcdefghijklmnopqrstuvwxyz CIPHERTEXT QRSKOWEIPLTUYACZMNVDHFGXJB One may naturally think that this cipher is secure, after all there are 26! different cipher alphabets ( 4 x 10 26 ) to choose from, however the letter frequencies and underlying patterns will be unchanged - and as such the cipher can be solved by pen and paper techniques. The best way to see how the cryptanalysis is performed is by doing some analysis. These more advanced techniques include looking systematically at the position of letters in words in order to identify vowels, pattern words, and looking at the letter frequencies, though common pairings (TH, HE etc.) may come up. The most common English letters are ETNROAIS (these are the letters in descending order) is highly likely that in any ciphertext, we have some matches - though it is not a certainty. It should also be noted that the most common trigraph (three letter sequence) in English is 'THE'. Of course the analysis may be done automatically by a computer program which observes letter positions and frequencies etc. 2.4 Key-based Encryption Keys are the fundamental essential element in generating modern ciphertext. A string of bits used widely in cryptography, allowing people to encrypt and decrypt data; a key can be used to perform other mathematical operations as well. Given a cipher, a key determines the mapping of the plaintext to the ciphertext. The key to a particular cryptosystem is some value which, when applied to ciphertext, allows the encrypted message to be decrypted and when applied to plaintext encrypts it. It is important to note that in the study of cryptography one talks about the lengths of keys in terms of bits. Messages, too, can be encrypted in 'n-bit blocks'. The longer a key is the more difficult it is to break the encrypted message. The most common method of breaking ciphers is by a brute-force attack. This sort of attack involves running through possible combinations of keys and applying them to the cryptosystem until the message is decrypted. It is the same as trying to guess a PIN for someone's ATM card by going through all the possible combinations of 10

Chapter 2.Cryptography and security concepts numbers. It is said that any university with computer science major would have enough computer power available to be able to break most 56-bit key cryptosystems in less than one week. 2.5 Cryptographic services 2.5.1 User Authentication If you log to a computer system there must (or at least should) be some way that you can convince it of your identity. Once it knows your identity, it can verify whether you are entitled to enter the system. The other principal applies when one person tries to communicate with another: as a first step you want to verify that you are communicating with the right person. Therefore there must be some way in which you can prove your identity. This process is called user authentication [10]. In general, one also requires that the computer authenticates itself to the person logging on. If both parties are authenticated to each other, we use the term mutual authentication. 2.5.2 Data authentication Data authentication consists of two components: the fact that data has not been modified (data integrity) and the fact that you know who the sender is (data origin authentication). 2.5.3 Data integrity A data integrity service guarantees that the content of the message, that was sent, has not been tampered with. Data integrity by itself is not meaningful: it does not help you to know that the data you have received has not been modified, unless you know it has been sent directly to you by the right person. Therefore it should always be combined with data origin authentication [10]. Alice Bob Intruder Figure 2.2 Data integrity. 11

Chapter 2.Cryptography and security concepts 2.5.4 Data origin authentication Here one wants to make sure that the person who is claiming to be the sender of the message really is the one from whom it originates. In Figure 2.3, if A sends a message to B, but the enemy intercepts it and sends it to B, claiming A has sent it, how can B be sure of the real origin of this data? A variation on this theme is: the enemy could send a message to B claiming it A is the originator. Thanks to cryptography, there are techniques to ensure against this type of fraud [10]. Alice Block Message Bob Intruder 2.5.5 Non-repudiation of origin Figure 2.3 Data origin authentication. Non-repudiation protects against denial by one of the entities involved in a communication of having participated in all or part of the communication [10]. Alice Bob 2.5.6 Data confidentiality Figure 2.4 Non-repudiation of origin. This aspect of data security has an analogy of a letter that was written in a recognizable handwriting, with a seal and a signature. Confidentiality protection is very important in the medical world and also in the banking sector. World-wide there are several million transactions each day and all of these have to be passed from one financial institution to another. If there were no ways to protect confidentiality, everybody would be able to see who had purchased what, who has made what kind of withdrawal, and so on [10]. Bob 12

Chapter 2.Cryptography and security concepts Clearly this would violate individuals and companies rights to privacy. In order to provide confidentiality, it is necessary to transform the message with a cipher. Alice Bob Intruder 2.6 Cryptographic primitives Figure 2.5 Data confidentiality. The cryptographic services can be realized by several cryptographic primitives: we distinguish between primitives for encryption, primitives for authentication, and cryptographic protocols. Encryption primitives can be used to provide confidentiality, authentication primitives can be used to provide data authentication [10]. 2.7 Encryption primitives In cryptography one often makes use of encryption. With encryption we transform the clear text (or plaintext) into ciphertext. To get back to the original text, we apply the inverse transformation, called decryption [10]. These transformations themselves are public: this makes it possible to analyze these algorithms and to develop efficient implementations. However they use a secret parameter: the keys which are known only by the sender and/or the receiver. This key is the only thing one needs to know in order to encipher or decipher. Thus it is really important to manage one's keys and keep them secret where necessary. We discuss two types of encryption primitives, symmetric or conventional ciphers and asymmetric or public key ciphers. 2.7.1 Symmetric ciphers Traditional encryption techniques rely on both the sender and the receiver of a message knowing a particular secret key. The sender encrypts the message with a particular cryptosystem using the secret key and the receiver decrypts the message 13

Chapter 2.Cryptography and security concepts with the same key. This method of encryption is called private key, or symmetric, encryption [10]. It relies on no one else being able to find out what the private key is. This is fine if encrypted files are only stored on the hard disk (in which case only the encryptor needs to know the key) or if one is sending data to someone close by, say in the same office, in which case one can let the key be known personally. If the receiver is not close by, however, then the key must somehow be sent. It could be sent by courier or told over the telephone or even sent separately to the actual message. All these methods involve trusting a third party not to divulge the secret key. Furthermore, the receiver of the message must also be trusted, as they could decrypt any message sent using the same key. Symmetric ciphers are generally faster than public key ciphers. Some symmetric ciphers, such as DES, can be implemented in hardware. This makes them very fast. Disadvantages include: a) For use in anything other than private encryption of files, one could not determine the authenticity of the originator of the data. This lack of protection does not allow this method to verify electronic orders and financial transactions. b) The private key used now has to be transmitted in a very secure channel. Spontaneous secure transmission may not be feasible. c) When used across a network of users, there may have to be a large number of keys to facilitate one-to-one communication between each user. In a network of n users, the total number of keys are n*(n - 1)/ 2. 2.7.2 Stream ciphers and block ciphers There are two types of symmetric encryption algorithms: stream ciphers and block ciphers. A stream cipher is one that encrypts a digital data stream one bit at a time [1]. Whereas block ciphers encrypt multiple bits of data (normally 64 bits) called a block. 2.7.3 Asymmetric ciphers Public key encryption is also known as asymmetric key encryption. It uses different keys to encrypt and decrypt a message. Under this system everyone gets a pair of keys: a public key which is published for all to see and use, and a private key 14

Chapter 2.Cryptography and security concepts which is to be kept secret. The public key could then be used to encrypt a message, which only the holder of the corresponding private key, could decrypt and read [10]. The private key never gets transmitted, so there are no problems associated with asymmetric key encryption. Furthermore, public key encryption can be used for authentication via the digital signature [4] mechanism. In this sense, asymmetric key is particularly strong in authentication. Message is not only protected in terms of secrecy, but also in integrity. Public key, or asymmetric key encryption, ciphers generally require longer keys than symmetric ciphers to achieve the same level of security. 2.7.4 Symmetric versus asymmetric ciphers The biggest drawback of the asymmetric systems until now has been the relative low performance compared to the symmetric ones. DES is typically 1000 times faster than the RSA-scheme [10]. Public key systems provide significant benefits in terms of key management: if every user generates his own key, only an authentic channel is required, eliminating (expensive) secret channels like couriers. In systems without a central trusted server, the number of keys can be reduced. Indeed, suppose we have a network of n users each of whom wanting to communicate with the others. Since each communication requires a secret key, the total number of keys required equals n*(n-1)/2. In the public key system each user only needs a personal public/secret key pair, making a total of only 2n keys. 2.8 Authentication primitives 2.8.1 One-way functions and hash codes A one-way function is defined as a function f such that for every x in the domain of f, f(x) is easy to compute; but for virtually all y in the range of f, it is computationally infeasible to find an x such that y=f(x) [10]. One-way functions are used to protect passwords: one will store a one-way image of the password in the computer rather than the password itself. One applies then the one-way function to the input of the user and verifies whether the outcome agrees with the value stored in the table. 15

Chapter 2.Cryptography and security concepts A hash function is a function which maps an input of arbitrary length into a fixed number of output bits [10]. In order to be useful for cryptographic applications, a hash function has to satisfy some additional requirements. One can distinguish two types of hash functions. A MAC (Message Authentication Code) that uses a secret key, and an MDC (Manipulation Detection Code) that works without a key. For a MAC one requires that it should be impossible to compute the MAC without knowledge of the secret key. For an MDC one requires that it is a one-way function, and - in most cases - that it is collision resistant, which means that it should be hard to find two arguments hashing to the same result. 2.8.2 Digital signature Public key techniques can also be used for other purposes than for enciphering information. If Alice adds some redundancy to her message and transforms the result using her secret key, anyone who knows Alice's public key can verify that this message was sent by Alice (by verifying the redundancy). In this way one can create a digital signature, which is the equivalent of the hand-written signature on a document. Assume Bob has received from Alice a digitally signed message. If Alice subsequently denies having sent the message, Bob can go to a third party (e.g., a judge), who will be able to obtain Alice's public key. Subsequently he can verify the validity of the signature. In this way a digital signature can provide non-repudiation of origin [10]. It is easy to see that it provides in addition data authentication, i.e., data integrity and data origin authentication. 2.8.3 Hash functions versus digital signatures Hash functions can only be used in a situation where the parties mutually trust each other: they cannot be used to resolve a dispute (unless one uses, in addition tamper resistant hardware). As in the case of encryption, hash functions tend to be three orders of magnitude faster than digital signatures [10]. This explains why in general one will first compute the hash code of the message with a fast hash function and subsequently apply the digital signature to this short hash code. This provides digital signatures which are not only faster and shorter, but also more secure. 16

Chapter 2.Cryptography and security concepts 2.9 Rivest Shamir Adleman (RSA) RSA is a public key cryptosystem for both encryption and authentication. It was invented in 1977 [11]. It is an encryption algorithm that uses very large prime numbers to generate the public key and the private key. RSA is typically used in conjunction with a secret key cryptosystem such as DES. DES would be used to encrypt the message as a whole and then use RSA to encrypt the secret key. Thus, RSA provides a digital envelope for the message. RSA is in wide use today, it is possibly the most commonly used public key algorithm used. Because of this it has undergone a lot of public scrutiny and there is much empirical evidence of its security. It can be used for both encryption and signing. Although it would be possible to factor out the public key to get the private key (2 prime factors must be found out), the numbers are so large as to make it very impractical to do so. The encryption algorithm itself is very slow, which makes it impractical to use RSA to encrypt large data sets. In PGP (and most other RSA-based encryption programs), a symmetrical key is encrypted using the public key, then the remainder of the data is encrypted with a faster algorithm using the symmetrical key. The symmetrical key itself is randomly generated, so that the only way to get it would be by using the private key to decrypt the RSA-encrypted symmetrical key. At the labs of MIT, in 1976, Rivest, Shamir, and Adleman made a new algorithm for key exchange named as RSA, after the initials of its three inventors. RSA was based on the Diffie-Hellman paper "New Directions in Cryptography." RSA satisfied the original Diffie-Hellman description of "multi-user cryptography" because it does not require two active participants when performing both the encryption and decryption. 2.9.1 RSA Example An Example of the RSA Algorithm is given below [12]: P = 61 first prime number (destroy this after computing E and D) Q = 53 second prime number (destroy this after computing E and D) PQ = 3233 modulus (give this to others) E = 17 public exponent (give this to others) D = 2753 private exponent (keep this secret!) Your public key is (E,PQ). Your private key is D. 17

Chapter 2.Cryptography and security concepts The encryption function is: encrypt(t) = (T E ) mod PQ = (T 17 ) mod 3233 The decryption function is: decrypt(c) = (C D ) mod PQ = (C 2753 ) mod 3233 To encrypt the plaintext value 123, do this: encrypt(123) = (123 17 ) mod 3233 = 337587917446653715596592958817679803 mod 3233 = 855 To decrypt the ciphertext value 855, do this: decrypt(855) = (855 2753 ) mod 3233 = 123 2.10 Details of PGP PGP combines some of the best features of both conventional and public key cryptography. PGP is a hybrid cryptosystem [26]. When a user encrypts plaintext with PGP, PGP first compresses the plaintext. Data compression saves modem transmission time and disk space and, more importantly, strengthens cryptographic security. Most cryptanalysis techniques exploit patterns found in the plaintext to crack the cipher. PGP then creates a session key, which is a one-time-only secret key. This key is a random number generated from the random movements of your mouse and the keystrokes you type. This session key works with a very secure, fast conventional encryption algorithm to encrypt the plaintext; the result is ciphertext. Once the data is encrypted, the session key is then encrypted to the recipient's public key. This public key-encrypted session key is transmitted along with the ciphertext to the recipient. 18

Chapter 2.Cryptography and security concepts Figure 2.6 How PGP encryption works. Decryption works in the reverse. The recipient's copy of PGP uses his or her private key to recover the temporary session key, which PGP then uses to decrypt the conventionally-encrypted ciphertext. Figure 2.7 How PGP decryption works. The combination of the two encryption methods combines the convenience of public key cryptography to solve key distribution problem with the speed of conventional encryption. Conventional encryption is about 1,000 times faster than public key encryption. Public key encryption in turn provides a solution to key distribution and data transmission issues. Used together, performance and key distribution are improved in PGP. 19

Chapter 3. Email protocols and encoding Chapter 3 EMAIL PROTOCOLS AND ENCODING 3.1 Email protocols Electronic mail, also called email, is a computer based method of sending messages from one computer user to another. These messages usually consist of individual pieces of text which you can send to another computer user even if the other user is not logged in (i.e. using the computer) at the time you send your message. The message can then be read at a later time. This procedure is analogous to sending and receiving a letter. Originally, email messages were restricted to simple text, but now many systems can handle more complicated formats, such as graphics and word processed documents. When mail is received on a computer system, it is usually stored in an electronic mailbox for the recipient to read later. Electronic mailboxes are usually special files on a computer which can be accessed using various commands. Each user normally has their individual mailbox. Today almost every email server supports Simple Mail Transfer Protocol (SMTP) and Post Office Protocol version 3 (POP3). These are the protocols which are widely used for email messaging. 3.2 SMTP SMTP transfers mail with consistency. SMTP [3] does not depend on the any network and needs only a consistent data channel to transmit emails. SMTP can also relay mail across transport service environments. A transport service provides an Inter Process Communication Environment (IPCE). An IPCE may cover one network, several networks, or a subset of a network. It is important to realize that transport systems (or IPCEs) are not one-to-one with networks. Mail can be communicated between processes in different IPCEs by relaying through a process connected to two (or more) IPCEs. More specifically, mail can be relayed between hosts on different transport systems. 20

Chapter 3. Email protocols and encoding 3.2.1 SMTP COMMUNICATION MODEL In SMTP communication model [19], email is transmitted from sender-smtp to receiver-smtp. The receiver-smtp may be destination or an in-between receiver SMTP. SMTP commands are generated by the sender-smtp and sent to the receiver- SMTP. SMTP replies are sent from the receiver-smtp to the sender-smtp in response to the commands. Note that it is not necessary that user is also present at the receiving end and the email message resides on the File system in the absence of the recipient. User File System Sender SMTP SMTP Commands SMTP Replies Receiver SMTP File System Figure 3.1 SMTP communication model. The communication sequence is as follows [19]: a) User sends a mail request to the sender-smtp. b) As the result of a user mail request, the sender-smtp establishes a two-way transmission channel to a receiver-smtp. c) Once the transmission channel is established, the SMTP-sender sends a MAIL command indicating the sender of the mail. d) If the SMTP-receiver can accept mail it responds with an OK reply. e) Then SMTP-sender then sends a RCPT command identifying a recipient of the mail. f) If the SMTP-receiver can accept mail for that recipient it responds with an OK reply; if not, it responds with a reply rejecting that recipient (but not the whole mail transaction). g) The SMTP-sender and SMTP-receiver may negotiate several recipients. h) When the recipients have been negotiated the SMTP-sender sends the mail data, terminating with a special sequence. If the SMTP-receiver successfully processes the mail data it responds with an OK reply. 21

Chapter 3. Email protocols and encoding 3.2.2 A Typical SMTP Transaction Scenario Following SMTP transaction scenario shows mail sent by Nassar at host PNEC-ISIF, to AbdulRahman, Athar, and Kamran at host SSUET-UNIX. Suppose that in this case host PNEC-ISIF contacts host SSUET-UNIX directly. The mail is accepted for AbdulRahman and Kamran. Athar does not have a mailbox at host SSUET-UNIX. R: receiver SMTP S: sender SMTP R: 220 SSUET-UNIX.ARPA Simple Mail Transfer Service Ready S: HELO PNEC-ISIF.ARPA R: 250 SSUET-UNIX.ARPA S: MAIL FROM:<Nassar@PNEC-ISIF.ARPA> R: 250 OK S: RCPT TO:<AbdulRahman@SSUET-UNIX.ARPA> R: 250 OK S: RCPT TO:<Athar@SSUET-UNIX.ARPA> R: 550 No such user here S: RCPT TO:<Kamran@SSUET-UNIX.ARPA> R: 250 OK S: DATA R: 354 Start mail input; end with <CRLF>.<CRLF> S: begin 0666 cipher-without-uue.txt S: MBM;.7E5QS1T:Q3K3(J&+90"A`#BIR;LKWB;X;!1]LQ6%:<L31M,S=/ZBG6 S: M<,3O8N.75W+.Q2Z7^Y"NK/M/!@LJ`P3%\PA]5%SV0K0Q#9>4OQ#M<R*- S: M""02^99+Q]J%WSN?]_OY@?OAN0`$H'.\0<,+78B\1(51W41@RUJP)I.MSZ! S: MIQ'?O;I.$94DMC:H)5-%"(!UU#&:_YZZ%2N*O]2&(AAH&9:F$OB.Y<?HX' 22

Chapter 3. Email protocols and encoding S: MX;X0\TE=XKMI.#Z%VA2G?M4BR:.I=Y>+%.\.@\C7ME><6U"<"&3*AZZ< S:.. S: end S:. R: 250 OK S: QUIT R: 221 SSUET-UNIX.ARPA Service closing transmission channel 3.3 Post Office Protocol version 3 (POP3) On certain types of smaller nodes in the Internet it is often not practical to maintain a message transport system (MTS). Similarly, it may be expensive (or impossible) to keep a personal computer interconnected to an IP-style network for long amounts of time. Despite this, it is often very useful to be able to manage mail on these smaller nodes, and they often support a user agent (UA) to aid the tasks of mail handling. To solve this problem, a node which can support an MTS entity offers a maildrop service to these inefficient nodes. The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion [20]. Usually, this means that the POP3 protocol is used to allow a workstation to retrieve mail that the server is holding for it. POP3 is not intended to provide extensive manipulation operations of mail on the server; normally, mail is downloaded and then deleted. In the context of POP3, client host refers to a host making use of the POP3 service, while the term server host refers to a host which offers the POP3 service. 3.3.1 POP3 Basic Operation Initially, the server host starts the POP3 service by listening on TCP port 110. When a client host wishes to make use of the service, it establishes a TCP connection with the server host. When the connection is established, the POP3 server sends a greeting. The client and POP3 server then exchange commands and responses (respectively) until the connection is closed or aborted. Commands in the POP3 consist of a case-insensitive keyword, possibly followed by one or more arguments. All commands are terminated by a CRLF pair. 23

Chapter 3. Email protocols and encoding Keywords and arguments consist of printable ASCII characters. Keywords and arguments are each separated by a single SPACE character. Keywords are three or four characters long. Each argument may be up to 40 characters long. Responses in the POP3 consist of a status indicator and a keyword possibly followed by additional information. All responses are terminated by a CRLF pair. Responses may be up to 512 characters long, including the terminating CRLF. There are currently two status indicators: positive ("+OK") and negative ("-ERR"). Servers MUST send the "+OK" and "-ERR" in upper case. Responses to certain commands are multi-line. In these cases, which are clearly indicated below, after sending the first line of the response and a CRLF, any additional lines are sent, each terminated by a CRLF pair. When all lines of the response have been sent, a final line is sent, consisting of a termination octet (decimal code 046, ".") and a CRLF pair. "CRLF.CRLF". A POP3 session progresses through a number of states during its lifetime. Once the TCP connection has been opened and the POP3 server has sent the greeting, the session enters the AUTHORIZATION state. In this state, the client must identify itself to the POP3 server. Once the client has successfully done this, the server acquires resources associated with the client's maildrop, and the session enters the TRANSACTION state. In this state, the client requests actions on the part of the POP3 server. When the client has issued the QUIT command, the session enters the UPDATE state. In this state, the POP3 server releases any resources acquired during the TRANSACTION state and says goodbye. The TCP connection is then closed. A server MUST respond to an unrecognized, unimplemented, or syntactically invalid command by responding with a negative status indicator. A server MUST respond to a command issued when the session is in an incorrect state by responding with a negative status indicator. A POP3 server MAY have an inactivity auto logout timer. Such a timer MUST be of at least 10 minutes'duration. The receipt of any command from the client during that interval should suffice to reset the auto logout timer. When the timer expires, the session does NOT enter the UPDATE state--the server should close the TCP connection without removing any messages or sending any response to the client. 24

Chapter 3. Email protocols and encoding 3.3.2 POP3 Security Considerations It is conjectured that use of the APOP command provides origin identification and replay protection for a POP3 session. Accordingly, a POP3 server which implements both the PASS and APOP commands must not allow both methods of access for a given user; that is, for a given "USER name" either the PASS or APOP command is allowed, but not both. Further, note that as the length of the shared secret increases, so does the difficulty of deriving it. Servers that answer -ERR to the USER command are giving potential attackers clues about which names are valid. Use of the PASS command sends passwords in the clear over the network. Use of the RETR and TOP commands sends mail in the clear over the network. Otherwise, security issues are not discussed in this memo. 3.3.3 Example POP3 Session In the following example, assume that S=Server POP3 host and C=Client POP3 host. S: <wait for connection on TCP port 110> C: <open connection> S: +OK POP3 server ready <1896.697170952@ssuet.edu.pk> C: APOP mrose c4c9334bac560ecc979e58001b3e22fb (authentication APOP cmd.) S: +OK mrose's maildrop has 2 messages (320 octets) C: STAT S: +OK 2 320 C: LIST S: +OK 2 messages (320 octets) S: 1 120 S: 2 200 S:. C: RETR 1 S: +OK 120 octets S: <the POP3 server sends message 1> S:. 25

Chapter 3. Email protocols and encoding C: DELE 1 S: +OK message 1 deleted C: RETR 2 S: +OK 200 octets S: <the POP3 server sends message 2> S:. C: DELE 2 S: +OK message 2 deleted C: QUIT S: +OK dewey POP3 server signing off (maildrop empty) C: <close connection> S: <wait for next connection> In the following picture the combined working of both SMTP and POP3 is illustrated. Email sent by workstation received by server using SMTP Workstation1 Network Switch Workstation 2 Email is requested from server by client using POP3 Figure 3.2 SMTP and POP3 in action. 3.4 Encoding and decoding mail messages Email Server Email is the transmission of messages between individuals or within groups of people, and is the most heavily used of all network services. It is not unique to the 26

Chapter 3. Email protocols and encoding Internet: email works uniformly across all the world's interconnected networks, although the de facto standard is of Internet origin. Most messages are text, but mailing systems are becoming more common which can embed other objects such as images, sound, programs, or data in the message. This document explains why it is sometimes necessary to encode messages, how to do so when needed, and how to decode any encoded messages you may receive. This document does not discuss encryption, which is a completely separate topic, and has nothing to do with the encoding of messages for transportation. 3.4.1 Requirement of encoding Although all mailers let you use some kind of editing system to write and reply to email, these are not usually much good as word processors in the usual sense of the word (although some of them, like Emacs, are vastly better at the hard graft of editing text). Word processors are normally expected to be able to decorate your work with different typefaces, variable size headings and subheadings, etc. In order to do this, though, word processors have to store your documents in non-text files, because of all the formatting codes. But email systems in their raw state cannot handle non-text material: they are restricted to the 96 printable characters of the ASCII character set (A-Z, a-z, 0-9 and punctuation only). This conflict can be resolved in two ways: a) strip away all the formatting and font material, leaving just the raw text, with line breaks and spaces in the right places; or b) use a coding program which will make a file containing a representation of your untouched word processor document, but using only printable characters. However, if you need to send a binary word processor document file in its original state (e.g. if you and your recipient both use the same word processor, or you are required to submit a document in a specific format) you need to use the second method. This doesn't just apply to word processor files, of course - all non-text files need encoding before being sent by email. Common examples are compressed archive files created using PKzip (PCs), Gzip (PCs and UNIX), compress (UNIX), StuffIt (Apple Mac) or similar programs; binary data files; executable programs; desktop 27

Chapter 3. Email protocols and encoding publishing files; spreadsheets; databases; and sounds or graphical images (e.g. SND, AU, GIF, JPEG, MOV, or MPG files). 3.4.2 Transfer Encoding A transfer encoding is a reversible transformation that maps a data set containing a wide range of bytes to and from a restricted set of bytes [30]. For example, a transfer encoding can map a data set of 8-bit text to 7-bit text and vice versa. Transfer encoding is used to create a "tunnel" between two cooperating applications, which enables them to exchange data bytes that would otherwise be discarded or corrupted by the interface between them. The transfer encoding is applied to the data stream before it is sent to the interface. The transfer encoding is then removed or decoded when retrieved from the interface. The following diagram shows an overview of transfer encoding. Sender Receiver Encoder Decoder Restricted Interface Restricted Interface Figure 3.3 Transfer encoding. 3.4.3 UUEncode and UUDecode Overview Basically UUEncode and UUDecode are used to transfer binary files across the network [21]. Binary files usually contain non ASCII and unreadable characters which are not transferable until converted into ASCII format. UUEncode converts a binary file into readable ASCII characters. In context of transferring ciphertext UUencoding is also helpful, as the ciphertext may also contain the unreadable non ASCII characters. In the Secure messaging system using ECC, UUencode is also used to encode the ciphertext before transmitting over the network. UUencode stands for Unix-to-Unix Encode. It is a text-based binary encryption protocol in wide use on the Internet to transfer files across multiple platforms including UNIX, Windows, MS- 28

Chapter 3. Email protocols and encoding DOS, Macintosh, and other operating systems. UUencode is the UNIX name for the encryption program; it is normally used with another UNIX program, UUdecode, which decodes an encrypted message. UUencode was initially started from the UNIX platform but now it is used in other platforms as well. 3.4.4 Need of UUEncode The basic idea behind UUencoding a file is to translate a binary representation of data--which could be a graphic image, compressed file, or other type of binary data--into an encrypted text representation of that file. There are two reasons for doing this: a) First reason is that many mail systems used on the Internet cannot handle binary transmissions since they are designed for text data. However, if a file is UUencoded, it can be included as text in the message. b) Second reason is that many mail systems and gateways have size limitations, often less than 50 kilobytes (KB). It is sometimes necessary to use a text editor to split or combine such files. Since a binary representation of that data would make the editing of data very difficult, and since software that automatically joins these binary files is relatively rare, UUencoding a binary file allows common text editors to be used to join such files. 3.4.5 UUEncode Message format There is no standard file name convention, although most UNIX-based systems use a.uu as a suffix. DOS-based computers, with their standard three-digit suffixes, generally use.uue. This is one general method of telling whether or not it is a UUencoded file. Another method is actually looking at the first line of the file. A UUencoded file can be identified by the first line of the file: begin 644 myfile.gif This line is followed immediately by the start of the data. The first character of every line is the letter M. If the file has other characters other than M, the file is either not a UUencoded file, or has been damaged: MuVAA=baI<RabzvYHyw@_cpUbzvYHyw@@zwl@xF]TzbaAhgmE=baOyBaA< The block ends with a single line containing the statement: end 29

Chapter 3. Email protocols and encoding The first line signals the start of the block. The number 644 is a UNIX permission flag (in this case, giving the owner of the file full read, write, and execute permissions). The third part is the file name to which UUdecode will expand the file. We can convert any non text file into text version for transmission over the network such as GIF, TIFF, JPG, EXE and also ciphertext in encryption systems. 30

Chapter 4. Mathematical background of ECC Chapter 4 MATHEMATICAL BACKGROUND OF ECC In this Chapter we will discuss the basic mathematical understanding of the theory of elliptic curves [24]. 4.1 Elliptic curve Elliptic curve is not the same as an ellipse. But to be more positive: from school mathematics, we probably know the equation for a circle centered on the (a,b) of radius r, which is [13]: where x, y, a, b and r are real numbers. (x-a) 2 + (y-b) 2 = r 2 (4.1) An elliptic curve is also defined by an equation, but it has the slightly more complicated form: [13] y 2 [+ x y] = x 3 + a x 2 + b (4.2) Notation: means multiplication, y 2 means y y and x 3 means x x x. The square brackets mean that the term is optional -sometimes it is there, sometimes it isn't! Again x and y are variables, a and b are constants. However, these quantities are not necessarily real numbers, instead they may be values from any field. For cryptographic purposes we always use a "finite" field - that is x, y, a and b are chosen from a finite set of distinct values. 4.2 Group A group is a set of numbers with a custom-defined arithmetic operation. The unique rules for arithmetic in groups are a source of the hard problems necessary for cryptographic security. Two groups used in cryptography are Z n, the additive group of integers modulo a number n; and Z p *, the multiplicative group of integers modulo a prime number p. 4.3 The group Z n 31

Chapter 4. Mathematical background of ECC The group Z n uses only the integers from 0 to n - 1. Its basic operation is addition, which ends by reducing the result modulo n; that is, taking the integer remainder when the result is divided by n. One very important feature of arithmetic in a group is that all calculations give numbers which are in the group; this is called closure. Modular reduction by n ensures that all additions result in numbers between 0 and n - 1. The additive group Z 15 uses the integers from 0 to 14. Here are some sample additions in Z 15 : (10 + 12) mod 15 = 22 mod 15 = 7 (4 + 11) mod 15 = 15 mod 15 = 0 In Z 15, 10 + 12 = 7 and 4 + 11 = 0. Notice that both calculations have answers between 0 and 14. 4.4 Additive Inverses Each number x in an additive group has an additive inverse element in the group; that is an integer -x such that x + (-x) = 0 in the group. In Z 15, -4 = 11 since (4+11) mod 15 = 15 mod 15 = 0. 4.5 Other operations While addition is the main operation in the additive group Zn, other operations can be derived from addition. For example, the subtraction x - y can be performed as the addition x + (-y) mod n. In Z 15, 1-4 = 1 + (-4) = 1 + 11 mod 15 = 12. It is also possible to define multiplication in Zn by repeated addition. For example, the multiplication 4(9) in Z 15 can be achieved by adding together 9 + 9 + 9 + 9 mod 15 = 36 mod 15 = 6. 4.6 The group Z p * Cryptosystems using arithmetic in Z p * include the Diffie-Hellman Key Agreement Protocol and the Digital Signature Algorithm (DSA). The multiplicative group Z p * uses only the integers between 1 and p - 1 (p is a prime number), and its basic operation is multiplication. Multiplication ends by taking the remainder on division by p; this ensures closure. The multiplicative group Z 11 * uses the integers from 1 to 10. Multiplication in Z 11 * finishes by taking the remainder when the result is divided by 11. Here are some examples of multiplication in Z 11 *: 4 * 7 mod 11 = 28 mod 11 = 6 32

Chapter 4. Mathematical background of ECC 9 * 5 mod 11 = 45 mod 11 = 1. Thus in Z 11 *, 4 * 7 = 6 and 9 * 5 = 1. Notice that both the calculations shown have answers between 1 and 10. 4.7 Multiplicative Inverses Each number x in a multiplicative group has a multiplicative inverse element in the group; that is an integer x -1 such that x * x -1 = 1 in the group. In Z 11 *, 9-1 = 5 since 9 * 5 mod 11 = 1. In a multiplicative group, each element must have a multiplicative inverse. Consider the integers modulo the (composite) number 15. It is possible to define multiplication on the numbers from 1 to 14, always finishing with reduction modulo 15. With this system, the number 6 has no inverse, since there is no number y such that 6 * y mod 15 = 1: 4.8 Abelian Groups An arithmetic operation is said to be commutative if the order of its arguments is insignificant. With ordinary numbers, addition and multiplication are commutative operations; for example, 2*9 = 9*2 and 2 + 9 = 9 + 2. However, subtraction and division are not commutative since 2-9 9-2 and 2 / 9 9 / 2. A group is called abelian if its main operation is commutative. Thus an additive group is abelian if a + b = b + a for all elements a, b in the group. A multiplicative group is abelian if a * b = b * a for all elements a, b in the group. The additive group Z n and the multiplicative group Z p * are both abelian groups. 4.9 Field A field is a set of elements with two custom-defined arithmetic operations: most commonly, addition and multiplication. The elements of the field are an additive abelian group, and the non-zero elements of the field are a multiplicative abelian group. This means that all elements of the field have an additive inverse, and all nonzero elements have a multiplicative inverse. As is true for groups, other operations can be defined in a field, using its main two operations. 33

Chapter 4. Mathematical background of ECC A field is called finite if it has a finite number of elements. The most commonly used finite fields in cryptography are the field F p (where p is a prime number) and the field F m 2. 4.10 The field F p The finite field F p (p a prime number) consists of the numbers from 0 to p - 1. Its operations are addition and multiplication, which are defined as for the groups Z n and Z p * respectively: all calculations end with reduction modulo p. The restriction that p be a prime number is necessary so that all non-zero elements have a multiplicative inverse (see Z p * for details). As with Z n and Z p *, other operations in F p (such as division, subtraction and exponentiation) are derived from the definitions of addition and multiplication. Calculations in the field F 23 include 10* 4-11 mod 23 = 29 mod 23 = 6 7-1 mod 23 = 10 since 7*10 mod 23 = 70 mod 23 = 1 (8 3 ) / 7 mod 23 = 512 / 7 mod 23 = 6* 7-1 mod 23 = 6*10 mod 23 = 14. 4.11 The field F 2 m Although the description of the field F m 2 is complicated, this field is extremely useful because its computations can be done efficiently when implemented in hardware. Over here arithmetic in F m 2 ; is described by polynomial representation. 4.12 Polynomial Representation 34

Chapter 4. Mathematical background of ECC The elements of F 2 m are polynomials of degree less than m, with coefficients in F 2 ; that is, {a m-1 x m-1 + a m-2 x m-2 +... + a 2 x 2 + a 1 x + a 0 a i = 0 or 1}. These elements can be written in vector form as (a m-1... a 1 a 0 ). F 2 m has 2 m elements. The main operations in F 2 m are addition and multiplication. Some computations involve a polynomial f(x) = x m + f m-1 x m-1 + f m-2 x m-2 +... + f 2 x 2 + f 1 x + f 0, where each f i is in F 2. The polynomial f(x) must be irreducible [2]; that is, it cannot be factored into two polynomials over F 2, each of degree less than m. 4.13 Addition (a m-1... a 1 a 0 ) + (b m-1... b 1 b 0 ) = (c m-1... c 1 c 0 ) where each c i = a i + b i over F 2. Addition is just the componentwise XOR of (a m-1... a 1 a 0 ) and (b m-1... b 1 b 0 ). 4.14 Subtraction In the field F 2 m, each element (a m-1... a 1 a 0 ) is its own additive inverse, since (a m-1... a 1 a 0 ) + (a m-1... a 1 a 0 ) = (0... 0 0), the additive identity. Thus addition and subtraction are equivalent operations in F 2 m. 4.15 Multiplication (a m-1... a 1 a 0 ) (b m-1... b 1 b 0 ) = (r m-1... r 1 r 0 ) where r m-1 x m-1 +... + r 1 x + r 0 is the remainder when the polynomial (a m-1 x m-1 +... + a 1 x + a 0 ) (b m-1 x m-1 +... + b 1 x + b 0 ) is divided by the polynomial f(x) over F 2. (Note that all polynomial coefficients are reduced modulo 2.) 4.16 Exponentiation The exponentiation (a m-1... a 1 a 0 ) e is performed by multiplying together e copies of (a m-1... a 1 a 0 ). 4.17 Multiplicative Inversion There exists at least one element g in F 2 m such that all non-zero elements in F 2 m can be expressed as a power of g. Such an element g is called a generator of F 2 m. The multiplicative inverse of an element a = g i is a -1 = g (-i) mod (2m-1). 4.18 Example - F 2 4 with Polynomial Representation The elements of F 2 4 are the 16 vectors: (0000) (0001) (0010) (0011) (0100) (0101) (0110) (0111) (1000) (1001) (1010) (1011) (1100) (1101) (1110) (1111). Table 4.1 4 16 vectors for F 2 35

Chapter 4. Mathematical background of ECC The irreducible polynomial used will be f(x) = x 4 + x + 1. The following are sample calculations. Addition (0110) + (0101) = (0011). Multiplication (1101) (1001) = (x 3 + x 2 + 1) (x 3 + 1) mod f(x) = x 6 + x 5 + 2x 3 + x 2 + 1 mod f(x) = x 6 + x 5 + x 2 + 1 mod f(x) (coefficients are reduced modulo 2) = ( x 4 + x + 1)(x 2 + x) + (x 3 + x 2 + x + 1) mod f(x) [Note that (x 6 + x 5 + x 2 + 1)/( x 4 + x + 1) = (-x 3 - x 2 - x + 1) ] = x 3 + x 2 + x + 1 = (1111). Exponentiation To compute (0010) 5, first find (0010) 2 = (0010) (0010) = x x mod f(x) = ( x 4 + x + 1)(0) + (x 2 ) mod f(x) [ as x 2 can not be divided by ( x 4 + x + 1) ] = x 2 = (0100). Then (0010) 4 = (0010) 2 (0010) 2 = (0100) (0100) = x 2 x 2 mod f(x) = ( x 4 + x + 1)(1) + (x + 1) mod f(x) [as (x 4 )/ ( x 4 + x + 1) = -x-1 ] = x + 1 = (0011). 36

Chapter 4. Mathematical background of ECC Finally, (0010) 5 = (0010) 4 (0010) = (0011) (0010) = (x + 1) (x) mod f(x) = (x 2 + x) mod f(x) = ( x 4 + x + 1)(0) + (x 2 + x) mod f(x) [because (x 2 + x) can not be divided by ( x 4 + x + 1) ] = x 2 + x = (0110). 4.19 Multiplicative Inversion The element g = (0010) is a generator for the field. The powers of g are: g 0 = (0001) [2 0 = 1] g 1 = (0010) [2 1 = 2] g 2 = (0100) [2 2 = 4] g 3 = (1000) [2 3 = 8] g 4 = (0011) [2 4 = 16, 16 = (10000) 2 =x 4, (x 4 )/ ( x 4 + x + 1) = -x-1= (0011)] g 5 = (0110) g 6 = (1100) g 7 = (1011) g 8 = (0101) g 9 = (1010) g 10 = (0111) g 11 = (1110) g 12 = (1111) g 13 = (1101) g 14 = (1001) g 15 = (0001). The multiplicative identity for the field is g 0 = (0001). The multiplicative inverse of g 7 = (1011) is given by: g -7 mod 15 = g 8 mod 15 [as 15-7=8] =g 8 = (0101). 37

Chapter 4. Mathematical background of ECC To verify this, see that (1011) (0101) = (x 3 + x + 1) (x 2 + 1) mod f(x) = x 5 + x 2 + x + 1 mod f(x) = ( x 4 + x + 1)(x) + (1) mod f(x) = 1 = (0001), which is the multiplicative identity. 4.20 Use of Elliptic Curve The crucial property of an elliptic curve is that we can define a rule for "adding" two points which are on the curve, to obtain a 3rd point which is also on the curve. This addition rule satisfies the normal properties of addition. The points and the addition law form a finite Abelian group. Having defined addition of two points, we can also define multiplication k*p where k is a positive integer and P is a point as the sum of k copies of P. Thus 2*P = P+P 3*P = P+P+P This is analogous to how we define "powers" in normal arithmetic, where x 2 = x.x x 3 = x.x.x Now we are in a position to do some cryptography! Alice, Bob, Cathy, David... agree on a (non-secret) elliptic curve and a (nonsecret) fixed curve point F. Alice chooses a secret random integer Ak which is her secret key, and publishes the curve point AP = Ak*F as her public key. Bob, Cathy and David do the same. Ak = secret key of Alice; AP = public key of Alice = Ak*F Bk = secret key of Bob ; BP = Bk*F Now suppose Alice wishes to send a message to Bob. One method is for Alice to simply compute Ak*BP and use the result as the secret key for a conventional symmetric block cipher (say DES). Bob can compute the same number by calculating Bk * AP, since Bk*AP = Bk*(Ak*F) = (Bk*Ak)*F = Ak*(Bk*F) = Ak*BP. 38

Chapter 4. Mathematical background of ECC The security of the scheme is based on the assumption that it is difficult to compute k given F. Chapter 5 THE SECURE MESSAGING APPLICATION In this chapter the overall working of our secure ECC messaging application is discussed. All the possible scenarios for messaging are also discussed. 5.1 Key Generation For the Key generation purpose, both parties who want to participate in the secure communication over the network, must have the ECC application. For example Alice and Bob want to communicate securely, then both need to generate a pair of keys, one is public key and other is private key. Both can exchange their public keys, but private keys must be kept by themselves and not to be disclosed. After generating keys, the private key must not be kept anywhere on the hard disk, instead it should be stored on a separate medium such as floppy disk or CD ROM and must not be stored anywhere in the system. Even if the private key is initially stored on the hard disk then it must be moved later on to some other media and deleted from the Hard disk. Keys should be permanently purged via professional file eliminator software such as Evidence Eliminator or FileAssurity [27] etc. Once the keys are generated, the public keys must be exchanged over the network. The easy way to exchange keys is to transmit them via SMTP. Public Keys can also be stored on a central key server and anyone who wishes to communicate with someone must download the recipient s key first from the key server. 39

Chapter 5. The secure messaging application Public Key Internet Public Key ECC Key Generation Sender Receipient ECC Key Generation Private Key Public Key Store (Key Server / HDD) Private Key Figure 5.1 ECC key generation and exchange of public keys. 5.2 ECC Encryption Process Our encryption overall process has a great analogy with the PGP encryption process. Suppose that Alice and Bob want to communicate, first of all plaintext file or any kind of message which Alice intend to transmit over the network, is compressed using LZSS [14]. Then a random 128 bit AES [15] key is generated and this key is used in encrypting the plaintext via AES symmetric encryption scheme. The Advanced Encryption Standard supersedes DES [1] as the new information protection standard defined by the US to protect certain levels of Federal information and communications [15]. After that the compressed and encrypted message is again encoded using UUencode module. This is because after encryption file is ready to be transmitted over the network but it is not yet ready for transmission via electronic mail. It is so because the ciphertext that is generated via AES may contain characters out of the range of ASCII character set. UUencode process makes sure that all of the ciphertext is converted in ASCII format before initiating the transfer process. The random 128 bit symmetric encryption key is again in-turn encrypted using Bob s public key. We have used ECC public key cryptography feature to encrypt a very small session key and by doing this we are reducing the time factor involved in the slow encryption process of the public key scheme. In the end encrypted session key and UUencoded ciphertext message is bundled in an email and sent to the intended recipient. 40

Chapter 5. The secure messaging application Plain text LZSS Compress AES Encrypt UU Encode ECC Public Key ECC SMTP Internet Session Key Random Key Figure 5.2 5.3 ECC Decryption Process ECC encryption. In the decryption process, first of all the Bob downloads his email via POP3. After receiving the ECC encrypted session key and UUencoded ciphertext in his email, he then starts the decryption process. First the encrypted session key is decrypted by using the Bob s private key. In this way only Bob can decrypt the message being sent over the network. Now the UUencoded message is decoded using UUdecode process which results in an AES encrypted message. This AES encrypted message and the session key obtained earlier are then used for AES symmetric decryption process to decrypt the message. After the message is decrypted, the outcome is a compressed message. This message is again decompressed using LZSS to re-produce the plaintext again. ECC Private Key ECC Encrypted Session Key ECC Plain session Key Plain text AES Decrypt Compressed data LZSS Decompress Internet UU Encoded message UU Decode AES Encrypted Data Figure 5.3 ECC decryption. 5.4 Importance of compression before encryption In any secure messaging application; there is a great significance of compression before encryption process. The purpose of compression is to basically reduce the plaintext properties from the confidential message being sent over the network. A plaintext property of a message means that there is a certain frequency of alphabets in the content of the message depending on the context of the discussion. For example if the context of the message is English literature or some classical 41

Chapter 5. The secure messaging application children story, then it is possible that the frequencies of the alphabets such as E, T or A may be higher then other alphabets. Similarly if the context is lets say based on the subject of computer security then it might be possible that frequency of other alphabets such as S, C may become higher. As the compression algorithms reduce the redundancies i.e., the bits per information content form the message so it is very important that we must compress the data before encryption. An encryption algorithm such as ECC is also available in the public domain, but the methodology that we have chosen for encryption, generates a random session key which is not known to anyone before decryption process. In this way we can safely reduce the plaintext properties from the message and also make our messaging more secure. If we place the compression module after encryption, then it will not be that secure as in case of before encryption, because intruder may take advantage of the public domain algorithm and may uncompress the ciphertext having the plaintext inherent properties. In this case our ciphertext may go immediately under cryptanalytic attack. 42

Chapter 5. The secure messaging application Chapter 6 IMPLEMENTATION DETAILS This chapter mainly concerns with the implementation details of the secure ECC messaging application. Source code of the main function of the application (key generation, encryption and decryption) is also listed in this chapter. RSA is also discussed in the last section as it is used for comparing results generated with ECC. 6.1 Libraries used For the implementation many different libraries are used for the development of ECC secure messaging application to create the best possible integrated solution. The development tool used for ECC application is Visual C++ 6.0. See Appendix A for further details. 6.2 System Requirements Minimum system requirements for ECC messaging application are as follows: 1) Minimum Pentium 133 MHz PC. (recommended P4 1GHz for development and test generation) 2) 32 MB RAM (recommended 128 MB for better performance.) 43

Chapter 6. Implementation details Although the test results are generated on Pentium 4 (Dell optiplex GX 240) system having 256 MB RAM, 20 GB HDD. 6.3 Source Code Although the code is very lengthy and complex, but for the general overview of the ECC implementation, only few function for the key generation, encryption, and decryption are listed in the following section. 6.3.1 OnButtonGenerateKyes function OnButtonGenerateKeys() is a function that is always called when used presses the button to generate keys. Code is listed below: void CECCDlg::OnButtonGenerateKeys() { BeginWaitCursor(); SYSTEMTIME st1,st2; GetSystemTime(&st1); // gets current time long ms01 = 60000*(st1.wMinute) + 1000*(st1.wSecond) + st1.wmilliseconds; UpdateData(1); EC_Domain_Parameters dp; if (m_combo01 == "NIST_B_163") { } use_nist_b_163 (); dp = NIST_B_163; if (m_combo01 == "NIST_B_233") { } use_nist_b_233 (); dp = NIST_B_233; if (m_combo01 == "NIST_B_283") { use_nist_b_283 (); dp = NIST_B_283; if (m_combo01 == "NIST_B_409") 44

Chapter 6. Implementation details { } use_nist_b_409 (); dp = NIST_B_409; if (m_combo01 == "NIST_B_571") { } use_nist_b_571 (); dp = NIST_B_571; ECPrivKey sk (dp); // generate random private key ECPubKey pk (sk);// calculate the public key the private key DER sk_der_encoding (sk); DER pk_der_encoding (pk); std::ofstream key_outfile1 (m_editpublickeyfile.getbuffer(m_editpublickeyfile.getlength()), std::ios::binary); if (!key_outfile1) { } AfxMessageBox("Error can't open file1!"); return; key_outfile1 << HexEncoder(pk_der_encoding); key_outfile1.close(); std::ofstream key_outfile2 (m_editprivatekeyfile.getbuffer(m_editprivatekeyfile.getlength()), std::ios::binary); if (!key_outfile2) { AfxMessageBox("Error can't open file2!"); return; } key_outfile2 << HexEncoder(sk_der_encoding); key_outfile2.close(); 45

Chapter 6. Implementation details GetSystemTime(&st2); // gets current time long ms02 = 60000*(st2.wMinute) + 1000*(st2.wSecond) + st2.wmilliseconds; CFile logfile01("log.txt", CFile::modeCreate CFile::modeWrite CFile::modeNoTruncate ); logfile01.seektoend(); CString logbuff01; logbuff01 = "----------"; CTime t1 = CTime::GetCurrentTime(); logbuff01 += t1.format( "%A, %B %d, %Y - %H : %M : %S " ); logbuff01 += "---------\r\n"; logfile01.write(logbuff01.getbuffer(logbuff01.getlength()), logbuff01.getlength()); logbuff01.format("time to Generate Keys : %d milliseconds.\r\n", ms02- ms01); logfile01.write(logbuff01.getbuffer(logbuff01.getlength()), logbuff01.getlength()); logbuff01 = "---------==========---------\r\n"; logfile01.write(logbuff01.getbuffer(logbuff01.getlength()), logbuff01.getlength()); EndWaitCursor(); } 6.3.2 Calculation of Execution time First of all, GetSystemTime(&st1) is called which gets current time and stores into st1 structure. Similarly, when the key generation stops, GetSystemTime(&st2) is again called and time in milliseconds is again recorded in st2 and the total time of key generation is calculated by st2-st1. The GetSystemTime() function retrieves the current system date and time. And stores the value of time in the SYSTEMTIME structure. 6.3.3 OnButtonEncrypt function void CECCDlg::OnButtonEncrypt() { 46

Chapter 6. Implementation details BeginWaitCursor(); SYSTEMTIME st1,st2; GetSystemTime(&st1); // gets current time long ms01 = 60000*(st1.wMinute) + 1000*(st1.wSecond) + st1.wmilliseconds; OnButtonCompress(); UpdateData(1); CString KeyStr; LONG InBytes; int NumberCharecters; void* InBuffer; CFile InFile1(m_EditPublicKeyFile,CFile::modeRead); InBytes = InFile1.GetLength(); InBuffer = malloc( InBytes ); if( InBytes == NULL ) AfxMessageBox("Insufficient memory available for m_editpublickeyfile"); else { InFile1.Seek(0, CFile::begin); NumberCharecters = InFile1.Read(InBuffer,InBytes); } InFile1.Close(); KeyStr=(char*)InBuffer; KeyStr.Delete(InBytes,KeyStr.GetLength()-InBytes); free( InBuffer ); KeyStr = Hex2Ascii(KeyStr,KeyStr.GetLength()); OCTETSTR pubkeyvectorread(keystr.getlength()); int i; for (i=0; i<keystr.getlength(); i++) { 47

Chapter 6. Implementation details } pubkeyvectorread[i] = KeyStr[i]; DER pk2_der = pubkeyvectorread; ECPubKey pk2 = pk2_der.toecpubkey(); std::ifstream plaintext_infile1("lzss-comp-a.txt", std::ios::binary); if (!plaintext_infile1) { AfxMessageBox("Error can't open file!"); return; } OCTETSTR plaintextvectorread; char c2; OCTET o2; while (plaintext_infile1.get (c2)) { o2 = (unsigned char)c2; plaintextvectorread.push_back (o2); } plaintext_infile1.close(); int keysize = 128; // 128 bit symmetric encryption key OCTETSTR P1; // This is 0 OCTETSTR Z(keysize/8); for (i=0; i<(keysize/8); i++) { Z[i] = (OCTET)gen_random (); } OCTETSTR key = KDF2 (Z, keysize/8, P1); std::ofstream cypher_outfile0 ("plain-session.txt", std::ios::binary); if (!cypher_outfile0) { AfxMessageBox("Error can't open file0!"); 48

Chapter 6. Implementation details return; } cypher_outfile0 << HexEncoder(key); cypher_outfile0.close(); OCTETSTR c3 = AES_CBC_IV0_Encrypt (key, plaintextvectorread, keysize); ECIES ct1 (key, pk2); // encrypt using the public key DER cyphertext_der_encoded(c3); DER session_key_der_encoded(ct1); std::ofstream cypher_outfile1 ("cipher-without-uue.txt", std::ios::binary); if (!cypher_outfile1) { AfxMessageBox("Error can't open file1!"); return; } cypher_outfile1 << cyphertext_der_encoded; cypher_outfile1.close(); FILE *f; f = fopen(m_editcyphertextfile.getbuffer(m_editcyphertextfile.getlength()),"wb"); if (f == NULL) { printf("impossible to open cipheruue.txt\n"); } fclose(f); uuencode(f,"cipher-without-uue.txt"); std::ofstream cypher_outfile2 ("sessionkey.txt", std::ios::binary); if (!cypher_outfile2) { AfxMessageBox("Error can't open file2!"); return; } 49

Chapter 6. Implementation details cypher_outfile2 << HexEncoder(session_key_der_encoded); cypher_outfile2.close(); DeleteFile("lzss-comp-a.txt"); DeleteFile("cipher-without-uue.txt"); DeleteFile("plain-session.txt"); GetSystemTime(&st2); // gets current time long ms02 = 60000*(st2.wMinute) + 1000*(st2.wSecond) + st2.wmilliseconds; CFile logfile01("log.txt", CFile::modeCreate CFile::modeWrite CFile::modeNoTruncate ); logfile01.seektoend(); CString logbuff01; logbuff01 = "----------"; CTime t1 = CTime::GetCurrentTime(); logbuff01 += t1.format( "%A, %B %d, %Y - %H : %M : %S " ); logbuff01 += "---------\r\n"; logfile01.write(logbuff01.getbuffer(logbuff01.getlength()), logbuff01.getlength()); logbuff01.format("time to Encrypt : %d milliseconds.\r\n", ms02-ms01); logfile01.write(logbuff01.getbuffer(logbuff01.getlength()), logbuff01.getlength()); logbuff01 = "---------==========---------\r\n"; logfile01.write(logbuff01.getbuffer(logbuff01.getlength()), logbuff01.getlength()); EndWaitCursor(); } 6.3.4 OnButtonDecrypt function void CECCDlg::OnButtonDecrypt() { 50

Chapter 6. Implementation details BeginWaitCursor(); SYSTEMTIME st1,st2; GetSystemTime(&st1); // gets current time long ms01 = 60000*(st1.wMinute) + 1000*(st1.wSecond) + st1.wmilliseconds; UpdateData(1); CString PrivKeyStr; LONG InBytes; int NumberCharecters; void* InBuffer; CFile InFile1(m_EditPrivateKeyFile,CFile::modeRead); InBytes = InFile1.GetLength(); InBuffer = malloc( InBytes ); if( InBytes == NULL ) AfxMessageBox("Insufficient memory available for m_editprivatekeyfile"); else { InFile1.Seek(0, CFile::begin); NumberCharecters = InFile1.Read(InBuffer,InBytes); } InFile1.Close(); PrivKeyStr=(char*)InBuffer; PrivKeyStr.Delete(InBytes,PrivKeyStr.GetLength()-InBytes); free( InBuffer ); PrivKeyStr = Hex2Ascii(PrivKeyStr,PrivKeyStr.GetLength()); OCTETSTR privkeyvectorread(privkeystr.getlength()); int i; for (i=0; i<privkeystr.getlength(); i++) { privkeyvectorread[i] = PrivKeyStr[i]; } 51

Chapter 6. Implementation details DER sk_der = privkeyvectorread; ECPrivKey sk = sk_der.toecprivkey(); CString SessKeyStr; CFile InFile2("sessionkey.txt",CFile::modeRead); InBytes = InFile2.GetLength(); InBuffer = malloc( InBytes ); if( InBytes == NULL ) AfxMessageBox("Insufficient memory available for sessionkey.txt"); else { InFile2.Seek(0, CFile::begin); NumberCharecters = InFile2.Read(InBuffer,InBytes); } InFile2.Close(); SessKeyStr=(char*)InBuffer; SessKeyStr.Delete(InBytes,SessKeyStr.GetLength()-InBytes); free( InBuffer ); SessKeyStr = Hex2Ascii(SessKeyStr,SessKeyStr.GetLength()); OCTETSTR encr_sessionkeyread(sesskeystr.getlength()); for (i=0; i<sesskeystr.getlength(); i++) { encr_sessionkeyread[i] = SessKeyStr[i]; } DER encr_sessionkey_der = encr_sessionkeyread; ECIES ct1 = encr_sessionkey_der.toecies(); OCTETSTR plain_text_sessionkey_octetstr; try { // try to catch any exceptions if the tag is invalid plain_text_sessionkey_octetstr = ct1.decrypt(sk); // decrypt using the private key } catch (borzoiexception e) { // print the error message and exit e.debug_print (); return; 52

Chapter 6. Implementation details } FILE *f; f = fopen(m_editcyphertextfile.getbuffer(m_editcyphertextfile.getlength()),"rb"); if (f == NULL) { printf("i can't find %s\n",m_editcyphertextfile.getbuffer(m_editcyphertextfile.getlength())); } uudecode(f); fclose(f); std::ifstream cypher_infile1("cipher-without-uue.txt", std::ios::binary); if (!cypher_infile1) { AfxMessageBox("Error can't open file!"); return; } OCTETSTR cypherread; char c3; OCTET o3; while (cypher_infile1.get (c3)) { o3 = (unsigned char)c3; cypherread.push_back (o3); } cypher_infile1.close(); int keysize = 128; // 128 bit symmetric encryption key OCTETSTR compressed_plaintext; try { // try to catch any exceptions compressed_plaintext = AES_CBC_IV0_Decrypt (plain_text_sessionkey_octetstr, cypherread, keysize); } catch (borzoiexception e) { // print the error message and exit e.debug_print (); return; } DER compressed_plaintext_der_encoded(compressed_plaintext); 53

Chapter 6. Implementation details std::ofstream plain_text_outfile1 ("lzss-comp-b.txt", std::ios::binary); if (!plain_text_outfile1) { AfxMessageBox("Error can't open file1!"); return; } plain_text_outfile1 << compressed_plaintext_der_encoded; plain_text_outfile1.close(); OnButtonUncompress(); DeleteFile("lzss-comp-b.txt"); DeleteFile("cipher-without-uue.txt"); GetSystemTime(&st2); // gets current time long ms02 = 60000*(st2.wMinute) + 1000*(st2.wSecond) + st2.wmilliseconds; CFile logfile01("log.txt", CFile::modeCreate CFile::modeWrite CFile::modeNoTruncate ); logfile01.seektoend(); CString logbuff01; logbuff01 = "----------"; CTime t1 = CTime::GetCurrentTime(); logbuff01 += t1.format( "%A, %B %d, %Y - %H : %M : %S " ); logbuff01 += "---------\r\n"; logfile01.write(logbuff01.getbuffer(logbuff01.getlength()), logbuff01.getlength()); logbuff01.format("time to Decrypt : %d milliseconds.\r\n", ms02-ms01); logfile01.write(logbuff01.getbuffer(logbuff01.getlength()), logbuff01.getlength()); logbuff01 = "---------==========---------\r\n"; logfile01.write(logbuff01.getbuffer(logbuff01.getlength()), logbuff01.getlength()); EndWaitCursor(); } 6.3.5 RSA implementation of Crypto++ 54

Chapter 6. Implementation details The crypto++ implementation of RSA is used over here only for the sake of comparing results with ECC. Crypto++ uses RSAES-OAEP [22] (RSA Encryption Scheme - Optimal Asymmetric Encryption Padding) for encryption and SHA-1 for getting the hash. RSAES-OAEP is a public key encryption scheme combining the RSA algorithm with the OAEP method. RSA Laboratories recommends the RSAES- OAEP encryption scheme. RSAES-OAEP encryption also employs padding. Encryption padding is necessary to avoid dictionary attacks: by adding a random string to the encrypted message, the re-encryption of very short messages (such as yes or no) does not allow vu attacks (building-up dictionaries) [23]. Chapter 7 THE FRONT END TO ECC AND RSA In this chapter, the front end of the ECC and RSA application is discussed. ECC messaging application is executed by the ECC.exe binary and RSA messaging application is executed by the RSA.exe binary located in the sample directory. 7.1 The ECC GUI After execute the Ecc.exe, dialog box as indicated in the Figure 7.1 is displayed. User can select the message file which is the ciphertext in our case, set the subject of email, set the To and From addresses, select the session key file as an attachment and finally set the name of SMTP server. Note that in our application we have chosen that session key may be transmitted as an email attachment and ciphertext may go in the message body, how ever is the user wants to do the reverse, he can do so. For sending email user need to press the Send Mail button. For receiving emails via pop, user ID, password and POP3 server is entered and Get Mail button is pressed. 55

Chapter 7. The front end to ECC and RSA Figure 7.1 ECC application s main dialog box. By pressing the ECC button on the main dialog box of the ECC application, user can see the new dialog box as shown Figure 7.2. This interface contains the main ECC functions i.e., encrypt, decrypt and generate keys. The numbering scheme on the interface is self descriptive. User can also select available NIST curves [17] from list. 7.2 The RSA GUI Figure 7.2 The ECC dialog box. When we execute RSA.exe, the dialog box is shown as in Figure 7.3. This is almost the similar to the ECC.exe. In case of RSA.exe, the whole message is encrypted using RSA and there is no need to send the session key as an attachment. 56

Chapter 7. The front end to ECC and RSA Figure 7.3 RSA application s main dialog box. In the RSA Key generation dialog box, we need to specify the Key length, private key file, public key file and also select the directory to store files and then press the Generate Keys button. This is illustrated in Figure 7.4. Figure 7.4 RSA Key generation. In RSA crypto interface, encryption and decryption is facilitated. For encryption we need to set the public key, private key and the ciphertext file names and then press the RSA encrypt button. 57

Chapter 7. The front end to ECC and RSA Figure 7.5 RSA encryption - decryption. 7.3 Opening the attachment in outlook When we press the Get mail button in ECC or RSA application, it downloads all of the emails via POP3 and names the file according to following convention: server_name-account_name-serial_no.eml. For example, the file name may be mail.myrealbox.com-armahmood- 0001.eml and the next file name may be mail.myrealbox.com-armahmood-0002.eml etc. When we double click the downloaded email file with *.eml extension, it will automatically opened in the outlook express. User can save the attachment (session key) in a separate file and copy the message test and also create a new file and then he can start the decryption process. 58

Chapter 7. The front end to ECC and RSA Figure 7.6 Email in Outlook Chapter 8 RESULTS AND OBSERVATIONS 59

Chapter 8. Results and observations In this chapter very interesting analysis is presented based on the elliptic curves and RSA results. The results are obtained from the ECC and RSA applications that are developed during the research work. All the results obtained are based on the DELL Optiplex P4 with 128 MB RAM, results may vary if application is tested on different platform and operating system. 8.1 ECC results In the Table 8.1, curves of different bit lengths are tabulated against the execution time of different functions of ECC such as key generation, encryption and decryption time. The plaintext data size in this case is 9693 bytes. Analysis of the key generation cost against curves concludes that both are directly proportional. Key generation cost also increases as the increase in bit length of curve. Curve Key generation Encryption time time (milli sec.) (milli sec.) NIST 163 125 265 250 NIST 233 328 578 500 NIST 283 328 922 922 NIST 409 704 1953 1781 Decryption time (milli sec.) NIST 571 1485 4594 4750 Table 8.1 ECC key generation, encryption and decryption cost. Analysis of the encryption cost against curves concludes that both are directly proportional. Encryption cost also increases as the increase in bit length of curve but this increase is more exponential then key generation cost. Analysis of the decryption cost against curves again gives an idea that both are directly proportional. Decryption cost also increases as the increase in bit length of curve but this increase is too much exponential as compared with other two costs. As a result of ECC, we can conclude that key generation is the least costly process in ECC, but encryption and decryption takes much more time. Hence it is best practice to encrypt only small session key and not to encrypt the whole message with elliptic curves. The results that we have discusses so far are also presented in graphically in Figure 8.1 for easy visual representation. 60

Chapter 8. Results and observations 5000 4500 4000 Key generation time (milli seconds) Encription time (milli seconds) Decription time (milli seconds) 3500 3000 time (ms) 2500 2000 1500 1000 500 0 NIST 163 bit NIST 233 bit NIST 283 bit NIST 409 bit NIST 571 bit Figure 8.1 ECC key generation, encryption and decryption cost. 8.2 RSA results In the Table 8.2, key length are tabulated against the execution time of different functions of RSA such encryption and decryption cost. Analysis of the encryption cost against key length gives an indication that encryption seems to be a constant function against key length as encryption time is always around 15 milliseconds, even if we continue to increase the key length. The message size that is to be encrypted also increases as the key size increases. For example 1024 bit key is secure only for 86 bytes message. Hence the data size is also directly proportional to key length. Analysis of the decryption cost against key length indicates that both are directly proportional. Decryption cost also increases as the increase in bit length of key but this increase much exponential as compared with other two costs. 61

Chapter 8. Results and observations As a result of RSA, we can conclude that RSA encryption time remains constant while the bit length increases, but the decryption cost increases rapidly. Key length(bits) Encryption time (ms) data size (bytes) Decryption time (ms) 512 bits 16 22 1 1024 bits 15 86 15 2048 bits 15 214 78 4096 bits 15 470 438 8192 bits 15 982 2625 Table 8.2 RSA encryption and decryption cost The results of RSA encryption and decryption are also presented in graphically in Figure 8.2 for easy visual representation. 3000 2500 2000 Encryption time (milli sec) data size (bytes) Decryption time (milli sec) time (ms) 1500 1000 500 0 512 bits 1024 bits 2048 bits 4096 bits 8192 bits Figure 8.2 RSA encryption and decryption cost In the Table 8.3, key length is tabulated against the execution time of key generation function of RSA. The key generation time is highly exponential that s why we have tabulated it separately. The analysis shows that key generation is directly proportional and increases at an exponential rate as the key length increases. This is the most interesting fact that we have obtained so far about RSA. It shows that the key generation process in RSA is really very time consuming process and is the most costly process. For example for 8192 bit key it takes about 116.891 seconds or approximately 2 minutes. Key length(bits) Key generation time(milli sec) 512 bits 31 62

Chapter 8. Results and observations 1024 bits 141 2048 bits 531 4096 bits 63844 8192 bits 116891 Table 8.3 RSA key generation cost The results of RSA key generation is also plotted in the following plot, i.e., Figure 8.3 Key generation time(milli sec) 140000 120000 time (ms) 100000 80000 60000 40000 20000 0 512 bits 1024 bits 2048 bits 4096 bits 8192 bits Figure 8.3 RSA key generation cost The same results as plotted in Figure 8.3 that is RSA key generation time is again plotted as a 3 dimensional bar graph in Figure 8.4 The reason to plot another 3D bar graph is to clarify that decryption time is not equal to zero in case of 512 bits and 1024 bits of data. The values under consideration in Figure 8.3 look like zero although it has some as also shown in Table 8.3. 63

Chapter 8. Results and observations 120000 Key generation time(milli sec) Key generation time(milli sec) 100000 80000 time (ms) 60000 40000 20000 0 512 bits 1024 bits 2048 bits 4096 bits 8192 bits Key generation time(milli sec) Figure 8.4 8.3 Comparison of ECC and RSA RSA key generation cost The results presented in Table 8.1 for ECC is not comparable to RSA because data size for the plaintext was different. For the comparison of ECC and RSA we have regenerated the results for both ECC and RSA based on the same data size, (i.e., 22 bytes) which is represented as Table 8.4 and Table 8.5. Curve Key generation Encryption time (ms) Decryption time (ms) time (ms) NIST 163 291 521 470 NIST 233 530 112 2 1082 NIST 283 731 2013 2053 NIST 409 1563 4396 4026 NIST 571 3695 11206 11858 Table 8.4 ECC key generation, encryption and decryption cost (22 bytes) Key length (bits) Key generation Encryption time (ms) Decryption time (ms) time(ms) 512 bits 100 30 30 1024 bits 370 30 50 2048 bits 4736 20 110 4096 bits 10224 30 531 8192 bits 417330 30 3115 Table 8.5 RSA key generation, encryption and decryption cost (22 bytes) Key lengths of 160 bit as in ECC ensure the security of a RSA key of 1024 Bit, which is used as a standard today [9]. According to this we can see that the key 64

Chapter 8. Results and observations generation time of 1024 bit RSA keys is 370 ms whereas it is 291 ms as compared to NIST 163 bit keys. It means that ECC key generation process is 1.2 times faster. For easy visual representation comparison is also shown graphically in Figure 8.5. Also as we can see from Table 8.1, that NIST 160 bit curve is secure enough to encrypt huge data of 9693 bytes in RSA 1024 bit keys can only manage data up to 86 bytes. If we increase the data more than 86 bytes, then application will throw an error that message is too long for this key. time (ms) 600 500 400 300 200 100 0 ECC key generation ECC encryption ECC decryption RSA key generation RSA encryption RSA decryption Figure 8.5 ECC 160 bit vs. RSA 1024 bit On the other hand we can see that encryption and decryption costs of RSA are much lower than its equivalent of ECC, i.e., NIST 160 bit. This proves that ECC encryption and decryption are highly computation intensive processes. Encryption of RSA is 17.3 times faster than ECC similarly RSA decryption is also 15.6 times faster. That s why in our application we have used ECC to encrypt 128 bit session key which is an effort to make it cost effective. Note that results of Table 8.4 and Table 8.5 are generated on a system having Celeron 700 MHz processor with 256 MB RAM. 8.4 Relative cost of equivalent key sizes in RSA and ECC Symmetric ECCKey RSA Key Time to Break Memory Key 56 112 430 less than 5 minutes Trivial 80 160 760 600 months 4 Gb 96 192 1020 3 million years 170 Gb 128 256 1620 10 16 yrs 120 Tb Table 8.6 Relative cost of equivalent key sizes in RSA and ECC 65

Chapter 8. Results and observations As we can also see from Table 8.4 [16] that the key length of RSA is far larger as compared with the ECC key lengths and hence it gives more memory overhead for a secure message transmission such as 1620 bit key length of RSA. As we can see from the data that is generated by our ECC messaging application, as the no of bits increases the time to generate the keys, encryption time and the decryption time increases. The Key generation time is always very small as compared to encryption and decryption time. In our application we have used ECC only to encrypt a small session key and for actual encryption of plaintext we have used the symmetric key encryption as it is always fast for lengthy messages as compared with public key encryption scheme of ECC. This also proves that our adopted methodology is also the most cost effective way that combines the advantages of both of the symmetric and asymmetric key cryptography. 7000 6000 5000 RSA Key size (bits) 4000 3000 2000 1000 ECC 0 10000 1E+8 1E+12 Time to break (MIPS years) 1E+20 1E+36 Figure 8.6 Time to break ECC and RSA The graph in Figure 8.4 shows how long should it take to break the ECC and RSA cryptosystems of different key length [18]. The hard problem of RSA is factorization of a large integer while solving the discrete logarithm problem [25] is needed to break ECC. For the same security level, the key size of ECC is much 66

Chapter 8. Results and observations shorter then RSA. In other words, ECC provides a more secure cryptosystem for the same key length as RSA. 8.5 Important considerations: Most of the results are generated on Pentium 4 (Dell Optiplex GX 240) system having 256 MB RAM. It is very important to take the hardware as an important factor in the results generation because all the costs including key generation cost, encryption cost and decryption cost depends on the hardware used. For instance if RAM or processor speed is lower then the test system used in our case then time taken for encryption, decryption and key generation maybe much higher then our calculations.. If you are using a different hardware to regenerate the results again of the secure ECC messaging application then your results may vary according to the hardware configuration that you are using. 67

Chapter 9. Conclusion and future extensions Chapter 9 CONCLUSION AND FUTURE EXTENSIONS Elliptic curve cryptography provides a methodology for obtaining high-speed, efficient, and scalable implementations of a messaging system. In this research thesis, have described in detail the working and implementation of elliptic curve cryptographic technique, and the results of our implementation of the elliptic curve cryptography and finally we have compared our results with its rival of ECC i.e., RSA. The methodology for this research work is a software based development of system offering the features appropriate to the secure messaging system. These functions are then integrated and results are analyzed primarily for the offered speed and security. The system developed is then followed by trials and release of beta version. The implementation has been done using a host of available tools and libraries that were easily available meeting the prime requirement of ease of use. The detailed description of the tools and libraries used is available in Appendix A. 9.1 Conclusion The conclusion is based on the comparative analysis of NIST 160 bit curve and 1024 bit RSA key size because they provide the similar level of security. a) The results show that ECC is a highly computation intensive process as compared with RSA because the encryption / decryption cost of ECC is much more than that of RSA. b) Moreover we have observed that data size that RSA can process is much lower than that of ECC which is an advantage of ECC. c) Further to the results it was observed that key the generation time of ECC is almost equal or relatively efficient then RSA. 68

Chapter 9. Conclusion and future extensions 9.2 Proposed Future extensions of the application Although the basic encryption / decryption engine of a secure ECC application is developed but for future enhancement following features can be incorporated in the application. a) To implement the instant messaging system, Jabber [28] can be targeted because Jabber is an open, XML-based protocol for instant messaging, it is platform independent and has a large number of "free software" clients [31]. b) Key management feature is also needed in the application. c) A separate key server can also be allocated for the storage of the ECC specific keys and retrieval. d) The implementation of ECC that is developed in this research work can be further carried and the code developed can be used to create a COM component of ECC. This COM object may be used in different programming languages such as VB and also can be ported to different platforms as well. 69

Appendix A Appendix A TOOLS AND LIBRARIES For the implementation different libraries are used for the development of ECC secure messaging application to create best possible integrated solution. In appendix A, brief introductions of these tools are provided. The most important library that is used in the development is the Elliptic Curves library knows as Borzoi [32]. This library implements the digital signature algorithm and integrated encryption scheme using elliptic curves defined over finite fields of characteristic 2 (F m 2 ). The AES [15] symmetric encryption scheme and DER encoding functions are also included. Borzoi library is written in C++ and used a core encryption / decryption engine in the implementation of the secure messaging application. For the purpose of email communication the GetMail 2.0 [33] and SendMail 2.0 [33] are used. These libraries are also written in C++ and implements POP3 [20] and SMTP [19]. In these libraries, SMTP [19] mail delivery agent that can be used either as console program or as DLL. It handles multiple recipients and multiple file attachments. GetMail 2.0 [33] is POP3 [20] mail account retriever which saves mail messages in.eml Windows file format. Compression and decompression algorithms in the secure messaging application are implemented using LZSS [14] library - a variant of LZ77 [34]. This algorithm generally yields a better compression ratio in text files. The decoding is still extremely simple and quick. It is implemented in almost all of the popular archivers such as PKZip, ARJ etc. Of course, every archiver implements it differently. UUENCODE / UUDECODE [35] are used to encode / decode messages before sending them to the recipient. UUENCODE.EXE and UUDECODE.EXE are small Win32 console-mode utilities, written in Microsoft Visual C/C++ v4.0, which encode/decode single files based on the standard uuencode / uudecode algorithms. RSA is also implemented to compare the results with ECC. RSA is implemented using Crypto++ 4.1 [36]. Crypto++ is a free C++ class library of 70

Appendix A cryptographic schemes, some of which is other people's code, repackaged into classes. Crypto++ was designed to be easily portable to a large variety of platforms including Windows, MacOS, UNIX, WIN32, BeOS, and MSDOS. Also it supports many popular compilers such as MSVC 6.0, Borland C++ Builder, GCC 2.95.2, CodeWarrior Pro 5.3 and 6.0. For the implementation of this secure messaging application we have selected Microsoft Visual C++ 6.0 because it provides the most powerful and flexible development environment on windows platform for C++ language. MSVC 6.0 has also imported all the 3 rd party C++ libraries and classes very easily. One can use the integrated development environment for creating all of your Visual C++ programs. The environment provides a broad set of development tools for completing, testing and refining your program. For example, the development environment includes a text editor, resource editors, build options, an optimizing compiler, an incremental linker, a source code browse window, and an integrated debugger. The files you create for your C++ program will be organized into a Visual C++ project in a workspace. When creating Visual C++ programs that use the Microsoft Foundation Classes (MFC) or the Active Template Library (ATL), Win32 programs or libraries a wizard will help you create the C++ project files and some starter source files for your program [37]. Figure A.1 Microsoft Visual C++ 6.0 IDE 71

Appendix B Appendix B ACRONYMS USED API AES APOP ASCII ASN.1 ATM BASR BDS UNIX COM CPU CRLF DER DES DOS DSA ECC ECIES EMAIL ERR FAQ FIPS GB GIF GUI HDD IP IPCE ARPANET IT JPEG LAN MAC MB MDC MHz MIT MIPS MTS NIST OAEP Application Programming Interface Advanced Encryption Standard Authenticated Post Office Protocol American Standard Code for Information Interchange Abstract Syntax Notation One Automatic Teller Machine Board of Advanced Studies and Research UNIX version developed at the University of California, Berkeley Component Object Model Central Processing Unit Carriage Return Line Feed Distinguished Encoding Rules Data Encryption Standard Disk Operating System Digital Signature Algorithm Elliptic Curve Cryptography Elliptic Curve Integrated Encryption Scheme Electronic Mail Error Frequently Asked Question Federal Information Processing Standard Gigabyte Graphical Interchange Format Graphical User Interface Hard Disk Drive Internet Protocol Interprocess Communication Environment Advanced Research Projects Agency Network Information Technology Joint Photographic Experts Group Local Area Network Message Authentication Code Mega Byte Manipulation Detection Code Megahertz Massachusetts Institute of Technology Million Instructions per Second Message Transport System National Institute of Standards and Technology Optimal Asymmetric Encryption Padding 72

Appendix B PC Personal Computer PGP Pretty Good Privacy PIN Personal Identification Number PKI Public Key Infrastructure POP Post Office Protocol POP3 Post Office Protocol version 3 RAM Random Access Memory RETR Retrieve ROM Read Only Memory RSA Rivest Shamir Adleman RSAES-OAEP RSA Encryption Scheme - Optimal Asymmetric Encryption Padding SHA-1 Secure Hash Algorithm One SMTP Simple Mail Transfer Protocol SSL Secure Socket Layer SUN Sun Microsystems Inc. TAWIN An Image capturing API TCP Transport Control Protocol TIFF Tagged Image File Format UA User Agent VB Visual Basic WAN Wide Area Network XML Extensible Markup Language XOR Exclusive OR 73

References REFERENCES [1] Cryptography and network security principles and practice, 2 nd Edition by William Stallings, Prentice-Hall Inc., 1999, U. S. A. [2] A Handbook of Applied Cryptography, 4 th Edition by A. Menezes, P. van Oorschot and S. Vanstone, CRC press 1996, 2000 Corporate Blvd., N.W., Boca Raton, FL 33431, U. S. A. [3] Computer Networks, 3 rd Edition, by Andrew S. Tanenbaum, Prentice-Hall Inc., 1996, Upper Saddle River, New jersey 07458, U. S. A. [4] Computer Privacy handbook, 1 st Edition by Andre Bacard, Peachpit Press, 1995, Berkeley, CA, U. S. A. [5] Discrete Mathematics and its Applications, 4 th Edition by Kenneth H. Rosen, American Telephone and Telegraph Company AT&T Laboratories Division, 2000, McGraw-Hill Book Co. Singapore. [6] Data and Computer Communications, 5 th Edition by William Stallings, Prentice- Hall of India Private Limited, 1997, New Delhi -110 001. [7] Innovative Cryptographic Technologies Allow Faster Computation and Savings in Power, Memory and Bandwidth, SunNetwork 2002 Conference and Pavilion, September 18, 2002, SAN FRANCISCO. http://www.sun.com/smi/press/sunflash/2002-09/sunflash.20020918.17.html [8] What are elliptic curve cryptosystems?, RSA Laboratories frequently asked questions about today s cryptography 4.1, Copyright 2003 RSA Security Inc. http://www.rsasecurity.com/rsalabs/faq/3-5-1.html [9] Elliptic Curves Strong cryptography efficiently implemented by Uwe Krieger http://www.ecc-brainpool.org/art_spl.pdf [10] Introduction to Cryptography by Mark Vandenwauver, 1994, mark.vandenwauver@esat.kuleuven.ac.be [11] Basic Concepts in Data Encryption, Copyright 1999 ThinkQuest Team 27158 Developed for ThinkQuest 1999 http://www.geocities.com/arudyanto/encrypt/concept2_4.html 74

References [12] An Example of the RSA Algorithm, the Mathematical Guts of RSA Encryption, by Francis Litterio. http://world.std.com/~franl/crypto/rsa-example.html [13] Elliptic curve cryptography, FAQ v1.12, by George Barwood, 22-12-1997, george.barwood@dial.pipex.com http://www.cryptoman.com/elliptic.htm [14] LZSS Algorithm, Data Compression Reference Center Maintained and Copyrighted 1997 by Compression Team, compresswww@rasip.fer.hr http://www.rasip.fer.hr/research/compress/algorithms/fund/lz/lzss.html [15] AES/Rijndael, 2001-2003 SignalGuard International Ltd. 14 Leslie Hills Drive, Christchurch, New Zealand. info@signalguard.com. http://www.signalguard.com/encryption/aes-rijndael.htm http://www.javaworld.com/javaworld/jw-04-2000/jw-0428-aes_p.html [16] A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths, by Robert D. Silverman, RSA Laboratories, Number 2001, Copyright 2003 RSA Security Inc. http://www.rsasecurity.com/rsalabs/bulletins/bulletin13.html [17] FIPS PUB 186-2, FEDERAL INFORMATION, PROCESSING STANDARDS PUBLICATION, 2000 January 27, U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf [18] RSA vs. ECC by Ivan Leung, A Microcoded Elliptic Curve Cryptographic Processor, Tue Jun 5 2001. http://www.cse.cuhk.edu.hk/~khleung/thesis/node19.html [19] SIMPLE MAIL TRANSFER PROTOCOL, RFC 821, Network Working Group by J. Postel ISI August 1982, An Internet Encyclopedia http://www.freesoft.org/cie/rfc/821/index.htm [20] POP3, RFC 1939, Network Working Group, Category: Standards Track, J. Myers, Carnegie Mellon, M. Rose, Dover Beach Consulting, Inc., May 1996 http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1939.html [21] Uuencode, By Robert Dorsett, Copyright 2004 Apple Computer, Inc. http://www.mug.jhmi.edu/mirrors/infoalley/1195/14/description.html 75

References [22] RSAES-OAEP Encryption Scheme, Algorithm specification and supporting documentation, RSA Laboratories, RSA Security Inc., 20 Crosby Drive, Bedford, MA 01730 U. S. A. http://www.rsasecurity.com/rsalabs/rsa_algorithm/index.html [23] Padding Attacks on RSA, David Naccache, Published in Elsevier Information Security Technical Report, Gemplus Card International, 34 rue Guynemer, Issy-les- Moulineaux, F-92447, France, david.naccache@gemplus.com http://www.gemplus.com/smart/r_d/publi_crypto/pdf/nac00pad.pdf [24] ECC Math, Copyright Certicom Corp. 1997-2002. http://www.certicom.com/resources/ecc/math.html [25] RSA, RSA Security Inc http://www.rsa.com [26] PGP, Pretty Good Privacy Inc. http://www.pgp.com. [27] FileAssurity, A security software that protect your files, folders, documents, email attachments, Copyright 2001-2004 ArticSoft Limited. http://www.articsoft.com/products.htm [28] Jabber - the Jabber Software Foundation, Copyright 1999-2004. http://www.jabber.org [29] A Brief History of Cryptography by Anuj Seth http://www.anujseth.com/crypto/history.html [30] Transfer encoding, Documentation - Sun Software Product Internationalization Taxonomy, Copyright 1994-2003 Sun Microsystems, Inc. http://developers.sun.com/dev/gadc/des_dev/i18ntaxonomy/transferencod.html [31] Security of instant messaging, Thomas Herlea and Robert Maier. http://www.esat.kuleuven.ac.be/cosic/thesis/security-instant-messaging_en.html [32] Borzoi A library supporting Elliptic Curve routines, Dragongate Technologies Ltd. May 11, 2002 http://dragongate-technologies.com/products.html [33] GetMail and SendMail 2.0 A library for SMTP / POP3 by Davide Libenzi, Release Date 18-03-2000, davidel@xmailserver.org http://www.xmailserver.org 76

References [34] The LZ77 algorithm, Data Compression Reference Center, Maintained and Copyrighted 1997 by Compression Team, compresswww@rasip.fer.hr http://oldwww.rasip.fer.hr/research/compress/algorithms/fund/lz/lz77.html [35] UUencode public domain algorithm by Clem Dye, clem@bastet.com. ftp://ftp.simtel.net/pub/simtelnet/win95/fileutl/uue.zip [36] The Crypto++ 4.1 implementation of RSA used for only for comparison. http://www.eskimo.com/~weidai/cryptlib.html [37] Microsoft Foundation Classes http://www.microsoft.com/visualc 77