Asymmetric PAKE with Low Computation and communication

Abstract

In Crypto’21 Gu, Jarecki, and Krawczyk [25] showed an asymmetric password authenticated key exchange protocol (aPAKE) whose computational cost matches (symmetric) password authenticated key exchange (PAKE) and plain (i.e. unauthenticated) key exchange (KE). However, this minimal-cost aPAKE did not match prior aPAKE’s in round complexity, using 4 rounds assuming the client initiates compared to 2 rounds in an aPAKE of Bradley et al. [13].

In this paper we show two aPAKE protocols (but not strong aPAKEs like [13, 30]), which achieve optimal computational cost and optimal round complexity. Our protocols can be seen as variants of the Encrypted Key Exchange (EKE) compiler of Bellovin and Merritt [7], which creates password-authenticated key exchange by password-encrypting messages in a key exchange protocol. Whereas Bellovin and Merritt used this method to construct a PAKE by applying password-encryption to KE messages, we construct an aPAKE by password-encrypting messages of a unilaterally authenticated Key Exchange (ua-KE). We present two versions of this compiler. The first uses salted password hash and takes 2 rounds if the server initiates. The second uses unsalted password hash and takes a single simultaneous flow, thus simultaneously matching the minimal computational cost and the minimal round complexity of PAKE and KE.

We analyze our aPAKE protocols assuming an Ideal Cipher (IC) on a group, and we analyze them as modular constructions from ua-KE realized via a universally composable Authenticated Key Exchange where the server uses one-time keys (otk-AKE). We also show that one-pass variants of 3DH and HMQV securely realize otk-AKE in the ROM. Interestingly, the two resulting concrete aPAKE’s use the exact same protocol messages as variants of EKE, and the only difference between the symmetric PAKE (EKE) and asymmetric PAKE (our protocols) is in the key derivation equation.

Appendices

A Universally Composable Asymmetric PAKE Model

Fig. 9.

adapted from [25]

$\mathcal {F}_{\mathsf {aPAKE}}$: asymmetric PAKE functionality

Fig. 10.

$\mathcal {F}_{\mathsf {aPAKE}\text {-}\mathsf {cEA}}$: asymmetric PAKE with explicit $\mathsf {C}$-to-$\mathsf {S}$ authentication

We include for reference the UC aPAKE definition in the form of a functionality $\mathcal {F}_{\mathsf {aPAKE}}$, shown in Fig. 9. This functionality is largely as it was originally defined by Gentry, Mackenzie, and Ramzan [24], but it adopts few notational modifications introduced by Gu et al. [25]. These include naming what amounts to user accounts explicitly as $\mathsf {uid}$ instead of generic-sounding $\mathsf {sid}$, using $\mathsf {sid}$ instead of $\mathsf {ssid}$ as a session-identifier for on-line authentication attempts, and using only pairs $(\mathsf {S},\mathsf {uid})$ to identify server password files and not $(\mathsf {S},\mathsf {U},\mathsf {uid})$ tuples as in [24].

Because in this paper we differentiate between unsalted and (publicly) salted aPAKE’s, an explicit support for unsalted aPAKE’s is reflected in aPAKE functionality $\mathcal {F}_{\mathsf {aPAKE}}$ by introducing a slight modification in the functionality of [25]. These modifications are highlighted in Fig. 9, and they all concern a client-side usage of the user account field $\mathsf {uid}$. As we mention in the introduction, the round-minimal protocol $\mathsf {aEKE}$ is unsalted, and to enforce the aPAKE contract defined by [24], which is that a single real-world offline dictionary attack operation must correspond not only to a single password guess but also to a unique user password file, identified by a unique pair $(\mathsf {S},\mathsf {uid})$, the client must get as environment’s inputs both the server identifier $\mathsf {S}$ and the user account identifier $\mathsf {uid}$. This is reflected in including $\mathsf {uid}$ in the inputs to $\mathsf {CltSession}$ command in Fig. 9. However, since the client now performs computation on a fixed $\mathsf {uid}$, honest client and server sessions will not agree on the same output key unless they run not only on the same password $pw$ but also on the same $\mathsf {uid}$. Hence the $\mathsf {NewKey}$ processing now includes $\mathsf {uid}$-equality enforcement. Finally, for the same reason, an online password test $\mathsf {TestPwd}$ must specify the $\mathsf {uid}$ field in addition to password guess $pw ^*$.

Functionality $\mathcal {F}_{\mathsf {aPAKE}}$ currently allows both the server and the client sessions to leak the account identifier $\mathsf {uid}$ input to the adversary. The server-side leakage of this information was inherent (although not immediate to observe) in the original aPAKE functionality of [24], and it was adopted by subsequent works, including e.g. [25, 30]. Now, however, we also introduce client-side leakage of the same information. The $\mathsf {uid}$ has to be transmitted from the client to the server before the protocol starts, but it is not clear that the cryptographic protocol should leak it. We leave plugging this leakage and/or verifying whether it is necessary in known aPAKEs, including ours, to future work.

Client-to-Server Entity Authentication. Since our protocol $\mathsf {OKAPE}$ shown includes client-to-server authentication (it is not optional, and the protocol is insecure without it), it realizes an aPAKE functionality amended by client-to-server entity authentication. We use $\mathcal {F}_{\mathsf {aPAKE}\text {-}\mathsf {cEA}}$ to denote the variant of aPAKE functionality with uni-directional client-to-server entity authentication, and we include it in Fig. 10. Since protocol $\mathsf {OKAPE}$ is a salted aPAKE, it does not need the $\mathsf {uid}$ input on the client side, so the $\mathcal {F}_{\mathsf {aPAKE}\text {-}\mathsf {cEA}}$ functionality in Fig. 10 incorporates all the code of functionality $\mathcal {F}_{\mathsf {aPAKE}}$ but without the $\mathsf {uid}$-related modifications. To simplify $\mathsf {NewKey}$ processing functionality $\mathcal {F}_{\mathsf {aPAKE}\text {-}\mathsf {cEA}}$ in Fig. 10 assumes that the client party terminates first, so if two honest parties are connected then the client party computes its session key output first, and it is always the server party which can potentially get the same key copied by the functionality. One could define it more generally but we expect that in most aPAKE protocols with unilateral client-to-server explicit authentication the server will indeed be the last party to terminate.

B Simulator for Proof of Theorem 3

Because of space constraints, we refer the reader to [23] for a complete proof of Theorem 3, and provide here an abridged version containing only the overall proof strategy and the description of the simulator.

To prove the theorem we need to construct a simulator, denoted $\mathsf {SIM}$, such that the environment’s view of the real-world security game, i.e. an interaction between the adversary $\mathcal {A}$ (whom we consider as a subprocedure of the environment $\mathcal {Z}$) and honest parties following protocol $\mathsf {OKAPE}$, is indistinguishable from the environment’s view in the ideal-world interaction between $\mathcal {A}$, $\mathsf {SIM}$, and the functionality $\mathcal {F}_{\mathsf {aPAKE}\text {-}\mathsf {cEA}}$.

Fig. 11.

Real-world (left) vs. simulation (right) for protocol $\mathsf {OKAPE}$

Simulator Construction. We show an overview of our simulation strategy in Fig 11, which gives the top-level view of the real world execution compared to the ideal world execution which involves the simulator $\mathsf {SIM}$ shown in Figs. 12 and 13 as well as the simulator $\mathsf {SIM}_{\mathsf {AKE}}$ for the $\mathsf {otkAKE}$ subprotocol. The description of simulator $\mathsf {SIM}$ is split into two parts as follows: Fig. 12 contains the $\mathsf {SIM} \text{ pt.1 }$ part of the diagram in Fig 11, i.e. it deals with adversary’s ideal cipher and hash queries, and in addition with the compromise of password files. Figure 13 contains the $\mathsf {SIM} \text{ pt.2 }$ part of the diagram in Fig 11 dealing with on-line aPAKE sessions. We rely on the fact that protocol $\mathsf {otkAKE}$ realizes functionality $\mathcal {F}_{\mathsf {otkAKE}}$, so we can assume that there exists a simulator $\mathsf {SIM}_{\mathsf {AKE}}$ which exhibits this UC-security of $\mathsf {otkAKE}$. Our simulator $\mathsf {SIM}$ uses simulator $\mathsf {SIM}_{\mathsf {AKE}}$ as a sub-procedure. Namely, $\mathsf {SIM}$ hands over to $\mathsf {SIM}_{\mathsf {AKE}}$ the simulation of all $\mathsf {C}$-side and $\mathsf {S}$-side AKE instances where parties run on either honestly generated or adversarial AKE keys. $\mathsf {SIM}$ employs $\mathsf {SIM}_{\mathsf {AKE}}$ to generate such keys - in $\mathsf {H}$ queries, password file compromise and in $\mathsf {IC}$ decryption queries - see Fig. 12, and then it hands off to $\mathsf {SIM}_{\mathsf {AKE}}$ the handling of all AKE instances that run on such keys, see Fig. 13.

Fig. 12.

Simulator $\mathsf {SIM}$ showing that protocol $\mathsf {OKAPE}$ $\mathcal {F}_{\mathsf {aPAKE}\text {-}\mathsf {cEA}}$: part 1

Fig. 13.

Simulator $\mathsf {SIM}$ showing that protocol $\mathsf {OKAPE}$ realizes $\mathcal {F}_{\mathsf {aPAKE}\text {-}\mathsf {cEA}}$: part 2