Re: [Cfrg] Comments on the CPace proof and the CFRG PAKE selection process

["Hao, Feng" <[e-mail]>]

Dear Bjorn (and CFRG),

I hope you are all well.

I raised one question about CPace during the selection process, however I don't think it has been properly addressed. Also I don't know whether the selection panel have actually taken this into account. Given that the selection process has finished and that CPace will likely be fielded, I feel we (everyone on CRFG) still have the responsibility to make sure all the technical claims in CPace are accurate and that the protocol can indeed be implemented securely and efficiently.

CPace modifies SPEKE by adding a random string (session ID) in the first flow. It claims to be one-round and UC-Secure.

However, the design of CPace is based on an "unusual" assumption: namely, each party should know the shared password and the other party's identity even before any communication in key exchange takes place. I say this is "unusual" as no other PAKE protocols make the same assumption, as far as I can tell. 

The "standard" assumption (e.g., as defined in ISO/IEC 11770-4) in PAKE is that a user only needs to memorize a shared password. The identities are established in-flow as part of the key exchange process and are verified based on the equality of the two passwords supplied by the two parties. This is reflected in all the PAKE designs that I know - but with exception of CPace.

One implication for the "unusual" assumption in CPace is that now a user not only needs to memorize a password, but also memorize the other party's "exact" identity which is to going to be used in the key exchange. However, when a key exchange session fails, it's simply impossible to distinguish whether the failure is due to the use of the wrong password or the user mis-remembering the other party's identity. This will impose severe difficulties in the implementation, e.g., defending against online dictionary attacks.
 
The other issue I raised in the earlier discussion in this list is that from the protocol design perspective, CPace is under-specified: there is no specification in the discrete logarithm setting, and several critical efficiency/security questions have been abstracted away by the idealization of hash-to-curve (which is yet to be established). 

Best regards,
Feng