implementation of a secure messaging application...

IMPLEMENTATION OF A SECURE MESSAGINGAPPLICATION 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

i

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.

ii

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 011.2 Significance of a secure messaging application 021.3 Problem description 031.4 Objective 031.5 Methodology 041.6 Thesis Description with Technical details 04

Chapter 2 CRYPTOGRAPHY AND SECURITY CONCEPTS 06

2.1 Introduction 062.2 Classical Cryptography 072.3 Classical Cryptographic Techniques 07

2.3.1 Transpositions 072.3.2 Caesar Substitution 082.3.3 Monoalphabetic Substitution 08

2.4 Key-based Encryption 092.5 Cryptographic services 10

2.5.1 User Authentication 102.5.2 Data authentication 102.5.3 Data integrity 102.5.4 Data origin authentication 112.5.5 Non-repudiation of origin 112.5.6 Data confidentiality 11

2.6 Cryptographic primitives 122.7 Encryption primitives 12

2.7.1 Symmetric ciphers 122.7.2 Stream ciphers and block ciphers 132.7.3 Asymmetric ciphers 132.7.4 Symmetric versus asymmetric ciphers 14

2.8 Authentication primitives 142.8.1 One-way functions and hash codes 142.8.2 Digital signature 152.8.3 Hash functions versus digital signatures 15

2.9 Rivest Shamir Adleman (RSA) 162.9.1 RSA Example 16

2.10 Details of PGP 17

iii

Chapter 3 EMAIL PROTOCOLS AND ENCODING 19

3.1 Email protocols 193.2 SMTP 19

3.2.1 SMTP COMMUNICATION MODEL 203.2.2 A Typical SMTP Transaction Scenario 21

3.3 Post Office Protocol version 3 (POP3) 223.3.1 POP3 Basic Operation 223.3.2 POP3 Security Considerations 243.3.3 Example POP3 Session 24

3.4 Encoding and decoding mail messages 253.4.1 Requirement of encoding 263.4.2 Transfer Encoding 273.4.3 UUEncode and UUDecode Overview 273.4.4 Need of UUEncode 283.4.5 UUEncode Message format 28

Chapter 4 MATHEMATICAL BACKGROUND OF ECC 30

4.1 Elliptic curve 304.2 Group 304.3 The group Zn 304.4 Additive Inverses 314.5 Other operations 314.6 The group Zp* 314.7 Multiplicative Inverses 324.8 Abelian Groups 324.9 Field 324.10 The field Fp 334.11 The field F2

m 334.12 Polynomial Representation 334.13 Addition 344.14 Subtraction 344.15 Multiplication 344.16 Exponentiation 344.17 Multiplicative Inversion 344.18 Example - F2

4 with Polynomial Representation 344.19 Multiplicative Inversion 364.20 Use of Elliptic Curve 37

Chapter 5 THE SECURE MESSAGING APPLICATION 38

5.1 Key Generation 385.2 ECC Encryption Process 395.3 ECC Decryption Process 395.4 Importance of compression before encryption 40

Chapter 6 IMPLEMENTATION DETAILS 42

6.1 Libraries used 42

iv

6.2 System Requirements 426.3 Source Code 42

6.3.1 OnButtonGenerateKyes function 426.3.2 Calculation of Execution time 436.3.3 OnButtonEncrypt function 436.3.4 OnButtonDecrypt function 496.3.5 RSA implementation of Crypto++ 53

Chapter 7 THE FRONT END TO ECC AND RSA 54

7.1 The ECC GUI 547.2 The RSA GUI 557.3 Opening the attachment in outlook 56

Chapter 8 RESULTS AND OBSERVATIONS 58

8.1 ECC results 588.2 RSA results 598.3 Comparison of ECC and RSA 628.4 Relative cost of equivalent key sizes in RSA and ECC 638.5 Important considerations 65

Chapter 9 CONCLUSION AND FUTURE EXTENSIONS 66

9.1 Conclusion 669.2 Proposed Future extensions of the application 67

Appendix A TOOLS AND LIBRARIES 68

Appendix B ACRONYMS USED 70

References 72

v

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

vi

LIST OF TABLES

Table 4.1: 16 vectors for F24 [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

vii

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.

Chapter 1. Introduction

2

Chapter 1

INTRODUCTION1.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.


3

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


4

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 descriptionEmail 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 ObjectiveGoal 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.


5

1.5 MethodologyThe 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 detailsThesis 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.

CoreEncryption /Decryption

Engine.

EncryptedFile

OutgoingSMTPemail

Outgoinginstant

message

IncomingPOPEmail

IncomingInstant

Message

Public Keys

PrivateFiles

ScannedFile

(TWAIN)

OCR

GraphicalUser Interface

(GUI)

Figure 1.3 Pictorial representation of Secure Messaging System


6

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.

Chapter 2.Cryptography and security concepts

7

Chapter 2

CRYPTOGRAPHY AND SECURITY CONCEPTS2.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.


8

2.2 Classical CryptographyClassical 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 TechniquesThere 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 TranspositionsTransposition 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


9

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 SubstitutionThe 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 SubstitutionA 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


10

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


11

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 integrityA 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.


12

2.5.4 Data origin authenticationHere 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].

Block MessageAlice Bob

Intruder

Figure 2.3 Data origin authentication.

2.5.5 Non-repudiation of originNon-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

Bob

Figure 2.4 Non-repudiation of origin.

2.5.6 Data confidentialityThis 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].


13

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

Figure 2.5 Data confidentiality.

2.6 Cryptographic primitivesThe 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 primitivesIn 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


14

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 ciphersThere 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 ciphersPublic 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


15

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 ciphersThe 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 codesA 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.


16

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 signaturePublic 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.


17

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 ExampleAn 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.


18

The encryption function is:

encrypt(T) = (TE) mod PQ

= (T17) mod 3233

The decryption function is:

decrypt(C) = (CD) mod PQ

= (C2753) mod 3233

To encrypt the plaintext value 123, do this:

encrypt(123) = (12317) mod 3233

= 337587917446653715596592958817679803 mod 3233

= 855

To decrypt the ciphertext value 855, do this:

decrypt(855) = (8552753) mod 3233

= 123

2.10 Details of PGPPGP 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.


19

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.

Chapter 3. Email protocols and encoding

20

Chapter 3

EMAIL PROTOCOLS AND ENCODING3.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 SMTPSMTP 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.


21

3.2.1 SMTP COMMUNICATION MODELIn 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.

SenderSMTP

FileSystem

User

ReceiverSMTP

SMTP Commands

SMTP Replies FileSystem

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.


22

3.2.2 A Typical SMTP Transaction ScenarioFollowing 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:<[email protected]>

R: 250 OK

S: RCPT TO:<[email protected]>

R: 250 OK


R: 550 No such user here


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'


23

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 OperationInitially, 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.


24

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.


25

3.3.2 POP3 Security ConsiderationsIt 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 SessionIn 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 <[email protected]>

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: .


26

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 Server

Workstation1

Network Switch

Workstation 2

Email sent by workstation receivedby server using SMTP

Email is requested from server byclient using POP3

Figure 3.2 SMTP and POP3 in action.

3.4 Encoding and decoding mail messagesEmail 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


27

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


28

publishing files; spreadsheets; databases; and sounds or graphical images (e.g. SND,

AU, GIF, JPEG, MOV, or MPG files).

3.4.2 Transfer EncodingA 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

RestrictedInterface

RestrictedInterface

Decoder

Figure 3.3 Transfer encoding.

3.4.3 UUEncode and UUDecode OverviewBasically 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-


29

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 UUEncodeThe 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 formatThere 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


30

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.

Chapter 4. Mathematical background of ECC

31

Chapter 4

MATHEMATICAL BACKGROUND OF ECCIn 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]:

(x-a) 2 + (y-b) 2 =

r2

(4.1)

where x, y, a, b and r are real numbers.

An elliptic curve is also defined by an equation, but it has the slightly more

complicated form: [13]

y2 [+ x·y] = x3 + a·x2 + b (4.2)

Notation: · means multiplication, y2 means y·y and x3 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 GroupA 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 Zn, the additive group of

integers modulo a number n; and Zp*, the multiplicative group of integers modulo a

prime number p.

4.3 The group Zn


32

The group Zn 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 Z15 uses the integers from 0 to 14. Here are some sample

additions in Z15:

(10 + 12) mod 15 = 22 mod 15 = 7

(4 + 11) mod 15 = 15 mod 15 = 0

In Z15, 10 + 12 = 7 and 4 + 11 = 0. Notice that both calculations have answers

between 0 and 14.

4.4 Additive InversesEach 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 Z15, -4 = 11 since

(4+11) mod 15 = 15 mod 15 = 0.

4.5 Other operationsWhile 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 Z15, 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 Z15 can be achieved by adding together 9 + 9 + 9 + 9 mod 15 =

36 mod 15 = 6.

4.6 The group Zp*

Cryptosystems using arithmetic in Zp* include the Diffie-Hellman Key

Agreement Protocol and the Digital Signature Algorithm (DSA). The multiplicative

group Zp* 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 Z11* uses the integers

from 1 to 10. Multiplication in Z11* finishes by taking the remainder when the result is

divided by 11. Here are some examples of multiplication in Z11*:

4 * 7 mod 11 = 28 mod 11 = 6


33

9 * 5 mod 11 = 45 mod 11 = 1.

Thus in Z11*, 4 * 7 = 6 and 9 * 5 = 1. Notice that both the calculations shown have

answers between 1 and 10.

4.7 Multiplicative InversesEach 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 Z11*, 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 GroupsAn 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 Zn and the multiplicative group Zp* are both abelian groups.

4.9 FieldA 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 non-

zero elements have a multiplicative inverse. As is true for groups, other operations

can be defined in a field, using its main two operations.


34

A field is called finite if it has a finite number of elements. The most

commonly used finite fields in cryptography are the field Fp (where p is a prime

number) and the field F2m.

4.10 The field Fp

The finite field Fp (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 Zn

and Zp* 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 Zp* for details). As with Zn and Zp*, other operations in Fp

(such as division, subtraction and exponentiation) are derived from the definitions of

addition and multiplication. Calculations in the field F23 include

10* 4 - 11 mod 23

= 29 mod 23

= 6

7-1 mod 23

= 10

since

7*10 mod 23

= 70 mod 23

= 1

(83) / 7 mod 23

= 512 / 7 mod 23

= 6* 7-1 mod 23

= 6*10 mod 23

= 14.

4.11 The field F2m

Although the description of the field F2m is complicated, this field is extremely

useful because its computations can be done efficiently when implemented in

hardware. Over here arithmetic in F2m; is described by polynomial representation.

4.12 Polynomial Representation


35

The elements of F2m are polynomials of degree less than m, with coefficients

in F2; that is, {am-1xm-1 + am-2xm-2 + ... + a2x2 + a1x + a0 | ai = 0 or 1}. These elements

can be written in vector form as (am-1 ... a1 a0). F2m has 2m elements.

The main operations in F2m are addition and multiplication. Some computations

involve a polynomial f(x) = xm + fm-1xm-1 + fm-2xm-2 + ... + f2x2 + f1x + f0, where each fi is

in F2. The polynomial f(x) must be irreducible [2]; that is, it cannot be factored into

two polynomials over F2, each of degree less than m.

4.13 Addition(am-1 ... a1 a0) + (bm-1 ... b1 b0) = (cm-1 ... c1 c0) where each ci = ai + bi over F2.

Addition is just the componentwise XOR of (am-1 ... a1 a0) and (bm-1 ... b1 b0).

4.14 SubtractionIn the field F2

m, each element (am-1 ... a1 a0) is its own additive inverse, since

(am-1 ... a1 a0) + (am-1 ... a1 a0) = (0 ... 0 0), the additive identity. Thus addition and

subtraction are equivalent operations in F2m.

4.15 Multiplication

(am-1 ... a1 a0) (bm-1 ... b1 b0) = (rm-1 ... r1 r0) where rm-1xm-1 + ... + r1x + r0 is the

remainder when the polynomial (am-1xm-1 + ... + a1x + a0) (bm-1xm-1 + ... + b1x + b0) is

divided by the polynomial f(x) over F2. (Note that all polynomial coefficients are

reduced modulo 2.)

4.16 Exponentiation

The exponentiation (am-1 ... a1 a0)e is performed by multiplying together e

copies of (am-1 ... a1 a0).

4.17 Multiplicative InversionThere exists at least one element g in F2

m such that all non-zero elements in

F2m can be expressed as a power of g. Such an element g is called a generator of F2

m.

The multiplicative inverse of an element a = gi is a-1 = g(-i) mod (2m-1).

4.18 Example - F24 with Polynomial Representation

The elements of F24 are the 16 vectors:

(0000) (0001) (0010) (0011) (0100) (0101) (0110) (0111)(1000) (1001) (1010) (1011) (1100) (1101) (1110) (1111).

Table 4.1 16 vectors for F24


36

The irreducible polynomial used will be f(x) = x4 + x + 1. The following are

sample calculations.

Addition

(0110) + (0101) = (0011).

Multiplication

(1101) (1001)

= (x3 + x2 + 1) (x3 + 1) mod f(x)

= x6 + x5 + 2x3 + x2 + 1 mod f(x)

= x6 + x5 + x2 + 1 mod f(x) (coefficients are reduced modulo 2)

= ( x4 + x + 1)(x2 + x) + (x3 + x2 + x + 1) mod f(x)

[Note that (x6 + x5 + x2 + 1)/( x4 + x + 1) = (-x3 - x2 - x + 1) ]

= x3 + x2 + x + 1

= (1111).

Exponentiation

To compute (0010)5, first find

(0010)2

= (0010) (0010)

= x x mod f(x)

= ( x4 + x + 1)(0) + (x2) mod f(x) [ as x2 can not be divided by ( x4 + x + 1) ]

= x2

= (0100).

Then

(0010)4

= (0010)2 (0010)2

= (0100) (0100)

= x2 x2 mod f(x)

= ( x4 + x + 1)(1) + (x + 1) mod f(x) [as (x4)/ ( x4 + x + 1) = -x-1 ]

= x + 1

= (0011).


37

Finally, (0010)5

= (0010)4 (0010)

= (0011) (0010)

= (x + 1) (x) mod f(x)

= (x2 + x) mod f(x)

= ( x4 + x + 1)(0) + (x2 + x) mod f(x) [because (x2 + x) can not be divided by ( x4 + x

+ 1) ]

= x2 + x

= (0110).

4.19 Multiplicative InversionThe element g = (0010) is a generator for the field. The powers of g are:

g0 = (0001) [20 = 1]

g1 = (0010) [21 = 2]

g2 = (0100) [22 = 4]

g3 = (1000) [23 = 8]

g4 = (0011) [24 = 16, 16 = (10000)2 =x4 , (x4)/ ( x4 + x + 1) = -x-1= (0011)]

g5 = (0110)

g6 = (1100)

g7 = (1011)

g8 = (0101)

g9 = (1010)

g10 = (0111)

g11 = (1110)

g12 = (1111)

g13 = (1101)

g14 = (1001)

g15 = (0001).

The multiplicative identity for the field is g0 = (0001). The multiplicative inverse of g7

= (1011) is given by:

g-7 mod 15 = g8 mod 15 [as 15-7=8]

=g8= (0101).


38

To verify this, see that

(1011) (0101)

= (x3 + x + 1) (x2 + 1) mod f(x)

= x5 + x2 + x + 1 mod f(x)

= ( x4 + 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

x2 = x.x

x3 = 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 (non-

secret) 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.


39

The security of the scheme is based on the assumption that it is difficult to compute k

given F.

Chapter 5

THE SECURE MESSAGING APPLICATIONIn 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 GenerationFor 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.

Chapter 5. The secure messaging application

40

ECC KeyGeneration

Public Key

Private Key

Internet

Public KeyStore (Key

Server / HDD)

ECC KeyGeneration

Public Key

Private Key

Sender Receipient

Figure 5.1 ECC key generation and exchange of public keys.

5.2 ECC Encryption ProcessOur 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.


41

Plain text AESEncrypt

ECC PublicKey

LZSSCompress

Internet

UU Encode

SMTPECC

Session Key Random Key

Figure 5.2 ECC encryption.

5.3 ECC Decryption Process

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.

UU Encodedmessage

UU Decode

Compresseddata

Internet

LZSSDecompress

Plain textECC

EncryptedSession Key

ECC PrivateKey

ECC Plain sessionKey

AESEncrypted

Data

AES Decrypt

Figure 5.3 ECC decryption.

5.4 Importance of compression before encryptionIn 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


42

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.


43

Chapter 6

IMPLEMENTATION DETAILSThis 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 usedFor 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 RequirementsMinimum 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.)

Chapter 6. Implementation details

44

Although the test results are generated on Pentium 4 (Dell optiplex GX 240) system

having 256 MB RAM, 20 GB HDD.

6.3 Source CodeAlthough 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 functionOnButtonGenerateKeys() 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;

}


{


}


{




45

{


}


{


}

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) {


return;

}

key_outfile2 << HexEncoder(sk_der_encoding);

key_outfile2.close();


46



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);



logBuff01 = "---------==========---------\r\n";



EndWaitCursor();

}

6.3.2 Calculation of Execution timeFirst 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()

{


47

BeginWaitCursor();

SYSTEMTIME st1,st2;



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++) {


48

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) {



49

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);



return;

}

cypher_outfile1 << cyphertext_der_encoded;


FILE *f;

f =

fopen(m_EditCypherTextFile.GetBuffer(m_EditCypherTextFile.GetLength()),"wb");

if (f == NULL) {

printf("Impossible to open cipheruue.txt\n");

}

uuencode(f,"cipher-without-uue.txt");

fclose(f);

std::ofstream cypher_outfile2 ("sessionkey.txt", std::ios::binary);



return;

}


50

cypher_outfile2 << HexEncoder(session_key_der_encoded);


DeleteFile("lzss-comp-a.txt");

DeleteFile("cipher-without-uue.txt");

DeleteFile("plain-session.txt");



st2.wMilliseconds;




CString logBuff01;

logBuff01 = "----------";



logBuff01 += "---------\r\n";



logBuff01.Format("Time to Encrypt : %d milliseconds.\r\n", ms02-ms01);



logBuff01 = "---------==========---------\r\n";



EndWaitCursor();

}

6.3.4 OnButtonDecrypt functionvoid CECCDlg::OnButtonDecrypt()

{


51

BeginWaitCursor();

SYSTEMTIME st1,st2;



st1.wMilliseconds;

UpdateData(1);

CString PrivKeyStr;

LONG InBytes;

int NumberCharecters;

void* InBuffer;

CFile InFile1(m_EditPrivateKeyFile,CFile::modeRead);




AfxMessageBox("Insufficient memory available for

m_EditPrivateKeyFile");

else

{



}

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];

}


52

DER sk_der = privKeyVectorRead;

ECPrivKey sk = sk_der.toECPrivKey();

CString SessKeyStr;

CFile InFile2("sessionkey.txt",CFile::modeRead);




AfxMessageBox("Insufficient memory available for sessionkey.txt");

else

{



}

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;


53

}

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);


54

std::ofstream plain_text_outfile1 ("lzss-comp-b.txt" , std::ios::binary);

if (!plain_text_outfile1) {


return;

}

plain_text_outfile1 << compressed_plaintext_der_encoded;

plain_text_outfile1.close();

OnButtonUncompress();

DeleteFile("lzss-comp-b.txt");

DeleteFile("cipher-without-uue.txt");



st2.wMilliseconds;




CString logBuff01;

logBuff01 = "----------";



logBuff01 += "---------\r\n";



logBuff01.Format("Time to Decrypt : %d milliseconds.\r\n", ms02-ms01);



logBuff01 = "---------==========---------\r\n";



EndWaitCursor();

}

6.3.5 RSA implementation of Crypto++


55

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 RSAIn 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 GUIAfter 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.

Chapter 7. The front end to ECC and RSA

56

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.

Figure 7.2 The ECC dialog box.

7.2 The RSA GUI

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.


57

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.


58

Figure 7.5 RSA encryption - decryption.

7.3 Opening the attachment in outlookWhen 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.


59

Figure 7.6 Email in Outlook

Chapter 8

RESULTS AND OBSERVATIONS

Chapter 8. Results and observations

60

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 resultsIn 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 generationtime (milli sec.)

Encryption time(milli sec.)

Decryption time(milli sec.)

NIST 163 125 265 250NIST 233 328 578 500NIST 283 328 922 922NIST 409 704 1953 1781NIST 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.


61

0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

NIST 163 bit NIST 233 bit NIST 283 bit NIST 409 bit NIST 571 bit

Key generation time (milli seconds)

Encription time (milli seconds)Decription time (milli seconds)

time

(ms)

Figure 8.1 ECC key generation, encryption and decryption cost.

8.2 RSA resultsIn 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.


62

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 11024 bits 15 86 152048 bits 15 214 784096 bits 15 470 4388192 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.

0

500

1000

1500

2000

2500

3000

512 bits 1024 bits 2048 bits 4096 bits 8192 bits

Encryption time (milli sec)

data size (bytes)

Decryption time (milli sec)

time

(ms)

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


63

1024 bits 1412048 bits 5314096 bits 638448192 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)

0

20000

40000

60000

80000

100000

120000

140000

512 bits 1024 bits 2048 bits 4096 bits 8192 bits

time

(ms)

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.


64

512 bits1024 bits

2048 bits4096 bits

8192 bits

Key generation time(milli sec)

0

20000

40000

60000

80000

100000

120000

Key generation time(milli sec)Key generation time(milli sec)

Figure 8.4 RSA key generation cost

8.3 Comparison of ECC and RSAThe 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 generationtime (ms)

Encryption time (ms) Decryption time (ms)

NIST 163 291 521 470NIST 233 530 112 2 1082NIST 283 731 2013 2053NIST 409 1563 4396 4026NIST 571 3695 11206 11858Table 8.4 ECC key generation, encryption and decryption cost (22 bytes)

Key length (bits) Key generationtime(ms)

Encryption time (ms) Decryption time (ms)

512 bits 100 30 301024 bits 370 30 502048 bits 4736 20 1104096 bits 10224 30 5318192 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

time

(ms)


65

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)

0100200300400500600

ECC keygeneration

ECCencryption

ECCdecryption

RSA keygeneration

RSAencryption

RSAdecryption

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

SymmetricKey

ECCKey RSA Key Time to Break Memory

56 112 430 less than 5 minutes Trivial80 160 760 600 months 4 Gb96 192 1020 3 million years 170 Gb128 256 1620 1016 yrs 120 TbTable 8.6 Relative cost of equivalent key sizes in RSA and ECC


66

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.

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

RSA

ECC

1E+36Time to break (MIPS years)

Key

siz

e (b

its)

1E+201E+121E+810000

1000

0

7000

6000

5000

4000

3000

2000


67

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.

Chapter 9. Conclusion and future extensions

68

Chapter 9

CONCLUSION AND FUTURE EXTENSIONSElliptic 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 ConclusionThe 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.

Chapter 9. Conclusion and future extensions

69

9.2 Proposed Future extensions of the applicationAlthough 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.

Appendix A

70

Appendix A

TOOLS AND LIBRARIESFor 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 (F2m).

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

Appendix A

71

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 3rd 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

Appendix B

72

Appendix B

ACRONYMS USEDAPI Application Programming InterfaceAES Advanced Encryption StandardAPOP Authenticated Post Office ProtocolASCII American Standard Code for Information InterchangeASN.1 Abstract Syntax Notation OneATM Automatic Teller MachineBASR Board of Advanced Studies and ResearchBDS UNIX UNIX version developed at the University of California,

BerkeleyCOM Component Object ModelCPU Central Processing UnitCRLF Carriage Return Line FeedDER Distinguished Encoding RulesDES Data Encryption StandardDOS Disk Operating SystemDSA Digital Signature AlgorithmECC Elliptic Curve CryptographyECIES Elliptic Curve Integrated Encryption SchemeEMAIL Electronic MailERR ErrorFAQ Frequently Asked QuestionFIPS Federal Information Processing StandardGB GigabyteGIF Graphical Interchange FormatGUI Graphical User InterfaceHDD Hard Disk DriveIP Internet ProtocolIPCE Interprocess Communication EnvironmentARPANET Advanced Research Projects Agency NetworkIT Information TechnologyJPEG Joint Photographic Experts GroupLAN Local Area NetworkMAC Message Authentication CodeMB Mega ByteMDC Manipulation Detection CodeMHz MegahertzMIT Massachusetts Institute of TechnologyMIPS Million Instructions per SecondMTS Message Transport SystemNIST National Institute of Standards and TechnologyOAEP Optimal Asymmetric Encryption Padding

Appendix B

73

PC Personal ComputerPGP Pretty Good PrivacyPIN Personal Identification NumberPKI Public Key InfrastructurePOP Post Office ProtocolPOP3 Post Office Protocol version 3RAM Random Access MemoryRETR RetrieveROM Read Only MemoryRSA Rivest Shamir AdlemanRSAES-OAEP RSA Encryption Scheme - Optimal Asymmetric Encryption

PaddingSHA-1 Secure Hash Algorithm OneSMTP Simple Mail Transfer ProtocolSSL Secure Socket LayerSUN Sun Microsystems Inc.TAWIN An Image capturing APITCP Transport Control ProtocolTIFF Tagged Image File FormatUA User AgentVB Visual BasicWAN Wide Area NetworkXML Extensible Markup LanguageXOR Exclusive OR

References

74

REFERENCES

[1] Cryptography and network security principles and practice, 2nd Edition by William

Stallings, Prentice-Hall Inc., 1999, U. S. A.

[2] A Handbook of Applied Cryptography, 4th 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, 3rd Edition, by Andrew S. Tanenbaum, Prentice-Hall Inc.,

1996, Upper Saddle River, New jersey 07458, U. S. A.

[4] Computer Privacy handbook, 1st Edition by Andre Bacard, Peachpit Press, 1995,

Berkeley, CA, U. S. A.

[5] Discrete Mathematics and its Applications, 4th 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, 5th 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,

[email protected]

[11] Basic Concepts in Data Encryption, Copyright 1999 ThinkQuest Team 27158 —

Developed for ThinkQuest 1999

http://www.geocities.com/arudyanto/encrypt/concept2_4.html

References

75

[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,

[email protected]

http://www.cryptoman.com/elliptic.htm

[14] LZSS Algorithm, Data Compression Reference Center Maintained and

Copyrighted 1997 by Compression Team, [email protected]

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. [email protected].

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

References

76

[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, [email protected]

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, [email protected]

http://www.xmailserver.org

References

77

[34] The LZ77 algorithm, Data Compression Reference Center, Maintained and

Copyrighted 1997 by Compression Team, [email protected]

http://oldwww.rasip.fer.hr/research/compress/algorithms/fund/lz/lz77.html

[35] UUencode public domain algorithm by Clem Dye, [email protected].

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

implementation of a secure messaging application...

Documents