[Cfrg] Updated review of PAKEs

[Bjoern Tackmann <[e-mail]>]

This is a brief update of my review of all candidates sent on October 29 [1]. Note that there was a follow-up discussion in which Hugo pointed out flaws in my report. (None of them had an effect on the outcome.)


Balanced PAKE
===========

The short version is that I prefer CPACE over SPAKE2. The arguments are essentially the same as in the previous review. SPAKE2 seems an (almost) equally good alternative, and picking one of the two was difficult.

Sparked by Julia’s excellent review of the proofs [2], I wanted to share some of my own thoughts on this in a bit more detail. I fully support Julia’s argument that SPAKE2 has a published proof that is written clearly and in detail, and that has withstood scrutiny since 2005. The CPACE proof, by contrast, omits several important steps (such as all reduction arguments), has been more of a moving target during review, and has been published only last year. The SPAKE2 theorem is in concrete security (which I think is an important aspect), whereas the CPACE theorem only provides an asymptotic “soundness” guarantee. And yet, the formal statement for SPAKE2 has the assumption of uniformly distributed passwords; the protocol does not seem to use this anywhere but it is still a limitation in the proof support. It is also unclear how the proved security of SPAKE2 composes when the key is used in higher-level protocols. And last but not least, I think (disclaimer: what follows is not a statement I can make formal) that the dependency on stronger idealization in the proof of CPACE is linked to the use of a security model that is significantly stronger in corruption modeling. So in terms of proof support I find the two protocols incomparable, and my preference for CPACE mostly comes from the “more useful” (targeted) security statement. I fully understand Julia’s reasons for coming to a different conclusion.

Finally, and although it may be unnecessary to point this out: even subtle changes in protocols invalidate existing security proofs. I think it would be prudent for CFRG to re-evaluate the proof support after the now-discussed modifications to the chosen protocol (e.g., choice of session id for CPACE, choice of M,N for SPAKE2) are finalized, before deciding on the final outcome (“zero or one” candidates) of the process.

And just for completeness: I deliberately did not take possible IP issues into account.


Augmented PAKE
===========

The short version is that I prefer OPAQUE over AUCPACE. The main arguments are OPAQUE’s better compatibility with important application protocols through less protocol messages, and its flexibility.

Amending my previous review, the latest proof for OPAQUE is indeed a significant improvement over the one that was available when I started that review. So besides the preferable properties stated above, I now consider the proof support for OPAQUE also as better than that for AUCPACE. (This is in full agreement with Julia’s assessment.)


[1] https://mailarchive.ietf.org/arch/msg/cfrg/1sNu9USxo1lnFdzCL5msUFKBjzM/
[2] https://mailarchive.ietf.org/arch/msg/cfrg/47pnOSsrVS8uozXbAuM-alEk0-s/