Password-Only Authenticated Three-Party Key Exchange Proven Secure against Insider Dictionary Attacks

While a number of protocols for password-only authenticated key exchange (PAKE) in the 3-party setting have been proposed, it still remains a challenging task to prove the security of a 3-party PAKE protocol against insider dictionary attacks. To the best of our knowledge, there is no 3-party PAKE protocol that carries a formal proof, or even definition, of security against insider dictionary attacks. In this paper, we present the first 3-party PAKE protocol proven secure against both online and offline dictionary attacks as well as insider and outsider dictionary attacks. Our construct can be viewed as a protocol compiler that transforms any 2-party PAKE protocol into a 3-party PAKE protocol with 2 additional rounds of communication. We also present a simple and intuitive approach of formally modelling dictionary attacks in the password-only 3-party setting, which significantly reduces the complexity of proving the security of 3-party PAKE protocols against dictionary attacks. In addition, we investigate the security of the well-known 3-party PAKE protocol, called GPAKE, due to Abdalla et al. (2005, 2006), and demonstrate that the security of GPAKE against online dictionary attacks depends heavily on the composition of its two building blocks, namely a 2-party PAKE protocol and a 3-party key distribution protocol.


Introduction
Key exchange protocols (also known as key establishment protocols) enable two or more parties communicating over a public network to establish a shared secret key. This secret key, called a session key, is then used for building a confidential or integrity-preserving communication channel between the involved parties. Typically, a key exchange protocol is integrated with an authentication mechanism so that each party can ensure that the session key is in fact shared with the intended parties and not with an impostor. Achieving authenticated key exchange (AKE) inevitably requires some secret information to be preestablished between the parties during an initialization phase. Password-only authenticated key exchange (PAKE) protocols, for example, are designed to work when the preestablished secret information for authentication is only a human-memorable password.
The design of secure PAKE protocols continues to be a subject of active research. A major challenge in designing a PAKE protocol is to prevent dictionary attacks, in which an attacker exhaustively enumerates all possible passwords to find out the correct password. The difficulty of designing PAKE protocols secure against dictionary attacks is compounded in the 3-party setting, in which two clients wishing to establish a session key share their individual passwords only with an authentication server but not with any other client. A 3-party PAKE protocol must prevent potential dictionary attacks by a malicious client, who is registered with the server and thus is able to set up normal protocol sessions with other clients. (Throughout the paper, we will use the term "insider attacks" to refer to attacks mounted by a registered (malicious) client and use the term "outsider attacks" to refer to attacks mounted by a nonregistered party.) Indeed, a cursory review of 2 The Scientific World Journal the literature suggests that the majority of attacks mounted against 3-party PAKE protocols fall into the category of insider dictionary attacks; see, for example, Section 2 as well as [1][2][3][4][5][6].
The difficulties of obtaining a high level of assurance in the security of almost any new, or even existing, protocol are well illustrated with examples of errors found in many such protocols years after they were published. A widely accepted approach is to use a deductive reasoning process whereby the emphasis is placed on a proven reduction from the problem of breaking the protocol to another problem believed to be hard. Such an approach for key exchange protocols was made popular by Bellare and Rogaway [7] who provide the first formal definition for a model of adversary capabilities with an associated definition of the indistinguishabilitybased security. This model has been further revised several times, and one of the more recent revisions is the realor-random (ROR) model proposed by Abdalla et al. [8,9] for PAKE protocols. They also proposed a generic construction of a 3-party PAKE protocol that allows existing provably secure 2-party password-based key exchange and 3-party symmetric key distribution protocols to be plugged and played in a modular approach and yet remain secure [8,9].
To date, a number of 3-party PAKE protocols have been presented with a formal proof of security [1,[8][9][10][11][12][13][14][15][16][17]. Most of these protocols were proven secure only in a restricted model, in which the adversary is not allowed to corrupt protocol participants [1,[8][9][10][12][13][14]. In other words, these protocols were not proven secure against insider attacks including dictionary attacks conducted by insiders. Some protocols [11,13] were subsequently found to be flawed [6,18] and several protocols [15,16] were proven secure only in a model that cannot capture (both insider and outsider) online dictionary attacks. Although protocols such as those of [19,20] claimed to be provably secure against dictionary attacks of any kind, these protocols assume a "hybrid" 3-party setting where a server's public key is required in addition to passwords (see [21][22][23][24][25][26][27] for other protocols designed to work in a hybrid setting). To the best of our knowledge, no 3-party PAKE protocol has been proven secure against insider dictionary attacks.
We regard the contributions of this paper to be threefold.

Contribution 1.
We present the first 3-party PAKE protocol, a hashed variant of the protocol of [1], whose indistinguishability-based security as well as password security against all classes of dictionary attacks are formally proved in a well-defined communication model. Similar to the protocols of [1,8,9], our proposed protocol is generic in the sense that it can be constructed from any 2-party AKE protocol. Our construct can be viewed as a protocol compiler that transforms any 2-party AKE protocol into a 3-party AKE protocol with 2 more rounds of communication. If the given 2-party protocol is password-only authenticated, then the 3party protocol output by the compiler will also be passwordonly authenticated. We prove the security of our construct in the random oracle model under the gap Diffie-Hellman (GDH) assumption; see Section 4.

Contribution 2.
We offer a simple and intuitive approach of capturing dictionary attacks in the widely accepted model of Bellare et al. [28]. First, we clarify the relationship between the indistinguishability-based security of session keys and the password security against dictionary attacks.
(i) The indistinguishability-based security property in the Bellare-Pointcheval-Rogaway model implies security against (both insider and outsider) offline dictionary attacks. We demonstrate this by showing that a protocol cannot achieve the indistinguishabilitybased security if it is not secure against an offline dictionary attack (see Section 3.3).
(ii) The indistinguishability-based security property does not imply security against undetectable online dictionary attacks (referred to as "UD online dictionary attacks" in the remainder of this paper). It is important to note that a protocol may be insecure against a UD online dictionary attack but it can still achieve the indistinguishability-based security (see Section 3.3).
This observation allows us to exclude offline dictionary attacks from our consideration once we have proved the indistinguishability-based security. We then introduce a new security definition to capture UD online dictionary attacks. We claim that our approach, when compared to those of [19,20] (where a separate security definition is introduced to capture both UD online and offline dictionary attacks), provides a more intuitive and simpler way of proving security against dictionary attacks (see Section 3).

Contribution 3.
We revisit the generic protocol GPAKE of Abdalla et al. [8,9] to provide a detailed analysis of its security against UD online dictionary attacks. (We note that the work of Wang and Hu [1] has only provided a sketch of an insider UD online dictionary attack against GPAKE.) GPAKE is parameterized with a 2-party PAKE protocol 2PAKE and a 3-party key distribution protocol 3KD. We found that the security of GPAKE against both insider and outsider UD online dictionary attacks depends heavily on the security properties provided by 2PAKE and 3KD. For example, we can launch an insider UD online dictionary attack against the protocol GPAKE if neither 2PAKE nor 3KD provides client-to-server authentication. An outsider UD online dictionary attack can also be mounted under the same condition in addition to the condition that 2PAKE provides server-to-client authentication (see Section 2 for details).

Undetectable Online Dictionary Attacks against GPAKE
This section presents a comprehensive analysis of the security of the GPAKE protocol [8,9] against UD online dictionary attacks. Our analysis shows that (1) GPAKE relies its security against UD online dictionary attacks on how its building blocks are instantiated and (2) the attacks could be mounted not only by a registered client (an insider) but also by a nonregistered party (an outsider). After conducting the The Scientific World Journal Figure 1: GPAKE: Abdalla et al. 's generic 3-party PAKE protocol [8,9]. security analysis, we suggest possible combinations of the instantiations that allow the GPAKE protocol to avoid the attacks.

A Review of GPAKE.
The GPAKE protocol is constructed using a combination of three building blocks: (1) a 2party PAKE protocol 2PAKE, (2) a 3-party key distribution protocol 3KD, and (3) a message authentication code-(MAC-) based Diffie-Hellman key exchange protocol MDH. Let G be a finite cyclic group generated by an element ; and let Σ = (Mac, Ver) be a MAC scheme where Mac and Ver are the MAC generation and MAC verification algorithms, respectively. The security of MDH relies on the hardness of the decisional Diffie-Hellman (DDH) problem in G and on the security of the underlying MAC scheme Σ against chosen message attacks. represents a trusted server which registers clients and, during the registration, each client shares their individual password secretly with . Suppose that and are two registered clients who wish to establish a session key and and are the passwords of and , respectively.

Description.
A high-level depiction of GPAKE is given in Figure 1 and its brief description follows. First, (and ) and establish a shared high-entropy key, (and , resp.), by running the 2-party PAKE protocol, 2PAKE. Then, generates a MAC key, , and distributes to both and by running the 3-party key distribution protocol 3KD which takes and as input. A session key, = , will be established between and after running the MAC-based Diffie-Hellman key exchange protocol MDH which takes as an input.

Instantiations.
Abdalla et al. [8,9] suggested several practical and provably secure protocols that can be used in the instantiation of the 2-party protocol 2PAKE. Among them are the KOY protocol [29,30] and its generalization [31], the PAK suite [32], and other protocols based on encrypted key exchange (EKE) of Bellovin and Merritt [33] (e.g., Bresson et al. 's OMDHKE protocol [34]). For the instantiation of 3KD, any particular choice that is secure with respect to a single session will do since the symmetric keys given as input to 3KD differ from session to session. Bellare and Rogaway's 3PKD protocol [35], for example, was suggested as a possible choice. The MAC scheme used in MDH can be instantiated with the HMAC [36] and the CBC MAC.

An Insider
Attack. Let us consider, for example, the case where 2PAKE and 3KD are instantiated with the PPK protocol [32] and with the 3PKD protocol [35], respectively. In this case, a malicious client who is registered with the server, , can mount a UD online dictionary attack against any other client, for example, . It is important to note that we do not require either of the protocols, PPK (see Figure 2) and 3PKD (see Figure 3), to be insecure and, in fact, we assume that both protocols are secure. The Scientific World Journal Figure 2: The PPK protocol [32]. Figure 3: The 3PKD protocol [35].
of a groupĜ). The session key is computed as = ( ‖ ‖̃‖̃‖ ‖V ). We observe that two messages ⟨ ,̃⟩ and ⟨ ,̃⟩ are independent and thus the protocol can be easily modified to run in a single round.

The 3PKD
Protocol. The cryptographic tools used in 3PKD include (1) a symmetric encryption scheme consisting of a pair of encryption/decryption algorithms (Enc, Dec) and (2) a MAC scheme consisting of a pair of MAC generation/verification algorithms (Mac, Ver). The protocol runs between a trusted server, , and two clients, and . (and ) and are assumed to have preestablished a 2 -bit secret = enc ‖ mac (resp., = enc ‖ mac ). The protocol, depicted in Figure 3, begins by having choosing a random -bit challenge and sending it to client . also chooses a random -bit challenge and sends ⟨ , ⟩ to . Upon receiving ⟨ , ⟩, generates a session key which he will distribute. then encrypts under 's encryption key enc (resp., 's encryption key enc ) to get ciphertext (resp., ). Then, computes (resp. , ), the MAC under key mac (resp. mac ) of the string ‖ ‖ ‖ (resp. ‖ ‖ ‖ ). Then, sends ⟨ , ⟩ and ⟨ , ⟩ to and , respectively. and accept the session key if and only if their received MAC is valid.
In order for PPK and 3PKD to be used together, the session keys generated by PPK need to be at least 2 -bit long.

One Possible Attack
Scenario. The malicious client, , can mount the following UD online dictionary attack against another client, . Figure 4: The OMDHKE protocol [34].
(i) In the (dishonest) run R1, impersonating makes a guess (denoted by ) on 's actual password, , selects a random ∈ Z , computes̃= ⋅ 1 ( ), and sends the server a fabricated message ⟨ ,̃⟩. Sincẽ∈ G, will respond with the message ⟨ ,̃⟩. After obtaining ⟨ ,̃⟩, computes a key (ii) In the (honest) run R2, honestly performs all the operations as per protocol specification and establishes the key, = enc ‖ mac .
Step 2 (running 3PKD). Once R1 & R2 are completed, proceeds to run the protocol 3PKD by sending the server two random challenges and (selected as specified by the protocol). will respond to the random challenges with two messages ⟨ , ⟩ and ⟨ , ⟩. After obtaining these two messages, recovers the keys = Dec enc ( ) and = Dec enc ( ).
Step 3 (verifying the password guess). verifies the correctness of by checking that is equal to . If they are equal, is the correct password with an overwhelming probability. Otherwise, it means that ̸ = .

An Outsider Attack.
We now consider the case where 2PAKE and 3KD are instantiated with the OMDHKE protocol [34] and with the 3PKD protocol [35], respectively. Although OMDHKE (see Figure 4) is largely similar to PPK, there is a marked difference between the two. OMDHKE provides server-to-client authentication while PPK focuses on implicit key authentication. Note that, in OMDHKE, server-to-client authentication is achieved via the authenticator Auth sent by to .

One Possible Attack Scenario.
We now demonstrate how , a malicious adversary who is not registered with the server, can mount a UD online dictionary attack against two registered clients, and .
(ii) In the (dishonest) run R2, proceeds as per R1 but impersonating (instead of ) and making a guess (denoted as ) on 's password, . Let Auth denote the authenticator received (in response) from .
Step 5 (running 3PKD). After R1 & R2 are completed, runs the 3PKD protocol with while impersonating both and .

6
The Scientific World Journal (This step provides no useful information to but is required for the attack to go undetected.) Step 6 (verifying the password guess). can then verify the correctness of by computing Auth = ( ‖ ‖̃‖ ‖ ‖ ) and then checking if Auth is equal to Auth . If they are equal, is the correct password (with an overwhelming probability). Otherwise, knows that ̸ = . Similarly, the correctness of can be verified using the received Auth .
2.4. Discussion. The insider attack described in Section 2.2 works because neither PPK nor 3PKD provides client-toserver authentication. Indeed, the same attack also works if we replace the PPK protocol with the OMDHKE protocol [34], the EKE2 protocol [28], or the SPAKE protocol [37]. In other words, the GPAKE protocol becomes vulnerable to the insider attack when both 2PAKE and 3KD are instantiated with a protocol that does not provide client-to-server authentication. The outsider attack described in Section 2.3 works under the same circumstance but additionally exploits the fact that the OMDHKE protocol provides server-to-client authentication.
Informally, both attacks can be prevented if one of the two protocols, 2PAKE or 3KD, is instantiated with a protocol that provides client-to-server authentication. We observe that a typical 3-party key distribution protocol is not expected to provide client-to-server authentication, and hence, we suggest that the countermeasure targets the instantiation of 2PAKE. While some might also suggest that a round-optimal protocol (i.e., a protocol that runs in a single round) should be used in the instantiation of 2PAKE to achieve better efficiency, we caution against this as no round-optimal 2-party PAKE protocol is known to provide client-to-server authentication and achieve security against offline dictionary attacks.

Modelling Dictionary Attacks in the Password-Only 3-Party Setting
The ROR model used for security analysis of GPAKE [8,9] does not allow the adversary to access the Corrupt oracle and thus cannot capture any kind of insider attacks, in particular, (UD) online and offline dictionary attacks by a malicious insider. The security definition associated with the ROR model intends to capture indistinguishability of session keys and does not consider mounting an online dictionary attack against a protocol to be a violation of the security of the protocol (see Section 3.3). Consequently, none of the online dictionary attacks presented in Section 2 can be captured in the model. We begin this section by presenting a communication model adapted from the Bellare-Pointcheval-Rogaway 2000 model [28] to support key exchange in the password-only 3party setting. Our communication model allows the adversary to ask Corrupt queries and thereby captures insider attacks (as well as forward secrecy and unknown key share attacks). We then define a typical indistinguishability-based security of session keys, which we call the SK security. As we demonstrate in Section 3.3, the SK security implies security against offline dictionary attacks but does not imply security against UD online dictionary attacks. We then introduce a separate security definition to capture UD online dictionary attacks. Unlike the approach of [19,20] where a separate security definition is introduced to capture both online and offline dictionary attacks, we only need to prove the protocol secure against UD online dictionary attacks once we have proved that it is SK-secure.

Participants and Long-Term Keys.
We denote by a trusted authentication server and C by the set of all clients registered with . During registration, each client ∈ C selects a password, , from a dictionary, D, and shares with via a secure channel.
is used as the longterm secret key shared between and . Any two clients, , ∈ C, may run a 3-party PAKE protocol with at any point in time to establish a session key.
∈ U, may participate in multiple protocol sessions running, either serially or concurrently, with the same or different participants. Thus, at any given time, there could be multiple instances of a single user. Π denotes instance of user . We say that a client instance, Π , accepts when it computes its session key, sk , in an execution of the protocol.

Partnering.
We say, informally, that two instances are partners if they participate in a protocol execution and establish a (shared) session key. Formally, partnering between instances is defined in terms of the notions of session and partner identifiers (See [38] on the role and the possible construct of session and partner identifiers as a form of partnering mechanism that enables the right session key to be identified in concurrent protocol executions.) Session identifier (sid) is a unique identifier of a protocol session and is usually defined as a function of the messages transmitted in the session (although this may not be possible in a multiparty protocol where not all participants have the same view). sid denotes the sid of instance Π . A partner identifier (pid) is a sequence of identities of participants of a specific protocol session. Instances are given as input a pid before they can run the protocol. pid denotes the pid given to instance Π . Note that pid = ⟨ , , ⟩, where is another client with whom Π believes it runs the protocol. We say that two instances, Π and Π , are partners if the following holds: (1) both Π and Π have accepted, (2) sid = sid , and (3) pid = pid .

Adversary Capabilities.
The probabilistic polynomialtime (ppt) adversary A is in complete control of all communications between users, and its capabilities are modeled via a predefined set of oracle queries described below.
(i) Execute (Π , Π , Π ): this query models passive attacks against the protocol. It prompts an execution of the protocol between the instances Π , Π and Π and returns the transcript of the protocol execution to A.
The Scientific World Journal 7 Experiment Exp 0 : Phase 1. A makes any oracle queries at will as many times as it wishes, except that: (1) A is not allowed to ask the Test(Π ) query if the instance Π is unfresh.
(2) A is not allowed to ask the Reveal(Π ) query if it has already made a Test query to Π or Π , where Π is the partner of Π . Phase 2. Once A decides that Phase 1 is over, it outputs a bit as a guess on the hidden bit chosen by the Test oracle. A is said to succeed if = .
Box 1 (ii) Send (Π , ): this query sends message to instance Π , modelling active attacks against the protocol. Upon receiving , the instance Π proceeds according to the protocol specification. The message output by Π , if any, is returned to A. A query of the form Send (Π , start: ⟨ , , ⟩) prompts Π to initiate the protocol with pid i C = ⟨ , , ⟩. (iii) Reveal (Π ): this query captures the notion of known key security (it is often reasonable to assume that the adversary will be able to obtain session keys from any session different from the one under attack). The instance Π , upon receiving the query and if it has accepted, returns the session key, sk , back to A.
(iv) Corrupt ( ): this query returns the password of . If = (i.e., the server is corrupted), all clients' passwords stored by the server are returned. This query captures not only the notion of forward secrecy but also unknown key share attacks and insider attacks.
(v) Test (Π ): this query is used to define the indistinguishability-based security of the protocol. If Π has accepted, then, depending on a randomly chosen bit , A is given either the real session key sk (when = 1) or a random key drawn from the session-key space (when = 0). Following the ROR model [8,9], we allow A to ask as many Test queries as it wishes. All Test queries are answered using the same value of the hidden bit . Namely, the keys output by the Test oracle are either all real or all random. But, we require that, for each different set of partners, A should access the Test oracle only once.
We describe the number of queries asked by an adversary as the query complexity of the adversary. The query complexity is represented as an ordered sequence of five nonnegative integers, = ⟨ exec , send , reve , corr , test ⟩, where exec , send , reve , corr , and test refer to the numbers of queries that the adversary asked, respectively, to the Execute, Send, Reveal, Corrupt, and Test oracles.

Session Key (SK) Security.
We now proceed to define the basic security, called the SK security, of a 3-party PAKE protocol. The notion of freshness is a key element in defining the SK security. Intuitively, a fresh instance is one that holds a session key which should not be known to the adversary A, and an unfresh instance is one whose session key (or some information about the key) can be known by trivial means. A formal definition of freshness follows.
Definition 11. An instance Π is fresh unless one of the following occurs: where Π is the partner of Π ; or (2) A queries Corrupt ( ), for some ∈ pid , before Π or its partner Π accepts.
The SK security of a 3-party PAKE protocol is defined in the context of Box 1.
Let Succ 0 be the event that A succeeds in the experiment Exp 0 . Let Adv (A) denote the advantage of A in attacking protocol and be defined as Adv (A) = 2 ⋅ Pr ,A [Succ 0 ] − 1.

Definition 12. A 3-party PAKE protocol
is SK-secure if, for any ppt adversary A asking at most send Send queries, Adv (A) is only negligibly larger than ⋅ send /|D|, where is a very small constant (usually around 2 or 4) when compared with |D|.
To quantify the security of protocol in terms of the amount of resources expended by adversaries, we letAdv ( , ) denote the maximum value of Adv (A) over all ppt adversaries A with time complexity at most and query complexity at most .

Capturing Offline Dictionary
Attacks. The SK security described in Definition 12 implies security against offline dictionary attacks. In other words, a 3-party PAKE protocol is not SK-secure if it is not secure against an offline dictionary attack. To demonstrate this, suppose that the protocol is not secure against an offline dictionary attack whereby an attacker can derive the password of any registered client . Then we can construct an adversary A off who breaks the SK security of protocol as follows.
Corruption. If is a malicious insider, A off queries Corrupt ( ) to obtain the password . Otherwise, A off skips this step.
Dictionary Attack. Next, A off runs the protocol exactly in the way that conducts its offline dictionary attack against client . Note that A off can perfectly simulate 's attack by using the disclosed password and by asking oracle 8 The Scientific World Journal queries appropriately. At the end of this step, A off will obtain the password of client as a result of the attack.
Impersonation. Now, A off initiates a new protocol session by querying Send (Π , start: ⟨ , , ⟩), where Π is an unused instance of an uncorrupted client . A off runs this session as per the protocol specification, but simulating by itself all the actions of (by using ). At the end of the session, the instance Π will accept with its session key sk .
Test. Clearly the instance Π is fresh, since (1) no Reveal query has been made on Π or its partner (which does not exist in this case) and (2) no Corrupt query has been made against any of , , and . Thus, A off may ask the Test (Π ) query. Since A off can compute the same session key as sk , the probability that A off correctly guesses the bit chosen by the Test oracle is 1 and so is the advantage of A off in attacking the protocol. Then, by Definition 12, the protocol is not SK-secure since the number of Send queries asked by A off is much smaller (i.e., nonnegligibly smaller) than |D|/ .

Capturing Undetectable Online Dictionary Attacks.
Unfortunately, the SK security does not imply security against UD online dictionary attacks. In other words, a 3-party PAKE protocol that is not secure against a UD online dictionary attack may be rendered SK-secure. Let us assume a 3-party PAKE protocol that is susceptible to a UD online dictionary attack (e.g., the GPAKE protocol in Section 2). Then, we can construct an adversary A on who attacks protocol with advantage 1. The construction of A on is the same as that of A off , except that to correctly determine the password , A on may have to ask Send queries as many times as ⋅ |D| for some integer ≥ 1. Note that verifying the correctness of a password guess may require more than one Send query to be asked. Even if Adv (A on ) = 1, the protocol is still rendered SK-secure by Definition 12, as the following holds for some ≥ 1: This result is not surprising since we call a protocol SK-secure if mounting an online dictionary attack by asking Send queries is the best an adversary can do. However, we want to be able to distinguish UD online dictionary attacks from detectable online dictionary attacks and ensure that the best an adversary can do is to mount a detectable online dictionary attack. The following new definitions together provide a simple and intuitive way of capturing security against UD online dictionary attacks.
Definition 13 (an online dictionary attack). The Send (Π , ) query models an online dictionary attack if both the following are true at the time of the termination of instance Π : (1) was not output by a previous Send query asked to an instance of by which Π believes was sent and (2) the adversary A queried neither Corrupt ( ) nor Corrupt ( ).
In Definition 13, the first condition implies that a straightforward delivery of a message between instances is not considered as an online dictionary attack while the second condition implies that when is the (assumed) peer of client , the adversary A can corrupt the peer client to mount an (insider) online dictionary attack. Note that our definition of an online dictionary attack does not impose any restriction on asking Reveal queries.
Let Undet be the event that, in experiment Exp 0 , a server instance terminates normally when an online dictionary attack was mounted against the instance. We say that the adversary A succeeds in mounting an UD online dictionary attack if the event Undet occurs. Formally, we define protocol's security against UD online dictionary attacks as follows: Definition 14. A 3-party PAKE protocol is secure against a UD online dictionary attack if, for any ppt adversary A asking at most send Send queries, Pr ,A [Undet] is only negligibly larger than ⋅ send /|D|, where is as defined in Definition 12.

A Compiler for 3-Party PAKE Protocols
We now present a protocol compiler that transforms any 2-party PAKE protocol into a 3-party PAKE protocol. If the given 2-party protocol is SK-secure, then the 3-party protocol output by the compiler is not only SK-secure but also secure against both insider and outsider UD online dictionary attacks. (We stress again that the SK security implies resistance against both insider and outsider offline dictionary attacks.) This is the case regardless of whether the underlying 2-party protocol provides client-to-server authentication or not. Our transformation does not require the use of a 3-party key distribution protocol and always takes only two additional rounds of communication. Hence, applying the compiler to a round-optimal 2-party PAKE protocol immediately yields a 3-party PAKE protocol running in three communication rounds.
Our generic construction, which we call H3PAKE (" " for "hashed"), is a variant of NGPAKE that is the generic construction of Wang and Hu [1]. The key difference between H3PAKE and NGPAKE is in the computation of the session key. NGPAKE defines the session key simply as the Diffie-Hellman key , whilst H3PAKE defines the session key as (pid‖sid‖ ) where is a cryptographic hash function. The difference in how session key is computed, together with a minor modification in the specifications of the protocol messages, results in a significant improvement on the security of the constructions. More specifically, we are now able to prove that H3PAKE is secure against insider dictionary attacks, unlike NGPAKE where it is unclear whether it can be proven secure against insider dictionary attacks. Note that the security of NGPAKE was proved in the ROR model that does not allow the adversary to ask Corrupt queries; and as shown in Section 3.3, protocols proven secure in such a model cannot claim provable security against insider attacks of any kind.

Preliminaries.
We begin with the cryptographic primitives on which the security of our construction relies.  (1) the key generation algorithm Gen takes as input a security parameter 1 ℓ and outputs a key chosen uniformly at random from {0, 1} ℓ ; (2) the MAC generation algorithm Mac takes as input a key and a message and outputs a MAC (also known as a tag) ; and (3) the MAC verification algorithm Ver takes as input a key , a message , and a MAC and outputs 1 if is valid for under or outputs 0 if is invalid. Let Adv Σ (A) be the advantage of an adversary A in violating the strong existential unforgeability of Σ under adaptive chosen message attacks. More precisely, Adv Σ (A) is the probability that an adversary A, who mounts an adaptive chosen message attack against Σ with oracle access to Mac (⋅) and Ver (⋅), outputs a message/tag pair ( , ) such that (1) Ver ( , ) = 1 and (2) was not previously output by the oracle Mac (⋅) as a MAC on the message . We say that the MAC scheme Σ is secure if Adv Σ (A) is negligible for every ppt adversary A. We use Adv Σ ( , mac , ver ) to denote the maximum value of Adv Σ (A) over all ppt adversaries A running in time at most and asking at most mac and ver queries to Mac (⋅) and Ver (⋅), respectively.

2-Party PAKE Protocols.
H3PAKE takes as input a 2-party PAKE protocol 2PAKE. We assume that the given 2-party protocol 2PAKE outputs session keys distributed in {0, 1} ℓ and is SK-secure against an adversary who is given access to all the oracles: Send, Execute, Reveal, Corrupt, and Test. Let Adv 2PAKE (A) be the advantage of an adversary A in breaking the SK security of 2PAKE. We require that, for any ppt adversary A asking at most send Send queries, Adv 2PAKE (A) is only negligibly larger than send / |D|. Adv 2PAKE ( , ) denotes the maximum value of Adv 2PAKE (A) over all ppt adversaries A with time complexity at most and query complexity at most .
Additionally, H3PAKE uses a cryptographic hash function mapping {0, 1} * to {0, 1} , where is a security parameter representing the length of session keys. is modelled as a random oracle in our proof of security for H3PAKE.

Description of H3PAKE.
We assume that the following information has been preestablished and is known to all users in the network: (1) a cyclic group G of prime order and a generator of G, (2) a MAC scheme Σ = (Gen, Mac, Ver), (3) a 2-party PAKE protocol 2PAKE, and (4) a cryptographic hash function . These public parameters can be determined by the server and be broadcast to all its registered clients. Let and be two clients who wish to establish a session key, and let be the trusted server with which and have registered their passwords and , respectively. We denote the partner identifier pid given as input to (an instance of) (resp., and ) by pid (resp., pid and pid ). Recall that pid is a sequence of identities of protocol participants. The order of identities that appears in pid is of critical importance for the correctness of our construction and its security proof. For simplicity, we assume that pid = pid = pid = ⟨ , , ⟩. Figure 5 depicts how the generic 3-party PAKE protocol, H3PAKE, is constructed from any given 2-party protocol, 2PAKE. More specifically, H3PAKE is constructed as follows. 1. and establish a shared high-entropy key by running the 2-party protocol 2PAKE. Likewise, and establish a shared high-entropy key .
and establish their session key by running a MAC-based Diffie-Hellman key exchange protocol with assistance of .
At the end of the protocol execution, and will compute the same session key sk if they both hold the same sets of pid and sid and thus compute the same Diffie-Hellman key = . We do not require 2PAKE to be instantiated with a protocol that provides either unilateral or mutual authentication, as H3PAKE already provides mutual authentication between 10 The Scientific World Journal the server and the clients (via the MAC values exchanged in Phase 2). Hence, any 2-party protocol that provides implicit key authentication, including one-round protocols, will be suitable candidates to instantiate 2PAKE.

Proof of SK Security.
We claim that the generic construction H3PAKE described in Figure 5 is SK-secure in the random oracle model under the GDH assumption in G and the security of the MAC scheme Σ.

Theorem 15.
Let be a random oracle. Then, for any adversary with time complexity at most and query complexity at most = ⟨ , , V , , ⟩, its advantage in breaking the SK security of H3PAKE is bounded by where = ⟨2 , , , , 2 + ⟩ and is the maximum time required to perform the experiment Exp 0 involving an adversary who attacks H3PAKE with time complexity .
Proof. Assume a ppt adversary A who attacks H3PAKE with time complexity and query complexity = ⟨ exec , send , reve , corr , test ⟩. We prove the theorem by making a series of modifications to the experiment Exp 0 , bounding the difference in A's advantage between two consecutive experiments, and ending up with an experiment in which A's advantage is negligible. By Succ , we denote the event that A correctly guesses the hidden bit (chosen by the Test oracle) in experiment Exp .
Before presenting the first modified experiment, we define the notion of a clean instance.

Definition 16.
We say an instance Π is unclean if A has queried Corrupt ( ) for some ∈ pid . Otherwise, we say it is clean.
Experiment Exp 1 . This experiment is different from Exp 0 only in that we replace each different MAC key with a random key drawn uniformly from {0, 1} ℓ for all clean instances. The difference in A's advantage between Exp 0 and Exp 1 is bounded by the following lemma. Proof. We prove the lemma by constructing an adversary A attacking protocol 2PAKE from the adversary A whose advantage in attacking H3PAKE is different between Exp 0 and Exp 1 . A begins by choosing a bit uniformly at random. Then, A runs A as a subroutine while simulating the oracles as follows.
Execute Queries. When A makes an Execute (Π , Π , Π ) query, A first checks if any of , , and was previously corrupted.
(i) If so, A answers the Execute query as in experiment Exp 0 .
(ii) Otherwise, A answers the query using its own oracles. A first asks two queries Execute (Π , Π ) and Execute (Π , Π ). Let T 2PAKE and T 2PAKE be two transcripts returned in response to the Execute queries. Next, A makes the queries Test (Π ) and Test (Π ) and receives in return two keys and (either real or random). A then generates the rest of the protocol transcript (i.e., the messages to be sent in Phase 2), using and as the MAC keys. Finally, A returns these messages together with T 2PAKE and T 2PAKE after ordering them properly.
Send Queries. Whenever A makes a Send (Π , ) query, A checks if is a message for initiating a new session (of H3PAKE) or the Send query belongs to an execution of 2PAKE.
(1) If both conditions are untrue, A responds to the query as in experiment Exp 0 .
(2) Otherwise, A answers it by making the same query to its own Send oracle. If the query prompts Π to accept, then A checks if anyone in pid was previously corrupted.
(a) If so, A makes a Reveal (Π ) query and uses the output of this Reveal query as the MAC key of Π . (b) Otherwise, A makes a Test (Π ) query (unless the partner of Π has already been tested) and uses the output of this Test query as the MAC key of Π .
Reveal Queries. These queries are handled as in experiment Exp 0 .
Corrupt Queries. A answers these queries in the straightforward way using its own Corrupt oracle.
Test Queries. A answers these queries according to the bit that it has chosen at the beginning of the simulation. That is, A returns real session keys, which it has computed on its own, if = 1, and otherwise returns random keys chosen uniformly at random from {0, 1} .
At some point in time, A will terminate and output its guess . When this happens, A outputs 1, if = , and 0 otherwise.
From the simulation, it is obvious that (i) the probability that A outputs 1 when its Test oracle returns real session keys is equal to the probability that A correctly guesses the bit in experiment Exp 0 ; (ii) the probability that A outputs 1 when its Test oracle returns random keys is equal to the probability that A correctly guesses the bit in experiment Exp 1 . Experiment Exp 2 . Let Forge be the event that the adversary A makes a Send query of the form Send (Π , ‖ * ‖ ) before querying Corrupt ( ) and Corrupt ( ), where is a valid tag on ‖ * ‖pid and was not output by a previous oracle query as a tag on ‖ * ‖pid . Then Exp 2 is different from Exp 1 only in that, if Forge occurs, the experiment is aborted and the adversary does not succeed. We claim the following lemma. Proof. Given the adversary A attacking H3PAKE and assuming that the event Forge occurs, we construct an algorithm F that outputs, with a nonnegligible probability, a forgery against the MAC scheme Σ. The algorithm F is given oracle access to Mac (⋅) and Ver (⋅). The goal of F is to produce a message/tag pair ( , ) such that (1) Ver ( , ) = 1 and (2) was not previously output by the Mac (⋅) oracle on input .
Let be the number of all different MAC keys that are established via a Send query of A. Clearly, ≤ send . F begins by choosing a random ∈ {1, . . . , }. Let denote the th key among all the MAC keys, and letSend be a Send query that should be answered and/or verified using . F invokes A as a subroutine and handles the oracle calls of A as in experiment Exp 1 except that it answers all Send queries by accessing its MAC generation and verification oracles. As a result, the th MAC key is never used during the simulation. If Forge occurs against an instance that holds , F halts and outputs the message/tag pair generated by A as its forgery. Otherwise, F halts and outputs a failure indication.
If the guess is correct, then the simulation is perfect and F achieves its goal. Namely, Adv Σ (F) = Pr[Forge]/ . Since ≤ send , we get Pr[Forge] ≤ send ⋅ Adv Σ (F). Then, Lemma 18 follows by noticing that F has at most time complexity and makes at most two queries to Mac (⋅) and Ver (⋅).
Experiment Exp 3 . This experiment is different from experiment Exp 2 only in that the Execute and Send oracles are simulated as in "the Exp 3 modification" described in Box 2.
Since the view of A is identical between Exp 2 and Exp 3 , following Lemma 19 is clear.
In experiment Exp 3 , the advantage of A in attacking H3PAKE is bounded by the following lemma. Proof. The proof is via a reduction from the GDH problem which is believed to be hard. Assume that the advantage of A in attacking H3PAKE is nonnegligible. Then we can construct 12 The Scientific World Journal The Exp 3 Modification When A asks an Execute or Send query, the simulator answers it exactly as in experiment Exp 2 , except that it modifies the way of generating the public Diffie-Hellman values (denoted as and in the protocol) as follows: (i) The simulator chooses two random V 1 , V 2 ∈ Z and computes 1 = V 1 and 2 = V 2 .
(ii) For each instance Π , the simulator chooses a random ∈ Z , computes = { 1 if appears first in pid 2 if appears second in pid , and uses as the public Diffie-Hellman value (i.e., as or ) of Π .

Box 2
Deciding ? = kds Given a string and a tuple (pid , sid , , * , , * ), A GDH first checks if the bit-length of is equal to the bit-length of key derivation strings. If it is, then A GDH checks that (1) pid ‖sid is a prefix of and (2) O( , , G ) = 1 where G is a |G|-bit string that is a suffix of . If both are true, then = kds . Box 3 an algorithm A GDH that has a nonnegligible advantage in solving the GDH problem in G. The goal of A GDH is to compute and output the value 3 = 1 2 ∈ G when given a CDH-problem instance ( 1 = 1 , 2 = 2 ) ∈ G as well as an oracle O(⋅, ⋅, ⋅) that solves the DDH problem in G. A GDH runs A as a subroutine while simulating all the oracles on its own.
When A asks an Execute and Send query, A GDH answers it as specified in the Exp 3 modification but using 1 and 2 instead of 1 and 2 . In this way, A GDH can embed the CDH-problem instance ( 1 , 2 ) into all protocol sessions. Accordingly, A GDH can compute no session keys but can still correctly answer Reveal queries by storing all the keying materials associated with each instance. For each instance Π whose only remaining work is to compute its session key, A GDH checks if the instance Π is clean or unclean. If it is clean, A GDH stores a tuple (pid , sid , , , , ) into a list, which we denote as CDHList, where = 1 and = 2 . Here, the exponent (resp., ) is the one chosen for the instance whose user identity comes first (resp., second) in pid . If it is unclean, A GDH stores a tuple (pid , sid , , , , ⊥) if comes first in pid or a tuple (pid , sid , , ⊥, , ) if comes second in pid . Here, ⊥ indicates that the exponent of the received public Diffie-Hellman value may have been chosen by A.
While imbedding the CDH-problem instance as above, A GDH has to provide A with the same view as in experiment Exp 3 . To this end, let be a key derivation string from which a session key is computed by applying the random oracle . Let denote the of instance Π . Then, = pid ‖sid ‖ . As is clear from the above simulation, A GDH cannot compute any on its own. But, given a string , A GDH can determine whether is the of some instance Π or not by repeatedly performing the deciding operation for the tuples in CDHList as in Box 3.
The simulation of other oracles is provided as follows.
H Queries. A GDH uses a list, HList, to maintain input-output pairs of . For each query on a string , A GDH first checks if an entry of the form ( , ℎ) is in HList. If it is, A GDH returns ℎ to A. Otherwise, A GDH checks if is the of some instance Π by repeatedly performing the deciding operation above until a match is found.
(i) If a match is found and the corresponding tuple is of the form (pid , sid , , , , ), A GDH computes 3 = ( G ) 1/ and terminates outputting 3 . In this case, A GDH succeeds in solving the GDH problem.
(ii) If a match is found and the corresponding tuple is of the form (pid , sid , , , , ⊥) or (pid , sid , , ⊥, , ), A GDH checks if a tuple of the form (pid , sid , , , sk) is in the RList which is maintained by A GDH to store revealed session keys. If it is, A GDH returns sk to A and adds ( , sk) to HList. Otherwise, A GDH returns a random -bit string to A and adds ( , ) to HList.
(iii) Otherwise, A GDH returns a random -bit string to A and adds ( , ) to HList.
Reveal Queries. When A asks a Reveal (Π ) query, A GDH finds a tuple of the form (pid , sid , , * , , * ) in CDHList and checks if a tuple of the form (pid , sid , , , sk) is in the RList. If it is, A GDH returns sk to A. Otherwise, A GDH checks if HList contains an entry ( , ℎ) such that = . Given the tuple (pid , sid , , * , , * ), this check can be done by performing the deciding operation for all entries in HList. If such entry ( , ℎ) exists in HList, A GDH returns ℎ in response to the query and adds the tuple (pid , sid , , , ℎ) into RList. Otherwise, A GDH returns a random -bit string to A and adds the tuple (pid , sid , , , ) into RList.
Corrupt Queries. A GDH answers these queries in the obvious way.
Test Queries. For each of these queries, A GDH responses with a random -bit string.
Let Ask be the event that A makes an query on a string that is the of some fresh instance. From the simulation of , it can be easily seen that as soon as Ask occurs, A GDH outputs the desired result 3 = 1 2 and thus succeeds in solving the GDH problem in G. But, since is a random oracle, A gains no advantage in distinguishing the test keys from random if the event Ask does not occur. This implies the assertion of Lemma 20.
This result combined with Lemmas 17-19 concludes the proof for Theorem 15.

Proof of Resistance to Undetectable Online Dictionary
Attacks. We now claim that H3PAKE is secure against a UD online dictionary attack as long as the given 2-party protocol 2PAKE is SK-secure. Proof. Let A be an adversary who asks send Send queries in attacking the protocol H3PAKE. Assume that Pr H3PAKE,A [Undet] is nonnegligibly larger than send /|D|. Given the adversary A, we prove the theorem by constructing an adversary A against 2PAKE who asks at most send Send queries but has an advantage nonnegligibly larger than send /|D|.
A invokes A as a subroutine and answers the oracle queries of A as follows.
Execute Queries. When A makes an Execute (Π , Π , Π ) query, A answers the query using its own Execute and Reveal oracles. A first queries Execute (Π , Π ) and Execute (Π , Π ). Let T 2PAKE and T 2PAKE be two transcripts returned in response to the Execute queries. Next, A obtains two keys and by querying Reveal (Π ) and Reveal (Π ). A then generates the rest of the protocol transcript, using and as the MAC keys. Finally, A returns these messages together with T 2PAKE and T 2PAKE after ordering them properly.
Send Queries. When A makes a Send (Π , ) query, A checks if is a message for initiating a new session (of H3PAKE) or the Send query belongs to an execution of 2PAKE.
(1) If both conditions are untrue, A responds to the query as that in the original experiment Exp 0 .
(2) Otherwise, A answers it by making the same query to its own Send oracle. If the query prompts Π to accept, A checks if Π is a server instance against which A has mounted an online dictionary attack. If not, A makes a Reveal (Π ) query (and later uses the output of this Reveal query as the MAC key of Π ). (How to handle the other case will be explained below.) Corrupt Queries. A answers these queries using its own Corrupt oracle.
Reveal/Test Querise. A answers these queries as in the original experiment Exp 0 .
Let Π be any server instance against which A has mounted an online dictionary attack. Let be the session key that the instance Π has computed in its execution of 2PAKE. In order for the instance Π to terminate normally, the adversary A has to make a query of the form Send (Π , ‖ * ‖ ) such that Ver ( ‖ * ‖pid , ) = 1. When A makes such a Send query (i.e., when the event Undet occurs), A makes a Test query against the instance Π . Note that the instance Π is fresh as (1) it is partnered with no instance and (2) and must have not been corrupted. Let be the key returned in response to the Test query. A outputs 1, if Ver ( ‖ * ‖pid , ) = 1, and outputs 0, otherwise.
If Undet does not occur, A outputs a random bit. From the simulation above, it is clear to see that Then, Theorem 21 immediately follows since the number of Send queries asked by A against 2PAKE is at most send .

Concluding Remarks
The undetectable online dictionary attacks we presented against the widely studied GPAKE protocol of Abdalla et al. [8,9] are a reminder of the difficulty of designing a secure yet efficient 3-party PAKE protocol. The GPAKE protocol was proven secure in a model that does not capture undetectable online dictionary attacks, and thus, our attacks do not invalidate the proof of security for GPAKE. We also presented a simple and intuitive approach of capturing all classes of dictionary attacks in the framework of the widely accepted Bellare-Pointcheval-Rogaway model. 14 The Scientific World Journal What motivated our approach is the observation that no prior work has provided a rigorous formal treatment of insider (online/offline) dictionary attacks in the password-only 3party setting and as a consequence 3-party PAKE protocols insecure against such attacks have proliferated. We believe that our approach provides protocol designers with an easier and more accessible way of proving security of their protocols against dictionary attacks.
Finally, we presented a generic 3-party PAKE protocol (H3PAKE) and proved its security in the random oracle model under the gap Diffie-Hellman assumption. To the best of our knowledge, H3PAKE is the first 3-party PAKE protocol proven secure against both insider and outsider dictionary attacks as well as offline and online dictionary attacks. Future work includes coming up with a 3-party PAKE protocol that achieves the same (or even better) level of security and efficiency as H3PAKE but does not rely its security proof on the random oracle model.