[Crypto-panel] Round 2 Stage 4 of PAKE selection process

[Russ Housley <[e-mail]>]

CFRG is looking for a PAKE to support TLS 1.3 and IKEv2.  I provided an earlier review as part of Round 1, and I am providing this review as part of Round 2 (Stage 4).  The candidate algorithms fro Round 2 have been reduced to four choices, two Balanced PAKE algorithms and two Augmented PAKE algorithms.


Augmented PAKE (OPAQUE vs AuCPace)

RECOMMENDATION: OPAQUE

OPAQUE uses fewer messages than AuCPace.  The recent update to AuCPace (called AuPace without explicit key confirmation) reduces the round trips from the version that reviewed the the previous round.  OPAQUE is modular, so the CFRG will need to make choices for each of the component parts.  On one hand, the computational cost cannot be clearly known without picking all of the components.  On the other hand, there are reasonable choices for all of the components that fit well with TLS 1.3 and IKEv2, and if a problem is ever found with a particular choice, there are replacements already on the shelf.  Assuming very reasonable choices for the components, OPAQUE uses less computation that AuCPace. In addition, OPAQUE is "post-quantum prepared".  That is, the modular design allows post-quantum components to be selected after the NIST competition is complete.  The biggest downside was already raise by Scott Fluhrer, and that is the lack of "quantum annoyance".  Despite this downside, in my view, the modularity and reduced computational cost tilt the scale in favor of OPAQUE.



Balanced PAKE (CPace vs SPAKE2)

RECOMMENDATION: CPace

CPace requires fewwer elliptic curve operations by each party.  CPace has better "quantum annoyance" than SPAKE2.  Neither algorithm is "post-quantum prepared".  (In fact, Watson Ladd said "SPAKE2 is unlikely to have a post-quantum alternative".)  The lack of response to the Third Party IPR disclose against SPAKE2 is also a significant concern.