J-PAKE: Authenticated Key Exchange Without

PKI

Feng Hao1 and Peter Ryan2

1
Thales E-Security, Cambridge, UK
2
Faculty Of Science, University of Luxembourg

Abstract. Password Authenticated Key Exchange (PAKE) is one of the

important topics in cryptography. It aims to address a practical security

problem: how to establish secure communication between two parties

solely based on a shared password without requiring a Public Key In-

frastructure (PKI). After more than a decade of extensive research in this

field, there have been several PAKE protocols available. The EKE and

SPEKE schemes are perhaps the two most notable examples. Both tech-

niques are however patented. In this paper, we review these techniques

in detail and summarize various theoretical and practical weaknesses. In

addition, we present a new PAKE solution called J-PAKE. Our strategy

is to depend on well-established primitives such as the Zero-Knowledge

Proof (ZKP). So far, almost all of the past solutions have avoided using

ZKP for the concern on efficiency. We demonstrate how to effectively

integrate the ZKP into the protocol design and meanwhile achieve good

efficiency. Our protocol has comparable computational efficiency to the

EKE and SPEKE schemes with clear advantages on security.

Keywords: Password-Authenticated Key Exchange, EKE, SPEKE, key agree-

ment
1 Introduction

Nowadays, the use of passwords is ubiquitous. From on-line banking to accessing

personal emails, the username/password paradigm is by far the most commonly

used authentication mechanism. Alternative authentication factors, including

tokens and biometrics, require additional hardware, which is often considered

too expensive for an application.

However, the security of a password is limited by its low-entropy. Typically,

even a carefully chosen password only has about 20-30 bits entropy [3]. This

makes passwords subject to dictionary attacks or simple exhaustive search. Some

systems willfully force users to remember cryptographically strong passwords,
but that often creates more problems than it solves [3].

Since passwords are weak secrets, they must be protected during trans-

mission. Currently, the widely deployed method is to send passwords through

SSL/TLS [29]. But, this requires a Public Key Infrastructure (PKI) in place;

maintaining a PKI is expensive. In addition, using SSL/TLS is subject to man-

in-the-middle attacks [3]. If a user authenticates himself to a phishing website

by disclosing his password, the password will be stolen even though the session

is fully encrypted.

The PAKE research explores an alternative approach to protect passwords

without relying on a Public Key Infrastructure (PKI) at all [10, 16]. It aims to

achieve two goals. First, it allows zero-knowledge proof of the password. One

can prove the knowledge of the password without revealing it to the other party.

Second, it performs authenticated key exchange. If the password is correct, both

parties will be able to establish a common session key that no one else can
compute.

The first milestone in PAKE research came in 1992 when Bellovin and Merrit

introduced the Encrypted Key Exchange (EKE) protocol [10]. Despite some
reported weaknesses [16, 20, 23, 25], the EKE protocol first demonstrated that

the PAKE problem was at least solvable. Since then, a number of protocols have
been proposed. Many of them are simply variants of EKE, instantiating the
“symmetric cipher” in various ways [7].

The few techniques that claim to resist known attacks have almost all been
patented. Most notably, EKE was patented by Lucent Technologies [12], SPEKE

by Phoenix Technologies [18] and SRP by Stanford University [28]. The patent

issue is arguably one of the biggest brakes in deploying a PAKE solution in

practice [13].

2 Past work

2.1 Security requirements

Before reviewing past solutions in detail, we summarize the security requirements

that a PAKE protocol shall fulfill (also see [10, 11, 16, 28]).

1. Off-line dictionary attack resistance – It does not leak any information

that allows a passive/active attacker to perform off-line exhaustive search of

the password.
2. Forward secrecy – It produces session keys that remain secure even when

the password is later disclosed.

3. Known-session security – It prevents a disclosed session from affecting the

security of other established session keys.

4. On-line dictionary attack resistance – It limits an active attacker to test

only one password per protocol execution.

First, a PAKE protocol must resist off-line dictionary attacks. An attacker

may be passive (only eavesdropping) or active (directly engaging in the key

exchange). In either case, the communication must not reveal any data – say a
hash of the password – that allows an attacker to learn the password through

off-line exhaustive search.

Second, the protocol must be forward-secure. The key exchange is authen-

ticated based on a shared password. However, there is no guarantee on the

long-term secrecy of the password. A well-designed PAKE scheme should pro-
tect past session keys even when the password is later disclosed. This property

also implies that if an attacker knows the password but only passively observes
the key exchange, he cannot learn the session key.

Third, the protocol must provide known session security. If an attacker is

able to compromise a session, we assume he can learn all session-specific secrets.
However, the impact should be minimized such that a compromised session must

not affect the security of other established sessions.

Finally, the protocol must resist on-line dictionary attacks. If the attacker is

directly engaging in the key exchange, there is no way to prevent such an attacker

trying a random guess of the password. However, a secure PAKE scheme should
mitigate the effect of the on-line attack to the minimum – in the best case,

the attacker can only guess exactly one password per impersonation attempt.

Consecutively failed attempts can be easily detected and thwarted accordingly.

Some papers add an extra “server compromise resistance” requirement: an

attacker should not be able to impersonate users to a server after he has stolen
the password verification files stored on that server, but has not performed dic-

tionary attacks to recover the passwords [7, 17, 28]. Protocols designed with this
additional requirement are known as the augmented PAKE, as opposed to the

balanced PAKE that does not have this requirement.

However, the so-called “server compromise resistance” is disputable [24].

First, one may ask whether the threat of impersonating users to a compro-

mised server is significantly realistic. After all, the server had been compromised
and the stored password files had been stolen. Second, none of the augmented

schemes can provide any real assurance once the server is indeed compromised.
If the password verification files are stolen, off-line exhaustive search attacks are
inevitable. All passwords will need to be revoked and updated anyway.

Another argument in favor of the augmented PAKE is that the server does not
store a plaintext password so it is more secure than the balanced PAKE [28]. This

is a misunderstanding. The EKE and SPEKE protocols are two examples of the
balanced PAKE. Though the original EKE and SPEKE papers only mention the
use the plaintext password as the shared secret between the client and server [10,

16], it is trivial to use a hash of the password (possibly with some salt) as the
shared secret if needed. So, the augmented PAKE has no advantage in this
aspect.

Overall, the claimed advantages of an augmented PAKE over a balanced one

are doubtful. On the other hand, the disadvantages are notable. With the added

“server compromise resistance” requirement that none of the augmented PAKE

schemes truly satisfy [7, 17, 28], an augmented PAKE protocol is significantly
more complex and more computationally expensive. The extra complexity opens

more opportunities to the attacker, as many of the attacks are applicable on the
augmented PAKE [7].

2.2 Review on EKE and SPEKE

In this section, we review the two perhaps most well-known balanced PAKE

protocols: EKE [10] and SPEKE [16]. Both techniques are patented and have

been deployed in commercial applications.

There are many other PAKE protocols in the past literature [7]. Due to
the space constraint, we can only briefly highlight some of them. Goldreich and

Lindell first provided a formal analysis of PAKE, and they also presented a
PAKE protocol that satisfies the formal definitions [33]. However, the Goldreich-

Lindell protocol is based on generic multi-party secure computation; it is com-

monly seen as too inefficient for practical use [34, 35]. Later, there are Abdalla-
Pointcheval [1], Katz-Ostrovsky-Yung [34], Jiang-Gong [35] and Gennaro-Lindell [39]

protocols, which are proven secure in a common reference model (Abdalla-

Pointcheval additionally assumes a random oracle model [1]). All these protocols

require a “trusted third party” to define the public parameters: more specifically,

the security of the protocol relies on the “independence” of two group genera-
tors selected honestly by a trusted third party [1, 34, 35] 3 . Thus, as with any

“trusted third party”, the party becomes the one who can break the protocol
security [3]. (Recall that the very goal of PAKE is to establish key exchange

between two parties without depending on any external trusted party.) Another
well-known provably secure PAKE is a variant of the EKE protocol with for-

mal security proofs due to Bellare, Pointcheval and Rogaway [5] (though the

proofs are disputed in [7, 32], as we will explain later). In general, all the above
protocols [1, 5, 33–35, 39] are significantly more complex and less efficient than

the EKE and SPEKE protocols. In this paper, we will focus on comparing our

technique to the EKE and SPEKE protocols.

First, let us look at the EKE. Bellovin and Merrit introduced two EKE

constructs: based on RSA (which was later shown insecure [23]) and Diffie-

Hellman (DH). Here, we only describe the latter, which modifies a basic DH
protocol by symmetrically encrypting the exchanged items. Let α be a primitive

root modulo p. In the protocol, Alice sends to Bob [αxa ]s , where xa is taken

3
The Jiang-Gong paper proposes to use a trusted third party or a threshold scheme
to define the public parameters [35], while the KOY paper suggests to use a trusted
third party or a source of randomness [34]. However, neither paper provides concrete
descriptions of the “threshold scheme” and “source of randomness”. The Gennaro-
Lindell paper suggests to choose a large organization as the trusted party for all its
employees [39]. However, such a setup also severely limits the general deployment of
PAKE among the public.
randomly from [1, p−1] and [. . .]s denotes a symmetric cipher using the password

s as the key. Similarly, Bob sends to Alice [αxb ]s , where xb ∈R [1, p − 1]. Finally,
Alice and Bob compute a common key K = αxa ·xb . More details can be found
in [10].

It has been shown that a straightforward implementation of the above pro-

tocol is insecure [20]. Since the password is too weak to be used as a normal
encryption key, the content within the symmetric cipher must be strictly ran-

dom. But, for a 1024-bit number modulo p, not every bit is random. Hence, a
passive attacker can rule out candidate passwords by applying them to decipher

[αxa ]s , and then checking whether the results fall within [p, 21024 − 1].

There are suggested countermeasures. In [10], Bellovin and Merrit recom-

mended to transmit [αxa + r · p]s instead of [αxa ]s in the actual implementation,

where r · p is added using a non-modular operation. The details on defining r can

be found in [10]. However, this solution was explained in an ad-hoc way, and it
involves changing the existing protocol specification. Due to lack of a complete

description of the final protocol, it is difficult to assess its security. Alternatively,

Jaspan suggests addressing this issue by choosing p as close to a power of 2 as

possible [20]. This might alleviate the issue, but does not resolve it.

The above reported weakness in EKE suggests that formal security proofs
are unlikely without introducing new assumptions. Bellare, Pointcheval and Rog-

away introduced a formal model based on an “ideal cipher” [5]. They applied this

model to formally prove that EKE is “provably secure”. However, this result is
disputed in [7,32]. The so-called “ideal cipher” was not concretely defined in [5];

it was only later clarified by Boyd et al. in [7]: the assumed cipher works like a
random function in encryption, but must map fixed-size strings to elements of
G in decryption (also see [32]). Clearly, no such ciphers are readily available yet.

Several proposed instantiations of such an “ideal cipher” were easily broken [32].
 Another limitation with the EKE protocol is that it does not securely ac-

commodate short exponents. The protocol definition requires αxa and αxb be
uniformly distributed over the whole group Z∗p [10]. Therefore, the secret keys
xa and xb must be randomly chosen from [1, p − 1], and consequently, an EKE

must use 1024-bit exponents if the modulus p is chosen 1024-bit. An EKE cannot
operate in groups with distinct features, such as a subgroup with prime order

– a passive attacker would then be able to trivially uncover the password by

checking the order of the decrypted item.

Jablon proposed a different protocol, called Simple Password Exponential

Key Exchange (SPEKE), by replacing a fixed generator in the basic Diffie-

Hellman protocol with a password-derived variable [16]. In the description of
a fully constrained SPEKE, the protocol defines a safe prime p = 2q + 1, where

q is also a prime. Alice sends to Bob (s2 )xa where s is the shared password and

xa ∈R [1, q − 1]; similarly, Bob sends to Alice (s2 )xb where xb ∈R [1, q − 1].
Finally, Alice and Bob compute K = s2·xa ·xb . The squaring operation on s is to

make the protocol work within a subgroup of prime order q.

There are however risks of using a password-derived variable as the base, as

pointed out by Zhang [31]. Since some passwords are exponentially equivalent,

an active attacker may exploit that equivalence to test multiple passwords in one
go. This problem is particularly serious if a password is a Personal Identification

Numbers (PIN). One countermeasure might be to hash the password before

squaring, but that does not resolve the problem. Hashed passwords are still
confined to a pre-defined small range. There is no guarantee that an attacker is

unable to formulate exponential relationships among hashed passwords; existing

hash functions were not designed for that purpose. Hence, at least in theory,
this reported weakness disapproves the original claim in [16] that a SPEKE only

permits one guess of password in one attempt.

 Similar to the case with an EKE, a fully constrained SPEKE uses long ex-

ponents. For a 1024-bit modulus p, the key space is within [1, q − 1], where q is
1023-bit. In [16], Jablon suggested to use 160-bit short exponents in a SPEKE,
by choosing xa and xb within a dramatically smaller range [1, 2160 − 1]. But, this

would give a passive attacker side information that the 1023 − 160 = 863 most
significant bits in a full-length key are all ‘0’s. The security is not reassuring, as

the author later acknowledged in [19].

To sum up, an EKE has the drawback of leaking partial information about

the password to a passive attacker. As for a SPEKE, it has the problem that an
active attacker may test multiple passwords in one protocol execution. Further-

more, neither protocol accommodates short exponents securely. Finally, neither

protocol has security proofs; to prove the security would require introducing new
security assumptions [5] or relaxing security requirements [26].

3 J-PAKE Protocol

In this section, we present a new balanced PAKE protocol called Password Au-

thenticated Key Exchange by Juggling (J-PAKE). The key exchange is carried

out over an unsecured network. In such a network, there is no secrecy in commu-

nication, so transmitting a message is essentially no different from broadcasting

it to all. Worse, the broadcast is unauthenticated. An attacker can intercept a

message, change it at will, and then relay the modified message to the intended
recipient.

It is perhaps surprising that we are still able to establish a private and au-
thenticated channel in such a hostile environment solely based on a shared pass-
word – in other words, bootstrapping a high-entropy cryptographic key from a

low-entropy secret. The protocol works as follows.

 Let G denote a subgroup of Z∗p with prime order q in which the Decision

Diffie-Hellman problem (DDH) is intractable [6]. Let g be a generator in G. The

two communicating parties, Alice and Bob, both agree on (G, g). Let s be their
shared password4 , and s 6= 0 for any non-empty password. We assume the value

of s falls within [1, q − 1].

Alice selects two secret values x1 and x2 at random: x1 ∈R [0, q − 1] and

x2 ∈R [1, q − 1]. Similarly, Bob selects x3 ∈R [0, q − 1] and x4 ∈R [1, q − 1]. Note

that x2 , x4 6= 0; the reason will be evident in security analysis.

Round 1 Alice sends out g x1 , g x2 and knowledge proofs for x1 and x2 . Simi-

larly, Bob sends out g x3 , g x4 and knowledge proofs for x3 and x4 .

The above communication can be completed in one round as neither party

depends on the other. When this round finishes, Alice and Bob verify the received
knowledge proofs, and also check g x2 , g x4 6= 1.

Round 2 Alice sends out A = g (x1 +x3 +x4 )·x2 ·s and a knowledge proof for x2 · s.

Similarly, Bob sends out B = g (x1 +x2 +x3 )·x4 ·s and a knowledge proof for x4 · s.

When this round finishes, Alice computes K = (B/g x2 ·x4 ·s )x2 = g (x1 +x3 )·x2 ·x4 ·s ,

and Bob computes K = (A/g x2 ·x4 ·s )x4 = g (x1 +x3 )·x2 ·x4 ·s . With the same keying
material K, a session key can be derived κ = H(K), where H is a hash function.

The two-round J-PAKE protocol can serve as a drop-in replacement for face-

to-face key exchange. It is like Alice and Bob meet in person and secretly agree
a common key. So far, the authentication is implicit: Alice believes only Bob can

derive the same key and vice versa. In some applications, Alice and Bob may
want to perform an explicit key confirmation just to make sure the other party
actually holds the same key.
4
Depending on the application, s could also be a hash of the shared password together
with some salt.
 There are several ways to achieve explicit key confirmation. In general, it is

desirable to use a different key from the session key for key confirmation5 , say use
κ0 = H(K, 1). We summarize a few methods, which are generically applicable
to all key exchange schemes. A simple method is to use a hash function similar

to the proposal in SPEKE: Alice sends H(H(κ0 )) to Bob and Bob replies with
H(κ0 ). Another straightforward way is to use κ0 to encrypt a known value (or

random challenge) as presented in EKE. Other approaches make use of MAC

functions as suggested in [36]. Given that the underlying functions are secure,
these methods do not differ significantly in security.

In the protocol, senders need to produce valid knowledge proofs. The neces-
sity of the knowledge proofs is motivated by Anderson-Needham’s sixth principle

in designing secure protocols [2]: “Do not assume that a message you receive has

a particular form (such as g r for known r) unless you can check this.” For-

tunately, Zero-Knowledge Proof (ZKP) is a well-established primitive in cryp-

tography; it allows one to prove his knowledge of a discrete logarithm without

revealing it [29].

As one example, we could use Schnorr’s signature [30], which is non-interactive,

and reveals nothing except the one bit information: “whether the signer knows

the discrete logarithm”. Let H be a secure hash function6 . To prove the knowl-
edge of the exponent for X = g x , one sends {SignerID, V = g v , r = v−xh} where
SignerID is the unique user identifier, v ∈R Zq and h = H(g, V, X, SignerID).

The receiver verifies that X lies in the prime-order subgroup G and that g v equals
g r X h . Adding the unique SignerID into the hash function is to prevent Alice re-

playing Bob’s signature back to Bob and vice versa. Note that for Schnorr’s sig-

5
Using a different key has a (subtle) theoretical advantage that the session key will
remain indistinguishable from random even after the key confirmation. However, this
does not make much difference in practical security and is not adopted in [10, 16].
6
Schnorr’s signature is provably secure in the random oracle model, which requires a
secure hash function.
nature, it takes one exponentiation to generate it and two to verify it (computing

g r · X h requires roughly one exponentiation using the simultaneous computation

technique [37]) .

4 Security analysis

In this section, we show the protocol fulfills all the security requirements listed

in Section 2.1.

4.1 Off-line dictionary attack resistance

First, we discuss the protocol’s resistance against the off-line dictionary attack.
Without loss of generality, assume Alice is honest. Her ciphertext A contains

the term (x1 + x3 + x4 ) on the exponent. Let xa = x1 + x3 + x4 . The following

lemma shows the security property of xa .

Lemma 1 The xa is a secret of random value over Zq to Bob.

Proof. The value x1 is uniformly distributed over Zq and unknown to Bob. The

knowledge proofs required in the protocol show that Bob knows x3 and x4 . By
definition xa is computed from x3 and x4 (known to Bob) plus a random number

x1 . Therefore xa must be randomly distributed over Zq .

In the second round of the protocol, Alice sends A = gax2 ·s to Bob, where

ga = g x1 +x3 +x4 . Here, ga serves as a generator. As the group G has prime

order, any non-identity element is a generator [29]. So Alice can explicitly check
ga 6= 1 to ensure it is a generator. In fact, Lemma 1 shows that x1 + x3 + x4 is

random over Zq even in the face of active attacks. Hence, ga 6= 1 is implicitly

guaranteed by the probability. The chance of ga = 1 is extremely minuscule –
on the order of 2−160 for 160-bit q. Symmetrically, the same argument applies to

the Bob’s case. For the same reason, it is implicitly guaranteed by probability
that x1 + x3 6= 0, hence K = g (x1 +x3 )·x2 ·x4 ·s 6= 1 holds with an exceedingly

overwhelming probability.

Theorem 2 (Off-line dictionary attack resistance against active attacks)

Under the Decision Diffie-Hellman (DDH) assumption, provided that g x1 +x3 +x4

is a generator, Bob cannot distinguish Alice’s ciphertext A = g (x1 +x3 +x4 )·x2 ·s

from a random non-identity element in the group G.

Proof. Suppose Alice is communicating to an attacker (Bob) who does not

know the password. The data available to the attacker include g x1 , g x2 , A =

(x1 +x3 +x4 )·x2 ·s
ga and Zero Knowledge Proofs (ZKP) for the respective exponents.
The ZKP only reveals one bit: whether the sender knows the discrete logarithm7 .

Given that g x1 +x3 +x4 is a generator, we have x1 + x3 + x4 6= 0. From Lemma 1,

x1 + x3 + x4 is a random value over Zq . So, x1 + x3 + x4 ∈R [1, q − 1], un-

known to Bob. By protocol definition, x2 ∈R [1, q − 1] and s ∈ [1, q − 1], hence

x2 · s ∈R [1, q − 1], unknown to Bob. Based on the Decision Diffie-Hellman as-

sumption [29], Bob cannot distinguish A from a random non-identity element in

the group. u
t

The above theorem indicates that if Alice is talking directly to an attacker,

she does not reveal any useful information about the password. Based on the pro-

tocol symmetry, the above results can be easily adapted from Alice’s perspective

– Alice cannot compute (x1 + x2 + x3 ), nor distinguish B from a random element

in the group. However, the off-line dictionary attack resistance against an active

attacker does not necessarily imply resistance against a passive attacker (in the
former case, the two passwords are different, while in the latter, they are the

same). Therefore, we need the following theorem to show if Alice is talking to

authentic Bob, there is no information leakage on the password too.
7
It should be noted that if we choose Schnorr’s signature to realize ZKPs, we implicitly
assume a random oracle (i.e., a secure hash function), since Schnorr’s signature is
provably secure under the random oracle model [30].
Theorem 3 (Off-line dictionary attack resistance against passive attacks)

Under the DDH assumption, given that g x1 +x3 +x4 and g x1 +x2 +x3 are generators,
the ciphertexts A = g (x1 +x3 +x4 )·x2 ·s and B = g (x1 +x2 +x3 )·x4 ·s do not leak any in-
formation for password verification.

Proof. Suppose Alice is talking to authentic Bob who knows the password. We

need to show a passive attacker cannot learn any password information by corre-
lating the two users’ ciphertexts. Theorem 2 states that Bob cannot distinguish

A from a random value in G. This implies that even Bob cannot computationally
correlate A to B (which he can compute). Of course, a passive attacker cannot
correlate A to B. Therefore, to a passive attacker, A and B are two random and

independent values in G; they do not leak any useful information for password
verification. u
t

4.2 Forward secrecy

Next, we discuss the forward secrecy. In the following theorem, we consider

a passive attacker who knows the password secret s. As we explained earlier,

the ZKPs in the protocol require Alice and Bob know the values of x1 and

x3 respectively, hence x1 + x3 6= 0 (thus K 6= 1) holds with an exceedingly

overwhelming probability even in the face of active attacks.

Theorem 4 (Forward secrecy) Under the Square Computational Diffie-Hellman

(SCDH) assumption8 , given that K 6= 1, the past session keys derived from the
protocol remain incomputable even when the secret s is later disclosed.

Proof. After knowing s, the passive attacker wants to compute κ = H(K) given
inputs: {g x1 , g x2 , g x3 , g x4 , g (x1 +x3 +x4 )·x2 , g (x1 +x2 +x3 )·x4 }.
8
The SCDH assumption is provably equivalent to the Computational Diffie-Hellman
(CDH) assumption – solving SCDH implies solving CDH, and vice versa [4]
 Assume the attacker is able to compute K = g (x1 +x3 )·x2 ·x4 from those inputs.

For simplicity, let x5 = x1 + x3 mod q. Since K 6= 1, we have x5 6= 0. The at-

tacker behaves like an oracle – given the ordered inputs {g x2 , g x4 , g x5 , g (x5 +x4 )·x2 ,
g (x5 +x2 )·x4 }, it returns g x5 ·x2 ·x4 . This oracle can be used to solve the SCDH prob-

lem as follows. For g x where x ∈R [1, q − 1], we query the oracle by supplying
{g −x+a , g −x+b , g x , g b·(−x+a) , g a·(−x+b) }, where a, b are arbitrary values chosen
3
−(a+b)·x2 +ab·x
from Zq , and obtain f (g x ) = g (−x+a)·(−x+b)·x = g x . In this way, we
3 2 3
+(3−a−b)·x2 +(3−2a−2b+ab)·x+1−a−b+ab
can also obtain f (g x+1 ) = g (x+1) −(a+b)·(x+1) +ab·(x+1)
= gx .
2 ¡ ¢1/3
Now we are able to compute g x = f (g x+1 ) · f (g x )−1 · g (−3+2a+2b)·x−1+a+b−ab .

This, however, contradicts the SCDH assumption [4], which states that one can-
2
not compute g x from g, g x where x ∈R [1, q − 1]. u
t

4.3 Known session security

We now consider the impact of a compromised session. If an attacker is powerful

enough to compromise a session, we assume he can learn all session-specific

secrets, including the raw session key K and ephemeral private keys. In this

case, the password will inevitably be disclosed (say by exhaustive search). This
is an inherent threat and applies to all the existing PAKE protocols [1, 5, 7, 10,
16, 17, 28, 33–35].

Still, we shall minimize the impact of a compromised session: in particular, a

corrupted session must not harm the security of other established sessions. In the

J-PAKE protocol, the raw session key K = g (x1 +x3 )·x2 ·x4 ·s is determined by the

ephemeral random inputs x1 , x2 , x3 , x4 from both parties in the session. As we

mentioned earlier, the probability has implicitly guaranteed that K 6= 1 even in

the face of active attacks. The following theorem shows that the obtained session
key K is random too – in other words, the session keys are all independent.
Therefore, compromising a session (hence learning all session-specific secrets)

has no effect on other established session keys.

Theorem 5 (Random session key) Under the Decision Diffie-Hellman (DDH)

assumption, given that K 6= 1, the past session key derived from the protocol is
indistinguishable from a random non-identity element in G.

Proof. By protocol definition, x2 , x4 ∈R [1, q − 1], and s ∈ [1, q − 1]. Since

K = g (x1 +x3 )·x2 ·x4 ·s 6= 1, we have x1 + x3 6= 0. Let a = x1 + x3 and b = x2 · x4 · s.
Obviously, a ∈R [1, q−1] and b ∈R [1, q−1]. Based on the Decision Diffie-Hellman

assumption [29], the value g a·b is indistinguishable from a random non-identity

element in the group. u
t

4.4 On-line dictionary attack resistance

Finally, we study an active attacker, who directly engages in the protocol exe-
cution. Without loss of generality, we assume Alice is honest, and Bob is com-

promised (i.e., an attacker).

In the protocol, Bob demonstrates that he knows x4 and the exponent of

gb , where gb = g x1 +x2 +x3 . Therefore, the format of the ciphertext sent by Bob
0
can be described as B 0 = gb x4 ·s , where s0 is a value that Bob (the attacker) can

choose freely.

Theorem 6 (On-line dictionary attack resistance) Under the SCDH as-

sumption, an active attacker cannot compute the session key if he chose a value
s0 6= s.

Proof. After receiving B 0 , Alice computes

K 0 = (B 0 /g x2 ·x4 ·s )x2 (1)

0 0 2
·x4 ·(s0 −s)
= g x1 ·x2 ·x4 ·s · g x2 ·x3 ·x4 ·s · g x2 (2)

To obtain a contradiction, we reveal x1 and s, and assume that the attacker is

now able to compute K 0 . The attacker behaves as an oracle: given inputs {g x2 , x1 ,

 Modules Security property Attacker type Assumptions
Schnorr leak 1-bit: whether sender passive/active DL and
signature knows discrete logarithm random oracle
Password indistinguishable passive/active DDH
encryption from random
Session incomputable passive CDH
key incomputable passive (know s) CDH
incomputable passive (know other session keys) CDH
incomputable active (if s0 6= s) CDH
Key leak nothing passive –
confirmation leak 1-bit: whether s0 = s active CDH

Table 1. Summary of J-PAKE security properties

x3 , x4 , s, s0 }, it returns K 0 . Note that the oracle does not need to know x2 , and it
0
is still able to compute A = g (x1 +x3 +x4 )·x2 ·s and B0 = g (x1 +x2 +x3 )·x4 ·s internally.

Thus, the oracle can be used to solve the Square Computational Diffie-Hellman
2 0 0 −1
(s0 −s)−1
problem by computing g x2 = (K 0 /(g x1 ·x2 ·x4 ·s · g x2 ·x3 ·x4 ·s ))x4 . Here9 ,
x4 6= 0 and s0 − s 6= 0. This, however, contradicts the SCDH assumption [4],
2
which states that one cannot compute g x2 from g, g x2 where x2 ∈R [1, q − 1].
So, even with x1 and s revealed, the attacker is still unable to compute K 0 (and

hence cannot perform key confirmation later). u

t

The above theorem shows that what an on-line attacker can learn from the

protocol is only minimal. Because of the knowledge proofs, the attacker is left
with the only freedom to choose an arbitrary s0 . If s0 6= s, he is unable to
derive the same session key as Alice. During the later key confirmation process,

the attacker will learn one-bit information: whether s0 and s are equal. This

is the best that any PAKE protocol can possibly achieve, because by nature

we cannot stop an imposter from trying a random guess of password. However,

consecutively failed guesses can be easily detected, and thwarted accordingly.
The security properties of our protocol are summarized in Table 1.
9
This explains why in the protocol definition we need x4 6= 0, and symmetrically,
x2 6= 0
5 Comparison

In this section, we compare our protocol with two other balanced PAKE schemes:
EKE and SPEKE. These two techniques have several variants, which follow very
similar constructs [7]. However, it is beyond the scope of this paper to evaluate

them all. Also, we will not compare with augmented schemes (e.g., A-EKE,
B-SPEKE, SRP, AMP and OPAKE [27]) due to different design goals.

The EKE and SPEKE are among the simplest and most efficient PAKE
schemes. Both protocols can be executed in one round, while J-PAKE requires

two rounds. On the computational aspect, both protocol require each user to
perform only two exponentiations, compared with 14 exponentiations in J-PAKE

(see Table 2).

At first glance, the J-PAKE scheme looks too computationally expensive.

However, note that both the EKE and SPEKE protocols must use long ex-

ponents (see Section 2.2). Since the cost of exponentiation is linear with the

bit-length of the exponent [29], for a typical 1024-bit p and 160-bit q setting,
one exponentiation in an EKE or SPEKE is equivalent in cost to 6-7 exponen-

tiations in a J-PAKE. Hence, the overall computational costs for EKE, SPEKE

and J-PAKE are actually about the same.

There are several ways to improve the J-PAKE performance. First, the pro-
tocol enumerates 14 exponentiations for each user, but actually many of the

operations are merely repetitions. To explain this, let the bit length of the expo-

nent be L = log2 q. Computing g x1 alone requires roughly 1.5L multiplications

which include L square operations and 0.5L multiplications of the square terms.

However, the same square operations need not be repeated for other items with
the same base g (i.e., g x2 etc). This provides plenty room for efficiency opti-
mization in a practical implementation. In contrast, the same optimization is

not applicable to the EKE and SPEKE. Second, it would be more efficient, par-
 Item Description No of Exp
1 Compute {g x1 , g x2 } and KPs for {x1 , x2 } 4
2 Verify KPs for {x3 , x4 } 4
3 Compute A and KP for {x2 · s} 2
4 Verify KP for {x4 · s} 2
5 Compute κ 2
Total 14

Table 2. Computational cost for Alice in J-PAKE

ticularly on mobile devices, to implement J-PAKE using Elliptic Curve Cryp-

tography (ECC). Using ECC essentially replaces the multiplicative cyclic group
with an additive cyclic group defined over some elliptic curve. The basic protocol

construction remains unchanged.

6 Design considerations

One notable feature of the J-PAKE design is the use of the Zero Knowledge

Proof (ZKP), specifically: Schnorr Signature [30]. The ZKP is a well-established

cryptographic primitive [9]. For over twenty years, this primitive has been playing

a pivotal role in general two/multi-party secure computations [38].

Authenticated key exchange is essentially a two-party secure computation
problem. However, the use of ZKP in this area is rare. The main concern is on

efficiency: the ZKP is perceived as computationally expensive. So far, almost all

of the past PAKE protocols have avoided using ZKP for exactly the reason.

However, the use of ZKP does not necessarily mean the protocol must be in-

efficient. This largely depends on how to effectively integrate this primitive into
the overall design. In our construction, we introduced a novel juggling technique:

arranging the random public keys in such a structured way that the random-
ization factors vanish when both sides supplied the same password. (A similar
use of this juggling technique can be traced back to [15] and [8]). As we have

shown, this leads to computational efficiency that is comparable to the EKE and
SPEKE protocols. To our best knowledge, this design is significantly different

from all past PAKE protocols. In the area of PAKE research – which has been
troubled by many patent arguments surrounding existing schemes [13] – a new
construct may be helpful.

With the same juggling idea, the current construction of the J-PAKE pro-
tocol seems close to the optimum. Note in the protocol, we used four x terms –
x1 , x2 , x3 , x4 . As if one cannot juggle with only two balls, we find it difficult to

juggle with two x terms. This is not an issue in the multi-party setting where
there are at least three participants (each participant generates one “ball”) [15].

For the two-party case, our solution was to let each user create two ephemeral
public keys, and thus preserve the protocol symmetry. It seems unlikely that one
could improve the protocol efficiency by using a total of only 3 (or even 2) x

terms. However, we do not have a proof of minimality on this, so we leave the

question open.

7 Conclusion

In this paper, we proposed a protocol, called J-PAKE, which authenticates a

password with zero-knowledge and then subsequently creates a strong session

key if the password is correct. We showed that the protocol fulfills the following

properties: it prevents off-line dictionary attacks; provides forward secrecy; in-

sulates a compromised session from affecting other sessions; and strictly limits
an active attacker to guess only one password per protocol execution. As com-

pared to the de facto internet standard SSL/TLS, J-PAKE is more lightweight

in password authentication with two notable advantages: 1). It requires no PKI
deployments; 2). It protects users from leaking passwords (say to a fake bank

website).
Acknowledgments

We thank Ross Anderson and Piotr Zieliński for very helpful comments and
discussions.

References

1. M. Abdalla and D. Pointcheval, “Simple password-based encrypted key exchange

protocols,” Topics in Cryptology – CTRSA’05, LNCS 3376, pp. 191–208, 2005.

2. R.J. Anderson, R. Needham, “Robustness principles for public key protocols,”

Proceedings of the 15th Annual International Cryptology Conference on Advances

in Cryptology, LNCS 963, pp. 236–247, 1995.

3. R.J. Anderson, Security Engineering : A Guide to Building Dependable Distributed

Systems, New York, Wiley 2001.

4. F. Bao, R.H. Deng, H. Zhu, “Variations of Diffie-Hellman problem,” Proceeding of

Information and Communication Security, LNCS 2836, pp. 301–312, 2003.

5. M. Bellare, D. Pointcheval, P. Rogaway, “Authenticated key exchange secure

against dictionary attacks,” Eurocrypt’00, LNCS 1807, pp. 139–155, 2000.

6. D. Boneh, “The decision Diffie-Hellman problem,” Proceedings of the Third In-

ternational Symposium on Algorithmic Number Theory, LNCS 1423, pp. 48–63,

1998.

7. C. Boyd, A. Mathuria, Protocols for authentication and key establishment,

Springer-Verlag, 2003.

8. D. Chaum, “The dining cryptographers problem: unconditional sender and recipi-

ent untraceability,” Journal of Cryptology, Vol. 1, No. 1, pp. 65–67, 1988.

9. J. Camenisch and M. Stadler, “Proof systems for general statements about discrete

logarithms,” Technical report TR 260, Department of Computer Science, ETH

Zürich, March 1997.

10. S. Bellovin and M. Merritt, “Encrypted Key Exchange: password-based protocols

secure against dictionary attacks,” Proceedings of the IEEE Symposium on Re-

search in Security and Privacy, May 1992.

11. S. Bellovin and M. Merritt, “Augmented Encrypted Key Exchange: a password-

based protocol secure against dictionary attacks and password file compromise,”

Proceedings of the 1st ACM Conference on Computer and Communications Secu-

rity, pp. 244–250, November 1993.

12. S. Bellovin and M. Merritt, “Cryptographic protocol for secure communications,”

U.S. Patent 5,241,599.

13. E. Ehulund, “Secure on-line configuration for SIP UAs,” Master thesis, The Royal

Institute of Technology, August 2006.

14. W. Ford, B.S. Kaliski, “Server-assisted generation of a strong secret from a pass-

word,” Proceedings of the 9th International Workshops on Enabling Technologies,

pp. 176–180, IEEE Press, 2000

15. F. Hao, P. Zieliński, “A 2-round anonymous veto protocol,” Proceedings of the

14th International Workshop on Security Protocols, SPW’06, Cambridge, UK, May

2006.
16. D. Jablon, “Strong password-only authenticated key exchange,” ACM Computer

Communications Review, Vol. 26, No. 5, pp. 5–26, October 1996.

17. D. Jablon, “Extended password protocols immune to dictionary attack”, Proceed-

ings of the WETICE’97 Enterprise Security Workshop, pp. 248–255, June 1997.
18. D. Jablon, “Cryptographic methods for remote authentication,” U.S. Patent

6,226,383, March 1997.

19. D. Jablon, “Password authentication using multiple servers,” Topics in Cryptology

– CT-RSA, pp. 344–360, LNCS 2020, April 2001.

20. B. Jaspan, “Dual-workfactor Encrypted Key Exchange: efficiently preventing pass-

word chaining and dictionary attacks,” Proceedings of the Sixth Annual USENIX

Security Conference, pp. 43-50, July 1996.

21. K. Kobara, H. Imai, “Pretty-simple password-authenticated key-exchange under

standard assumptions,” IEICE Transactions, Vol. E85-A, No. 10, pp. 2229–2237,

2002.
22. Paul C. Van Oorschot, M.J. Wiener, “On Diffie-Hellman key agreement with short

exponents,” Advances in Cryptology, EUROCRYPT’96, LNCS 1070, pp. 332–343,

1996.
23. S. Patel, “Number theoretic attacks on secure password schemes,” Proceedings of

the IEEE Symposium on Security and Privacy, May 1997.

24. R. Perlman, C. Kaufman, “Secure password-based protocol for downloading a pri-

vate key,” Proceedings of the Network and Distributed System Security, February

1999.
25. p. MacKenzie, “The PAK suite: protocols for password-authenticated key ex-

change,” Technical Report 2002-46, DIMACS, 2002.

26. P. MacKenzie, “On the Security of the SPEKE Password-Authenticated Key Ex-

change Protocol,” Cryptology ePrint Archive: Report 057, 2001.

27. IEEE P1363 Working Group, P1363.2: Standard Specifications for Password-Based

Public-Key Cryptographic Techniques. Draft available at:

http://grouper.ieee.org/groups/1363/
28. T. Wu, “The Secure Remote Password protocol,” Proceedings of the Internet So-

ciety Network and Distributed System Security Symposium, pp. 97–111, March

1998.
29. D. Stinson, Cryptography: theory and practice, Third Edition, Chapman &

Hall/CRC, 2006.
30. C.P. Schnorr, “Efficient signature generation by smart cards,” Journal of Cryptol-

ogy, Vol. 4, No. 3, pp. 161–174, 1991.

31. Muxiang Zhang, “Analysis of the SPEKE password-authenticated key exchange

protocol,” IEEE Communications Letters, Vol. 8, No. 1, pp. 63-65, January 2004.
32. Z. Zhao, Z. Dong, Y. Wang, “Security analysis of a password-based authentication

protocol proposed to IEEE 1363,” Theoretical Computer Science, Vol. 352, No. 1,

pp. 280–287, 2006.

33. O. Goldreich, Y. Lindell, “Session-key generation using human passwords only,”

Crypto’01, LNCS 2139, pp. 408-432, 2001.

34. J. Katz, R. Ostrovsky, M. Yung, “Efficient password-authenticated key exchange

using human-memorable passwords”, Advances in Cryptology, LNCS 2045, pp.

475-494, 2001.
35. S.Q. Jiang, G. Gong, “Password based key exchange with mutual authentication,”

Selected Area in Cryptography, LNCS 3357, pp. 267-279, 2004.

36. H. Krawczyk, “HMQV: a high-performance secure Diffe-Hellman protocol,”

CRYPTO’05, LNCS 3621, pp. 546-566, 2005.

37. A.J. Menezes, P.C. van Oorschot and S.A. Vanstone, Handbook of applied cryptog-

raphy, CRC Press, 1996.

38. O. Goldreich, S. Micali and A. Wigderson, “How to play any mental game or

a completeness theorem for protocols with honest majority,” Proceedings of the

nineteenth annual ACM Conference on Theory of Computing, pp. 218–229, 1987.

39. R. Gennaro, Y. Lindell, “A framework for password-based authenticated key ex-

change,” Eurucrypt’03, LNCS, No. 2656, pp. 524-543, 2003.