THREE-PARTY PASSWORD-AUTHENTICATED KEY EXCHANGE

WITHOUT RANDOM ORACLES

Xun Yi

, Raylin Tso

and Eiji Okamoto

School of Engineering and Science, Victoria University, Melbourne, Victoria 8001, Australia

Department of Computer Science, National Chengchi University, Taipei 11605, Taiwan

Department of Risk Engineering, University of Tsukuba, Tsukuba, Ibaraki, 305-8573, Japan

Keywords:

Three-party PAKE, ID-based encryption scheme, ElGamal encryption scheme, Dictionary attack.

Abstract:

Password-authenticated key exchange (PAKE) in the 3-party setting is where two clients, who do not share

a password between themselves but only with a server, establish a common session key with the help of the

server. Abdalla, Fouque and Pointcheval were the ﬁrst formally to address 3-party PAKE issue and presented

a natural and generic construction from any 2-party PAKE protocols. Soon after, Abdalla and Pointcheval

presented a more efﬁcient 3-party PAKE protocol and proved its security in the random oracle model. In

this paper, we present a new 3-party PAKE protocol on the basis of identity-based encryption and ElGamal

encryption schemes. In our protocol, the client needs to remember passwords and the server’s identity only

while the server keeps passwords in addition to a private key related to its identity. We have put forth a formal

model of security for ID-based 3-party PAKE, and provided a rigorous proof of security for our protocol

without random oracles.

1 INTRODUCTION

Nowadays, most online business applications are

based on the client/server model, where it is common

for the client to choose a password as his private key

from a known small space, such as a dictionary of En-

glish words, in order to remember it, and then to share

it with the server for authentication. In order for the

client and the server who share a password to estab-

lish a common session key, with which to secure their

communications over an insecure network, password-

authenticated key exchange (PAKE) protocols are in

great demand.

PAKE protocols have to be immune to the dictio-

nary attack, in which an adversary exhaustively tries

all possible passwords from a dictionary in order to

determine the correct one. Even though these attacks

are not very effectivein the case of high-entropykeys,

they can be very damaging when the secret key is

a password since the attacker has a non-negligible

chance of winning. Dictionary attacks are usually di-

vided into off-line and on-line dictionary attacks.

Bellovin and Merritt (Bellovin and Merritt, 1992)

were the ﬁrst to consider authenticated key exchange

based on password only and introduced a series of

so-called “encrypted key exchange” (EKE) protocols.

Due to the practical signiﬁcance of PAKE, this initial

work has been followed by a number of protocol pro-

posals (Bellovin and Merritt, 1993; Gong et al., 1993;

Huang, 1996; Jablon, 1997; Lucks, 1997; Steiner

et al., 1995; Wu, 1998). However, only heuristic and

informal security arguments for these protocols were

provided. In fact, attacks against many of these pro-

tocols have been found (MacKenzie et al., 2000; Pa-

tel, 1997). This demonstrates the great importance of

rigorous proofs of security in a formal, well-deﬁned

model.

Formal models of security for PAKE were ﬁrstly

given independently by Bellare, Pointcheval and Ro-

gaway (Bellare et al., 2000), and Boyko, MacKen-

zie, Patel and Swaminathan (Boyko et al., 2000) in

2000. Based on these models, some efﬁcient PAKE

protocols (e.g.,(Abdalla et al., 2006; Abdalla and

Pointcheval, 2005; Bresson et al., 2003; Bresson

et al., 2004)) were constructed and proved to be se-

cure in the random oracle model. Katz et al. (Katz

et al., 2001) were the ﬁrst to give a PAKE proto-

col which is both practical and provably-secure un-

der standard cryptographic assumption. Their proto-

col was proved to be secure in the model of Bellare et

al. (Bellare et al., 2000) and based on the decisional

Difﬁe-Hellman assumption.

Yi X., Tso R. and Okamoto E..

THREE-PARTY PASSWORD-AUTHENTICATED KEY EXCHANGE WITHOUT RANDOM ORACLES.

DOI: 10.5220/0003446600150024

In Proceedings of the International Conference on Security and Cryptography (SECRYPT-2011), pages 15-24

ISBN: 978-989-8425-71-3

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

In practice, clients usually do not share any pass-

words between themselves but only with servers.

Can two clients, who share passwords with the same

server, respectively, establish a common session key

with the help of the server, where the key established

is known to the clients only and no one else, including

the server? This issue was formally addressed by Ab-

dalla, Fouque and Pointcheval (Abdalla et al., 2005;

Abdalla et al., 2006), and called 3-party PAKE (while

PAKE between single client and a server is called 2-

party PAKE).

In (Abdalla et al., 2005; Abdalla et al., 2006),

Abdalla, Fouque and Pointcheval put forth a formal

model of security for 3-party PAKE and presented a

natural and generic construction of a 3-party PAKE

from any secure 2-party PAKE. There are three phases

in their generic construction. In the ﬁrst phase, a

high-entropy session key is generated between the

server and each of the two clients using an instance

of the 2-party PAKE protocol for each client. In the

second phase, a message authentication code (MAC)

key is distributed by the server to each client using

a key distributed protocol. In the ﬁnal phase, both

clients execute an authenticated version of the Difﬁe-

Hellman keyexchangeprotocol (Krawczyk, 2003) us-

ing the MAC key obtained in the previous phase. The

generic construction was the ﬁrst provably-secure 3-

party PAKE protocol and does not rely on the random

oracles as long as the underlying primitives them-

selves do not rely on it. Though attractive and nat-

ural, the construction given in (Abdalla et al., 2005;

Abdalla et al., 2006) is not efﬁcient. Not only does it

require a large amount of computation by the server

and the clients, but it also needs a large number of

rounds (at least 6 rounds of communications). When

the underlying 2-party PAKE is the encrypted key

exchange protocol of Bellovin and Meritt (Bellovin

and Merritt, 1992), Abdalla and Pointcheval (Abdalla

and Pointcheval, 2005) presented a rather efﬁcient 3-

party PAKE protocol, specially when compared to the

generic construction in (Abdalla et al., 2005; Abdalla

et al., 2006), and prove its security in the random or-

acle model.

Other works related to the 3-party PAKE include

(Byun et al., 2002; Gong, 1995; Lin et al., 2000;

Wang et al., 2004; Yeh et al., 2003). As pointed out

in (Abdalla et al., 2005; Abdalla et al., 2006), none of

them enjoys provable security. Wen, Lee and Hwang

(Wen et al., 2005) presented a 3-party PAKE protocol

with Weil pairing, which was claimed to be provably

secure in the random oracle model under the bilin-

ear Difﬁe-Hellman assumption. However, their pro-

tocol has been shown to be insecure in the presence

of an active adversary in (Nam et al., 2007). This

means that their security proof was ﬂawed. Recently,

Huang (Huang, 2009) proposed a simple three-party

password-based authenticated key exchange protocol,

which is claimed to be not only secure against var-

ious attacks, but also more efﬁcient than previously

3-party PAKE protocols. However, Yoon and Yoo

(Yoon and Yoo, 2010) demonstrated that Huang’spro-

tocol is vulnerable to undetectable online password

guessing attacks and off-line password guessing at-

tacks by any other user.

Any group PAKE, where a group of clients, each

of them shares his password with an “honest but cu-

rious” server, intend to establish a common secret

key (i.e., the group key) with the help of the server,

can be used for 3-party PAKE. More recently, Yi et

al. (Yi et al., 2009) presented a compiler that trans-

forms any group key exchange protocol into group

PAKE. When using the compiler for 3-party PAKE,

two clients ﬁrstly run a 2-party key exchange pro-

tocol (e.g., (Difﬁe and Hellman, 1976)) to establish

a key without any help of the server, and then the

server helps the clients with mutual authentication

and key conﬁrmation by the shared passwords (pro-

tected with an identity-based encryption scheme), and

ﬁnally each client authenticates the server, along with

partnered client and the established key during the 2-

party key exchange, by an identity-based signature

scheme. This solution can achieve explicit mutual au-

thentication (that is, a party knowsits intended partner

has successfully computed a matching session key)

and has provablesecurity without random oracles, but

still needs 4 rounds of communications.

Contribution. To the best of our knowledge, exist-

ing 3-party PAKE protocols with explicit authentica-

tion and provable security without random oracles,

such as the generic construction (Abdalla et al., 2005;

Abdalla et al., 2006) and the ID-based group PAKE

compiler (Yi et al., 2009), usually need a large num-

ber of rounds, and thus are inefﬁcient. Is it possible

to achieve more efﬁcient and provably secure 3-party

PAKE without random oracles?

In this paper, we present a new construction of

3-party PAKE protocol, based on the identity-based

encryption (IBE) scheme with security against adap-

tive chosen ciphertextattacks without random oracles,

such as (Gentry, 2006; Waters, 2005), and the ElGa-

mal encryption scheme (ElGamal, 1985), which has

been proved to be secure against chosen-plaintext at-

tacks without random oracles providing that the Deci-

sional Difﬁe-Hellman (DDH) assumption holds (Wa-

ters, 2009). Our protocol needs only 2 rounds of com-

munications and enjoys provably security without

random oracles. It is rather efﬁcient, when compared

to the generic construction (Abdalla et al., 2005; Ab-

SECRYPT 2011 - International Conference on Security and Cryptography

dalla et al., 2006) and the ID-based group PAKE com-

piler (Yi et al., 2009) with provably security without

random oracles.

We put forth a formal model of security for ID-

based PAKE in the 3-party setting by embedding

Boneh et al.’s ID-based model (Boneh and Franklin,

2001; Boneh and Franklin, 2003) into Abdalla et al.’s

3-party PAKE model (Abdalla et al., 2005; Abdalla

et al., 2006). Under this model, we provide a rigorous

proof of security for our protocol.

2 DEFINITIONS

A formal model of security for 3-party PAKE was

ﬁrstly given by Abdalla et al. in (Abdalla et al., 2005;

Abdalla et al., 2006), based on Bellare et al.’s for-

mal model for 2-party PAKE. Boneh and Franklin

ﬁrstly deﬁned chosen ciphertext security for IBE un-

der chosen identity attack in (Boneh and Franklin,

2001; Boneh and Franklin, 2003). In this section,

we put forward a new model of security for ID-based

3-party PAKE, a combination of deﬁnitions given by

Abdalla et al. and Boneh et al.

Participants, Initialization and Passwords. An ID-

based 3-party PAKE protocol involves three kinds of

participants: (1) A set of clients (denoted as Client),

which is composed of two disjoint sets - the set of

honest clients (denoted as Client

), and the set of

malicious clients (denoted as Client

), i.e., Client =

Client

; (2) A set of servers (denoted as

Server), each behaves in an honest but curious man-

ner in terms that it honestly follows the protocol, but

may want to know the session key established be-

tween clients; (3) A set of of trusted third parties

(called the Private Key Generators (PKGs), denoted

as PKG

,PKG

,··· ,PKG

), which cooperate to gen-

erates public parameters and private keys for servers.

We assume that ClientServerPair is the set of pairs

of the client and the server, who share a common

password. In addition, User = Client

Server and

Client

Server =

Prior to any execution of the protocol, we assume

that an initialization phase occurs. During initial-

ization, PKGs cooperates to generate public param-

eters for the protocol, which are available to all par-

ticipants, and private keys for servers. For any pair

(A,S) ∈ ClientServerPair, the client A and the server S

are assumed to share the same password. We assume

that the client A chooses pw

independently and uni-

formly at random from a “dictionary” D = {pw

,pw

··· ,pw

} of size N, where N is a ﬁxed constant which

is independent of the security parameter. The pass-

word pw

is then stored at the server S for authentica-

tion.

Execution of the Protocol. In the real world, a proto-

col determines how users behave in response to input

from the environments. In the formal model, these

inputs are provided by the adversary. Each user is

assumed to be able to execute the protocol multiple

times (possibly concurrently) with different partners.

This is modeled by allowing each user to have unlim-

ited number of instances with which to execute the

protocol. We denote instance i of user U as U

. A

given instance may be used only once. The adversary

is givenoracle access to these differentinstances. Fur-

thermore, each instance maintains (local) state which

is updated during the course of the experiment. In

particular, each instance U

has associated with it the

variables sid

,pid

,acc

,term

,used

,state

,sk

initialized as NULL or FALSE (as appropriate) dur-

ing the initialization phase, as (Katz et al., 2001; Yi

et al., 2009).

• sid

and pid

are variables (initialized as NULL)

containing the session identity and partner iden-

tity for an instance, respectively. The session

identity sid

is simply a way to keep track of the

different executions of a particular user U. With-

out loss of generality, we simply let this be the

(ordered) concatenation of all messages sent and

received by instance U

. The partner identity pid

is the set of users with whom U

believes it is in-

teracting.

• acc

and term

are boolean variables (initialized

as FLASE) denoting whether a given instance has

been accepted or terminated, respectively. Ter-

mination means that the given instance has done

receiving and sending messages, acceptance indi-

cates successful termination.

• used

is a boolean variable (initialized as FLASE)

denoting whether an instance has begun executing

the protocol. This is a formalism which will en-

sure each instance is used only once.

• state

(initialized as NULL) records any state

necessary for execution of the protocol by a user

instance U

• sk

is a variable (initialized as NULL) containing

the session key for a client instance A

. Compu-

tation of the session key is, of course, the ulti-

mate goal of the protocol. When A

accepts (i.e.,

acc

= TRUE), sk

is no longer NULL.

The adversaryA is assumed to havecomplete con-

trol over all communications in the network and the

adversary’s interaction with the users (more speciﬁ-

cally, with various instances) or PKG is modeled via

access to oracles which we describe now. The state

THREE-PARTY PASSWORD-AUTHENTICATED KEY EXCHANGE WITHOUT RANDOM ORACLES

of an instance may be updated during an oracle call,

and the oracle’s output may depend upon the relevant

instance. The oracle types are as follows:

• Execute(A

) – If A

and S

have

not yet been used (where (A,S), (B, S) ∈

ClientServerPair, and A,B ∈ Client), this oracle

executes the protocol between these instances and

outputs the transcript of this execution. This ora-

cle call represents passive eavesdropping of a pro-

tocol execution. In addition to the transcript, the

adversary receives the values of sid, pid, acc, and

term for all instances, at each step of protocol ex-

ecution.

• Send(U

,M) – This sends message M to instance

. Assuming term

= FALSE, this instance

runs according to the protocol speciﬁcation, up-

dating state as appropriate. The output of U

(i.e., the message sent by the instance) is given

to the adversary, who receives the updated values

of sid

,pid

,acc

, and term

. This oracle call

models the active attack to a protocol.

• KeyGen(PKGs,S) – This sends the identity of the

server S to PKGs, which generate the private key

corresponding to S and forwards it to the ad-

versary. This oracle models possible compromis-

ing of a server due to, for example, hacking into

the server. This implies that all passwords stored

in the server are disclosed.

• Corrupt(PKG

) – This query allows the adversary

to learn the master secret key of a Private Key

Generator PKG

, which models possible compro-

mising of PKG

due to, for example, hacking into

PKG

• Corrupt(A) – This query allows the adversary to

learn the password of the client A, which models

the possibility of subverting a client by, for exam-

ple, witnessing a user type in his password, or in-

stalling a “Trojan horse” on his machine. Once

Corrupt(A) happens, A is no more honest, i.e.,

A ∈ Client

• Reveal(A

) – This outputs the current value of ses-

sion key sk

for a client instance if acc

= TRUE.

This oracle call models possible leakage of ses-

sion keys due to, for example, improper erasure

of session keys after use, or cryptanalysis.

• Test(A

) – This oracle does not model any real-

world capability of the adversary, but is instead

used to deﬁne security of the session key of client

instance A

. If acc

= TRUE, a random bit b is

generated. If b = 0, the adversary is givensk

, and

if b = 1 the adversary is given a random session

key. The adversary is allowed only a single Test

query, at any time during its execution.

Partnering. The deﬁnition of partnering uses the no-

tion of session identity sid, which is the partial tran-

script of the conversation among the clients and the

server. We say that client instances A

and B

are

partnered if there exists a server instance S

such

that (1) (A,S),(B,S) ∈ ClientServerPair; (2) sid

sid

|sid

6= NULL; and (3) pid

= pid

NULL. The notion of partnering will be fundamen-

tal in deﬁning both correctness and security.

Correctness. To be viable, a key exchange protocol

must satisfy the following notion of correctness: if A

and B

are partnered and acc

= acc

= TRUE, then

it must be the case that sk

= sk

(i.e., they conclude

with the same session key).

Freshness. Informally, the adversary succeeds if it

can guess the bit b used by the Test oracle. Before for-

mally deﬁning the adversary’s success, we must ﬁrst

deﬁne a notion of freshness. A honest client instance

is fresh unless one of the following is true at the

conclusion of the experiment, namely, at some point,

• The adversary queried Reveal(A

) or Reveal(B

)

with the instances A

and B

being partnered.

• The adversary queried all Corrupt(PKG

)

(i = 1, 2, · · · ,n) before a query of the form

Send(U

ℓ

,M), where U

ℓ

∈ pid

, has taken place,

for some message M (or identities).

• The adversary queried KeyGen(PKGs,S), where

there exists a server instance S

∈ pid

, before a

query of the form Send(U

ℓ

,M), where U

ℓ

∈ pid

has taken place, for some message M (or identi-

ties).

• The adversary queried Corrupt(A) or Corrupt(B)

where there exists a instance B

∈ pid

, before a

query of the form Send(U

ℓ

,M), where U

ℓ

∈ pid

has taken place, for some message M (or identi-

ties).

The adversary is thought to succeed only if its

Test query is made to a fresh instance.

Advantage of the Adversary. We say an adversary A

succeeds if it makes a single query Test(A

) to a fresh

client instance A

, with acc

= TRUE at the time of

this query, and outputs a single bit b

′

with b

′

= b (re-

call that b is the bit chosen by the Test oracle). We

denote this event by Succ. The advantage of adver-

sary A in attacking protocol P is then given by

Adv

A ,P

(k) = 2· Pr[Succ] − 1

where the probability is taken over the random coins

used by the adversary and the random coins used dur-

SECRYPT 2011 - International Conference on Security and Cryptography

ing the course of the experiment (including the initial-

ization phase). It remains to deﬁne what we mean by a

secure protocol. Note that a probabilistic polynomial-

time (PPT) adversary can always succeed by trying

all passwords one-by-one in an on-line impersonation

attack. This is possible since the size of the password

dictionary is constant. Informally, a protocol is se-

cure if this is the best an adversary can do. Formally,

an instance U

represents an on-line attack if both the

following are true at the time of the Test query: (1)

at some point, the adversary queried Send(U

,∗), and

(2) at some point, the adversary queried Reveal(A

)

or Test(A

), where A ∈ Client and either A = U or

A ∈ pid

In particular, instances with which the adversary

interacts via KeyGen, Execute, and Corrupt queries

are not counted as on-line attacks. The number of

on-line attacks represents a bound on the number of

passwords the adversary could have tested in an on-

line fashion.

Deﬁnition 1. Protocol P is a secure protocol for 3-

party PAKE if, for all dictionary size N and for all

PPT adversaries A making at most Q(k) on-line at-

tacks, there exists a negligible function ε(·) such that

Adv

A ,P

(k) ≤ Q(k)/N + ε(k)

The above deﬁnition ensures that the adversary can

(essentially) do no better than guess a single pass-

word during each on-line attack. Calls to the KeyGen,

Execute and Corrupt oracles, which are not included

in Q(k), are of no help to the adversary in breaking

the security of the protocol. This means the passive

attacks and off-line dictionary attacks are of no use.

3 ID-BASED 3-PARTY PAKE

PROTOCOL

The high-level depiction of the protocol is illustrated

in Fig. 1, and a more detailed description follows. A

completely formal speciﬁcation of the protocol will

appear in Section 4.

We present the protocol by describing initializa-

tion and execution. We let k be the security parameter

given to the setup algorithm.

Initialization. Given a security parameter k ∈ Z

∗

, the

initialization works as follows:

Parameter Generation

. On input k, Private Key Gener-

ators, PKG

,PKG

,··· , PKG

, cooperate to generate

public parameters params

IBE

and master-secrets

IBE

for the IBE scheme, such as (Waters, 2005; Gen-

try, 2006), and a group G with a generator g of

prime order q with |q| = k for the ElGamal encryp-

tion scheme, and choose two hash functions H :

{0,1}

∗

→ M (where M stands for the plaintext group

of the IBE) and h : {0, 1}

∗

→ G from a collision-

resistant family. The public parameters Params =

{params

IBE

,(G,g,q),H,h}.

Key Generation

. On input S ∈ Server, PKGs coop-

erate to set a private key d

for the server S such

that d

is only known to the server S as long as

one of PKGs is trusted. For example, based on the

Boneh-Franklin IBE scheme (Boneh and Franklin,

2001)(Boneh and Franklin, 2003), a PKG

chooses

a master secret key s

randomly and publishes P

G as its public key. The common public key P =

∑

i=1

. Given the identity ID

of the server S, each

PKG

sends d

= s

H(ID

) to S via a secure chan-

nel. The secret key d

of S is set as

∑

i=1

Password Generation

. On input (A,S) ∈

ClientServerPair, the client A chooses a string

, the password, uniformly drawn from the dic-

tionary Password = {pw

,pw

,··· ,pw

}, and then

store it in the server S. We implicitly assume that

N < q, which will certainly be true in practice.

Protocol Execution. For any A,B ∈ Client,

where there exists a server S such that (A,S), (B, S) ∈

ClientServerPair, when A (with password pw

) and B

(with password pw

) want to establish a session key

via S, the client A ﬁrstly randomly chooses r

∈ Z

∗

and computes g

= g

and an IBE encryption of

H(A|B|S|g

|pw

) based on the identity of the server

, denoted as c

. Then the client A sends msg

A|B|S|g

to the server S.

Similarly, the client B randomly chooses r

∈ Z

∗

and computes g

= g

and an IBE encryption of

H(B|A|S|g

|pw

) based on ID

, denoted as c

. Then

the client B sends msg

= B|A|S|g

to the server S.

Upon receiving the messages msg

and msg

, the

server S decrypts the ciphertexts with its private key

and then veriﬁes the passwords. Both clients A

and B are authenticated if

IBD[c

] = H(A|B|S|g

|pw

) (1)

IBD[c

] = H(B|A|S|g

|pw

) (2)

If both (1) and (2) hold, S randomly chooses r

∈ Z

∗

and computes g

= g

, g

= g

, an ElGamal en-

cryption of h(S|A|B|g

|pw

) based on the public key

, denoted as c

, and an ElGamal encryption of

h(S|B|A|g

|pw

) based on the public key g

, de-

noted as c

. Then the server S sends msg

S|A|B|g

and msg

= S|B|A|g

to A and B,

respectively. If either (1) or (2) does not hold, the

server S sends a failure notiﬁcation to A and B, re-

spectively, and then terminates the protocol.

THREE-PARTY PASSWORD-AUTHENTICATED KEY EXCHANGE WITHOUT RANDOM ORACLES

Params ← {params

IBE

,(G,g,q),H,h}

Client A (pw

) Client B (pw

)

← Z

∗

← g

← IBE[H(A|B|S|g

|pw

),ID

]

msg

← A|B|S|g

← Z

∗

← g

← IBE[H(B|A|S|g

|pw

),ID

]

msg

← B|A|S|g





Server S (pw

,pw

)

If IBD[c

] 6= H(A|B|S|g

|pw

) ∨ IBD[c

] 6= H(B|A|S|g

|pw

), return ⊥

← Z

∗

← g

← E(h(S|A|B|g

|pw

),g

],c

← E(h(S|B|A|g

|pw

),g

]

msg

← S|A|B|g

msg

← S|B|A|g





If D[c

] 6= h(S|A|B|g

|pw

), re. ⊥

← g

If D[c

] 6= h(S|B|A|g

|pw

), re. ⊥

← g

Figure 1: ID-based 3-party password-authenticated key exchange.

Upon receiving msg

, the client A decrypts the

ciphertext c

with its private key r

and then veriﬁes

the password pw

. Both the server S and the client B

are authenticated if

D[c

] = h(S|A|B|g

|pw

) (3)

If so, A computes the session key sk

= g

. Other-

wise, A sends a failure notiﬁcation to S and B, respec-

tively, and then terminates the protocol.

Similarly, upon receiving msg

, B decrypts the

ciphertext c

with its private key r

and then veriﬁes

the password pw

. Both the server S and the client A

are authenticated if

D[c

] = h(S|B|A|g

|pw

) (4)

If so, B computes the session key sk

= g

. Other-

wise, B sends a failure notiﬁcation to S and A, respec-

tively, and then terminates the protocol.

Correctness. In an honest execution of the protocol,

the clients A and B compute identical session keys be-

cause

= g

= (g

)

= (g

)

= g

= (g

)

= (g

)

= g

Explicit Authentication. By verifying (1)-(2), the

server S is certain that clients A and B are authenti-

cated. By verifying (3) (or (4)), the client A (or B)

is certain that S and B (or S and A) are authenticated.

The session keys sk

and sk

derived from authen-

ticated messages are authenticated. This shows that

our protocol achieves explicit authentication, that is, a

party knows that its intended partner has successfully

computed a matching session key. Note that previous

3-party PAKE protocols achieved implicit authentica-

tion only (e.g., (Abdalla et al., 2005; Abdalla et al.,

2006; Abdalla and Pointcheval, 2005)).

4 PROOF OF SECURITY

We follow the method of the security proof given by

Katz et al. in (Katz et al., 2001) to prove the security

of our protocol without random oracles.

Given an adversary A , we imagine a simulator that

runs the protocol for A . More preciously, the simula-

tor begins by running algorithm Initialize(1

) (which

includes choosing passwords for clients) and giving

the public output of the algorithm to A . When A

queries an oracle, the simulator also responds by ex-

ecuting the appropriate algorithm. The simulator also

records all state information deﬁned during the course

of the experiment. In particular, when the adversary

queries the Test oracle, the simulator chooses (and

records) the random bit b. When the adversary com-

pletes its execution and outputs a bit b

′

, the simulator

can tell whether the adversary succeeds by checking

whether (1) a single Test query was made, for some

client instance U

; (2) acc

was true at the time of

Test query; (3) instance U

is fresh; and (4) b

′

= b.

Success of the adversary is denoted by event Succ.

For any experiment P we deﬁne Adv

A ,P

(k) =

2Pr

A ,P

[Succ]−1 where Pr

A ,P

[·] denotes the probabil-

SECRYPT 2011 - International Conference on Security and Cryptography

Initialize(1

)

(params

IBE

,master-secret

IBE

← Setup

IBE

), {G,g,q}

← Setup

ElGamal

)

{H,h}

← CRHF(1

)

(Client,Server,ClientServerPair)

← UserGen(1

)

For each i ∈ {1,2,··· } and each U ∈ User

acc

← term

← used

← FALSE,sid

← pid

← sk

← NULL

For each S ∈ Server,

← Extract(params

IBE

,master-secrets

IBE

)

For each (A,S) ∈ ClientServerPair, pw

← {pw

,pw

,·· · ,pw

}

Return Client,Server, ClientServerPair,params

IBE

,master-secret

IBE

,{G,g,q},H,h

Figure 2: Speciﬁcation of the initialize.

Execute(A

), where A,B ∈ Client

If (A,S) ∨ (B,S) 6∈ ClientServerPair ∨ used

∨ used

, return ⊥

used

← used

← TRUE,pid

← pid

← {A

}

← Z

∗

← g

← IBE[H(A

|pw

),ID

]

msg

← A

← Z

∗

← g

← IBE[H(B

|pw

),ID

]

msg

← B

← Z

∗

← g

← E[h(S

|pw

),g

],c

← E[h(S

|pw

),g

]

msg

← S

,msg

← S

sid

← msg

|msg

,sid

← msg

|msg

,sid

← sid

|sid

acc

← term

← acc

← term

← acc

← term

← TRUE

← sk

← g

Return status

,status

Figure 3: Speciﬁcation of the Execute oracle.

ity of an event when the simulator interacts with the

adversary A in accordance with experiment P.

Based on the deﬁnition of security described in

Section 2, we have

Theorem 1. Assume that (1) the decisional Difﬁe-

Hellman (DDH) problem is hard over (G,g,q); (2) the

IBE scheme has chosen ciphertext security under cho-

sen identity attack without random oracles; (3) CRHF

is a collision-resistant hash family; then the protocol

described in Fig. 1 is a secure ID-based 3-party PAKE

protocol.

Sketch of Proof. First of all, we provide a formal

speciﬁcation of the Initialize, Execute, Send, KeyGen,

Corrupt, Reveal, and Test oracles in Fig. 2-5.

The description of the Execute oracle matches the

high-level protocol described in Fig. 1, but additional

details (for example, the updating of state informa-

tion) are included. We let status

denote the vec-

tor of values (sid

,pid

,acc

,term

) associated with

instance U

. We begin with some terminology that

will be used throughout the proof. A given msg is

called oracle-generated if it was output by the sim-

ulator in response to some oracle query (whether a

Send or Execute query). The message is said to be

adversarially-generated otherwise. An adversarially-

generated message must not be the same as any

oracle-generated message.

We refer to the real execution of the experiment

as P

. We introduce a sequence of transformations to

the original experiment and bound the effect of each

transformation on the adversary’s advantage. We then

bound the adversary’s advantage in the ﬁnal experi-

ment. This immediately yields a bound on the adver-

sary’s advantage in the original experiment.

Experiment P

: In this experiment, the simulator in-

THREE-PARTY PASSWORD-AUTHENTICATED KEY EXCHANGE WITHOUT RANDOM ORACLES

KeyGen(PKGs,S)

← Extract(params,master-secrets)

Return d

Corrupt(PKG

)

Return master-secret

Corrupt(A)

Return pw

Reveal(A

)

Return sk

Test(A

)

← {0,1},sk

′

← Z

∗

If b = 1 return sk

′

else return sk

Figure 4: Speciﬁcation of KeyGen, Corrupt, Reveal and Test oracles.

teracts with the adversary as before except that at any

point during the experiment, an oracle-generatedmes-

sage is repeated or a collision occurs in the hash func-

tions h,H. It is immediate that the two events occur

with only negligible probability. Put everything to-

gether, we can see that |Adv

(k) − Adv

(k)| is neg-

ligible.

Experiment P

: In this experiment, the simulator in-

teracts with the adversary A as in experiment P

ex-

cept that the adversary’s queries to Execute oracles

are handled differently: for any Execute(A

)

oracle, the session keys sk

and sk

are replaced with

the same random value from G.

The difference between the current experiment

and the previous one is bounded by the probability

that an adversary solves the DDH problem. More pre-

cisely, if the decisional Difﬁe-Hellman (DDH) prob-

lem is hard over (G,q,g), then |Adv

(k) −Adv

(k)|

is negligible.

Experiment P

: In this experiment, we modify the

simulator’s responses to Send

and Send

queries.

When the adversary makes an oracle query

Send

, msg

) (or Send

,msg

)) to a fresh

sever instance S

, the simulator examines msg

(or

msg

). If it is adversarially-generated and valid, the

simulator halts and acc

is assigned the special value

∇. In any other case, the query is answered exactly

as in experiment P

. When the adversary makes an

oracle query Send

,msg

) (or Send

,msg

))

to a fresh client instance A

(or B

), the simulator

examines msg

(or msg

) . If it is adversarially-

generated and valid, the simulator halts and acc

(or

acc

) is assigned the special value ∇. In any other

case, the query is answered exactly as in experiment

Now, we change the deﬁnition of the adver-

sary’s success in P

. If the adversary ever queries

Send

,∗) to a fresh server instance S

with acc

∇ or Send

,∗) (or Send

,∗)) to a fresh client

instance A

(or B

) with acc

= ∇ (or acc

= ∇), the

simulator halts and the adversary succeeds. Other-

wise the adversary’s success is determined as in ex-

periment P

. Therefore, Adv

(k) ≤ Adv

(k).

Experiment P

: In this experiment, the simula-

tor interacts with the adversary A as in exper-

iment P

except that the adversary’s queries to

Execute and Send

oracles are handled differently:

for Execute(A

) or Send

) queries

to the fresh client instance A

, c

is computed as

IBE[H(A

|pw

′

),ID

] where pw

′

is randomly

chosen from D .

The difference between the current experiment

and the previous one is bounded by the probability

that an adversary breaks the IBE scheme. If the IBE

scheme is secure against the chosen-ciphertext attack,

then |Adv

(k) − Adv

(k)| is negligible.

Experiment P

: In this experiment, the simulator

interacts with A as in experiment P

except that

the adversary’s queries to Send

oracles are han-

dled differently: for Send

,msg

) queries to

the fresh client instance A

, c

is computed as

E[H(S

|pw

′

),g

] where pw

′

is randomly

chosen from D .

The difference between the current experiment

and the previous one is bounded by the probability

that an adversary breaks the ElGamal scheme. If

the ElGamal scheme is secure against the chosen-

plaintext attack under the assumption that the DDH

problem is hard, then |Adv

(k) − Adv

(k)| is negli-

gible.

In experiment P

, for any adversarially-generated

Send

,∗) or Send

,∗) queries to the fresh in-

stances S

or A

, all Execute and Send queries are in-

dependent of the passwords pw

or pw

in the view

of the adversary.

In order to win the game by online attacks, the

adversary has to try all passwords one-by-one in an

online impersonation attack. This probability is at

most Q(k)/N, where Q(k) is the number of online at-

tacks made by the adversary. If online attacks do not

occur, the adversary’s probability of success is 1/2.

The preceding discussion implies that Pr

[Succ] ≤

Q(k)/N + 1/2·(1− Q(k)/N) and thus the adversary’s

advantage in experiment P

is at most Q(k)/N.

SECRYPT 2011 - International Conference on Security and Cryptography

Send

)

If (A,S) 6∈ ClientServerPair ∨ used

, return ⊥

used

← TRUE,pid

← {A

}

← Z

∗

← g

← IBE[H(A|B|S|g

|pw

),ID

]

msg

← A

,state

← (r

,msg

)

Return status

Send

,msg

),msg

))

If (A,S) ∨ (B,S) 6∈ ClientServerPair ∨ used

, return ⊥

used

← TRUE,pid

← {A

}

If IBD[c

] = H(A

|pw

) ∧ IBD[c

] = H(B

|pw

)

{ r

← Z

∗

← g

← E[h(S

|pw

),g

],c

← E[h(S

|pw

),g

]

msg

← S

,msg

← S

sid

← (msg

|msg

)|(msg

|msg

),acc

← term

← TRUE }

Else {term

← TRUE}

Return status

Send

,msg

))

If ¬used

∨ term

∨ {S

} 6∈ pid

, return ⊥

state

← (r

,msg

)

If D[c

] = h(S

|pw

)

{ sid

← msg

|msg

,acc

← term

← TRUE,sk

← g

}

Else {term

← TRUE}

Return status

Figure 5: Speciﬁcation of the Send oracles.

5 CONCLUSIONS

In this paper, we have presented a security model for

ID-based 3-party PAKE at ﬁrst and then proposed

a construction for ID-based 3-party PAKE. Assume

that the DDH problem is hard and the underlying IBE

scheme has chosen ciphertext security, we have pro-

vided a rigorous proof of security for our protocol

without random oracles.

REFERENCES

Abdalla, M., Fouque, P. A., and Pointcheval, D. (2005).

Password-based authenticated key exchange in the

three-party setting. In Proc. PKC’05, pages 65–84.

Abdalla, M., Fouque, P. A., and Pointcheval, D. (2006).

Password-based authenticated key exchange in the

three-party setting. IEE Proceedings in Information

Security, 153(1):27–39.

Abdalla, M. and Pointcheval, D. (2005). Interactive difﬁe-

hellman assumption with applications to password-

based authentication. In Proc. FC’05, pages 341–356.

Bellare, M., Pointcheval, D., and Rogaway, P. (2000). Au-

thenticated key exchange secure against dictionary at-

tacks. In Proc. Eurocrypt’00, pages 139–155.

Bellovin, S. M. and Merritt, M. (1992). Encrypted key ex-

change: Password-based protocol secure against dic-

tionary attack. In Proc. 1992 IEEE Symposium on Re-

search in Security and Privacy, pages 72–84.

Bellovin, S. M. and Merritt, M. (1993). Augmented en-

crypted key exchange: a password-based protocol se-

cure against dictionary attacks and password ﬁle com-

promise. In Proc. CCS’93, pages 244–250.

Boneh, D. and Franklin, M. (2001). Identity based encryp-

tion from the weil pairing. In Proc. Crypto’01, pages

213–229.

Boneh, D. and Franklin, M. (2003). Identity based encryp-

tion from the weil pairing. SIAM Journal of Comput-

ing, 32(3):586–615.

Boyko, V., Mackenzie, P., and Patel, S. (2000). Prov-

ably secure password-authenticated key exchange us-

ing difﬁe-hellman. In Proc. Eurocrypt’00, pages 156–

171.

Bresson, E., Chevassut, O., and Pointcheval, D. (2003). Se-

curity proofs for an efﬁcient password-based key ex-

change. In Proc. CCS’03.

Bresson, E., Chevassut, O., and Pointcheval, D. (2004).

THREE-PARTY PASSWORD-AUTHENTICATED KEY EXCHANGE WITHOUT RANDOM ORACLES

New security results on encrypted key exchange. In

Proc. PKC’04, pages 145–158.

Byun, J. W., Jeong, I. R., Lee, D. H., and Park, C. S. (2002).

Password-authenticated key exchange between clients

with different passwords. In Proc. ICICS’02, pages

134–146.

Difﬁe, W. and Hellman, M. (1976). New directions

in cryptography. IEEE Trans. Information Theory,

22(6):644–654.

ElGamal, T. (1985). A public-key cryptosystem and a sig-

nature scheme based on discrete logarithms. IEEE

Trans. Information Theory, 32(4):469472.

Gentry, C. (2006). Practical identity-based encryption with-

out random oracle. In Proc. Eurocrypt’06, pages 445–

464.

Gong, L. (1995). Optimal authentication protocols resistant

to password guessing attacks. In Proc. 8th IEEE Com-

puter Security Foundations Workshop, pages 24–29.

Gong, L., Lomas, T. M. A., Needham, R. M., and Saltzer,

J. H. (1993). Protecting poorly-chosen secret from

guessing attacks. IEEE J. on Selected Areas in Com-

munications, 11(5):648–656.

Huang, H. F. (1996). Strong password-only authenticated

key exchange. ACM Computer Communication Re-

view, 26(5):5–20.

Huang, H. F. (2009). A simple three-party password-based

key exchange protocol. International Journal of Com-

munication Systems, 22(7):857862.

Jablon, D. (1997). Extended password key exchange pro-

tocol immune to dictionary attack. In Proc. of WET-

ICE’97, pages 248–255.

Katz, J., Ostrovsky, R., and Yung, M. (2001). Efﬁcient

password-authenticated key exchange using human-

memorable passwords. In Proc. Eurocrypt’01, pages

457–494.

Krawczyk, H. (2003). Sigma: The “sign-and-mac” ap-

proach to authenticated difﬁe-hellman and its use in

the ike protocols. In Proc. Crypto’03, pages 17–21.

Lin, C. L., Sun, H. M., and Hwang, T. (2000). Three-party

encrypted key exchange: attacks and a solution. ACM

SIGOPS Operating System Review, 34(4):12–20.

Lucks, S. (1997). Open key exchange: How to defeat dic-

tionary attacks without encryption public keys. In Se-

curity Protocol Workshop’97, pages 79–90.

MacKenzie, P., Patel, S., and Swaminathan, R. (2000).

Password-authenticated key exchange based on rsa. In

Proc. Asiacrypt’00, pages 599–613.

Nam, J., Kim, S., and Won, D. (2007). Security weakness

in a three-party password-based key exchange proto-

col using weil pairing. Information Sciences: an In-

ternational Journal, 177(6):1364–1375.

Patel, S. (1997). Number-theoretic attack on secure pass-

word scheme. In Proc. IEEE Symposium on Research

in Security and Privacy, pages 236–247.

Steiner, M., Tsudik, G., and Widner, M. (1995). Reﬁne-

ment and extension of encrypted key exchange. ACM

Operating System Review, 29(3):22–30.

Wang, S., Wang, J., and Xu, M. (2004). Weakness of

a password-authenticated key exchange protocol be-

tween clients with different passwords. In Proc.

ACNS’04, pages 414–425.

Waters, B. (2005). Efﬁcient identity-based encryption with-

out random oracles. In Proc. Eurocrypt’05, pages

114–127.

Waters, B. (2009). Elgamal encryption. In

CS395T Advanced Cryptography Lectures.

http://userweb.cs.utexas.edu/˜rashid/395Tcrypt/2 1.pdf.

Wen, H. A., Lee, T. F., and Hwang, T. (2005). Provably

secure three-party password-based authentication key

exchange protocol using weil pairing. IEE Proceeding

- Communications, 152(2):138–143.

Wu, T. (1998). The secure remote password protocol. In

Proc. Internet Society Symp. on Network and Dis-

tributed System Security, pages 97–111.

Yeh, H. T., Sun, H. M., and Hwang, T. (2003). Efﬁcient

three-party authentication and key agreement proto-

cols resistant to password guessing attacks. Journal

of Information Science and Engineering, 19(6):1059–

1070.

Yi, X., Tso, R., and Okamoto, E. (2009). Id-based

group password-authenticated key exchange. In Proc.

IWSEC’09, pages 192–211.

Yoon, E. J. and Yoo, K. Y. (2010). Cryptanalysis of a sim-

ple three-party password-based key exchange proto-

col. International Journal of Communication Systems.

SECRYPT 2011 - International Conference on Security and Cryptography