Abstract
Protocols for password authenticated key exchange (PAKE) allow two parties who share only a weak password to agree on a cryptographic key. We revisit the notion of PAKE in the universal composability (UC) framework, and propose a relaxation of the PAKE functionality of Canetti et al. that we call lazyextraction PAKE (lePAKE). Our relaxation allows the idealworld adversary to postpone its password guess until after a session is complete. We argue that this relaxed notion still provides meaningful security in the passwordonly setting. As our main result, we show that several PAKE protocols that were previously only proven secure with respect to a “gamebased” definition of security can be shown to UCrealize the lePAKE functionality in the randomoracle model. These include SPEKE, SPAKE2, and TBPEKE, the most efficient PAKE schemes currently known.
You have full access to this open access chapter, Download conference paper PDF
Similar content being viewed by others
1 Introduction
Protocols for password authenticated key exchange (PAKE) allow two parties who share only a weak password to agree on a cryptographically strong key by communicating over an insecure network. PAKE protocols have been studied extensively in the cryptographic literature [8,9,10, 13, 14, 16, 26], and are compelling given the widespread use of passwords for authentication. Even though the current practice is to implement passwordbased authentication by using TLS to set up a secure channel over which the password is sent, there are many arguments in favor of using PAKE protocols in conjunction with TLS [23]. Continued interest in PAKE is indicated by the fact that several PAKE protocols are currently under active consideration for standardization by the IETF [29].
Defining security for PAKE protocols is made challenging by the fact that a password shared by the parties may have low entropy, and so can be guessed by an adversary with noticeable probability. This must somehow be accounted for in any security definition. Roughly speaking, the security guaranteed by a PAKE protocol is that an attacker who initiates Q online attacks—i.e., actively interferes in Q sessions of the protocol—can make at most Q password guesses (i.e., at most one per session in which it interferes) and can succeed in impersonating a party only if one of those guesses was correct. In particular, this means that offline attacks, in which an adversary merely eavesdrops on executions of the protocol, should not help the adversary in any way.
Two paradigms of PAKE security. In the cryptographic literature there are two leading paradigms for defining the above intuition. The first is the socalled “gamebased” definition introduced by Bellare et al. [8]. Here, a password is chosen from a distribution with minentropy \(\kappa \), and the security experiment considers an interaction of an adversary with multiple instances of the PAKE protocol using that password. A PAKE protocol is considered secure if no probabilistic polynomialtime (PPT) attacker can distinguish a real session key from a random session key with advantage better than \(Q \cdot 2^{\kappa }\) plus a negligible quantity.
A second approach uses a “simulationbased” definition [10, 13]. The most popular choice here is to work in the universal composability (UC) framework [12], and this is what we assume here. This approach works by first defining an appropriate ideal functionality for PAKE; a PAKE protocol is then considered secure if it realizes that functionality in the appropriate sense. Canetti et al. [13] pursued this approach, and defined a PAKE functionality that explicitly allows an adversary to make password guesses; a random session key is generated unless the adversary’s password guess is correct. As argued by Canetti et al. [13], this approach has a number of advantages. A definition in the UC framework is better suited for handling general correlations between passwords, e.g., when a client uses unequal but related passwords with different servers, or when an honest party uses different but closely related passwords due to mistyping. It also ensures security under arbitrary protocol composition, which is useful for arguing security of protocols that use PAKE as a subroutine, e.g., for converting symmetric PAKE to asymmetric PAKE [15, 21] or strong asymmetric PAKE [23]. This is especially important in the context of PAKE standardization, because strong asymmetric PAKE protocols can strengthen the current practice of passwordoverTLS authentication while achieving optimal security against server compromise.
Is there an inherent price for simulationbased security? Simulationbased security for PAKE is a desirable target. Unfortunately, the current stateoftheart [11, 13, 25, 28] suggests that this notion is more difficult to satisfy than the gamebased definition. In particular, the most efficient UC PAKE protocol [11] is roughly a factor of two less efficient than the most efficient gamebased PAKEs^{Footnote 1} such as SPEKE [20, 22, 31], SPAKE2 [7], or TBPEKE [33].
Perhaps surprisingly, we show here that this “gap” can be overcome; in particular, we show that the SPEKE, SPAKE2, and TBPEKE protocols—which were previously only known to be secure with respect to the gamebased notion of security—can be shown to be universally composable (in the randomoracle model). The caveat is that we prove universal composability with respect to a relaxed version of the PAKE functionality originally considered by Canetti et al. [13]. At a high level, the main distinction is that the UC PAKE functionality of Canetti et al. requires an attacker conducting an online attack against a session to make its password guess before that session is completed, whereas the relaxed functionality we consider—which we call lazyextraction PAKE (lePAKE)—allows the attacker to delay its password guess until after the session completes. (However, the attacker is still limited to making a single password guess per actively attacked session.) On a technical level, this relaxed functionality is easier to realize because it allows the simulator to defer extraction of an attacker’s password guess until a later point in the attacker’s execution (see further discussion below). Nevertheless, the lazyextraction PAKE functionality continues to capture the core properties expected from a PAKE protocol. In particular, as a sanity check on the proposed notion, we show that lePAKE plus key confirmation satisfies the gamebased notion of PAKE with perfect forward secrecy (PFS) [5, 6, 8].
Implications for PAKE standardization. Recently, the Crypto Forum Research Group (CFRG), an IRTF (Internet Research Task Force) research group focused on applications of cryptographic mechanisms, initiated a PAKE selection process with the goal of providing recommendations for passwordbased authenticated key establishment for the IETF. Originally, four candidates were under consideration by the CRFG in the symmetric PAKE category; the final decision was between SPAKE2 and CPace, and the latter was ultimately selected. Our results validate the security of SPAKE2 and the proof we provide for TBPEKE will be adapted to cover CPace and included in the full version [2].
1.1 Technical Overview
The fundamental reason for an efficiency gap between known protocols achieving gamebased PAKE and simulationbased PAKE is that the UC PAKE functionality, as defined by Canetti et al. [13] and used in all subsequent work, requires the adversary’s password guesses to be (straightline) extractable from the adversary’s messages to the honest parties. Recall that for a PAKE to be UC secure there must exist an efficient simulator which simulates PAKE protocol instances given access to the ideal PAKE functionality, which in particular requires the simulator to specify a unique explicit password guess for each PAKE instance which the realworld adversary actively attacks. (The ideal PAKE functionality then allows the simulator, and hence the realworld adversary, to control the session key output by this instance if the provided password guess matched the password used by that PAKE instance, and otherwise the session key is random and thus secure.) The fact that the simulator must specify this explicit password before the attacked PAKE instance terminates, requires the simulator to online extract the password guess committed to in adversary’s messages. Moreover, this extraction must be performed straightline, because universal composibility prohibits rewinding the adversary.
Unfortunately, online extraction cannot be done for many efficient gamebased PAKE’s listed above, because in these protocols each party sends a single protocol message which forms a perfectly hiding commitment to the password. Specifically, if g generates group of prime order \( p \) then in SPAKE2 each party sends a message of the form \(X = g^z \cdot {P_i}^{ pw }\) where , \(P_1,P_2\) are random group elements in the CRS, and \(i\,{=}\,1\) or 2 depending on the party’s role. In TBPEKE, this message has the form \(X=(P_1\,\cdot \,{P_2}^{H( pw )})^z\), and in SPEKE it is \(X=H( pw )^z\) where H is a hash onto the group. These commitments are binding under the discrete logarithm hardness assumption (the first two are variants of the Pedersen commitment [32] and the third one requires the randomoracle model), and they are equivocable, i.e., the simulator can “cheat” on messages sent on behalf of the honest parties, but they are perfectly hiding and thus not extractable. These commitments can be replaced with extractable ones, but it is not clear how to do so without increasing protocol costs (or resorting to ideal ciphers over a group).
PAKE with postexecution input extraction. However, in all the above schemes the final session key is computed by hashing the protocol transcript and the DiffieHellman key established by this PAKE interaction, e.g. \(Z=g^{z_1\cdot z_2}\) in SPAKE2 or \(Z=(H( pw ))^{z_1\cdot z_2}\) in SPEKE. Since this final hash is modeled as a random oracle (RO), an adversary who learns any information on the session key must query this RO hash on the proper input. If the information in this hash query suffices for the simulator to identify the unique password to which this query corresponds, then a protocol message together with the final hash inputs do form an extractable commitment to the unique password guess the adversary makes on the attacked session.
However, the hash used in the final session key derivation is a local computation each party does in a “postprocessing” stage which can be executed after the counterpart terminates the protocol. Therefore a simulator which extracts a password guess from the adversary’s protocol message(s) and this local hash computation might extract it after the attacked session terminates. By the rules of the PAKE functionality of Canetti et al. [13], such extraction would happen too late, because the PAKE functionality allows the simulator to test a password guess against a session but does so only when this session is still active (and has not been attacked previously e.g. on a different password guess). Indeed, it would seem counterintuitive to allow the idealworld adversary, i.e., the simulator, to provide the unique effective password guess after the attacked session completes. Nevertheless, this is exactly how we propose to relax the UC PAKE functionality in order to accommodate protocols where inputextraction is possible, but succeeds only from the adversary’s postprocessing computation.
The relaxation we propose, the lazyextraction PAKE, will require the idealworld adversary to “interrupt” a fresh session while it is active in order to then perform the postexecution password test (we will call such tests “late” password tests). This models the UC PAKE requirement that an adversary can use an honest PAKE session as a passwordtesting oracle only if it actively attacks that session, and in particular it still holds that passively observed sessions do not provide any avenue for an attack. (To keep the new elements of the lazyextraction PAKE model clear we use separate terms, resp. \(\mathsf {RegisterTest}\) and \(\mathsf {LateTestPwd}\), for this new type of online session interruption and for the late password test, see Sect. 2.) Moreover, even if the adversary chooses this “lazyextraction attack” route, the functionality still allows for only a single password test on an actively attacked session. This requirement effectively commits a (computationally bounded) realworld adversary to a unique password guess on each actively attacked session, because an adversary who performs the local computation related to more than one password test would not be simulatable in the model where the idealworld adversary can submit at most one such test to the lazyextraction PAKE functionality.
Explicit authentication and perfect forward security. To test the proposed lazyextraction UC PAKE notion we show two further things. First, we show that any lazyextraction UC PAKE followed by a key confirmation round upgrades lazyextraction UC PAKE to PAKE with explicit (mutual) authentication (PAKEEA) [17], but it also realizes a stronger variant of lazyextraction PAKE functionality which we call the relaxed UC PAKE. In the relaxed PAKE model, the adversary can still make a (single) late password test on an actively attacked session but such sessions are guaranteed to terminate with an abort. Hence, the attacker cannot use a late password test to compromise a session. Intuitively, if a lazyextraction PAKE is followed by a key confirmation and the attacker delays its late password test until after the key confirmation is sent, then the key confirmation must fail and its counterpart will abort on such session. Hence, the “late password test” reveals if the tested passworded was correct but it cannot reveal a key of an active session.
Secondly, we show that any relaxed UC PAKE satisfies the gamebased notion of PAKE with perfect forward secrecy (PFS) [5, 6, 8]. (A similar test was done by Canetti et al. with regard to the original UC PAKE notion [13].) Intuitively, since the lazyextraction attack avenue against a relaxed PAKE cannot be used to compromise keys of any active session, it follows that all active sessions, i.e., all sessions which terminate with a session key as opposed to an abort, are as secure in the relaxed UC PAKE model as they are in the original UC PAKE model of Canetti et al. In particular, they are secure against future password compromise.
Related and concurrent work. Jarecki et al. [24] recently introduced the relaxed UC PAKE model in the context of the asymmetric PAKE (aPAKE) functionality [15], and showed that this relaxation is necessary to prove security of the OPAQUE protocol proposed in [23]. As discussed above, the lazyextraction PAKE model goes further than the relaxed PAKE model, and this further relaxation appears to be necessary in order to model protocols like SPEKE, SPAKE2, and TBPEKE as universally composable PAKEs. (See Section 2 for the precise specifications of the lazyextraction PAKE and the relaxed PAKE models.)
Hasse and Labrique [18] have recently argued that CPace [19] realizes a variant of the lazyextraction UC PAKE functionality, but the variant of this notion they consider seems unsatisfactory, e.g. it appears not to imply security of passively observed sessions, and it appears to be not realizable as stated (see Sect. 2 for discussion). They also argue that adding a keyconfirmation step suffices to convert such protocol into a standard UC PAKE, while we show that the result is still only a relaxed UC PAKE.^{Footnote 2}
In concurrent work, Shoup [34] analyzes the UC security of two variants of SPAKE2 in the symmetric (PAKE) and asymmetric (aPAKE) settings. Both variants include builtin key confirmation and the protocol flows are simplified so that only the initiator uses the password for blinding its first message. Shoup shows these protocols UC secure with respect to revised ideal functionalities for PAKE and aPAKE, under a slightly weaker assumption than the one required by our modular proof, namely strong DiffieHellman [3] instead of Gap CDH. (Strong DH is a variant of Gap CDH where the DDH oracle can be queried on triples whose first element is fixed.) The revised UC PAKE functionality considered in [34] appears equivalent to the relaxed UC PAKE functionality which we show is realized by SPAKE2 with key confirmation.
1.2 Publication Note
The work of Abdalla and Barbosa [1], which provides a gamebased security analysis of SPAKE2, has been merged with the current paper. However, since the focus of the present work is on the UC security analysis of practical PAKE schemes, we omit specific gamebased security analyses of SPAKE2 here and refer the reader to [1] for these analyses.
1.3 Paper Overview
In Sect. 2, we introduce the two relaxations of the UC PAKE functionality, namely the lazyextraction UC PAKE and relaxed UC PAKE functionalities, respectively abbreviated as lePAKE and rPAKE, together with the extension of the latter to explicit (mutual) authentication. In Sect. 3, we show that SPAKE2 scheme of [7] is a secure lePAKE under the Gap CDH assumption. In Sect. 4, we show that any lePAKE protocol followed by a key confirmation round is a secure rPAKEEA, i.e., rPAKE with explicit authentication. In Sect. 5, we show that every rPAKEEA protocol satisfies the gamebased notion of PAKE with perfect forward secrecy, and that every lePAKE protocol by itself already satisfies weak forward secrecy. In Sect. 6, we also include the proof that TBPEKE [33] is a secure lePAKE protocol under appropriate assumptions, and we explain that this proof extends to similar results regarding SPEKE [20, 22, 31] and other variants of TBPEKE.
2 Relaxations of UC PAKE
In Fig. 1, we present the PAKE functionality as defined by Canetti et al. [13], and compare it with two relaxations that we refer to as relaxed PAKE (rPAKE) and lazyextraction PAKE (lePAKE). We explain at a high level the differences between these various formulations. In the original PAKE functionality \(\mathcal {F}_{\mathsf {PAKE}}\), after a party initiates a session (but before the party generates a key) the attacker may try to guess the password used in that session by making a single \(\mathsf {TestPwd}\) query. If the attacker’s password guess is correct, the session is marked \(\mathsf {compromised}\); if not, the session is marked \(\mathsf {interrupted}\). When a session key is later generated for that session, the attacker is given the ability to choose the key if the session is marked \(\mathsf {compromised}\), but a random key is chosen otherwise. Importantly, the attacker is only allowed to make a password guess for a session before the key is generated and the session terminates.
In both the relaxed PAKE functionality \(\mathcal {F}_{\mathsf {rPAKE}}\) and the lazyextraction PAKE functionality \(\mathcal {F}_{\mathsf {lePAKE}}\), the attacker is given the ability to make a password guess for a session even after a session key is generated and that session has completed. Formally, this is allowed only if the attacker makes a \(\mathsf {RegisterTest}\) query before the session key is generated; this indicates the attacker’s intention to (possibly) make a password guess later, and models active interference with a realworld protocol execution. (Of course, the attacker also has the option of making a password guess before a key is generated as in the original \(\mathcal {F}_{\mathsf {PAKE}}\).) Having made a \(\mathsf {RegisterTest}\) query for a session, the attacker may then make a \(\mathsf {LateTestPwd}\) query to that session after the session key K is generated. \(\mathcal {F}_{\mathsf {rPAKE}}\) and \(\mathcal {F}_{\mathsf {lePAKE}}\) differ in what happens next:
First, in \(\mathcal {F}_{\mathsf {rPAKE}}\), the attacker is only told whether or not its password guess is correct, but learns nothing about K in either case. Secondly, in \(\mathcal {F}_{\mathsf {lePAKE}}\), the attacker is given K if its password guess is correct, and given a random key otherwise.^{Footnote 3}
It is easy to see that both \(\mathcal {F}_{\mathsf {rPAKE}}\) and \(\mathcal {F}_{\mathsf {lePAKE}}\) are relaxations of \(\mathcal {F}_{\mathsf {PAKE}}\), in the sense that any protocol realizing \(\mathcal {F}_{\mathsf {PAKE}}\) also realizes \(\mathcal {F}_{\mathsf {rPAKE}}\) and \(\mathcal {F}_{\mathsf {lePAKE}}\). Although, as defined, \(\mathcal {F}_{\mathsf {lePAKE}}\) and \(\mathcal {F}_{\mathsf {rPAKE}}\) are incomparable, the version of \(\mathcal {F}_{\mathsf {lePAKE}}\) in which the attacker is additionally notified whether its password guess is correct (cf. Footnote (See Footnote 3)) is a strict relaxation of \(\mathcal {F}_{\mathsf {rPAKE}}\).
Following the work of Groce and Katz [17], we also consider PAKE functionalities that incorporate explicit (mutual) authentication, which we refer to as PAKEEA.^{Footnote 4} Intuitively, in a PAKEEA protocol a party should abort if it did not establish a matching session key with its intended partner. As in the case of PAKE, the original PAKEEA functionality introduced by Groce and Katz required the attacker to make its password guess before the session key is generated, while we introduce a relaxed version of the PAKEEA functionality, denoted \(\mathcal {F}_{\mathsf {rPAKE}\text{ }\mathsf {EA}}\) and shown in Fig. 2, that allows the attacker to delay its password guess until after the session has completed.^{Footnote 5} If the attacker’s guess is correct, it is notified of that fact; our relaxation thus parallels that of \(\mathcal {F}_{\mathsf {rPAKE}}\). Note that such late password guess can only be performed on aborted sessions, since the attacker must send a \(\mathsf {RegisterTest}\) query before the session completes, which marks the session \(\mathsf {interrupted}\), and by the rule of explicit authentication, an \(\mathsf {interrupted}\) session must result in aborting.
Besides the intuitive appeal of our relaxed definitions, we justify these relaxations by showing that it is easy to realize \(\mathcal {F}_{\mathsf {rPAKE}\text{ }\mathsf {EA}}\) in the \(\mathcal {F}_{\mathsf {lePAKE}}\)hybrid world (Sect. 4), that any protocol realizing \(\mathcal {F}_{\mathsf {rPAKE}}\) satisfies perfect forward secrecy (Sect. 5), and that any protocol realizing \(\mathcal {F}_{\mathsf {lePAKE}}\) satisfies weak forward secrecy (Sect. 5.3).
Note on the relaxed PAKE functionality used in [18]. A preliminary version of the lazyextraction PAKE functionality, referred as “relaxed PAKE” therein, appeared in an early version of [24] and was adopted by [18] as a model for the CPace protocol. This version was imprecise in several respects: First, it does not require the adversary to explicitly attack an online session via a \(\mathsf {RegisterTest}\) query before issuing a \(\mathsf {LateTestPwd}\) query on a completed session. This appears too weak, e.g. because it allows an adversary to issue \(\mathsf {LateTestPwd}\) queries even on passively observed sessions. On the other hand, it restricts the adversary from making a \(\mathsf {LateTestPwd}\) query upon completion of the matching counterpart’s session (with a matching \( sid \) but not necessarily a matching password), which appears too strong, because a maninthemiddle attacker can make \(\mathcal {P}'\) complete with a random key or an abort, and this does not affect its capabilities regarding party \(\mathcal {P}\). Our lazyextraction PAKE functionality makes this notion more precise, and in Sect. 6 we show that TBPEKE [33] and SPEKE [22] realize the lePAKE fuctionality under (Gap) CDH and/or SDH assumptions. Since CPace [18, 19] is a close variant of SPEKE, these results can be extended to cover CPace as well.^{Footnote 6}
3 Security of SPAKE2
We consider SPAKE2 as a motivating example for our work. SPAKE2 was proposed by Abdalla and Pointcheval [7] and shown secure in the gamebased PAKE model [8] under the CDH assumption in the randomoracle model. SPAKE2 is, to the best of our knowledge, the most efficient PAKE protocol which does not assume ideal cipher over a group. Its costs are 2 fixedbase and 1 variablebase exponentiations per party, and it is roundminimal because it can be executed in a single simultaneous round of bidirectional communication.
We show that SPAKE2 realizes the lazyextraction UC PAKE functionality under the Gap CDH assumption, and the result is tight in the sense that any environment which distinguishes between the realworld execution of SPAKE2 and the idealworld interaction with a simulator and the lazyextraction PAKE functionality, and does so in time T with advantage \(\epsilon \), implies an attack on Gap CDH which achieves roughly the same \((T,\epsilon )\) advantage, where “roughly” means that both T and \(\epsilon \) are modified by only additive factors. This UC security proof complements the result that SPAKE2 meets the gamebased PFS definition [1], which was not considered in [7]. Interestingly, the gamebased PFS result of [1] is not tight: The proof relies on a special assumption introduced in [7] for which a reduction to Gap CDH is known, but it is not a tight reduction. Still, since we do not know that lazyextraction UC PAKE security implies PFS security by itself, this result is the only one we currently know for PFS security of (raw) SPAKE2.^{Footnote 7}
We recall the twoflow, simultaneous round SPAKE2 protocol of [7] in Fig. 3, with some notational choices adjusted to the UC setting.
Theorem 1
\(\mathsf {SPAKE2}\) realizes the LazyExtraction PAKE functionality \(\mathcal {F}_{\mathsf {lePAKE}}\) in the randomoracle model under the GapCDH assumption.
Gap CDH and Gap DL assumptions. Recall that the Computational DiffieHellman (CDH) assumption states that, given generator g and two random elements \(A=g^a\), and \(B=g^b\) in a cyclic group of prime order, it is hard to find \(C=\mathsf {DH}_g(A,B)=g^{ab}\), while the Discrete Logarithm (DL) assumption states that it is hard to find \(a=\mathsf {DL}_g(A)\) given (g, A), for random A. In the gap version of either assumption, the respective problem must remain hard even if the adversary has access to a Decisional DiffieHellman oracle, which on any triple of group elements (A, B, C) returns 1 if \(C=\mathsf {DH}_g(A,B)\) and 0 otherwise. The Gap DL assumption follows via a trivial (and tight) reduction from the Gap CDH assumption, but we introduce it to highlight the fact that certain forms of adversarial behavior in SPAKE2 imply solving the harder problem of Gap DL.
Simulator for SPAKE2. The UC simulator \(\mathsf {SIM}\) for SPAKE2, given in full in Fig. 4, acts as the ideal adversary, with access to the ideal functionality \(\mathcal {F}_{\mathsf {lePAKE}}\) (shortened to \(\mathcal {F}\) in the subsequent discussion). The simulator’s goal is to emulate, except for at most negligible probability, the realworld interaction between the environment \(\mathcal {Z}\), a realworld adversary \(\mathcal {A}\), and honest parties running the SPAKE2 protocol. Technically, \(\mathsf {SIM}\) must simulate messages that appear to come from the real players, respond appropriately to adversarial messages, and answer randomoracle queries consistently, and to do so with access to the \(\mathcal {F}\) interface, but not the secret inputs, i.e., the passwords, of the honest players.
We briefly describe how \(\mathsf {SIM}\) simulates client \(\mathcal {P}\)’s interaction with an arbitrary environment \(\mathcal {Z}\) and an adversary \(\mathbf {Adv}\). (The server case is similar since the protocol is symmetric.) \(\mathsf {SIM}\) first embeds trapdoors into the CRS, i.e., it picks and sets \(M=g^m\) and \(N=g^n\). To simulate the protocol message X, \(\mathsf {SIM}\) picks and sets \(X=g^z\). Since X is also uniformly distributed in the real protocol, the environment cannot tell the difference. When \(\mathcal {A}\) queries the random oracle \(\mathsf {H}( sid ,\mathcal {P},\mathcal {P}',X,Y',pw,W)\), \(\mathsf {SIM}\) decides whether it corresponds to a valid password guess: \(\mathsf {SIM}\) first computes the exponent \(\hat{x}\) such that \(X=g^{\hat{x}} \cdot M^{pw}\), using the CRS trapdoor m, and then checks if \(W=(Y'/N^{ pw })^{\hat{x}}\). If so, then \(\mathsf {SIM}\) stores \((Y', pw)\). If \(\mathcal {A}\) later sends a protocol message \(Y'\) aimed at \(\mathcal {P}\), then this is an online attack: when \(\mathcal {A}\) makes the RO query, \(\mathsf {SIM}\) picks a random string K as the output, and stores K together with \((Y', pw )\). Then, when \(\mathcal {A}\) sends \(Y'\), \(\mathsf {SIM}\) sends \((\mathsf {TestPwd},sid,\mathcal {P},pw)\) to \(\mathcal {F}\), and if \(\mathcal {F}\) replies “correct guess," then \(\mathsf {SIM}\) sets \(\mathcal {P}\)’s key to K by sending \((\mathsf {NewKey}, sid ,\mathcal {P},K)\) to \(\mathcal {F}\). (Otherwise, i.e., if \(\mathcal {F}\) replies “wrong guess”, \(\mathsf {SIM}\) sends \((\mathsf {NewKey}, sid ,\mathcal {P},0^{\kappa })\) and \(\mathcal {F}\) sets \(\mathcal {P}\)’s key to a random string). On the other hand, if \(\mathcal {A}\) makes an above query to \(\mathsf {H}\) after sending \(Y'\) to the client, then this is a postponed attack, so \(\mathsf {SIM}\) sends \((\mathsf {RegisterTest},sid,\mathcal {P})\) to \(\mathcal {F}\) when \(\mathcal {A}\) sends \(Y'\) for which no such query has been made yet, and later sends \((\mathsf {LateTestPwd}, sid ,\mathcal {P}, pw )\) to \(\mathcal {F}\) when \(\mathcal {A}\) makes the above query to \(\mathsf {H}\). If \(\mathcal {F}\) then replies with a key K (which is either correct or random, depending on whether \( pw \) is correct or not), \(\mathsf {SIM}\) “programs” \(\mathsf {H}\) output as K. An adversary could distinguish this emulation from a real interaction by querying \(\mathsf {H}\) on \(( sid ,\mathcal {P},\mathcal {P}',X,Y',pw_i,W_i)\) tuples for \(W_i=(Y'/N^{ pw _i})^{\hat{x}_i}\) and \(\hat{x}_i=\mathsf {DL}(X/M^{pw_i})\) for two different passwords \(pw_i\), but we show that this attack, as well as all others, can be reduced to Gap CDH.
Record keeping. For each party \(\mathcal {P}\) and session \( sid \), simulator \(\mathsf {SIM}\) stores a state \({\pi }_{\mathcal {P}}^{ sid }=(\mathsf {role},\mathsf {exp},\mathcal {C},\mathcal {S},X,Y,X^*,Y^*,\mathsf {pw},\mathsf {guesses},\mathsf {waiting})\) whose components are used as follows:

Variable \(\mathsf {role}\in \{\mathsf {client},\mathsf {server}\}\) is the role of \(\mathcal {P}\) in this session. (Note that in the protocol of Fig. 3 variable \(\mathsf {role}\) is used only in the ordering of the identities in the hash \(\mathsf {H}\) query).

\(\mathsf {exp}\) is the private exponent used in the network messages, x for \(\mathcal {C}\) and y for \(\mathcal {S}\). In the first few games, it has the same meaning as in the protocol, but for \(\mathsf {SIM}\) it is the discrete log of the simulated network message.

\(\mathcal {C},S\) are the the party party identifiers for client and server respectively, \(X,Y\) are the simulated messages sent by resp. \(\mathcal {C}\) and \(\mathcal {S}\) (on sessions identified by \( sid \)), and \(X^*,Y^*\) are the messages the adversary sends to resp. \(\mathcal {S}\) and \(\mathcal {C}\). Simulator \(\mathsf {SIM}\) stores messages X and \(Y^*\) for the client (copying Y from the server if it exists), and symmetrically it stores Y and \(X^*\) for the server (copying X from the client if it exists). Unknown values are set to \(\bot \).

\(\mathsf {pw}\) is a password used by party \(\mathcal {P}\) on session \( sid \). It is used only in intermediate games, while simulator \(\mathsf {SIM}\) always sets it to \(\bot \).

\(\mathsf {guesses}\) is a table mapping group elements \(Z^*\) to pairs \((\mathsf {pw},K^{*})\), representing potential password guesses and corresponding keys, which the simulator constructs from adversary’s queries to oracle \(\mathsf {H}\) of the form \(( sid ,\mathcal {P},\mathcal {P}',X,{Z}^{*}, \mathsf {pw}, \cdot )\) if \(\mathcal {P}\) plays the client role, and \(( sid ,\mathcal {P}',\mathcal {P},Y,{Z}^{*},\mathsf {pw},\cdot )\) if \(\mathcal {P}\) plays the server role. If the adversary sends \({Z}^{*}\) to party \(\mathcal {P}\), the simulator looks up the corresponding password \(\mathsf {pw}\), which it sends to \(\mathcal {F}\) as a tested password.

\(\mathsf {waiting}\) is a flag which is set to \(\mathtt {T}\) for the session which has not received an adversarial message \({Z}^{*}\), and \(\mathtt {F}\) otherwise. This flag is used to ensure that only the first message an adversary sends to a session is processed, and all others are ignored.
Let be the probability of the event that environment \(\mathcal {Z}\) with adversary \(\mathcal {A}\) outputs 1 in the real world, and \(\mathbf {Ideal}_{\mathcal {Z},\mathsf {SIM},\mathsf {SPAKE2}}\) be the corresponding probability in the ideal world. The goal is to show that is negligible. We use the wellknown sequenceofgames proof strategy to show that we may move from the real game to the simulator in a manner indistinguishable to the environment, except for negligible probability. We begin with Game 0, the real game, and move through a series of steps, each of which we show to be indistinguishable from the previous, to the final simulator. Throughout the proof, \(\mathbf {Gi}\) denotes the probability that \(\mathcal {Z}\) outputs 1 while interacting with Game i.
Proof of Theorem 1.
This is the real world, in which \(\mathcal {A}\) interacts with real players, and may view, modify, and/or drop network messages.
(Simulate real world with trapdoors) We now simulate the behavior of the real players and the random oracle. The simulation is exactly as the real game, except for the inclusion of record keeping, and embedding of trapdoors in M and N, by setting \(M = g^m\) and \(N=g^n\) for known m and n. The embedding of trapdoors is not noticeable to the environment as M and N are still drawn from the same distribution as before, thus:
(Random key if adversary is passive) If the adversary passes a simulated Z message sent to \(( sid ,\mathcal {P})\) without modification, output a random key for \(\mathcal {P}\) instead of the true randomoracle output. The environment notices this change only if \(\mathcal {A}\) makes a hash query that would result in an inconsistency, namely \(\mathsf {H}( sid ,\mathcal {C},\mathcal {S},X',Y', pw ,W=g^{xy})\), where \(X'=g^xM^{ pw }\) and \(Y'=g^yN^{ pw }\) are the simulated messages. We check for such queries, and abort if any occur.
We may reduce this event to GapCDH as follows. Let \(q_{s}\) be the maximum number of sessions invoked by the environment. Consider an adversary against GapCDH. On generalized CDH challenge^{Footnote 8} \((A_1=g^{a_1},\cdots ,A_{q_{s}}=g^{a_{q_{s}}},B_1=g^{b_1},\cdots ,B_{q_{s}} = g^{b_{q_{s}}})\), the reduction indexes sessions \(( sid ,\mathcal {P},\mathcal {P}')\), and embeds \(X_i = A_i \cdot M^{ pw _i}\), \(Y_i = B_i \cdot N^{ pw _i}\) when generating the simulated messages for the ith session. The reduction can reuse the code of , except for the cases where it requires the secret exponents \(a_i\) and \(b_i\): (1) to generate \(K \leftarrow \mathsf {H}( sid ,\mathcal {C},\mathcal {S},X,Y, pw ,\hat{Y}^{a_i} \{\mathrm { or }~\hat{X}^{b_i}\})\) and (2) to check for the “bad event" of an inconsistency in the hash response. To handle case (1), the reduction stores an additional value K for each session \(( sid ,\mathcal {C},\mathcal {S})\) which is set randomly when either the reduction must handle case (1), or when \(\mathcal {A}\) queries \(\mathsf {H}( sid ,\mathcal {C},\mathcal {S},X',Y', pw ,W)\) such that the password is correct and \(\mathsf {DDH}(X',Y',W)\) holds (checked via the DDH oracle): if either of these events happens again the same value of K is used. The check of case (2) can be done via the DDH oracle, i.e., by querying \(\mathsf {DDH}(A_i,B_i,W)\): if the bad event occurs, solves the CDH challenge with answer W. Thus:
(Random simulated messages) On \((\mathsf {NewSession}, sid , \mathcal {P},\mathcal {P}',\mathsf {role})\), if this is the first \(\mathsf {NewSession}\) for \(( sid , \mathcal {P})\), set \(Z \leftarrow g^{z}\) for , and send Z to \(\mathcal {A}\) as a message from \(\mathcal {P}\) to \((\mathcal {P}', sid )\). Note that we may now compute the original exponents via: \(\hat{x}= m \cdot {\pi }_{\mathcal {C}}^{ sid }.\mathsf {exp} m \cdot pw \) and \(\hat{y}= n \cdot {\pi }_{\mathcal {S}}^{ sid }.\mathsf {exp} n \cdot pw \). This change is not observable to the environment, as it is merely a syntactic change in the calculation of the exponents:
(Random keys if adversary does not correctly guess password) We now detect when an adversarial hash query corresponds to a password guess. We can detect this event by inspecting the \(X'\), \(Y'\), \( pw \) and W values provided to the hash oracle. Let us assume the adversary is guessing the client’s password (the server case is symmetric). To make a password guess against the client, the adversary must set \(X'= {\pi }_{\mathcal {C}}^{ sid }.X\), i.e., use the simulated message sent by the client. The adversary can use any choice of \(Y'\), but to correspond with a specific password guess, the following must hold: \(W = (Y'/N^{ pw })^{\hat{x}}\) (where \(\hat{x}\) is the exponent such that \({\pi }_{\mathcal {C}}^{ sid }.X = g^{\hat{x}}M^{ pw }\)). In other words, W must be the value that would be used by a real client if \(Y'\) were sent as the server’s message. If such a password guess query is detected, we check if \(Y'\) was previously sent as an adversarial message on behalf of the server: if so, and if the password guess is correct, we program the random oracle to match the previously sent key. If \(Y'\) was not previously sent, we note the values \(Y', pw \) queried by the adversary and the random key K output by the RO. If \(Y'\) is later sent as the adversarial message, and the password is correct, we output the stored key K. If the password is incorrect, we output a random key independent of the RO table. If at any point a second password guess (correct or incorrect) is detected for the same \( sid \) and party, we abort the game.
This change is noticeable to the environment only in the abort case, i.e, the case where the adversary makes two password guesses with a single \((X',Y')\) transcript, i.e.:
such that \( pw \ne pw '\), and
Call this event . It can be split into two cases: 1) for one of the passwords \( pw ^* \in \{ pw , pw '\}\) it holds that \(X'= M^{ pw ^*}\) or \(Y'= N^{ pw ^*}\), i.e., there is a collision between the guessed password \( pw ^*\) and the secret exponent x or y or 2) there is no such collision. Case 2, which we denote \({ bad ^{1}_{4}}\), can be reduced to GapCDH, as shown in Lemma 1. Case 1 can be reduced to GapDL as follows: Adversary on Gap DL challenge \(A = g^a\), sets simulated messages as: \(X_i = A \cdot g^{\varDelta _{i,x}}\) and \(Y_i = A \cdot g^{\varDelta _{i,y}}\), picking a fresh random \(\varDelta _{i,x}\) and \(\varDelta _{i,y}\) for each session \(( sid , \mathcal {P},\mathcal {P}')\). In the ith session (for every i), uses the \(\mathsf {DDH}\) oracle to check for . If true, further checks if \(Y'= N^{ pw ^*}\) or \(X'= M^{ pw ^*}\) for one of the passwords: in the former case this means that \(Y'= N^{ pw } = A \cdot g^{\varDelta _{i,y}}\), so \(n pw = a + \varDelta _{i,y}\), and can output the DL solution is \(a = n pw / \varDelta _{i,y}\), and the latter case is symmetric. We have that
(Use \(\mathcal {F}_{\mathsf {lePAKE}}\) interface) In the final game, we modify the challenger so that it uses the \(\mathsf {RegisterTest}\), \(\mathsf {TestPwd}\) and \(\mathsf {LateTestPwd}\) interfaces to check passwords, and the \(\mathsf {NewKey}\) interface to set keys. This is an internal change that is not noticeable to the environment, thus
In addition, this simulator perfectly mimics the ideal world except for the cases where it aborts, which we have already shown to happen with negligible probability, so:
Thus the distinguishing advantage of \(\mathcal {Z}\) between the real world and the ideal world is:
which is negligible if GapCDH is hard.
\(\square \)
Lemma 1
For every attacker \(\mathcal {A}\), there exists an attacker \(\mathcal {B}_{4.1}\) (whose running time is linear in the running time of \(\mathcal {A}\)) such that:
Proof
Consider an attacker \(\mathcal {B}_{4.1}\) against GCDH. It receives a challenge \((M=g^m,N=g^n)\) and wants to find \(\mathsf {CDH}(M,N)= g^{mn}\). The attacker emulates \(\mathbf {G4}\), except for setting the CRS values as M, N from the challenge instead of randomly. It uses the \(\mathsf {DDH}\) oracle to carry out the three checks in the if/else if/else if structure of the hash response, and for detecting the bad event.
In particular, it detects the bad event \({ bad ^{1}_{4}}\) when it sees two hash queries \(( sid ,X',Y', pw ,Z)\) and \(( sid ,X',Y', pw ',Z')\) such that \( pw \ne pw '\), and both of the following hold, where either x or y is known (i.e, chosen by the attacker as the exponent for a simulated message):
The attacker can then solve for the CDH response, \(g^{nm}\), as follows.
First, write \(Z = g^z;Z'=g^{z'}\) for unknown \(z,z' \in \mathbb {Z}_{ p }\). Considering only the exponents in Eqs. (1) and (2), we have that:
Assume that the attacker knows the exponent x (the other case is symmetric). Scaling Eqs. (3) and (4) by resp. \((x  pw ')\) and \((x  pw )\), gives:
Subtracting Eq. (6) from Eq. (5) allows us to remove the unknown y term:
Finally, we may solve for the desired CDH value:
This is possible as long as we are not dividing by zero, i.e., if \( pw \ne x\) and \( pw ' \ne x\), which is explicitly excluded in the definition of event \({ bad ^{1}_{4}}\) (see Case 1 of \(\mathbf {G4}\) for handling of this case). \(\square \)
Remark on Gap CDH. The proof relies on the gap version of CDH, and it seems hard to prove security from the standard CDH assumption, because the Decision DiffieHellman oracle is used by CDH reductions to maintain consistency of answers to RO queries, and it is not clear how to ensure this consistency otherwise. This is also the case in the all the other PAKE protocols we consider in Sect. 6.
4 Adding Explicit Authentication
We will show that any protocol that securely realizes the lazyextraction UC PAKE functionality \(\mathcal {F}_{\mathsf {lePAKE}}\), followed by a key confirmation round, is a secure realization of the relaxed UC PAKEEA functionality \(\mathcal {F}_{\mathsf {rPAKE}\text{ }\mathsf {EA}}\). (See Section 2 for the definition of these functionalities.) This protocol compiler construction is shown in Fig. 5.
Theorem 2
Protocol \(\varPi '\) shown in Fig. 5 realizes the Relaxed PAKEEA functionality \(\mathcal {F}_{\mathsf {rPAKE}\text{ }\mathsf {EA}}\) if \(\varPi \) realizes the LazyExtraction PAKE functionality \(\mathcal {F}_{\mathsf {lePAKE}}\) and \(\mathsf {PRF}\) is a secure PRF.
Figure 6 shows the simulator used in the proof of Theorem 2. (For notational simplicity, we denote the functionality \(\mathcal {F}_{\mathsf {rPAKE}\text{ }\mathsf {EA}}\) as simply \(\mathcal {F}\).) For the formal proof of this theorem we refer to the full version of this paper [2], but here we provide an informal overview.
The proof is essentially a casebycase argument, where all possible scenarios are divided into several cases, according to whether \(\mathcal {A}\) performs an online attack on party \(\mathcal {P}\)’s rPAKE session, and if so, whether it is an online attack or a postponed attack on \(\mathcal {P}\)’s lePAKE session.^{Footnote 9} Below we describe the cases, and how each case can be simulated:
Case 1 (online attack on lePAKE \(\rightarrow \) online attack on rPAKE): \(\mathcal {A}\) sends \((\mathsf {TestPwd}, sid ,\mathcal {P}, pw ^*)\) to \(\mathcal {F}_{\mathsf {lePAKE}}\) when \(\mathcal {P}\)’s lePAKE session is \(\mathsf {fresh}\).
In this case \(\mathsf {SIM}\) passes \((\mathsf {TestPwd}, sid ,\mathcal {P}, pw ^*)\) to \(\mathcal {F}\). If \(\mathcal {F}\) replies with “correct guess”, i.e., \( pw ^*= pw \), then \(\mathcal {P}\)’s rPAKE session is \(\mathsf {compromised}\), so \(\mathsf {SIM}\) can set its rPAKE output. Now on \((\mathsf {NewKey}, sid ,k^*)\) from \(\mathcal {A}\), \(\mathsf {SIM}\) can compute \((K,\tau ,\gamma )\) from \(k=k^*\) as the realworld session would, and send \(\tau \) to \(\mathcal {A}\); on a tag \(\tau ^*\) from \(\mathcal {A}\), \(\mathsf {SIM}\) lets \(\mathcal {P}\) output K if \(\tau ^*=\gamma \) and \(\bot \) otherwise, matching the realworld execution.
On the other hand, if \(\mathcal {F}\) replies with “wrong guess”, i.e., \( pw ^*\ne pw \), then \(\mathcal {P}\)’s rPAKE session is \(\mathsf {interrupted}\), hence \(\mathcal {P}\)’s rPAKE output is \(\bot \). \(\mathsf {SIM}\) simply computes \((K,\tau ,\gamma )\) from a random k and sends \(\tau \) to \(\mathcal {A}\). This again matches the realworld execution with overwhelming probability: \(\mathcal {P}\)’s rPAKE output is \(\bot \) unless \(\tau ^*=\gamma \), which happens with negligible probability, and \(\tau \) is computed in the exact same way.
Case 2 (postponed attack on lePAKE \(\rightarrow \) online attack on rPAKE): \(\mathcal {A}\) sends \((\mathsf {RegisterTest}, sid ,\mathcal {P})\) when \(\mathcal {P}\)’s lePAKE session is \(\mathsf {fresh}\), followed by \((\mathsf {NewKey}, sid ,\mathcal {P},k^*)\); and then sends \((\mathsf {LateTestPwd}, sid ,\mathcal {P}, pw ^*)\) to \(\mathcal {F}_{\mathsf {lePAKE}}\) (causing \(\mathcal {P}\)’s lePAKE session to complete) before sending a tag \(\tau ^*\) to \(\mathcal {P}\).
This is essentially the same as in Case 1, except that the order between the \(\mathsf {TestPwd}\) (or \(\mathsf {LateTestPwd}\)) queries and the \(\mathsf {NewKey}\) query to \(\mathcal {F}_{\mathsf {lePAKE}}\) is reversed. \(\mathsf {SIM}\) can reverse the order of these two queries on the rPAKE level too, by sending a \(\mathsf {RegisterTest}\) message to \(\mathcal {F}\) first.
Case 3 (postponed attack on lePAKE \(\rightarrow \) postponed attack on rPAKE): This is the complementary case of Case 2, i.e., \(\mathcal {A}\) sends \((\mathsf {RegisterTest}, sid ,\mathcal {P})\) when \(\mathcal {P}\)’s lePAKE session is \(\mathsf {fresh}\), followed by \((\mathsf {NewKey}, sid ,\mathcal {P},\star )\); and then a tag \(\tau ^*\) to \(\mathcal {P}\) before sending any \((\mathsf {LateTestPwd}, sid ,\mathcal {P}, pw ^*)\) message to \(\mathcal {F}_{\mathsf {lePAKE}}\). (Eventually \(\mathcal {A}\) may or may not send \(\mathsf {LateTestPwd}\).)
Again, in the real world \(\mathcal {P}\)’s rPAKE output is \(\bot \) unless \(\tau ^*=\gamma \), which happens with negligible probability, so \(\mathsf {SIM}\) can simply let \(\mathcal {P}\) output \(\bot \). However, if \( pw ^*= pw \), \(\mathcal {A}\) learns \(\mathcal {P}\)’s lePAKE output k (and thus can check if tag \(\tau \) is the “correct” one, i.e., \(\tau \) is derived from k using \(\mathsf {PRF}\)). This can be simulated as follows: on \(\mathsf {NewKey}\) from \(\mathcal {A}\), \(\mathsf {SIM}\) computes \((K,\tau ,\gamma )\) from a random k and sends \(\tau \) to \(\mathcal {A}\); on \(\tau ^*\) from \(\mathcal {A}\), \(\mathsf {SIM}\) sends \(\mathsf {RegisterTest}\) to \(\mathcal {F}\); on \((\mathsf {LateTestPwd}, sid ,\mathcal {P}, pw ^*)\) from \(\mathcal {A}\), \(\mathsf {SIM}\) passes this message to \(\mathcal {F}\), and if \(\mathcal {F}\) replies with “correct guess”, then \(\mathsf {SIM}\) sends k to \(\mathcal {A}\), making \(\tau \) the “correct” tag. (If \(\mathcal {F}\) replies with “wrong guess”, then \(\mathsf {SIM}\) sends a fresh random key to \(\mathcal {A}\).)
Case 4 (no attack on lePAKE): \(\mathcal {A}\) sends neither a \((\mathsf {TestPwd}, sid ,\mathcal {P},\star )\) nor a \((\mathsf {RegisterTest}, sid ,\mathcal {P})\) query to \(\mathcal {F}_{\mathsf {lePAKE}}\) when \(\mathcal {P}\)’s lePAKE session is \(\mathsf {fresh}\) (thus \(\mathcal {P}\)’s lePAKE session remains \(\mathsf {fresh}\) until it becomes \(\mathsf {completed}\)).
In this case, \(\mathcal {A}\) never learns \(\mathcal {P}\)’s lePAKE output k, so \(\mathsf {SIM}\) can send a random tag \(\tau \) to \(\mathcal {A}\). If \(\mathcal {A}\) merely passes the tags between \(\mathcal {P}\) and \(\mathcal {P}'\), then \(\mathsf {SIM}\) lets \(\mathcal {P}\) complete its rPAKE session by sending \((\mathsf {GetReady}, sid ,\mathcal {P})\) and then \((\mathsf {NewKey}, sid ,\mathcal {P},0^\kappa )\) to \(\mathcal {F}\); if \(\mathcal {P}\) and \(\mathcal {P}'\)’s passwords match, then \(\mathcal {P}\) outputs a random K, otherwise \(\mathcal {P}\) outputs \(\bot \). On the other hand, if \(\mathcal {A}\) modifies the tag from \(\mathcal {P}'\) to \(\mathcal {P}\), then it is not the “correct” tag of \(\mathcal {P}\), so \(\mathsf {SIM}\) lets \(\mathcal {P}\) output \(\bot \).
Compiler from PAKE to PAKE with entity authentication. If we replace the lazyextraction PAKE functionality with the (standard) PAKE, then the same compiler construction realizes the (standard) PAKE with explicit authentication functionality. In other words, by dropping the “laziness” of the underlying PAKE protocol, we get a compiler from PAKE to PAKE with explicit authentication. While technically not a corollary of Theorem 2, it is clear that the proof of Theorem 2 can be slightly modified to prove this conclusion: In that proof, the simulator \(\mathsf {SIM}\) sends a password test (i.e., send a \(\mathsf {LateTestPwd}\) message to \(\mathcal {F}_{\mathsf {rPAKE}\text{ }\mathsf {EA}}\)) only if \(\mathcal {A}\) does so (i.e., sends \(\mathsf {LateTestPwd}\) message aimed at \(\mathcal {F}_{\mathsf {lePAKE}}\) played by \(\mathsf {SIM}\)); therefore, if both \(\mathsf {SIM}\) and \(\mathcal {A}\) are not allowed to do a late password test, the simulation will still succeed.
While it is well known that PAKE plus “key confirmation” yields PAKE with explicit authentication, to the best of our knowledge, there has been no proof of this fact in the UC setting.
SPAKE2 with key confirmation. An immediate corollary of Theorems 2 and 1 is that SPAKE2 with key confirmation realizes the relaxed UC PAKEEA functionality \(\mathcal {F}_{\mathsf {rPAKE}\text{ }\mathsf {EA}}\) under the GapCDH assumption in the randomoracle model.
5 PAKE Relaxations and PFS
In this section we prove that any protocol that realizes the Relaxed PAKE functionality satisfies the standard gamebased notion of security for PAKE protocols offering perfect forward secrecy (PFS). This is an important sanity check for the definition, as it shows that the extra power given to the idealworld adversary by the late test feature does not weaken the security guarantee for PAKE sessions that are completed before passwords are corrupted. We show that a similar argument can be used to show that the weaker LazyExtraction PAKE definition implies a weak form of PFS, referred to as weak FS, where security in the presence of password leakage is only guaranteed with respect to passive attackers [27, 30].
5.1 Defining PFS
We recall the standard gamebased notion of security for PAKE protocols and which follows from a series of works [5, 6] that refined the security notion proposed by Bellare, Pointcheval and Rogaway in [8]. Section 3 and [1] include the full details.
The definition is based on an experiment in which a challenger emulates a scenario where a set of parties \(\mathcal {P}_1,\dots ,\mathcal {P}_n\), each running an arbitrary number of PAKE sessions, relies on a trusted setup procedure to establish preshared longterm (lowentropy) passwords for pairwise authentication. Passwords for each pair \((\mathcal {P}_i,\mathcal {P}_j)\) are sampled from a distribution over a dictionary \(\mathcal {D}\); we assume here the case where \(\mathcal {D}\) is any set of cardinality greater than one, and each password is sampled independently and uniformly at random from this set.^{Footnote 10} A ppt adversary \(\mathcal {A}\) is challenged to distinguish established session keys from truly random ones with an advantage that is better than password guessing.
The security experiment goes as follows. The challenger first samples passwords for all pairs of parties, generates any global public parameters (CRS) that the protocol may rely on and samples a secret bit b. The challenger manages a set of instances \(\pi _i^j\), each corresponding to the state of session instance j at party \(P_i\), according to the protocol definition. The adversary is then executed with the CRS as input; it may interact with the following set of oracles, to which it may place multiple adaptive queries:

Execute: Given a pair of party identities \((\mathcal {P}_i,\mathcal {P}_j)\) this oracle animates an honest execution of a new PAKE session established between the two parties and returns the communications trace to the attacker. This gives rise to two new session instances \(\pi _i^k\) and \(\pi _j^l\), which for correct protocols will have derived the same established session key.

Send: Given a party identity \(P_i\), an instance j and a message m, this oracle processes m according to the state of instance \(\pi _i^j\) (or creates this state if the instance was not yet initialized) and returns any outgoing messages to the attacker.

Corrupt: Given a pair of party identities \((\mathcal {P}_i,\mathcal {P}_j)\), this oracle returns the corresponding preshared password.

Reveal: Given a party identity \(\mathcal {P}_i\) and an instance j, this oracle checks \(\pi _i^j\) and, if this session instance has completed as defined by the protocol, the output of the session (usually either a secret key or an abort symbol) is returned to the attacker.

RoR: Given a party identity \(\mathcal {P}_i\) and an instance j, this oracle checks \(\pi _i^j\) and, if this session instance has completed as defined by the protocol and this session instance is fresh, the adversary is challenged on guessing bit b: if \(b=0\) then the derived key is given to the attacker; otherwise a new random key is returned.^{Footnote 11}
Eventually the adversary terminates and outputs a guess bit \(b'\). The definition of advantage excludes trivial attacks via the notion of session freshness used in the RoR oracle. Formal definitions are given in [1], here we give an informal description. Two session instances are partnered if their views match with respect to the identity of the peer, exchanged messages and derived secret keys—the first two are usually interpreted as a session identifier. A session is fresh if: a) the instance completed; b) the instance was not queried to Ror or Reveal before; c) at least one of the following four conditions holds: i. the instance accepted during a query to Execute; ii. there exists more than one partner instance; iii. no partner instance exists and the associated password was not corrupted prior to completion; iv. a unique fresh partner instance exists (implies not revealed).
A PAKE protocol is secure if, for any ppt attacker interacting with the above experiment and placing at most \(q_s\) queries to the Send oracle, we have that
where \(\epsilon \) is a negligible term.
The original definition proposed by Bellare, Pointcheval and Rogaway [8] allows for stronger corruption models—fixing the corrupt password maliciously and revealing the internal state of session instances—which we do not consider. We also do not deal with the asymmetry between client and server (also known as augmented PAKE).
Known results for UC PAKE. Canetti et al. [13] introduced the notion of UCsecure PAKE and proved that this definition implies gamebased security of the protocol as defined in [8]. Our proof that Relaxed PAKE implies gamebased PAKE with PFS follows along the same lines and relies on two auxiliary results from that original proof that we recover here; the first result concerns a generic mechanism for the handling of session identifiers called SIDenhancement and the second one is a general result for security against eavesdroppers.
Given a twoparty protocol \(\varPi \), its SIDenhancement \(\varPi '\) is defined as the protocol that has the parties exchange nonces and then uses the concatenation of these nonces as SID. This transformation converts any protocol \(\varPi \) that assumes SIDs provided by an external environment as the means to define matching sessions, into another one that generates the SID onthefly as required by the syntax of the gamebased security definition. Both the original proof and the one we give here show that the UC security of \(\varPi \) implies the gamebased security of \(\varPi '\). Intuitively, an environment simulating the PFSgame above can wait until the SID for the enhanced protocol is defined before calling NewSession to initiate the session of the parties in the UC setting.
For security against eavesdroppers, Canetti et al. show that no successful ideal world adversary can place \(\mathsf {TestPwd}\) queries on sessions for which the environment \(\mathcal {Z}\) instructed the adversary to pass messages between the players unmodified (i.e., to only eavesdrop on the session). We give here the intuition on why this is the case and refer the interested reader to [13] for a detailed proof.
The crucial observation is that, for eavesdropped sessions, the idealworld adversary generates all the trace and hence has no side information on the password; this means that for every environment \(\mathcal {Z}\) for which the idealworld attacker might place such a query, there exists an environment \(\mathcal {Z}'\) that can catch the simulator; \(\mathcal {Z}'\) operates as \(\mathcal {Z}\), but it uses a highentropy password for the problematic session: in the realworld a session the two honest parties will endup with matching keys with probability 1—one assumes perfect correctness here for simplicity—whereas an idealworld adversary placing a \(\mathsf {TestPwd}\) can never match the same behaviour. Indeed, querying a wrong password to \(\mathsf {TestPwd}\) leads to mismatching keys with overwhelming probability in the ideal world and the idealworld adversary cannot guess the password correctly except with small probability.
This argument extends trivially to LateTestPw queries, as these must be preceded by a RegisterTest query prior to session completion that also leads to mismatching keys with overwhelming probability. Furthermore, the above reasoning also applies when the idealworld adversary may have the extra power of simulating an ideal object, i.e., the UCsecure PAKE protocol is defined in an \(\mathcal {F}\)hybrid model. Indeed, whatever environment \(\mathcal {Z}\) may have leaked to the idealworld adversary via calls to \(\mathcal {F}\), there exists an environment \(\mathcal {Z}'\) that catches \(\mathcal {S}\) as above.
5.2 Relaxed PAKE Implies PFS
Theorem 3
Let \(\mathcal {F}\) be an ideal object such as a random oracle or an ideal cipher. If \(\varPi \) securely realizes \(\mathcal {F}_{\mathsf {rPAKE}}{}\) without explicit authentication, in the \((\mathcal {F}_\mathsf {CRS},\mathcal {F})\)hybrid model, then its SIDenhanced version \(\varPi '\) is PFSsecure according to the gamebased definition given above.
We refer to the full version of this paper [2] for the proof of the above theorem, but this proof is quite similar to the proof of the corresponding theorem given in [13], which showed that the original notion of UCsecure PAKE implies gamebased security (with PFS) of a PAKE protocol.
5.3 LazyExtraction PAKE Implies Weak FS
The proof of the above theorem can be adapted to show that any protocol that realizes the LazyExtraction UC PAKE functionality is secure under a weak form of gamebased security: the attacker is not allowed to corrupt the passwords of sessions against which it launches an active attack. This notion of gamebased security for PAKE is sometimes called weak FS.
Theorem 4
Let \(\mathcal {F}\) be an ideal object such as a random oracle or an ideal cipher. If \(\varPi \) securely realizes \(\mathcal {F}_{\mathsf {lePAKE}}{}\) without explicit authentication, in the \((\mathcal {F}_\mathsf {CRS},\mathcal {F})\)hybrid model, then its SIDenhanced version \(\varPi '\) is weak FSsecure.
5.4 Practical Implications
Putting together the results in Sect. 3 and Sect. 4 we obtain positive results for rPAKE secure protocols in the Universal Composability framework, namely SPAKE2, TBPEKE, CPace and SPEKE, followed by a round of key confirmation (although we did not give a detailed proof for the latter). The result in this section shows that all such protocols are also PFS secure in the gamebased setting. The caveat here is that this proof involves modifying the protocol to deal with session identifiers: The UC PAKE model requires a unique session identifier as an input of the protocol, while in practice agreeing on such identifier before the protocol starts can add extra communication rounds to the protocol. Nevertheless, a direct proof that SPAKE2 with key confirmation provides gamebased PFS with a tight reduction to Gap CDH in the randomoracle model can be found in [1].
6 Security of TBPEKE, SPEKE, and Their Variants
In this section, we prove that the TBPEKE protocol proposed by Pointcheval and Wang [33] also realizes the lazyextraction PAKE functionality under the same assumptions which were used to prove its gamebased security. Moreover, since TBPEKE is a representative example of a class of protocols which includes SPEKE [20, 22, 31] and CPace [18, 19], the same likely holds for these other protocols as well, or for their close variants. For example, it is straightforward to adapt our security proof for TBPEKE to show that lazyextraction UC PAKE functionality is realized under the same assumptions also by SPEKE [20, 22, 31].^{Footnote 12} Due to its recent selection by the CFRG, we will analyze the specific case of CPace in the full version [2]. (See Footnote 6)
We now recall the twoflow, simultaneous round TBPEKE protocol [33] in Fig. 7, with some notational choices adjusted to the UC setting.
For the security proof of TBPEKE we require the following computational assumptions [33].
SDH and Gap SDH assumptions. The Simultaneous DiffieHellman (SDH) assumption states that, given three random elements X, \(g=X^a\), and \(h=X^b\) in a cyclic group of prime order, it is hard to find \(Y\ne 1\) and R, S that simultaneously satisfy \(R=\mathsf {CDH}_g(X,Y)=Y^{1/a}\) and \(S=\mathsf {CDH}_h(X,Y)= Y^{1/b}\). In the gap version, the problem must remain hard even if the adversary has access to a Decisional DiffieHellman oracle.
Theorem 5
\(\mathsf {TBPEKE}\) realizes the LazyExtraction PAKE functionality \(\mathcal {F}_{\mathsf {lePAKE}}\) in the randomoracle model under the GapCDH and Gap Simultaneous DiffieHellman (GapSDH) assumptions.
For the formal proof of Theorem 5, we refer to the full version of this paper [2]. Here, we only present an informal overview of this proof and the simulator used in the proof, shown in Fig. 8.
The proof that TBPEKE is lazyextraction UC PAKE secure is structurally similar to that of SPAKE2. In particular, the simulator adopts the same highlevel strategy for dealing with passive and active attacks, while simulating the random oracle that is used for key derivation by taking advantage of knowing the CRS. The random oracle \(\mathsf {P}\) is trivially simulated, excluding collisions to avoid ambiguity between passwords. The sequence of games that justifies the simulation also follows the same pattern.
The only significant difference between the proofs for TBPEKE and SPAKE2 lies in the step where one must exclude the possibility that the adversary places two randomoracle queries for two different passwords that are consistent with the same protocol trace, which would prevent the simulator from maintaining consistency. In TBPEKE, this bad event corresponds to the case in which the adversary queries the hash oracle \(\mathsf {H}\) on inputs (\(g_{ pw _1}\), X, Y, \(W_1\)) and (\(g_{ pw _2}\), X, Y, \(W_2\)) such that at least one of the values X and Y is simulated and \((X, Y, W_i)\) is a valid DDH tuple with respect to the generator \(g_{ pw _i}\) for \(i={1,2}\). In the SPAKE2 proof, the corresponding event can be reduced to Gap CDH. For TBPEKE, the reduction to Gap CDH does not work and the stronger Gap SDH assumption (given above) is needed.
The strategy for embedding a Gap SDH instance in the reduction is the same as that adopted in [33]. More precisely, the reduction guesses the two queries to the oracle \(\mathsf {P}\) that correspond to the passwords that are involved in the bad event and programs the random oracle output for these passwords with two random values \(p_1\) and \(p_2\) from \(\mathbb {Z}_{ p }\). Then, given a Gap SDH challenge \((A, G_1,G_2)\), it sets \(V \leftarrow {(G_1/G_2)}^{1/(p_1p_2)}\) and \(U \leftarrow G_1 / V^{p_1}\) so that we have \(U \cdot V^{p_i} = G_i\) for \(i={1,2}\). Next, it embeds the value of A in the client and server messages X and Y (randomizing them appropriately) whenever it needs to simulate these values. Finally, if the bad event happens and the guesses for \( pw _1\) and \( pw _2\) are correct, then we know that \((X, Y, W_i)\) is a valid DDH tuple with respect to the generator \(G_i\) for \(i={1,2}\). If \(X = A^{\alpha }\) is the simulated value (the case in which Y is simulated is similar) and \(\alpha \) is the randomization factor, then it follows that \((Y, W_1^{1/{\alpha }},W_2^{1/{\alpha }})\) is a valid solution to the GapSDH problem.
Notes
 1.
 2.
In [18] this is explicitly claimed not for CPace itself but for its asymmetric (aPAKE) version called AuCPace.
 3.
Note that here the attacker is not explicitly notified whether its password guess is correct. While it is arguably more natural to notify the attacker, we obtain a slightly stronger functionality by omitting this notification. .
 4.
Although Canetti et al. [13] informally suggest a way of modeling explicit authentication in PAKE, the functionality they propose seems unacceptably weak in the sense that it does not require a party to abort even when an attacker successfully interferes with its partner’s session.
 5.
While relaxing the GroceKatz functionality, we also make some minor changes to their original: (1) we make the parties symmetric, and do not require the server to generate a session key first, and (2) we allow the adversary to force a party to abort by sending a \((\mathsf {NewKey}, sid ,\mathcal {P},\bot )\) message. (This second modification is required, and its omission appears to be an oversight of Groce and Katz.).
 6.
In CPace [18], the key derivation hash includes only the session ID and the DiffieHellman key, while our proof of TBPEKE security assumes that it also includes party IDs, the passworddependent base, and the transcript. The final version of CPace selected by the CFRG has been updated to include all these elements except the password. In the full version [2], we will analyze the security of this version of CPace.
 7.
 8.
The generalized CDH problem is tightly equivalent to the CDH problem by random selfreducibility.
 9.
Note that each rPAKE session runs a lePAKE session as a subprotocol, and these two sessions should not be confused. Similarly, each party has a lePAKE output (which is always a string) and an rPAKE output (which is either a string derived from its lePAKE output or \(\bot \)).
 10.
This assumption is standard for the corruption model captured by this gamebased definition. If correlated passwords were allowed, then corrupting one password might reveal information that allows the attacker to trivially infer another one; preventing trivial attacks in this setting leads to a definition in the style of [8], where the corruption of a password must invalidate RoR queries associated with all correlated passwords; this means the whole dictionary if no restrictions are imposed on the distribution. The finergrained definition of password corruption we adopt here does not easily extend to the case of arbitrary correlations between passwords. See [1] for a discussion. The UC definition covers arbitrary password sampling distributions and the results we prove in this section should extend to any reasonable gamebased definition that deals with more complex password distributions. This is clearly the case for the concrete distributions discussed in [1] .
 11.
We use RoR (RealorRandom) for this oracle rather than the standard Test oracle designation to avoid confusion with the test and late test requests that are included in the UC PAKE ideal functionality definitions.
 12.
For instance, in the case of SPEKE (in which \(g=G( pw )\)), one can adapt the proof for TBPEKE by simulating the random oracle G as \(U \cdot V^{\mathsf {P}( pw )}\).
References
Abdalla, M., Barbosa, M.: Perfect forward security of SPAKE2. Cryptology ePrint Archive, Report 2019/1194 (2019). https://eprint.iacr.org/2019/1194
Abdalla, M., Barbosa, M., Bradley, T., Jarecki, S., Katz, J., Xu, J.: Universally composable relaxed password authenticated key exchange. IACR Cryptology ePrint Archive (2020). https://eprint.iacr.org/2020/320
Abdalla, M., Bellare, M., Rogaway, P.: The oracle DiffieHellman assumptions and an analysis of DHIES. In: Naccache, D. (ed.) CTRSA 2001. LNCS, vol. 2020, pp. 143–158. Springer, Heidelberg (2001). https://doi.org/10.1007/3540453539_12
Abdalla, M., Catalano, D., Chevalier, C., Pointcheval, D.: Efficient twoparty passwordbased key exchange protocols in the UC framework. In: Malkin, T. (ed.) CTRSA 2008. LNCS, vol. 4964, pp. 335–351. Springer, Heidelberg (2008). https://doi.org/10.1007/9783540792635_22
Abdalla, M., Fouque, P.A., Pointcheval, D.: Passwordbased authenticated key exchange in the threeparty setting. In: Vaudenay, S. (ed.) PKC 2005. LNCS, vol. 3386, pp. 65–84. Springer, Heidelberg (2005). https://doi.org/10.1007/9783540305804_6
Abdalla, M., Fouque, P.A., Pointcheval, D.: Passwordbased authenticated key exchange in the threeparty setting. IEE Proc. Inf. Secur. 153(1), 27–39 (2006)
Abdalla, M., Pointcheval, D.: Simple passwordbased encrypted key exchange protocols. In: Menezes, A. (ed.) CTRSA 2005. LNCS, vol. 3376, pp. 191–208. Springer, Heidelberg (2005). https://doi.org/10.1007/9783540305743_14
Bellare, M., Pointcheval, D., Rogaway, P.: Authenticated key exchange secure against dictionary attacks. In: Preneel, B. (ed.) EUROCRYPT 2000. LNCS, vol. 1807, pp. 139–155. Springer, Heidelberg (2000). https://doi.org/10.1007/3540455396_11
Bellovin, S.M., Merritt, M.: Encrypted key exchange: passwordbased protocols secure against dictionary attacks. In: IEEE Symposium on Security and Privacy  S&P 1992, pp. 72–84. IEEE (1992)
Boyko, V., MacKenzie, P., Patel, S.: Provably secure passwordauthenticated key exchange using DiffieHellman. In: Preneel, B. (ed.) EUROCRYPT 2000. LNCS, vol. 1807, pp. 156–171. Springer, Heidelberg (2000). https://doi.org/10.1007/3540455396_12
Bradley, T., Camenisch, J., Jarecki, S., Lehmann, A., Neven, G., Xu, J.: Passwordauthenticated publickey encryption. In: Deng, R.H., GauthierUmaña, V., Ochoa, M., Yung, M. (eds.) ACNS 2019. LNCS, vol. 11464, pp. 442–462. Springer, Cham (2019). https://doi.org/10.1007/9783030215682_22
Canetti, R.: Universally composable security: a new paradigm for cryptographic protocols. In: 42nd FOCS, pp. 136–145. IEEE Computer Society Press (2001)
Canetti, R., Halevi, S., Katz, J., Lindell, Y., MacKenzie, P.: Universally Composable passwordbased key exchange. In: Cramer, R. (ed.) EUROCRYPT 2005. LNCS, vol. 3494, pp. 404–421. Springer, Heidelberg (2005). https://doi.org/10.1007/11426639_24
Gennaro, R.: Faster and shorter passwordauthenticated key exchange. In: Canetti, R. (ed.) TCC 2008. LNCS, vol. 4948, pp. 589–606. Springer, Heidelberg (2008). https://doi.org/10.1007/9783540785248_32
Gentry, C., MacKenzie, P., Ramzan, Z.: A method for making passwordbased key exchange resilient to server compromise. In: Dwork, C. (ed.) CRYPTO 2006. LNCS, vol. 4117, pp. 142–159. Springer, Heidelberg (2006). https://doi.org/10.1007/11818175_9
Goldreich, O., Lindell, Y.: Sessionkey generation using human passwords only. J. Cryptol. 19(3), 241–340 (2006)
Groce, A., Katz, J.: A new framework for efficient passwordbased authenticated key exchange. In: AlShaer, E., Keromytis, A.D., Shmatikov, V. (eds.) ACM CCS 2010, pp. 516–525. ACM Press (2010)
Haase, B., Labrique, B.: AuCPace: efficient verifierbased PAKE protocol tailored for the IIoT. Cryptology ePrint Archive, Report 2018/286 (2018). https://eprint.iacr.org/2018/286
Haase, B., Labrique, B.: AuCPace: efficient verifierbased PAKE protocol tailored for the IIoT. IACR TCHES 2019(2), 1–48 (2019). https://tches.iacr.org/index.php/TCHES/article/view/7384
Hao, F., Shahandashti, S.F.: The SPEKE protocol revisited. Cryptology ePrint Archive, Report 2014/585 (2014). http://eprint.iacr.org/2014/585
Hwang, J.Y., Jarecki, S., Kwon, T., Lee, J., Shin, J.S., Xu, J.: Roundreduced modular construction of asymmetric passwordauthenticated key exchange. In: Catalano, D., De Prisco, R. (eds.) SCN 2018. LNCS, vol. 11035, pp. 485–504. Springer, Cham (2018). https://doi.org/10.1007/9783319981130_26
Jablon, D.P.: Extended password key exchange protocols immune to dictionary attacks. In: 6th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE 1997), 18–20 June 1997, pp. 248–255. IEEE Computer Society, Cambridge (2007)
Jarecki, S., Krawczyk, H., Xu, J.: OPAQUE: An asymmetric PAKE protocol secure against precomputation attacks. In: Nielsen, J.B., Rijmen, V. (eds.) EUROCRYPT 2018. LNCS, vol. 10822, pp. 456–486. Springer, Cham (2018). https://doi.org/10.1007/9783319783727_15
Jarecki, S., Krawczyk, H., Xu, J.: OPAQUE: an asymmetric PAKE protocol secure against precomputation attacks. Cryptology ePrint Archive, Report 2018/163 (2018). https://eprint.iacr.org/2018/163
Jutla, C.S., Roy, A.: Dualsystem simulationsoundness with applications to UCPAKE and more. In: Iwata, T., Cheon, J.H. (eds.) ASIACRYPT 2015. LNCS, vol. 9452, pp. 630–655. Springer, Heidelberg (2015). https://doi.org/10.1007/9783662487976_26
Katz, J., Ostrovsky, R., Yung, M.: Efficient passwordauthenticated key exchange using humanmemorable passwords. In: Pfitzmann, B. (ed.) EUROCRYPT 2001. LNCS, vol. 2045, pp. 475–494. Springer, Heidelberg (2001). https://doi.org/10.1007/3540449876_29
Katz, J., Ostrovsky, R., Yung, M.: Forward secrecy in passwordonly key exchange protocols. In: Cimato, S., Persiano, G., Galdi, C. (eds.) SCN 2002. LNCS, vol. 2576, pp. 29–44. Springer, Heidelberg (2003). https://doi.org/10.1007/3540364137_3
Katz, J., Vaikuntanathan, V.: Roundoptimal passwordbased authenticated key exchange. In: Ishai, Y. (ed.) TCC 2011. LNCS, vol. 6597, pp. 293–310. Springer, Heidelberg (2011). https://doi.org/10.1007/9783642195716_18
Krawczyk, H.: The OPAQUE asymmetric PAKE protocol (2019). https://www.ietf.org/id/draftkrawczykcfrgopaque03.txt
Krawczyk, H.: HMQV: a highperformance secure DiffieHellman protocol. In: Shoup, V. (ed.) CRYPTO 2005. LNCS, vol. 3621, pp. 546–566. Springer, Heidelberg (2005). https://doi.org/10.1007/11535218_33
MacKenzie, P.: On the security of the SPEKE passwordauthenticated key exchange protocol. Cryptology ePrint Archive, Report 2001/057 (2001). http://eprint.iacr.org/2001/057
Pedersen, T.P.: Noninteractive and informationtheoretic secure verifiable secret sharing. In: Feigenbaum, J. (ed.) CRYPTO 1991. LNCS, vol. 576, pp. 129–140. Springer, Heidelberg (1992). https://doi.org/10.1007/3540467661_9
Pointcheval, D., Wang, G.: VTBPEKE: verifierbased twobasis password exponential key exchange. In: Karri, R., Sinanoglu, O., Sadeghi, A.R., Yi, X. (eds.) ASIACCS 17, pp. 301–312. ACM Press (2017)
Shoup, V.: Security analysis of spake2+. Cryptology ePrint Archive, Report 2020/313 (2020). https://eprint.iacr.org/2020/313
Acknowledgments
Michel Abdalla was supported in part by the ERC Project aSCEND (H2020 639554) and by the French ANR ALAMBIC Project (ANR16CE390006). Work of Manuel Barbosa was supported in part by the grant SFRH/BSAB/143018/2018 awarded by FCT, Portugal, and by the ERC Project aSCEND (H2020 639554). Stanisław Jarecki and Tatiana Bradley were supported by NSF SaTC award #1817143. Work of Jonathan Katz and Jiayu Xu was supported in part under financial assistance award 70NANB15H328 from the U.S. Department of Commerce, National Institute of Standards and Technology.
Author information
Authors and Affiliations
Corresponding authors
Editor information
Editors and Affiliations
Rights and permissions
Copyright information
© 2020 International Association for Cryptologic Research
About this paper
Cite this paper
Abdalla, M., Barbosa, M., Bradley, T., Jarecki, S., Katz, J., Xu, J. (2020). Universally Composable Relaxed Password Authenticated Key Exchange. In: Micciancio, D., Ristenpart, T. (eds) Advances in Cryptology – CRYPTO 2020. CRYPTO 2020. Lecture Notes in Computer Science(), vol 12170. Springer, Cham. https://doi.org/10.1007/9783030567842_10
Download citation
DOI: https://doi.org/10.1007/9783030567842_10
Published:
Publisher Name: Springer, Cham
Print ISBN: 9783030567835
Online ISBN: 9783030567842
eBook Packages: Computer ScienceComputer Science (R0)