[Cfrg] Reviews for augmented PAKEs (BSPAKE, AuCPace, OPAQUE, VTBPEKE)

[Kevin Lewi <[e-mail]>]

I'm providing this review from the perspective of using these
augmented PAKE schemes in place of the existing account login protocol
for Facebook, in which a client sends a plaintext password over a
secure channel to a server. More details here:
https://mailarchive.ietf.org/arch/msg/cfrg/1QQ_FfRsOxvoLGqX0t48WLTMSNU
. The points I cover in this review are more focused on the practical
implications of integrating an aPAKE into account registration/login,
and so I will defer to other experts to analyze the validity of the
security proofs and cryptographic assumptions underlying these
proposals.

---

First, I've outlined some of the high-level concerns which I found to
be common across multiple candidate aPAKEs:

(1) Unspecified / unsafe registration step

In a password-based login protocol, there is a registration step
(where the client registers a username and password pair for account
creation) and an account login step. It is problematic when aPAKEs
assume that the server begins the protocol with some information
derived from the password. We would like to have the guarantee that
the password is also not vulnerable to the same kinds of attacks from
eavesdroppers, server compromise, etc. during the registration step as
well as the login step.


(2) Lack of protection against pre-computation attacks

In the normal password-based login protocol, the account salt is kept
secret by the server, and when employed with a password hashing
function like scrypt/argon. If we are to replace this mechanism with
an augmented PAKE, we do not want to reduce security against
eavesdroppers, server compromise, etc. Indeed, it is already noted as
a requirement for augmented PAKEs to have pre-computation security
anyway.


(3) Client-only password hashing

We want to support a large range of clients, from browsers to low-end
mobile phones. For augmented PAKE protocols which require password
hashing to be done on the client, it seems like we must make a
tradeoff between performance/usability on the client device and the
difficulty of brute-forcing password hashes after a server compromise.
This differs from the normal password-based login protocol, where
password hashing occurs on the server, and hence this tradeoff is not
as significant.


---

And here are the comments I have gathered specifically for each proposal:


BSPAKE: See (1); it seems like the server has to start with parameters
dependent on the password, but it isn't clear how to do this in
registration without sending a password-equivalent to the server.
Also, see (3).
AuCPace: See (2) and (3).
OPAQUE: See (3).
VTBPEKE: See (1); server needs to start with V^H(s, pw), and it is not
clear how to transmit this securely on account creation. Also, see (2)
and (3).