1. 1
PASSWORD AUTHENTICATED KEY
EXCHANGE PROTOCOL (PAKE)
Thivya Devaraj
Student ID: 14023164
Supervised By: Dr. Richard Conway
Thesis submitted to the faculty of The University of Limerick, September 2015
in partial fulfillment of the requirements for the degree of
MASTER OF ENGINEERING
IN
INFORMATION AND NETWORK SECURITY

2. 2
Declaration
This dissertation is an original work and is a consequence of the original efforts
and research of the author. This work does not contain previously published
material, knowledge from any other author or entity, except where due reference or
acknowledgement has been provided. Further, this work has not been submitted for
any prior academic award or recognition.
- Thivya Devaraj
September 2015

3. 3
Acknowledgements
In this section I would like to acknowledge all the people named and unnamed
below, who helped in the completion of this dissertation and supported me
throughout the way.
I would firstly like to specially thank my supervisor Dr Richard Conway for
giving me the opportunity to work on this dissertation, his valuable feedback and
support, encouragement and also for directing me towards the right direction at
times when my mind was in a state of chaos.
I would also like to heartily thank my parents, Devaraj Packriswamy and, Padmini
Devaraj my family Pepper and Candy for their love, support and encouragement
throughout to keep me going.
I would also like to thank Mohamed Amrutheen Samsudeen for his suggestions,
feedbacks, encouragement, support and patience throughout this process to help
me complete the research and the dissertation.

4. 4
ABSTRACT
Password Authenticated Key Exchange (PAKE) protocol was designed to
establish a secure communication between two parties exchanging a secret key based on a shared
password. Public key cryptography was used in this paper to establish a mutually generated
session/secret key which was later used with the symmetric key encryption method to generate a
public key by encrypting the secret key along with the shared password. The protocol also
performs hashing algorithm which ensure the user from the data being changed or altered by
providing data integrity and data confidentiality. PAKE was designed in such a way that it
facilitates the user to share a simple non alpha numeric password. Nowadays, users are forced to
provide a strong password that contains alpha numeric values, capital letters and some special
characters which is generally hard to remember. They are mainly enforced to do so, to prevent
their communication from being spoofed by an attacker/intruder. Hence the password
authenticated key exchange (PAKE) protocol was designed to ensure a high level of security to
two parties communicating using a shared password.

5. 5
Table of Contents
1. INTRODUCTION........................................................................................8
2. LITERATURE REVIEW ............................................................................10
2.1 Proposed Method..................................................................................14
3. ALGORITHMS IMPLEMENTED ..............................................................16
3.1 The RSA Algorithm..............................................................................16
3.2 Advanced Encryption Standard (AES) ...................................................18
3.2.1 Structure of AES.............................................................................18
3.2.2 Detailed AES Structure....................................................................20
3.3 HASHING ALGORITHM ....................................................................22
3.3.1 Secure Hash Algorithm: (SHA-1) ....................................................24
4. REVIEWING THE ENCRYPTED KEY EXCHNAGE PROTOCOL............25
4.1 Implementation of RSA algorithm in EKE Protocol................................25
4.1.1 Advantage of sending “n” as a clear text form ..................................27
4.2 Implementation of ElGamal algorithm in EKE protocol..........................27
4.3 Complete EKE Protocol: .......................................................................30
4.3.1 Applications of EKE protocol..........................................................31
5. IMPLEMENTATION OF PAKE PROTOCOL............................................33
5.1 NetBeans IDE and JAVA ......................................................................33
5.2 Software Implementation.......................................................................34
6. RESULT ....................................................................................................42

6. 6
7. CONCLUSION & FUTURE ENHANCEMENT..........................................47
7.1 Conclusion............................................................................................47
7.2 Future Enhancement..............................................................................47
8. REFERENCE:............................................................................................48
9. APPENDIX A- CODING............................................................................50
9.1 Client Side............................................................................................50
9.2 Server Side ...........................................................................................62
Figures
Figure 3.1: Encryption process of AES algorithm. ..............................................19
Figure 3.2: Encryption and Decryption process of AES. .....................................21
Figure 3.3: Hash Fuction. ..................................................................................23
Figure 5.1: Command prompt for establishing server’s connection......................34
Figure 5.2: Command prompt for establish client’s connection ...........................34
Figure 5.3: Highlighting the client’s jar file address............................................35
Figure 5.4: Highlighting the server’s jar file address...........................................35
Figure 5.5: Initializing communication at the server end. ...................................36
Figure 5.6: Initializing communication at the client side. ....................................36
Figure 5.7: Menu Pop-up Box............................................................................37
Figure 5.8: Communication at the client side......................................................37
Figure 5.9: Communication at the Server end. ....................................................38
Figure 5.10: Terminating the communication at the client side............................39
Figure 5.11: Terminating the communication at the server’s side. .......................39

7. 7
Figure 5.12: Menu Pop-up Box..........................................................................40
Figure 5.13: Pop-up menu to enter file’s path.....................................................40
Figure 5.14:Pop-up box for providing name and destination address for the
encrypted file....................................................................................................40
Figure 5.15: File Encryption performed .............................................................41
Figure 5.16: Pop-up Menu.................................................................................41
Figure 6.1: String encryption at the client’s end..................................................42
Figure 6.2: String encryption at the server side. ..................................................42
Figure 6.3: File moved ......................................................................................43
Tables
Table 3.1:Parameters of AES.............................................................................20
Table 3.2: Necessary function used to perform hashing operation and their
description........................................................................................................23
Table 6.1: The following table depicts the different types of algorithms used in
each paper discussed in the literature review. .....................................................43

8. 8
CHAPTER 1
1. INTRODUCTION
In the real world of communication over the internet, it is important to notice that
our communication is secured. To secure a conversation, one must use a key that is known to
both the parties. Passwords are one of the main key sources to prevent a communication between
two parties which should be shared among both the users before initializing their
communication. Cryptographic methods assure the users to communicate over the network
securely by providing security to the passwords through implementing various algorithmic
schemes in which the password is protected by encrypting the plaintext, where this coded text is
known as ciphertext.
Cryptography consists of two different encryption methods such as symmetric key encryption
and asymmetric key encryption or public key cryptography. In symmetric encryption scheme it
uses only a single key for both encryption and decryption process.
The symmetric encryption method has the five components such as,
Plaintext: It is the original understandable message that is given as an input to the algorithm.
Encryption Algorithm: It implements various substitution and permutation algorithms on the
plaintext.
Secret Key: The secret key is fed as an input to the encryption algorithm depending on which
the substitution and permutation operations are performed to produce the output.
Ciphertext: It is a non-understandable scrambled output message which depends on the
plaintext and secret key.
Decryption Algorithm: It performs the inverse function of the encryption algorithm to decode
the ciphertext using secret key to obtain the original plaintext message.
There are few advantages and disadvantages in using the symmetric key encryption
technique and hence the public key cryptography or asymmetric key encryption is used to

9. 9
overcome those problems. In the asymmetric key encryption method two different keys are used
such as public and private key. The public key is common and is shared between both the users
whether as the private key is kept unshared by the users and is used by them while decrypting the
message. In asymmetric key encryption six factors are used to implement the operation,
Plaintext: It is the original understandable message that is given as an input to the algorithm.
Encryption Algorithm: It implements various substitution and permutation algorithms on the
plaintext.
Public and Private Key: These keys are used to perform encryption and decryption process. If
the public key is used for encryption then private key is used to decrypt the text and vice versa.
Ciphertext: It is a non-understandable scrambled output message which depends on the
plaintext and secret key.
Decryption Algorithm: It performs the inverse function of the encryption algorithm to decode
the ciphertext using secret key to obtain the original plaintext message [17].
Even though the passwords are protected using these various factors, the attackers find their own
method to spoof the passwords. Therefore, nowadays users are instructed to keep strong alpha
numeric passwords that prevents from dictionary and other types of attacks. However
remembering such hard passwords by the users is difficult as human-being mostly choose bad
passwords or forget them. Hence the password authenticated key exchange (PAKE) protocol is
introduced in which two parties can communicate by sharing a simple passwords say four
lettered. In this project both the symmetric and asymmetric key encryption techniques are used to
design the password authenticated key exchange protocol. The Advanced Encryption standard
(AES) was used to perform symmetric encryption and the asymmetric encryption technique was
performed using RSA and Hashing (Secure Hash Algorithm) was used to provide data integrity.

10. 10
CHAPTER 2
2. LITERATURE REVIEW
In the year 1992, Steven M Bellovin and Michael Merritt published a paper
“Encrypted Key Exchange: Password Based protocols secure against dictionary attacks” in
which they explained how two parties share a password provided a symmetric session key over
an insecure public networks by implementing RSA and ElGamal schemes. Further details
regarding this paper were discussed elaborately in the later sections as this EKE is the
background for the password authenticated key exchange protocol that is implemented in this
project [1].
Later in 1993, Bellovin and Merritt published another paper “Augmented EKE: a
password based protocol secure against dictionary attacks and password file comparison” here
the EKE protocol is augmented through which the passwords are not stored in a clear text format
in the host. As mentioned in the 1992 paper that it is not recommended to store the passwords in
a plaintext format, in 1993 they instead used a one way hashing function H(P) to store each and
every user’s password P. Later the password validation is achieved by performing the one way
hash function on H(P’) with the password P’ and verification is done with the stored password
from the users. In the augmented EKE protocol two different methods are implemented such as
public key cryptography, digital signature and also using a one-way hash functions. This paper
was also very keen focusing on the password to be protected against dictionary type of attacks
which are mostly successful in spoofing the shared password. Therefore with the help of an
augmented EKE protocol there is no necessity of a trusted third party instead an operating
system’s file protection technique is used to protect the hashed passwords, whereas the new
protocol is used to prevent the passwords from remote users [2].
Victor Boyko, Philip Mackerzie and Sarvar Patel researched “Provably Secure Password
Authenticated Key Exchange using Diffie Hellman” in 2000, by using a new protocol PAK
which uses Diffie-Hellman based password authenticated key exchange protocol to afford
security against active and passive attackers. This protocol is introduced to prevent the
information from an attacker who can be able to run an off-line dictionary attack to obtain the

11. 11
original password. The PAK protocol affords a mutual explicit authentication and hence they
also implemented another more efficient protocol PPK which affords implicit authentication. In
this PAK protocol the client stores the plaintext password whereas the server stores a verifier for
the password which is denoted as a PAK-X protocol. This protocol has a fewer rounds to
implement, it is theoretically simpler with a simple proofs and they do not need the RSA
algorithm for implementation rather uses the Diffie-Hellman problem [3].
Mihir Bellare, et.al in the same year 2000 published a paper “Authenticated key exchange
secure against dictionary attacks” in which they provide definiteness to the EKE protocol
proposed by Bellovin and Merritt. This protocol works against the use of passwords that are
spoofed by the attacker, offline, all possible passwords. In this paper, they determine the basic
idea of Encrypted Key Exchange (EKE) protocol suggested by Bellovin and Merritt in which
they justify the security issues implemented using the two protocols in EKE using the Diffie
Hellman key exchange method [4]. Jonathan Katz, et.al published a paper “Efficient Password
Authenticated Key Exchange using Human Memorable Passwords” in the year 2001, in which
they used a three round PAKE protocol which shares a human memorable passwords. This
protocol is proved to be secure when implemented using decisional Diffie-Hellman method
which needs eight times more computational work than the original standard Diffie-Hellman key
exchange protocol to make the security still stronger. This paper is very much concerned in
providing efficiency and security to the PAKE which is successfully achieved [5].
In 2002, Benny Pinkas and Tomas Sander released a paper “Securing Passwords against
Dictionary Attacks” by suggesting an authentication method that protects the traditional
password authentication by simultaneously evoking a challenge that is answerable by humans,
but unattainable for programs trying to attack the passwords using dictionary attack and denial of
service attack. During a dictionary attack the adversaries try to login to an account by trying all
the possible passwords. In this paper they introduced a new security protocol known as Reverse
turning test (RTT) which is easier for the human users to perform, yet difficult for an automated
attacker to answer correctly in the test with a feasibility of better guessing. This scheme provides
a better standard of security for the users from adversaries and is used by many standard web
browsers [6].

12. 12
Jin Wook Byun, Ik Rae Jeong, et.al proposed a paper “Password Authenticated Key
Exchange between clients with Different Passwords” in 2002 proposed a new scheme called
Client-to-Client Password Authenticated Key Exchange (C2C-PAKE) which is based on two
asymmetric passwords without any shared secret key. In this paper they proved this method to be
secured against online and offline dictionary attacks, Kerberos attack, man in the middle attack,
replay attack, Denning-Sacco and perfect forward secrecy attacks. They used a C2C-PAKE in a
cross-realm setting known as Fake Ticket Protocol which is then integrated with the Kerberos
realm that consists of an authentication server and Ticket Granting Server to provide security and
also reduces communication intricacy [7].
Further in the year 2004, Shuhong wang, Jie Wang and Maozhi Xu published a paper
“Weaknesses of a Password Authenticated Key Exchange Protocol between Clients with
Different Passwords” in which they explained the weakness that they analyzed from the previous
paper published by Byun et al. in which the protocol obtains a secret session key from two
different clients. In this paper they analyzed that the protocol proposed by Byun et al. is insecure
because of the parameters. They also demonstrated the flaw that they researched in Byun et al.
paper using three different types of attacks such as dictionary attack, forward secrecy and
eavesdrop to prove the in-secureness. To overcome this problem they proposed few counter
measures that reduced the occurrence of possible attacks [8].
Michel Abdalla & David Pointcheval released a paper “Simple Password based
Encrypted Key Exchange Protocols” in 2005 proposed two simple password based EKE
protocols subject to Bellovin and Merritt’s proposal. They designed one protocol to share
passwords among different servers and the other protocol is used to provide security. These two
protocols are considered to provide better efficiency than the previous protocol methods that are
discussed so far in the literature. In this paper they used the computational Diffie-Hellman
problem to afford security hardness for which they used different methods and new variants than
those are previously used [9].
In the same year 2005, Arvind Narayanan and Vitaly Shmatikov published “Fast
Dictionary Attacks on Passwords using Time Space Tradeoff” in which they used Markov
algorithmic techniques to reduce the size of the password search by using natural language
processing in which the passwords are provided in the native language of the users. With this

13. 13
time space tradeoff method they reduced the memory access to a comparatively less amount of
“partial dictionary” to overcome dictionary type of attacks [10].
In 2006, “A Secure Password Authenticated Key Exchange between Clients with
Different Passwords” proposed by Eun-Jun Yoon and Kee- Young Yoo illustrated the
accessibility of the modified C2C PAKE protocol and also suggested improvements to overcome
those problems. The main motive of this protocol is that the two parties can exchange their secret
key if and only if they pre-share the passwords using a single server or with dual servers. In this
paper they implemented this modified C2C PAKE protocol, because the recent document
published by Kim et al. is liable to Denning-Sacco attack by an inside attacker. This protocol is
proved to be secure against Denning-Sacco attack as well as Dictionary attack from a malignant
server. Yet, this modified protocol is prone to one-way- MITM attack (man in the middle).
Nevertheless, this paper mainly focuses on Kim et al.’s C2C PAKE protocol and introduces an
improved and modified scheme to overcome the problem that were found in the past paper and
also facilitates a greater efficiency by decreasing the computation costs, message transmission
cost and number of rounds [11].
Weijia Wang and Lei Hu in the same year proposed a paper “Efficient and Provably
Secure Generic Construction of Three-Party Password authenticated key exchange protocols” in
which they analyzed the security issues of 3-party password authenticated key exchange
protocols that are against unnoticeable online dictionary attacks which are serious hidden menace
for the protocols. In this paper they mainly concentrated on the design of 3-party PAKE
protocols enduring against both unnoticeable online dictionary attack and offline dictionary
attack. They also used the Decisional Diffie-Hellman assumption and Message authentication
codes (MAC) to design the protocol to provide security, efficiency and also versatility [12].
Feng Hao and Peter Ryan published a paper “Password Authenticated Key Exchange by
Juggling” in 2008 suggested methods to overcome the security problems using a method
different from all other past solutions called J-PAKE. They achieved this by using two steps,
initially two parties share public keys and finally they encrypt the shared key by juggling method
in which the public key is verified by which they assure the security of the protocol using zero-
knowledge proof. Here in J-PAKE protocol they authenticated the password using zero-
knowledge proof and later used Diffie-Hellman method to implement security by performing

14. 14
online dictionary attack resistance, offline dictionary attack resistance, forward secrecy and
known key security. J-PAKE protocol seems to prevent users from disclosing passwords and also
it involves no PKI deployments [13].
Further they proposed another paper in the year 2010 “JPAKE: Authenticated Key
Exchange without PKI” in which they used zero-knowledge proof (ZKP) to obtain efficiency. In
this research they obtained a protocol which provides a better efficiency to EKE and SPEKE
protocol methods with security. In the past papers many authors have avoided zero knowledge
proof due to efficiency issues, but in this paper Feng et al. mainly focused to achieve zero
knowledge proof to overcome efficiency and secondly performed authenticated key exchange by
sharing the session key only if the password entered were correct. Here they reviewed the
previous paper by comparing with the EKE and SPEKE protocols implemented by Bellovin and
Merritt in which they found that the J-PAKE provides more efficiency compared to EKE and
SPEKE when implemented on mobile devices and it requires the same computational costs as
those two protocols [14].
In the recent research by Junghyun Nam, Kim-Kwang Raymond Choo and et al. in the
year 2013 published a paper “An offline Dictionary Attack against Three-party Key Exchange
Protocol” in which they revised Abdalla and Pointcheval’s PAKE protocol and described that the
protocol is liable to offline dictionary attack through which one client can trace out another
client’s password. This paper aims on three scenarios Message Authentication, Message
Encryption and Key Confirmation using Diffie-Hellman method to prevent the protocol against
offline dictionary attack, which was successfully implemented and tested [15].
2.1 ProposedMethod
After the deep analysis of the Encrypted key exchange protocol suggested by Bellovin
and Merritt, which gave an idea in implementing the project in a more secure and efficient way.
From the analysis of the further papers discussed above a new protocol called Password
Authenticated Key Exchange (PAKE) was proposed in this paper, which is used to establish a
secure communication between two parties sharing a common password. The RSA algorithm is
used to generate a strong session key using 1024 bit keys, which is very difficult for an attacker

15. 15
to attain the secret key during an active conversation, the AES algorithm (Asymmetric
Encryption Standard) was used to generate a public key for the client and the server by
performing its operation using the shared password and the secret key generated by RSA.
Finally, Secured Hash Algorithm (SHA-1) is used to provide data integrity i.e. the input data or
password cannot be changed/altered by an attacker to attack a conversation between two parties.
Further details regarding the implementation of the protocol are explained in the following
chapters.

16. 16
CHAPTER 3
3. ALGORITHMS IMPLEMENTED
3.1 The RSA Algorithm
Rivest, Shamir and Adleman developed the RSA algorithm in the year 1977 which is one
of the first successful method for public key cryptography. The RSA method is a block cipher
which consists of plaintext and ciphertext in the form of integers between 0 and n-1. Generally
the value of n is 1024 bits or n less than 21024. The RSA algorithm encrypts the plaintext in the
form of blocks such that each block is less than n, where n lies between 2l<n≤2l+1. The plaintext
is denoted as M and ciphertext is denoted as C.
C = Me mod n
M = Cd mod n = (Me)d mod n = Med mod n
The public key is of the form PU = {e, n} and private key is of the form PR = {d, n}. for
a public key cryptography the following necessity should be fulfilled.
 The public and private key values such as e, d and n can be found, if Med mod n = M for
all M < n.
 If the values of M is lesser than n i.e. M < n, then it easier for the algorithm to compute
Me mod n and Cd mod n.
 The private key d cannot be determined if the public keys e and n are known.
Now the value for M should be determined from the equation Med mod n = M, to perform
the operation. It is noted that the e and d value should be of a multiplicative inverse modulo ϕ(n).
Hence the equation becomes,
ed mod ϕ(n) = 1
ed ≡ 1 mod ϕ(n)
d ≡ e-1 mod ϕ(n).

17. 17
Here the necessity values required for the RSA algorithm are noted. p and q are two
prime numbers where n = pq. The value of e is calculated such that gcd(ϕ(n),e) = 1 and d ≡ e-1
mod ϕ(n) are calculated before performing RSA. The RSA key generation steps are as follows,
i. Two prime numbers are selected such that p = 17 and q = 11.
ii. The value of n calculated n = pq = 17 x 11 = 187
iii. ϕ(n) value is calculated, where ϕ(n) = (p - 1) (q - 1) = 16 x 10 = 160.
iv. Select a prime value of e such that it is less than ϕ(n). Thus e = 7 was choosed.
v. Now perform ed ≡ 1 mod ϕ(n), ed ≡ 1 (mod 160) to find the value of d. hence the d value
is 23.
The main important factor in RSA is choosing the prime factors p and q. the value of p
and q should be chosen from a large set of numbers such that it is hard for the attacker to
discover them since the value of n = pq. At the same time, an efficient method should be used to
identify the p and q prime values. Miller-Rabin algorithm is used to determine such popular and

18. 18
efficient prime number values from a randomly chosen set of integer number that are hard to
identify. The RSA algorithm is proved to be secure if the choices of prime values are chosen
efficiently. The RSA algorithm can be attacked only by finding the private keys are by factoring
the n value to get the prime numbers. To avoid such attacks the value of n should be of 1024 bit
keys which is used in this project. In this project the RSA algorithm was used to perform a
mutually generated secret key between two parties sharing a common password [16].
3.2Advanced Encryption Standard (AES)
National Institute of Standards and Technology (NIST) published the Advanced
Encryption Standard (AES) in 2001. AES is a block cipher proposed to replace Data Encryption
Standard (DES) for commercial applications. The structure of AES is relatively complicated and
difficult to explain when compared to public key ciphers such as RSA. Instead of using Feistel
structure, AES use four separate functions such as byte substitution, permutation, arithmetic
operations over a finite field, and XOR with a key. The AES algorithm performs the above
mentioned functions in this project to generate a public key along with the secret key generated
by RSA algorithm and the shared password by the client and server [16].
3.2.1 Structure of AES
The structure of AES encryption process was shown in figure 1. The cipher takes the key
length as 16, 24 or 32 bytes (128,192 or 256 bits respectively), the plaintext block size can be 16
bytes or 128 bits. This algorithm is referred as AES 128, AES-192, or AES-256, depending on
the key length which is shown in table 3.1. The input to the encryption and decryption algorithms
is a single 128-bit block and it consists of input, state array, and output operation, that is depicted
as 4 × 4 square matrix of bytes in FIPS PUB 197. This 128- bit block is copied into the state
array and altered in each stage of encryption and decryption. After the last stage, state is copied
to an output matrix and the key is shown as a square matrix of bytes, which is extended into an
array of key schedule words.
Number of rounds in the cipher depends on the key length, for a 16 byte key, number of
rounds is 10, whereas 24 byte key has 12 rounds, 32 byte key has 14 rounds as shown in table
below. The first N-1 rounds consist of four specific transformation functions; they are SubBytes,

19. 19
ShiftRows, MixColumns, and AddRoundKey. The final round consist of three transformation in
which before the first round it has a zero round which means an initial stage transformation
before the first round. Each transformation takes one or more 4 × 4 matrix as an input and
generates a 4 × 4 as an output where the output of each round is a 4 × 4 matrix, with the output
of the final round being the ciphertext as shown in figure 3.1.
Figure 3.1: Encryption process of AES algorithm.

20. 20
Table 3.1:Parameters ofAES
Key size (words/bytes/bits) 4/16/128 6/24/192 8/32/256
Plaintext Block Size (words/bytes/bits) 4/16/128 4/16/128 4/16/128
Number of Rounds 10 12 14
Round key size (words/bytes/bits) 4/16/128 4/16/128 4/16/128
Expanded key size (words/bytes) 44/176 52/208 60/240
3.2.2 Detailed AES Structure
Detailed description of AES structure was shown in figure 3.2, in each round the sequence of
transformation and corresponding decryption function shown.
Comments about AES structure:
1. AES does not have a FEISEL structure, it processes the whole data block as a single
matrix, during each round using substitutions and permutation, but in the Feistel
structure, half of the data block is used to modify the other half of the data block and then
the halves are swapped.
2. Figure 5.3 shows that, the key that is given as an input is developed into an array of forty-
four 32-bit words, w[i]. Four different words of 128 bits are given as a round key for each
round.
3. Four different stages are used in which one performs permutation and the remaining three
performs substitution:
 Substitute bytes: A S-box is used to perform a byte-by-byte substitution of the
block
 ShiftRows: It performs a simple permutation steps.
 MixColumns: A substitution that makes use of arithmetic over GF(28)
 AddRoundKey: A bitwise XOR operation is performed to the portion of the
expanded key of the current block.
4. The structure is very simple for both encryption and decryption. The cipher starts with an
AddRoundKey stage, followed by nine rounds that each includes all four stages, followed
by a tenth round of three stages.

21. 21
Figure 3.2: Encryption and Decryption process of AES.

22. 22
5. Since the AddRoundKey stage alone makes use of the key, the cipher starts and
completes its action with this stage. If any other stage uses the key without any prior
knowledge, then that stage would contain no security.
6. This stage is similar to Vernam cipher as it is not so dreadful to itself compared to the
other three stages as they offer diffusion, confusion and nonlinearity and they are also
insecure as they do not use any key.
7. The Substitute Byte, Shift Rows and Mixcolumns stages performs an inverse function in
the decryption algorithm process whereas AddRoundKey stage achieves the inverse
function by performing XOR operation as all these above stages are performed in a
reverse order.
8. This decryption algorithm utilizes the expanded key in the reversible order, still it is not
similar with the encryption algorithm used.
9. After all the four stages are performed in the reverse order, the plaintext can be obtained
through the decryption process.
10. The last stage of this AES algorithm has only three stages during encryption as well as in
decryption process to make the cipher reversible [16].
3.3HASHING ALGORITHM
A hash algorithm is used to convert the variable sized message M into a fixed length size
hash value h = H(M). A hash function results in producing an output which has a uniformly
distributed random value. Hashing maintains data accuracy and consistency which is referred to
as data integrity. A cryptographic hashing algorithm makes it unattainable for the attacker to
compute the result of the hash value and obtain the original message M. The figure 3.3 depicts
the process of hashing and the necessary functions needed to perform hashing algorithm are
explained in table 3.2. Hence the hashing algorithm is used to identify if the data has been
modified i.e. if the single bit of information is changed then the entire output value obtained will
be different from the original value. Secure Hash Algorithm is a widely used and most important
hashing function that is used in this paper [16].

23. 23
Figure 3.3: Hash Fuction.
Table 3.2: Necessary function used to perform hashing operation and their description
Requirement Description
Variable input size The value of H can be used on a data block of
variable size.
Fixed output size The output obtained from the hash function H
is of a fixed length.
Efficiency The efficiency of the hash function H(x) is
relatively high in software and hardware
implementation for any given value x.
Pre-image resistant For any hash function H(y) = h, it is
unattainable to find the value of y.
Second pre-image resistant For any hash function H(y) = H(x), it is
unattainable to compute y≠ x.
Collision resistant It is unattainable to compute (x,y), where H(x)
= H(y)
Pseudo-randomness Pseudo-randomness test is performed for the
output obtained.

24. 24
3.3.1 Secure Hash Algorithm: (SHA-1)
National Institute of Standards and Technology developed the SHA and published as a
federal information processing standard (FIPS 180) in the year 1993. A few drawbacks have
been recognized in the SHA and revised version was published in the year 1995 as SHA-1. The
output hash value of SHA-1 generates 160 bits. The secure hash algorithm performs its operation
by taking the input message and divides them according to a fixed sized length L containing 160
bits each. The last block consists of a value which includes the total length of the input given to
the hash function which makes it difficult for the attacker to identify. The attacker should get two
messages of equal length to perform hashing or two messages containing the same value with
different message length to perform hashing which is generally difficult and takes more time to
compute. Therefore SHA-1 is considered to be a secure hashing algorithm as the key values
generated by them are difficult to crack which was analysed with the other similar kind of
algorithms such as MD5, PGP and digital signature. It is proved by a German cryptographer that
SHA-1 is secured against the remaining algorithms. Hence the Secured Hash Algorithm (SHA-1)
was implemented in this project to provide data integrity from the password being altered by an
intruder [16].

25. 25
CHAPTER 4
4. REVIEWING THE ENCRYPTEDKEY EXCHNAGE PROTOCOL
In the EKE protocol they introduced a concept of symmetric and asymmetric key
cryptographic combination that is encrypted using a randomly generated public key, which
provides a feasible amount of security by maintaining authentication and confidentiality over an
unreliable network. The protocol obligates the parties to provide a simple password, a hindrance
which is not usually provided due over an insecure network. Moreover in general, it is not
recommended for the two parties to store their shared passwords in a plaintext form or in a
reversibly-encrypted form, because an adversary can retrieve the encrypted password through
which he can easily spoof the hosts and also can implement dictionary type of attacks against the
hosts to the user. Hence the EKE protocol is implemented using RSA and ElGamal algorithms
to provide necessary security to an active network by making it difficult for an attacker to
retrieve the essential information [1].
4.1Implementation of RSA algorithm in EKE Protocol
The EKE protocol seems difficult to implement and hence RSA algorithm is used to
demonstrate those difficulties. The RSA cryptosystem has a public key EA which consists of (e,
n) a pair of large natural numbers where e is a prime number and n is a multiple of two large
primes p and q.
φ(n) = φ(p)φ(q) = (p – 1) (q – 1).
The key d is decrypted performed by,
ed ≡ 1 (mod (p – 1) (q – 1)). (1)
The plain text message m is encrypted using,
c ≡ me (mod n)
The cipher text message c is decrypted using,
m ≡ cd (mod n).

26. 26
From the above encryption and decryption process it is not clearly stated how to encrypt
(e, n) pair precisely such that it is identical from a random string. It is also easy for an adversary
to find out that all the possible values of n’ have small prime numbers and therefore they have
been incorrect. Let us consider p and q in the form of 2p’ + 1 and 2q’ + 1, in which p’ and q’ are
prime numbers and hence, (mod n) is calculated by performing (p – 1) (q – 1) = 4p’q’ which is a
valid public key e. Therefore it is difficult for an intruder to gather more information about the
password P if he performed a dictionary attack on P(e) [1].
In the above process n is send in a clear text format to analyse the complexity of the
protocol. For example, if an intruder substitutes n’ instead of n in the first message such that the
message reaches B as (P(e), n’). The response from B is in the form,
(R, challenge B)e (mod n’).
With the password P’ gained from B, the intruder can evaluate,
e’ = P’-1(P(e)).
Let us assume here, that the intruder is aware of the factorization of n’, therefore he/she can
perform the private key d’ to encrypt
(R, challenge B)e (mod n’),
attaining,
(R, challenge B)ed’ (mod n’).
(R, challenge B) is a random challenge generated if e ≠ e’, which is of no use to an adversary. If
the attacker imposed a dictionary attack he should response to the message which he/she is not
aware of either challenge B or R. At this point the intruder stops his attack as he/she is unable to
generate the following message and the alarm rings at both A and B.
R(challenge A, challenge B).

27. 27
4.1.1 Advantage of sending “n” as a clear text form
 It discloses the liability of cryptanalysis to the users. More specifically, if the value of n is
visible to the attacker he/she can factorize the value of n which helps in exposing the
values of R and the password P to perform attack.
 If the value of n is unknown, then it is difficult for an intruder to solve the plaintext to
guess the password P which is impossible to perform.
Yet, there is an obstacle of encrypting the public key it seen that only the second message can be
secured by the password P which is vulnerable to RSA attack.
Let us consider that the attacker masquerade as A and selects p and q and also e and n values. If
the value of e is unsatisfied for the above equation (1) then the encryption process was disrupted.
The feasible values of
EA(R) = Re (mod n)
The values of (the e- residues (mod n) are in the range of [0, n-1]. An EKE attack is possible by
an attacker if a decryption
P’-1(P (EA(R)))
provides an e-residue which are possible decisions.
Preventing against the above attack leads B to analyse the fake values of e that can be detected
from the factorization of n and the values of φ(n) which cannot be performed directly without the
value of e. To avoid such problems, B sends few random messages to A for decryption that are
encrypted using the value of e, accurate response to those messages proves that e has an
appropriate value [1].
4.2Implementation of ElGamalalgorithm in EKE protocol
Diffie-Hellman exponential key exchange protocol is the base to derive ElGamal’s
algorithm .RA and RB are the random exponents of A and B, considering α and β as base module.
A calculates YA ≡ (αRA (mod β)) and B calculates YA ≡ (αRB (mod β)). With the values of RA and
αRB (mod β), A can calculate,
(αRB) RA (mod β) ≡ αRB RA (mod β)

28. 28
B calculates,
(αRA) RB (mod β) ≡ αRA RB (mod β)
The result obtained is the key. It is hard for an attacker to do the same computation by only
having the values of αRA (mod β) and αRB (mod β).
For an asymmetric encryption system, the following exponential X can be the public key.
YX ≡ αRX (mod β)
A random number k was chosen between 0 and β – 1 by sender A for sending a message to B. A
then calculates,
c1 ≡ αk (mod β)
and
c2 ≡ m(YB)k (mod β)
≡ m(αRB)k (mod β)
≡ mαRBk (mod β)
The encrypted message consist of the pair <c1,c2>.
B then decrypts the message with RB and computes,
K ≡ c1
RB (mod β)
≡ αRBk (mod β).
From the computed K, the value of m can be obtained by dividing c2 by K.
By selecting the appropriate values for α and β, the cryptosystem can fix them into the EKE
scheme. When the public key αRA is distributed uniformly in the range of [0, β – 1]; the encrypted
information are not leaked. The value of c1 and c2 are uniformly distributed and hence the
message becomes,
P(αRA (mod β)) (2)
and,

29. 29
P(αk (mod β), RαRAk (mod β)). (3)
Initially, it seems that the encryption process can be excluded with the password P. If the above
message (3) is sent in a clear text format then an attack can be imposed by an attacker depending
on the challenge/response message obtained. A sends B an encrypted public key:
P(αRA (mod β)). (4)
Now the attacker attacks the above message. If the attacker is unaware of the password P, then it
is impossible to decrypt as well as to calculate (αRA)k. Therefore X is replaced as a random value.
Later,
c1 ≡ αk (mod β)
thus, the message becomes,
αk (mod β), RX (mod β). (5)
A now calculates,
K ≡ αRAk (mod β).
and therefore
𝑅′
=
𝑅𝑋
α 𝑅 𝐴 𝐾 (mod β)
Now R’ is used to encode,
R′ (challengeA). (6)
This R’ value cannot be computed without knowing αRA,.
Even after all such calculation and providing a secret random number k, the ElGamal algorithm
can be decrypted by the attacker if the receipient’s public key is known along with the random
number k. But the in the case of RSA, the above attack becomes unsuccessful.
Let us now consider RSA, performing encryption E with key K and decryption D with key K-1
process which are an inverse of each other.
E: K × M → C

30. 30
D: K-1× M → C
In the case of ElGamal algorithm, an added decryption function D’ and a free space k ϵ S is used,
D′: (K× S) × C → M
With the result of D’ an attacker can forge to encrypt the message M [1].
4.3Complete EKE Protocol:
From the above discussed RSA and ElGamal algorithms, the EKE protocol is
implemented which generates a random session key value without the need of transmission R.
Step 1: A chooses random number RA and performs P(𝛼Ra (mod 𝛽)) and sends it to B.
A, P(𝛼Ra (mod 𝛽)) (i)
Step 2: Now B chooses random number RB and performs (𝛼Rb (mod 𝛽)) to decrypts the password
P along with the message received P(𝛼Ra (mod 𝛽)) and generates,
(𝛼Ra 𝛼Rb)(mod 𝛽)
And a challenge is generated and sent to A,
P(𝛼Ra (mod 𝛽)), K(challenge B) (ii)
Step 3: A receives the challenge message from B and decrypts them and generates its own
challenge. A now transmits,
K (challenge A, challenge B) (iii)
Step 4: Now B decrypts the above received challenge from A and validates them. And sends its
reply message to A if the validates was correct.
K (challenge A) (iv)
Step 5: In this stage, A decrypts the challenge obtained from B and validates them whether it
matches with the challenge that it created.

31. 31
In the previous cases it is discussed that the attacker can be able to replace the message
received from A,
A, 𝛼Ra (mod 𝛽).
But with our improved EKE protocol model the attacker cannot decrypt the message obtained
from B, through which he cannot obtain any useful information. Hence the attacker cannot reply
to the challenge message received from A without the knowledge of RA value.
In the case of an attacker choosing 0 as the exponent value, to obtain,
(𝛼Ra 𝛼Rb)(mod 𝛽) ≡ 1.
as a result. Luckily, these kinds of attacks are detected and hence the other possible exponent
values are not known.
To overcome this problem, the value for 𝛼 and 𝛽 should be choose to avoid cost and
security issues. There are many options available for the modulus 𝛽 in which it can be chosen as
a relatively large prime number to provide security. An another option is to make the 𝛼 and 𝛽
values constant as there will be no exposure of information or the value of 𝛽 should be very large
which causes the exponential operation to be difficult for the intruder to perform. Suppose if the
attacker tries to record the user’s conversation and tries to decrypt modulo value and reads the
old conversations of the users by which the attacker can retrieve some of the valid information.
To prevent such attacks, a large modulus value can be used. To overwhelm the above discussed
problem the 𝛽 value should be of the form kp + 1 in which k is a small integer and p is a prime
number [1].
4.3.1 Applications of EKE protocol
 The EKE protocol is implemented to provide security to public telephones by enabling a
compact, keypad entering password. The drawback with this application is the protocol
takes more time for generating a session key to make a call.
 Secondly, EKE is used in cellular phones to prevent fraudulent by offering the users to
provide security PIN numbers to recover the cell phones if they were stolen.
 Encrypted key exchange protocol is also used to identify eavesdroppers and hence this
protocol is used as a substitute of Rivest and Shamir’s Interlock protocol.

32. 32
 Another application of EKE is it is used as a privacy amplifier function to enhance the
weak symmetric and asymmetric systems. This function mainly depends on the modulus
value that is picked. To provide more security one must pick a lengthy modulus number
to make it harder for the attacker to guess them, which is a drawback of this protocol [1].
Hence in this paper, the RSA algorithm is used to generate the secret key between the
client and the server, whereas the Hashing algorithm performs data integrity to make the protocol
stronger than the EKE protocol. The hashing algorithm is used in this paper to prevent changes
in the input values by the intruder, because it is noticed from the above EKE protocol that the
attacker can forge the data if he identified the 𝛽 value through few random guesses. It is known
that by performing a hash function, only the hashed values are stored in the hash table, whereas it
is difficult for an attacker to retrieve from the input values by decrypting the hashed data. Yet the
attacker can run a dictionary attack to find the password by which he can gain the full access to
the information.

33. 33
CHAPTER 5
5. IMPLEMENTATIONOF PAKE PROTOCOL
5.1NetBeans IDE and JAVA
In this project NetBeans Interactive Development Environment (IDE) software is used to
develop the java code and GUI graphical user interface. It is a user-friendly, open source
platform to implement java programs and it supports all the necessary library files needed to
implement and also the project can be build and run in the same window. In this project the Java
programming language is used which was developed by James Gosling at Sun Microsystems in
the year 1995. Java is one of the most standard programming languages that were used mainly
for developing a server client application. The Java Virtual Machine (JVM) is used to run all the
java program applications.
Java Virtual Machine (JVM) is used mainly to execute the java code which consists of
standard library files containing application program interface with which the software can be
developed. This project is implemented using the NetBeans and Java program to demonstrate the
password authenticated key exchange protocol. The protocol is implemented by performing
RSA, AES and SHA (Hashing) algorithms.

34. 34
5.2Software Implementation
Open the NetBeans IDE application and clean and build both the server and client
program that was coded. Open two command prompt windows, one for the running the client
application and the other for server.
Figure 5.1: command prompt for establishing server’s connection
Figure 5.2: Command prompt for establish client’s connection

35. 35
Once the clean and build was successful at the client and server, copy the java jar file address that is
shown at the end of the compilation comments at the output section.
Figure 5.3: highlighting the client’s jar file address
Figure 5.4: highlighting the server’s jar file address.

36. 36
Now paste the copied client’s and server’s address in their respective command prompt and press enter.
The program will be initiated at both the client and server side. The key generated were validated to be
safe and the communication begins at both the client and server.
Figure 5.5: initializing communication at the server end.
Figure 5.6: Initializing communication at the client side.

37. 37
Once the communication is initialized a pop-up dialog box appears, which performs the
following operation.
 String Encryption
 File Encryption
 Exit
Figure 5.7: Menu Pop-up Box.
The below screen shows the string encryption operation performed at the client side. The
communication is established by the client and the response from the server is received back.
Figure 5.8: Communication at the client side.

38. 38
Here the message received from the client is validated by the server and the response is send
back to the client by the server.
Figure 5.9: Communication at the Server end.

39. 39
The screenshots below depicts the termination operation performed by the client and server. In
this project “bye” is used to denote that the conversation was terminated. Once the operation is
terminated, the loop tries to retrieve the pop-up window to offer the other options that are
available for the user to perform.
Figure 5.10: Terminating the communication at the client side
Figure 5.11: Terminating the communication at the server’s side.

40. 40
Now the pop-up box appears again, and the user can select the file encryption option if
he/she wants to transfer files. Enter the option 2 and press OK.
Figure 5.12: Menu Pop-up Box.
Once the file encryption menu is selected, an another pop-up appears prompting the user to
provide the path including the name of the file to be encrypted.
Figure 5.13: Pop-up menu to enter file’s path.
After providing the file name and address, another pop-up box appears recommending the
user to provide a new name and destination path for storing the encrypted file.
Figure 5.14:Pop-up box for providing name and destination address for the encrypted file.

41. 41
The file is then encrypted securely and saved in the new location that is provided. The file to
be encrypted can be a text file or an image file.
Figure 5.15: File Encryption performed
Finally, the loop returns back to the menu option after completing the file encryption. If the
option 3 EXIT is choosed, then the loop is terminated. Thus the basic implementation of
password authenticated key exchange protocol was implemented successfully.
Figure 5.16: Pop-up Menu

42. 42
CHAPTER 6
6. RESULT
As demonstrated in the implementation of the project the results obtained from the
designed protocol is as follows. It is shown in the figure 6.1 that the string encryption between a
client and server was successfully implemented by generating a secure session key using the
algorithms.
Figure 6.1: string encryption at the client’s end.
Figure 6.2: String encryption at the server side.

43. 43
The following figure 6.3 shows the result of file encryption performed by the client and
the server. The algorithm is designed to any type of files such as text documents and image files.
Figure 6.3: File moved
Table 6.1: The following table depicts the different types of algorithms used in each paper
discussed in the literature review.
Name of the
Journal
RSA Kerberos Hashing Diffie-
hellman
ElGamal Public key
cryptography
Digital
signature
Reverse
Turning
Test
Markov Zero
Knowledge
Proof
C2C
PAKE
Protocol
1 EKE:
password
based
protocols
secure
against
dictionary
attacks
Yes Yes
2 PAKE by
juggling
Yes Yes Yes
3 Provably
Secure
Password
Authenticated
Key
Exchange
using Diffie
Hellman
Yes
4 J-PAKE:
Authenticated
Yes Yes

44. 44
key exchange
without PKI
5 Augmented
EKE: a
password
based
protocol
Yes Yes Yes
6 Weakness of
PAKE
protocol
between
clients with
different
passwords
Yes
7 A secure
PAKE
between
clients with
different
passwords
Yes
8 An offline
dictionary
attack against
3rd
party key
exchange
protocol
Yes
9 Authenticated
key exchange
secure
against
dictionary
attack
Yes Yes
10 Efficient and
provably
secure
generic
construction
of 3rd
party
PAKE
protocols
Yes

45. 45
11 Efficient
PAKE using
human
memorable
passwords
Yes
12 Fast
dictionary
attack on
passwords
using time
space trade
off
Yes
13 PAKE
between
clients with
different
passwords
Yes Yes
14 Securing
passwords
against
dictionary
attacks
Yes
15 Simple
passwords
based EKE
protocols
Yes
The table above provides the information about the algorithms used in each and every
paper. After thorough analysis of various papers and algorithms, three main algorithms such as
RSA, AES and Hashing (SHA) are used in this paper to provide a secure communication
between two parties sharing a simple password. These algorithms together present a strong
protocol known as Password Authenticated Key Exchange (PAKE) which was considered to be
secure against attacks. The algorithms are implemented in such way that the RSA algorithm
generates the public key mutually for both the parties by performing an asymmetric encryption
process; the secret key was generated by the AES algorithm for both the parties using the public
key that was generated using RSA asymmetric encryption process. Secure Hash Algorithm

46. 46
provides data integrity which means the data cannot be changed or altered by an unauthorized
person or by an attacker. The protocol also ensures data confidentiality by encrypting the
password and restricting the user’s access by which it assures security to the protocol. Hence the
above security measures and PAKE protocol implementation ensures that the password was
prevented against the attackers sharing a simple password.

47. 47
CHAPTER 7
7. CONCLUSION & FUTURE ENHANCEMENT
7.1Conclusion
The main objective of this research is to provide a protocol which allows two parties to
share a simple password against attacks. Hence the PAKE protocol was designed to provide
simple passwords by the user that helps them from remembering a complicated alpha numeric
password. Considerable security was also provided in this protocol using three different
algorithms RSA, AES (Advanced Encryption Standard) and SHA1 (Hashing) which assures
them a secured communication. The RSA and AES algorithms generate a public and private key
by encrypting the password to provide data confidentiality, whereas the SHA1 algorithm assures
the data being changed or altered by an intruder by providing data integrity. The above process
demonstrates that the protocol is safe against an intruder, even if a simple password was used by
the client and server for communicating.
7.2 Future Enhancement
To further support this project, an extension can be done with this implementation by
enforcing few attacks to ensure that this PAKE protocol is secured. To facilitate the
implementation of attacks, a period is 3-4 weeks is required to produce a positive result. An
active attack such as man in the middle, etc. or a passive attack such as brute force, dictionary
attack, etc. can be implemented against this protocol to verify whether the protocol is prone to
any such attacks. Since the hashing algorithm was used in the PAKE protocol it is hard for the
attacker to gather the information about the shared password as this password would have
undergone a numerous number of steps to perform hashing. Finally this research would suggest
implementing various attacks against the PAKE protocol to ensure the level of security
implemented in PAKE, may have virtue.

48. 48
8. REFERENCE:
1) M.Bellovin, s. and Merritt, M. (1992). Encrypted Key Exchange: Password Based
protocols secure against dictionary attacks. IEEE symposium on research in security and
privacy. [online] Available at: https://www.cs.columbia.edu/~smb/papers/neke.pdf.
2) M.Bellovin, s. and Merritt, M. (1993). Augmented EKE: a password based protocol
secure against dictionary attacks and password file comparison. computer and
communication security, 93-11/93.
3) bokyo, V., mackerzie, p. and patel, s. (2000). Provably Secure Password Authenticated
Key Exchange using Diffie Hellman. EUROCRYPT 2000.
4) Bellare, M., PointCheval, D. and Rogaway, P. (2000). Authenticated key exchange
secure against dictionary attacks. Advances in Cryptology - Eurocrypt '00, 77.
5) Katz, J., Ostrovsky, R. and Yung, M. (2001). Efficient Password Authenticated Key
Exchange using Human Memorable Passwords. Eurocrypt 2001, pp.475-494.
6) Pinkas, B. and Sander, T. (2002). Securing Passwords against Dictionary Attacks.
[online] Available at: http://www.pinkas.net/PAPERS/pwdweb.pdf.
7) Wook Byun, J., Rae Jeong, I., Hoon Lee, D. and Park, C. (2002). Password Authenticated
Key Exchange between clients with Different Passwords. ICICS 2002, 2513, pp.134-146.
8) Wang, S., Wang, J. and Xu, M. (2004). Weaknesses of a Password Authenticated Key
Exchange Protocol between Clients with Different Passwords. ACNS 2004, 3089, pp.414-
425.
9) Abdalla, M. and Pointcheval, D. (2005). Simple Password-Based Encrypted Key
Exchange Protocols. CT-RSA 2005, [online] 3376, pp.191-208. Available at:
http://www.di.ens.fr/~pointche/Documents/Papers/2005_rsa.pdf.
10) Narayanan, A. and shmatikov, V. (2015). Fast Dictionary Attacks on Passwords Using
Time-Space Tradeoff. CCS'05. [online] Available at:
https://www.cs.utexas.edu/~shmat/shmat_ccs05pwd.pdf [Accessed 26 june. 2015].
11) Yoon, E. and Yoo, K. (2006). A Secure Password Authenticated Key Exchange between
Clients with Different Passwords. APWeb Workshop 2006. [online] Available at:
http://link.springer.com/chapter/10.1007%2F11610496_88.

49. 49
12) Wang, W. and Hu, L. (2006). Efficient and Provably Secure Generic Construction of
Three-Party Password authenticated key exchange protocols. INDOCRYPT 2006, [online]
4329, pp.118-132. Available at:
http://link.springer.com/chapter/10.1007%2F11941378_10#page-1.
13) Password Authenticated Key Exchange by Juggling. (2008). university of Newcastle upon
Tyne, Computer Science, 2008. [online] Available at:
http://grouper.ieee.org/groups/1363/Research/contributions/hao-ryan-2008.pdf.
14) Hao, F. and Ryan, P. (2010). J-PAKE: Authenticated Key Exchange Without PKI.
[online] Available at: https://eprint.iacr.org/2010/190.pdf [Accessed 30 Jun. 2015].
15) Nam, J., Raymond Choo, K., Paik, J. and Won, D. (2013). An offline Dictionary Attack
against Three-party Key Exchange Protocol. [online] Available at:
https://eprint.iacr.org/2013/666.pdf [Accessed 30 Jun. 2015].
16) Stallings, W. (1999). Cryptography and network security. 5th ed. Upper Saddle River,
N.J.: Prentice Hall.
17) krishnan, k. (2015). Computer Networks and Computer Security. 8th ed. pp.Lectures 22-
24.

50. 50
9. APPENDIXA- CODING
9.1Client Side
package project;
import com.chilkatsoft.*;
import java.io.*;
import java.net.*;
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
/**
*
* @author Thivya
*/
public class Client {
/**
*
*/
public final static int FILE_SIZE = 80000000;
static {
try {
System.load("D:UL Lecture Notes INSThesisprojectchilkat-9.5.0-jdk8-
x64chilkat.dll");
} catch (UnsatisfiedLinkError e) {
System.err.println("Native code library failed to load.n" + e);

51. 51
System.exit(1);
}
}
/**
*
* @param args
* @throws Exception
*/
public static void main(String args[]) throws Exception {
CkRsa rsa1 = new CkRsa();
boolean success = rsa1.UnlockComponent("T12302015RSA_nn56BzHGIRMg");
if (success != true) {
System.out.println("RSA component unlock failed");
return;
}
// This example also generates the public and private
// keys to be used in the RSA encryption.
// Normally, you would generate a key pair once,
// and distribute the public key to your partner.
// Anything encrypted with the public key can be
// decrypted with the private key. The reverse is
// also true: anything encrypted using the private
// key can be decrypted using the public key.
// Generate a 1024-bit key. Chilkat RSA supports
// key sizes ranging from 512 bits to 4096 bits.
success = rsa1.GenerateKey(1024);
if (success != true) {
System.out.println(rsa1.lastErrorText());

52. 52
return;
}
CkPrivateKey privKey = new CkPrivateKey();
CkPublicKey pubKey = new CkPublicKey();
// Keys are exported in XML format:
String publicKey = rsa1.exportPublicKey();
String privateKey = rsa1.exportPrivateKey();
// Save the private key in PEM format:
CkCrypt2 crypt6 = new CkCrypt2();
String p = crypt6.genRandomBytesENC(32);
//Generating a random number
//Hashing
CkCrypt2 crypt1 = new CkCrypt2();
// Any string argument automatically begins the 30-day trial.
success = crypt1.UnlockComponent("T12302015Crypt_sHyDCAFgIR1v");
if (success != true) {
System.out.println(crypt1.lastErrorText());
return;
}
String z = p;
crypt1.put_HashAlgorithm("sha1");
crypt1.put_EncodingMode("hex");
// Other possible EncodingMode settings are:
// "quoted-printable", "base64", and "url"
String hash = crypt1.hashStringENC(z);

53. 53
//JOptionPane.showMessageDialog(null,"SHA1: " + hash);
//Encryption
CkRsa rsaEncryptor1 = new CkRsa();
// Encrypted output is always binary. In this case, we want
// to encode the encrypted bytes in a printable string.
// Our choices are "hex", "base64", "url", "quoted-printable".
rsaEncryptor1.put_EncodingMode("hex");
// We'll encrypt with the public key and decrypt with the private
// key. It's also possible to do the reverse.
rsaEncryptor1.ImportPrivateKey(privateKey);
boolean usePrivateKey = true;
String encryptedStr = rsaEncryptor1.encryptStringENC(hash, usePrivateKey);
String encryptedStr4 = rsaEncryptor1.encryptStringENC(z, usePrivateKey);
CkRsa rsaEncryptor = new CkRsa();
// Encrypted output is always binary. In this case, we want
// to encode the encrypted bytes in a printable string.
// Our choices are "hex", "base64", "url", "quoted-printable".
rsaEncryptor.put_EncodingMode("hex");
// We'll encrypt with the public key and decrypt with the private
// key. It's also possible to do the reverse.
/////////////////////////////////////////
//public key from server
//
///////////////////////////////////////////
Socket key = new Socket("localhost", 8080);

54. 54
ObjectOutputStream outk = new ObjectOutputStream(key.getOutputStream());
outk.writeObject(publicKey);
ObjectInputStream oisk = new ObjectInputStream(key.getInputStream());
String publickeys = (String) oisk.readObject();
//System.out.println(publickeys);
key.close();
///////////////////////////////////
//public key from server
//
//////////////////////////////////
boolean x = rsaEncryptor.ImportPublicKey(publickeys);
boolean usePublicKey = false;
String encryptedStr1 = rsaEncryptor.encryptStringENC(encryptedStr,
usePublicKey);
String encryptedStr2 = rsaEncryptor.encryptStringENC(encryptedStr4,
usePublicKey);
//JOptionPane.showMessageDialog(null,"Encrypted Sring:- "+encryptedStr);
//Client Sending key part
Socket sock = new Socket("localhost", 1000);
ObjectOutputStream out = new ObjectOutputStream(sock.getOutputStream());
out.writeObject(encryptedStr1);
out.writeObject(encryptedStr2);
ObjectInputStream ois = new ObjectInputStream(sock.getInputStream());
String message1 = (String) ois.readObject();
String message2 = (String) ois.readObject();
//System.out.println(message);
sock.close();

55. 55
//
//
//Get the string from Server here and then decrypt
//
//
// Now decrypt:
CkRsa rsaDecryptor = new CkRsa();
rsaDecryptor.put_EncodingMode("hex");
rsaDecryptor.ImportPrivateKey(privateKey);
usePrivateKey = true;
String decryptedStr = rsaDecryptor.decryptStringENC(message1, usePrivateKey);
String decryptedStr2 = rsaDecryptor.decryptStringENC(message2, usePrivateKey);
//System.out.println(decryptedStr);
//System.out.println(decryptedStr2);
CkRsa rsaDecryptor1 = new CkRsa();
rsaDecryptor1.put_EncodingMode("hex");
rsaDecryptor1.ImportPublicKey(publickeys);
usePublicKey = false;
String decryptedStr1 = rsaDecryptor1.decryptStringENC(decryptedStr,
usePublicKey);
String decryptedStr3 = rsaDecryptor1.decryptStringENC(decryptedStr2,
usePublicKey);
////////////////
//
//Compare hash
//

56. 56
///////////////
CkCrypt2 crypt3 = new CkCrypt2();
// Any string argument automatically begins the 30-day trial.
success = crypt3.UnlockComponent("T12302015Crypt_sHyDCAFgIR1v");
if (success != true) {
System.out.println(crypt3.lastErrorText());
return;
}
String op = decryptedStr3;
crypt3.put_HashAlgorithm("sha1");
crypt3.put_EncodingMode("hex");
// Other possible EncodingMode settings are:
// "quoted-printable", "base64", and "url"
String hashnew = crypt3.hashStringENC(op);
//System.out.println(hashnew);
if (hashnew.equals(decryptedStr1) == true) {
System.out.println("safe key");
} else {
System.out.println("key not safe");
}
//Generate session key for AES
//////////////
CkCrypt2 crypt = new CkCrypt2();
success = crypt.UnlockComponent("T12302015Crypt_sHyDCAFgIR1v");

57. 57
if (success != true) {
System.out.println(crypt.lastErrorText());
return;
}
// AES is also known as Rijndael.
crypt.put_CryptAlgorithm("aes");
// CipherMode may be "ecb" or "cbc"
crypt.put_CipherMode("cbc");
// KeyLength may be 128, 192, 256
crypt.put_KeyLength(256);
// The padding scheme determines the contents of the bytes
// that are added to pad the result to a multiple of the
// encryption algorithm's block size. AES has a block
// size of 16 bytes, so encrypted output is always
// a multiple of 16.
crypt.put_PaddingScheme(0);
// EncodingMode specifies the encoding of the output for
// encryption, and the input for decryption.
// It may be "hex", "url", "base64", or "quoted-printable".
crypt.put_EncodingMode("hex");
// An initialization vector is required if using CBC mode.
// ECB mode does not use an IV.
// The length of the IV is equal to the algorithm's block size.
// It is NOT equal to the length of the key.
String keya = p + op;

58. 58
String ivHex = "000102030405060708090A0B0C0D0E0F";
crypt.SetEncodedIV(ivHex, "hex");
// The secret key must equal the size of the key. For
// 256-bit encryption, the binary secret key is 32 bytes.
// For 128-bit encryption, the binary secret key is 16 bytes.
String keyHex = keya;
crypt.SetEncodedKey(keya, "hex");
String msg = "Enter the choice from the menu n";
int ok = JOptionPane.YES_OPTION;
while (ok == JOptionPane.YES_OPTION) {
String ms = JOptionPane.showInputDialog("1)String Encryption n2)File Encryption
n3)Exitn" + msg);
int choice = Integer.parseInt(ms);
switch (choice) {
case 1:
Socket sock1 = new Socket("localhost", 7070);
ObjectOutputStream out1 = new ObjectOutputStream(sock1.getOutputStream());
String encStr = crypt.encryptStringENC("Hello .....The quick brown fox jumps over
the lazy dog.");
out1.writeObject(encStr);
ObjectInputStream ois1 = new ObjectInputStream(sock1.getInputStream());
String message4 = (String) ois1.readObject();
String decStr = crypt.decryptStringENC(message4);
System.out.println(decStr);
//System.out.println(message);
sock1.close();

59. 59
break;
case 2:
// Encrypt a string...
// The input string is 44 ANSI characters (i.e. 44 bytes), so
// the output should be 48 bytes (a multiple of 16).
// Because the output is a hex string, it should
// be 96 characters long (2 chars per byte).
// Now decrypt:
///////////
//
//Secure channel created can be used for chatting
//
//
////////////
////////////////////
//
//Sending a file
//
////////////////////////
int bytesRead;
int current = 0;
FileOutputStream fos = null;
BufferedOutputStream bos = null;
Socket sockf = null;
try {
sockf = new Socket("localhost", 123);
System.out.println("Trying ...");

60. 60
// receive file
byte[] mybytearray = new byte[FILE_SIZE];
InputStream is = sockf.getInputStream();
fos = new
FileOutputStream("C:UsersThivyaDocumentsNetBeansProjectsaesEncrypted.dat");
bos = new BufferedOutputStream(fos);
bytesRead = is.read(mybytearray, 0, mybytearray.length);
current = bytesRead;
do {
bytesRead
= is.read(mybytearray, current, (mybytearray.length - current));
if (bytesRead >= 0) {
current += bytesRead;
}
} while (bytesRead > -1);
bos.write(mybytearray, 0, current);
bos.flush();
// System.out.println("File " + FILE_TO_RECEIVED+ " downloaded (" + current + " bytes
read)");
} finally {
if (fos != null) {
fos.close();
}
if (bos != null) {
bos.close();
}
if (sockf != null) {

61. 61
sockf.close();
}
}
String filename1 = JOptionPane.showInputDialog("enter the destination path");
success =
crypt.CkDecryptFile("C:UsersThivyaDocumentsNetBeansProjectsaesEncrypted.dat",
filename1);
if (success != true) {
System.out.println(crypt.lastErrorText());
return;
}
JOptionPane.showMessageDialog(null, "file moved to the specified location");
break;
case 3:
ok = JOptionPane.showConfirmDialog(null, "Exitn" + " Do you want to continue",
"Message box", JOptionPane.YES_NO_OPTION);
break;
default:
JOptionPane.showMessageDialog(null, "Invalid Input");
break;
}
}
} }

62. 62
9.2Server Side
package project;
import com.chilkatsoft.*;
import java.lang.*;
import java.io.*;
import java.net.*;
import javax.swing.JOptionPane;
import java.util.Random;
class Server {
static {
try {
System.load("D:UL Lecture Notes INSThesisprojectchilkat-9.5.0-jdk8-
x64chilkat.dll");
} catch (UnsatisfiedLinkError e) {
System.err.println("Native code library failed to load.n" + e);
System.exit(1);
}
}
public static void main(String args[]) throws Exception {
CkRsa rsa1 = new CkRsa();
boolean success = rsa1.UnlockComponent("T12302015RSA_nn56BzHGIRMg");
if (success != true) {
System.out.println("RSA component unlock failed");
return;

63. 63
}
// This example also generates the public and private
// keys to be used in the RSA encryption.
// Normally, you would generate a key pair once,
// and distribute the public key to your partner.
// Anything encrypted with the public key can be
// decrypted with the private key. The reverse is
// also true: anything encrypted using the private
// key can be decrypted using the public key.
// Generate a 1024-bit key. Chilkat RSA supports
// key sizes ranging from 512 bits to 4096 bits.
success = rsa1.GenerateKey(1024);
if (success != true) {
System.out.println(rsa1.lastErrorText());
return;
}
CkPrivateKey privKey = new CkPrivateKey();
CkPublicKey pubKey = new CkPublicKey();
// Keys are exported in XML format:
String publicKey = rsa1.exportPublicKey();
String privateKey = rsa1.exportPrivateKey();
//System.out.println("Public key server "+publicKey );
// Save the private key in PEM format:
CkCrypt2 crypt6 = new CkCrypt2();
String p = crypt6.genRandomBytesENC(32);
//parts is the part of the random number generated by serverto be used in AES key
generation
//Hashing using Sha1 of randomly generated number
CkCrypt2 crypt1 = new CkCrypt2();

64. 64
// Any string argument automatically begins the 30-day trial.
success = crypt1.UnlockComponent("T12302015Crypt_sHyDCAFgIR1v");
if (success != true) {
System.out.println(crypt1.lastErrorText());
return;
}
String z = p;
//System.out.println(s);
crypt1.put_HashAlgorithm("sha1");
crypt1.put_EncodingMode("hex");
// Other possible EncodingMode settings are:
// "quoted-printable", "base64", and "url"
String hash = crypt1.hashStringENC(z);
//JOptionPane.showMessageDialog(null,"SHA1: " + hash);
//Encryption
CkRsa rsaEncryptor1 = new CkRsa();
// Encrypted output is always binary. In this case, we want
// to encode the encrypted bytes in a printable string.
// Our choices are "hex", "base64", "url", "quoted-printable".
rsaEncryptor1.put_EncodingMode("hex");
rsaEncryptor1.ImportPrivateKey(privateKey);
//System.out.println(privateKey);
boolean usePrivateKey1 = true;
String encryptedStr = rsaEncryptor1.encryptStringENC(hash, usePrivateKey1);

65. 65
String encryptedStr4 = rsaEncryptor1.encryptStringENC(z, usePrivateKey1);
//System.out.println("String to be encrypted"+encryptedStr);
CkRsa rsaEncryptor = new CkRsa();
// Encrypted output is always binary. In this case, we want
// to encode the encrypted bytes in a printable string.
// Our choices are "hex", "base64", "url", "quoted-printable".
rsaEncryptor.put_EncodingMode("hex");
// We'll encrypt with the public key and decrypt with the private
// key. It's also possible to do the reverse.
//rsaEncryptor.ImportPublicKey(publicKey);
//System.out.println(publicKey);
////////////////////////////////////////////
//
//key from client
//
////////////////////////////////////
ServerSocket Servsockey = new ServerSocket(8080);
Socket key = Servsockey.accept();
ObjectInputStream oisk = new ObjectInputStream(key.getInputStream());
String publickeyc = (String) oisk.readObject();
//System.out.println(publickeyc);
if (publickeyc != null) {
ObjectOutputStream outk = new ObjectOutputStream(key.getOutputStream());
outk.writeObject(publicKey);
outk.close();
}
key.close();
Servsockey.close();

66. 66
////////////////////////////////////////////
//
//key from client
//
////////////////////////////////////
boolean x = rsaEncryptor.ImportPublicKey(publickeyc);
//System.out.println(x);
boolean usePublicKey = false;
String encryptedStr1 = rsaEncryptor.encryptStringENC(encryptedStr, usePublicKey);
String encryptedStr2 = rsaEncryptor.encryptStringENC(encryptedStr4, usePublicKey);
//System.out.println(encryptedStr1);
//encryption of the hashed message done using public key of client
//JOptionPane.showMessageDialog(null,"Encrypted Sring:- "+encryptedStr1);
//Trying to receive part of encrypted key from Client
//Reading the message from the client
ServerSocket Servsoc = new ServerSocket(1000);
Socket sock = Servsoc.accept();
ObjectInputStream ois = new ObjectInputStream(sock.getInputStream());
String message1 = (String) ois.readObject();
String message2 = (String) ois.readObject();
//System.out.println(message);
if (message1 != null) {
ObjectOutputStream out = new ObjectOutputStream(sock.getOutputStream());
out.writeObject(encryptedStr1);
out.writeObject(encryptedStr2);
out.close();
}
sock.close();
Servsoc.close();

67. 67
//
//Get the string from Client here and then decrypt
//
//
// Now decrypt:
CkRsa rsaDecryptor = new CkRsa();
rsaDecryptor.put_EncodingMode("hex");
rsaDecryptor.ImportPrivateKey(privateKey);
usePrivateKey1 = true;
String decryptedStr = rsaDecryptor.decryptStringENC(message1, usePrivateKey1);
String decryptedStr2 = rsaDecryptor.decryptStringENC(message2, usePrivateKey1);
//System.out.println(decryptedStr);
CkRsa rsaDecryptor1 = new CkRsa();
rsaDecryptor1.put_EncodingMode("hex");
rsaDecryptor1.ImportPublicKey(publickeyc);
usePublicKey = false;
String decryptedStr1 = rsaDecryptor1.decryptStringENC(decryptedStr, usePublicKey);
String decryptedStr3 = rsaDecryptor1.decryptStringENC(decryptedStr2, usePublicKey);
//System.out.println(decryptedStr1);
/// Compare Hash
CkCrypt2 crypt3 = new CkCrypt2();
// Any string argument automatically begins the 30-day trial.
success = crypt3.UnlockComponent("T12302015Crypt_sHyDCAFgIR1v");
if (success != true) {
System.out.println(crypt3.lastErrorText());

68. 68
return;
}
String op = decryptedStr3;
crypt3.put_HashAlgorithm("sha1");
crypt3.put_EncodingMode("hex");
// Other possible EncodingMode settings are:
// "quoted-printable", "base64", and "url"
String hashnew = crypt3.hashStringENC(op);
//System.out.println(hashnew);
if (hashnew.equals(decryptedStr1) == true) {
System.out.println("Key is safe");
} else {
System.out.println("key is compromised");
}
//////////////
//
//Generate session key for AES
//
//////////////
CkCrypt2 crypt = new CkCrypt2();
success = crypt.UnlockComponent("T12302015Crypt_sHyDCAFgIR1v");
if (success != true) {
System.out.println(crypt.lastErrorText());
return;
}

69. 69
// AES is also known as Rijndael.
crypt.put_CryptAlgorithm("aes");
// CipherMode may be "ecb" or "cbc"
crypt.put_CipherMode("cbc");
// KeyLength may be 128, 192, 256
crypt.put_KeyLength(256);
// The padding scheme determines the contents of the bytes
// that are added to pad the result to a multiple of the
// encryption algorithm's block size. AES has a block
// size of 16 bytes, so encrypted output is always
// a multiple of 16.
crypt.put_PaddingScheme(0);
// EncodingMode specifies the encoding of the output for
// encryption, and the input for decryption.
// It may be "hex", "url", "base64", or "quoted-printable".
crypt.put_EncodingMode("hex");
// An initialization vector is required if using CBC mode.
// ECB mode does not use an IV.
// The length of the IV is equal to the algorithm's block size.
// It is NOT equal to the length of the key.
String keya = op + p;
String ivHex = "000102030405060708090A0B0C0D0E0F";
crypt.SetEncodedIV(ivHex, "hex");
// The secret key must equal the size of the key. For

70. 70
// 256-bit encryption, the binary secret key is 32 bytes.
// For 128-bit encryption, the binary secret key is 16 bytes.
String keyHex = keya;
crypt.SetEncodedKey(keyHex, "hex");
//Sending astring
ServerSocket Servsoc1 = new ServerSocket(7070);
Socket sock1 = Servsoc1.accept();
ObjectInputStream ois1 = new ObjectInputStream(sock1.getInputStream());
String message12 = (String) ois1.readObject();
String decStr = crypt.decryptStringENC(message12);
System.out.println(decStr);
if (message12 != null) {
ObjectOutputStream out = new ObjectOutputStream(sock1.getOutputStream());
String encStr = crypt.encryptStringENC("Hi Fox!!!Whats up???");
out.writeObject(encStr);
out.close();
}
sock.close();
Servsoc1.close();
//Sending a file
FileInputStream fis = null;
BufferedInputStream bis = null;
OutputStream os = null;
ServerSocket servsock = null;
Socket sockf = null;
try {
servsock = new ServerSocket(123);

71. 71
while (true) {
System.out.println("Waiting...");
try {
sockf = servsock.accept();
System.out.println("Accepted connection : " + sockf);
// send file
String filename = JOptionPane.showInputDialog("Name the file to be encrypted");
success = crypt.CkEncryptFile(filename,
"C:UsersThivyaDocumentsNetBeansProjectsaesEncrypted.dat");
if (success != true) {
System.out.println(crypt.lastErrorText());
return;
}
File myFile = new
File("C:UsersThivyaDocumentsNetBeansProjectsaesEncrypted.dat");
byte[] mybytearray = new byte[(int) myFile.length()];
fis = new FileInputStream(myFile);
bis = new BufferedInputStream(fis);
bis.read(mybytearray, 0, mybytearray.length);
os = sockf.getOutputStream();
//System.out.println("Sending " + FILE_TO_SEND + "(" + mybytearray.length + "
bytes)");
os.write(mybytearray, 0, mybytearray.length);
os.flush();
//System.out.println("Done.");
} finally {
if (bis != null) {
bis.close();
}
if (os != null) {

72. 72
os.close();
}
if (sockf != null) {
sockf.close();
}
}
}
} finally {
if (servsock != null) {
servsock.close();
}
}}}