# Bibliography on augmented PAKE

###### tags: `bibliography`

# Papers

## [Asymmetric PAKE with Low Computation and communication (EUROCRYPT 2022)](https://link.springer.com/content/pdf/10.1007/978-3-031-07085-3_5.pdf?pdf=inline%20link)
* Bruno Freitas Dos Santos, Yanqi Gu, Stanislaw Jarecki & Hugo Krawczyk
* Proposed two compilers: OKAPE and aEKE
* "Note that every aPAKE can be generically transformed to support a publicly salted hash if the server first sends the salt to the client and the two parties run aPAKE on the password appended by the salt." (Actually don't have to send the salt)
* Both require an ideal cipher
* Introduced a role in Gentry et al.'s model

## [KHAPE: asymmetric PAKE from key-hiding key exchange (CRYPTO 2021)](https://ia.cr/2021/873)
* Yanqi Gu, Stanislaw Jarecki & Hugo Krawczyk
* Based on an ideal cipher
* It doesn't provide pre-computation security, but the authors say such security can be added by using the compiler in OPAQUE.

## [Separating Symmetric and Asymmetric Password-Authenticated Key Exchange (SCN 2020)](https://link.springer.com/content/pdf/10.1007/978-3-030-57990-6_29.pdf?pdf=inline%20link)
* Julia Hesse
* "Not surprisingly, the original publication of the Ω- method did not include a proof but only a claim of security, which is invalidated with our findings of their functionality being impossible to realize"
* Analyzes issues of Gentry et al's model and discusses fixes.
* The paper is very theoretical. Hard to read.

## [Strong asymmetric PAKE based on trapdoor CKEM (CRYPTO 2019)](https://eprint.iacr.org/2019/647.pdf)
* Tatiana Bradley, Stanislaw Jarecki, and Jiayu Xu
* "The conference paper of OPAQUE [24] reported it as 2 message flows but the full version [25] explain why 3 flows seem necessary." (worth noting)
* "Unlike OPAQUE, it does not require hashing onto a curve, which simplifes its implementation over some some curves"
* Based on DDH, strong DH and any assumptions necessary for the (hashed) Boneh-Boyen function to realize a saulted tight one-way function.
* Defer the formal proofs to a full version (which refers back to the same IACR version)
* Based on CRS. Requires **a trusted setup**
* Mentioned motivation to avoid hash-to-curve in OPAQUE

## [Round-Reduced Modular Construction of Asymmetric Password-Authenticated Key Exchange (SCN 2018)](https://link.springer.com/content/pdf/10.1007/978-3-319-98113-0_26.pdf?pdf=inline%20link)
* Jung Yeon Hwang, Stanislaw Jarecki, Taekyoung Kwon, Joohee Lee, Ji Sun Shin & Jiayu Xu
* It says Gentry et al's method requires "two additional communication rounds" (Is that right? should be 1 or 2 rounds)
* Propose an alternative method that only requires one round (should be 0 or 1 round)
* "The UC definition of PAKE has become a de facto standard in the cryptographic literature on PAKEs because it is widely recognized as capturing several security issues pertinent to PAKEs which the gamebased PAKE notions of [4,9] do not cover"
* "Specifically, apart of standard UC guarantee of security under arbitrary protocol composition, UC PAKE implies forward-security, i.e. security of past protocol sessions in case of password compromise, and security for arbitrary password distribution, which implies security for password mistyping and for related passwords."
* "OPAQUE relies on the somewhat non-standard and interactive assumption of one-more Diffie-Hellman"
* It explains that Gentry et al's symmetric PAKE model modifies Canetti et al's by exposting some bitstring as the transcript to the enviroenment.
* Proposed two compilers: based on 1) Diffie-Hellman 2) digital signature
* First compiler - based on Diffie-Hellman
* The server stores $H_1(\pi), g^{H_0(\pi)}$;
* The server sends $g^y$
* The client sends $t = H_2(g^{y H_0(\pi)} || K_1 || g^y || transcript)$, where $K_1$ is the raw key from symmetric PAKE.
* Cost: client 1 exp, server 2 exp (actually it should be client 2 exp, since the public key validation should be counted)
* Second compiler: based on a digital signature (using Schnorr NIZK)
* The server stores $H_1(\pi)$, $g^{H_0(\pi)}$
* After symmetric PAKE, client sends $(g^x, z=x+v H_2(K||X||tr)$, similar to Schnorr's signature.
* Cost: 1 exp for the client and 1 exp for the server.
* "ECDSA signature is indeed a version of the same NIZK-PK of discrete logarithm as we use here."
* It says the proofs are in a full paper, but I can't find the full paper.
* It defines $\pi$ to be the password. But then an attacker only needs to build one pre-computed table to break $g^{H_0(\pi)}$.

## [Security of the J-PAKE Password-Authenticated Key Exchange Protocol (IEEE S&P 2015)](https://www.normalesup.org/~fbenhamo/files/publications/SP_AbdBenMac15.pdf)
* Michel Abdalla; Fabrice Benhamouda; Philip MacKenzie
* Present a proof of security for the J-PAKE protocol in the Bellare, Pointcheval, and Rogaway model under the Decision Square Diffie-Hellman (DSDH) assumption.
* "We note that we could reduce this assumption to DDH and Computational Square Diffie-Hellman (CSDH) by using the random-oracle model"

## [Dual-system simulation-soundness with applications to UCPAKE and more (ASIACRYPT 2015)](https://eprint.iacr.org/2014/805.pdf)
* Charanjit S. Jutla and Arnab Roy

## [Relatively-sound NIZKs and password-based key-exchange (PKC 2012)](https://link.springer.com/content/pdf/10.1007/978-3-642-30057-8_29.pdf?pdf=inline%20link)
* Charanjit Jutla & Arnab Roy
* Based on CRS

## [Efficient two-party password-based key exchange protocols in the UC framework, CT-RSA 2008](https://link.springer.com/content/pdf/10.1007/978-3-540-79263-5_22.pdf?pdf=inline%20link)
* Michel Abdalla, Dario Catalano, Céline Chevalier & David Pointcheval
* "Canetti et al. proposed a new security model in the universal composability (UC) framework which makes no assumption on the distribution on passwords used by the protocol participants." (we should discuss the distribution of passwords)

## [A Method for Making Password-Based Key Exchange Resilient to Server Compromise (Crypto 2006)](https://iacr.org/archive/crypto2006/41170140/41170140.pdf)
* Craig Gentry, Philip MacKenzie & Zulfikar Ramzan
* Sever stores: H(pw), a signature public key and the corresponding private signing key encrypted by pw
* Main idea: Use H(pw) to do a balanced PAKE session; server uses the session key to send the password-encrypted private signing key; client obtains the private signing key and signs the transcript.

## [One-time verifier-based encrypted key exchange (PKC 2005)](https://www.di.ens.fr/~mabdalla/papers/ACP05-letter.pdf)
* Michel Abdalla, Olivier Chevassut & David Pointcheval

## [Universally composable security: a new paradigm for cryptographic protocols (FOCS 2001)](https://eprint.iacr.org/2000/067.pdf)
* Ren Canetti

## Separating Symmetric and Asymmetric Password-Authenticated Key Exchange
* Dos Santos et al.

## [Asymmetric PAKE with Low Computation and communication](https://eprint.iacr.org/2013/833)