<= div dir=3D"ltr">

Dea= r CFRG chairs,

Please find below my review of the = nominated PAKEs (a Stage 5 review - i.e., an overall review, taking into ac= count the partial reviews published at https://github.com/cfrg/pake-selection= ) with my opinion about possible recommendations.

According to th= e PAKE selection process plan, it is one of the Crypto Review Panel experts= reviews, which are to be taken into account by the CFRG chairs at Stage 6 = ("01.11.2019-16.11.2019: CFRG chairs discuss the obtained reviews and = make their recommendations to CFRG/convey to CFRG that they can=E2=80=99t m= ake a recommendation yet.") =E2=80=93 so I am not sure that we want to= disclose these reviews to the group beforehand.

<= br>Documents: 8 PAKEs, nominated to the PAKE selection process; partial rev= iews provided at Stage 4 (see https://github.com/cfrg/pake-selection).
Rev= iewer: Stanislav Smyshlyaev
Review Date: 2019-10-23
Summary:=C2=A0

I would recommend selecting two PAKEs (one balanced and one augm= ented): SPAKE2 and OPAQUE.=C2=A0

No strong objections agai= nst: CPace, AuCPace, VTBPEKE

1. Balanced
1.1. SPAKE2

The main is= sue with SPAKE2 is potential existence of a backdoor in case when the param= eters M and N have not been selected in a way that their joint discrete log= arithm is guaranteed to be unknown. A variant of the protocol has been prop= osed, which is using a hash-to-curve function =E2=80=93 but such a change w= ould lead to a different protocol, which requires a separate security analy= sis. Another possible issue is that the protocol is not =E2=80=9Cquantum an= noying=E2=80=9D, since one needs to calculate only one discrete logarithm t= o break any instance of the protocol.
In my opinion, this is not an imp= ortant issue for the current PAKE selection process. From the security poin= t of view (regarding =E2=80=9Cclassical=E2=80=9D attacks on key exchange pr= otocols), SPAKE2 has such an advantage as absence of known attacks exploiti= ng small subgroups. Nevertheless, the checks related to cofactors are menti= oned in the draft, which is good. The experts do not see major issues with = integrating SPAKE2 into TLS 1.3, while there is a note about minor issues w= ith mixing-in a password value into KDF (but it seems to be possible to mix= it as ePSK). There does not seem to be any major issues with integrating i= nto IKEv2 also or IoT applications also.=C2=A0

1.2, 1.3. CPace an= d SPEKE
SPEKE and CPace are based on the same basic scheme, but SPEKE ha= s been initially defined for the finite fields with the proof only for that= case. Therefore, it seems that it is worth considering CPace, since it is = defined in the general case.
The main issue with CPace seems to be about= the stage of negotiating =E2=80=9Csid=E2=80=9D parameter. Such a stage tur= ns the CPace into a 2-RTT protocol, which eliminates its main advantage, ef= ficiency. Such a sid is needed to provide a proof in UC-framework.=C2=A0 Th= e existence of sid for UC-framework may be more a technical issue for the a= pproach, so CPace without negotiating the sid could be considered. The impo= rtant part of the protocol is a Map2Point function, which impacts the overa= ll security of the protocol, hence a careful choice of such a primitive is = required.=C2=A0 The CPace without negotiating sid seems to be easily integr= ated into TLS 1.3, IKEv2 and IoT protocols.=C2=A0

Nevertheless, C= Pace should be separately defined and described (not only as a part of AuCP= ace) and carefully studied for the case without sid. In my opinion, if CPac= e is selected as recommended PAKE, these actions can be done during the fur= ther steps of writing a CFRG RFC on recommendations for PAKEs.
1.4. J-PA= KE
The main advantage of J-PAKE seems to be that it does not use any has= h-to-curve functions, that can lead to some vulnerabilities or backdoors. A= t the same time, it has significant problems with efficiency. Therefore, it= seems to be much more problematic to integrate it into TLS and IKEv2. More= over, since IKEv2 and IoT protocols are very sensitive to the message sizes= , long messages (with up to three points in a single message) in J-PAKE loo= k like a real problem for practical usage.
There are no major problems w= ith the security of the protocol, although some improvements of the proofs = could be made (SE-NIZK-proofs, but =E2=80=9Cnone of them would be nearly as= practical=E2=80=9D).
1.5. Balanced: overall

Two ideas com= pete: DH on password-based points as generators (CPace =D0=B8 SPEKE) and DH= on points, which are masked with password-based points (SPAKE2).
In my= opinion, only CPace and SPAKE can be considered in the current selection p= rocess. For CPace the security without pre-negotiation of sid should be stu= died.
Since the only issue with SPAKE2 seems to be eliminating the disc= rete logarithm (between M and N) problem and since it can be done (in my op= inion) during the further steps of writing a CFRG RFC on recommendations fo= r PAKEs, I would recommend SPAKE2 as a balanced PAKE.

2. Augm= ented
2.1. OPAQUE
OPAQUE is more a =E2=80=9Cconverter=E2=80=9D of AKE= s to PAKEs using a secure OPRF. The main advantage of OPAQUE is security ag= ainst precomputations, which is desirable for applications, for which augme= nted PAKEs are preferred.
OPAQUE can be integrated into TLS 1.3 (the met= hod of this integration has already been specified) without any changes in = the protocol.
The authors have recently updated the security proof, addr= essing the raised concerns about it; nevertheless, in my opinion, the secur= ity assessment is already mature enough and sufficient for considering it s= ecure.
The protocol is also not =E2=80=9Cquantum annoying=E2=80=9D, but,= in my opinion, that cannot be treated as a major disadvantage of the proto= col.
2.2. AuCPace
AuCPace is an augmented version of CPace. AuCPace i= tself is not secure against precomputations, but preventing precomputation = is a minor change =E2=80=93 a strong version of AuCPace is called strong Au= CPace.
There are some questions to the security proof of AuCPace (one of= the reviewers treats the initially subitted version of it as =E2=80=9Crath= er sketchy=E2=80=9D), but, as well as OPAQUE, the security assessment seems= to be already mature enough and sufficient for considering it secure.
A= uCPace is a =C2=ABquantum annoying=C2=BB PAKE.
Integrating AuCPace into = TLS 1.3 is deeply studied in the materials =E2=80=93 there exist some issue= s, but none of them seems to be critical.
2.3. BSPAKE
BSPAKE =E2=80= =93 is an augmented Elligator-version of SPAKE2. The main disadvantage of i= t is absence of a complete security proof (the authors just say that the se= curity follows from the security of the underlying elements of the construc= tion).
The blind salt mechanism is similar to the one used in OPAQUE (OP= RF); the mechanism of using blind salt in AuCPace is different: in AuCPace = the salt is chosen by the client during registration phase. =C2=A0
BSPAK= E is =C2=ABquantum annoying=C2=BB.
BSPAKE is 2-RTT, so it needs certain = efforts to be integrated into TLS 1.3. It seems that a separate work of mod= ifying the PAKE in a way similar to OPAQUE for TLS 1.3.
BSPAKE does not = seem to be a solid construction with detailed security analysis, in my opin= ion it should not be considered to be recommended as a selected PAKE.
2.= 4. VTBEKE
VTBEKE =E2=80=93 is an augmented version of TBEKE (a modified = SPEKE). VTBEKE is not secure against precomputations, but it can be modifie= d to be such by adding blind salt.
The game-based security proof is suff= icient to consider the protocol secure. The situation with integrating AuCP= ace into TLS 1.3 is similar to the one with AuCPace, several issues have to= be resolved.
2.5. Augmented: overall
In my opinion, only AuCPace, V= TBEKE and OPAQUE can be considered in the current selection process. Curren= tly only OPAQUE provides security against precomputations =E2=80=93 and in = my opinion, it is important for an augmented PAKE (otherwise, balanced PAKE= s are not much less convenient for the same client-server applications).Blind-salt versions of AuCPace =D0=B8 VTBEKE should be considered instead = of the "plain" versions of them, but the corresponding detailed s= ecurity proofs should be obtained to do so.
In addition, since integrati= on of OPAQUE into TLS 1.3 also seems to be studied more deeply, I would rec= ommend OPAQUE as an augmented PAKE, if no patent issues occur to be prevent= ing it.

3. Remarks

To be considered in the futu= re for the selected PAKEs: while integrating a PAKE into protocol, it is im= portant to decide, on which step to negotiate PAKE parameters (e.g., ellipt= ic curve group); cross-cipher suite security must also be taken into accoun= t.

4. Overall recommendations
Overall recommendations about the a= nticipated results of the PAKE selection. If we are to use PAKEs for IKEv2 = or other peer-to-peer protocols, a balanced PAKE is desirable. To address t= he remote access applications or other client-server scenarios, it is bette= r to also have an augmented PAKE.
Therefore, I would recommend selectin= g one balanced PAKE and one augmented PAKE.
I would recommend selecti= ng two PAKEs (one balanced and one augmented): SPAKE2 and OPAQUE. In my= opinion, these protocols are mature enough and do not have any significant= problems; all existing concerns can be addressed during the work on a CFRG= RFC on recommendations for PAKEs. CPace, AuCPace and VTBPEKE are also stro= ng candidates (I wouldn't have any strong objections against CFRG recom= mending any of them).=C2=A0

Best regards,

Stanislav= Smyshlyaev

=D0=BF=D1=82, 20 =D1=81=D0=B5=D0=BD=D1=82. 2019 =D0=B3. =D0= =B2 19:23, Stanislav V. Smyshlyaev <smyshsv@gmail.com>:

Dear Bjoern, = Scott, Russ, Yaron, Tibor (and myself :) ),

Many t= hanks again for volunteering to provide overall reviews for the nominated P= AKEs on behalf of the Crypto Review Panel.

Accordi= ng to the PAKE selection process plan, at Stage 5=C2=A0Crypto Review Panel = members write overall reviews for all candidate PAKEs, based on the materia= ls that have been gathered and verified. According to the plan, Stage 5 wil= l last until October, 30th.

Those materials (inclu= ding all partial reviews) have been gathered (many thanks, Yaron!) here:=C2= =A0htt= ps://github.com/cfrg/pake-selection

Best regar= ds,
Stanislav,
CFRG secretary