From nobody Thu Sep 12 06:46:49 2019 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003F7120071 for ; Thu, 12 Sep 2019 06:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtCDZ8QXaV_u for ; Thu, 12 Sep 2019 06:46:44 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8DD12007C for ; Thu, 12 Sep 2019 06:46:43 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id y23so23644161lje.9 for ; Thu, 12 Sep 2019 06:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=j78jcR9tV33cmMxUEMSA670EjLl/Z13YROBo0MHpA0U=; b=ttuOqFuNqtScO4Fghd7O4f8McuTWsY2oSrM2d+pnmCUYBWcL5+oenrvYmyPC57priK +SbmvpJDMak95+jc9BCdksnC+fBM8OV20Hv8wZRRPI6ON3jrozn50701I/cAvUjXYo0X ezQWI5SRN1g9RjQ/XrVuKnY9SP9migYpkYGQqt+yS+Jr7lzlIgYZ/8PU7HvLYb3GpYho 4Uca1ThUp/bOBcRIwWnztZjZIyFGfX9SzgHeezf6beWBkBJb8X5cYZBIu+vp8u16Yzq8 3FCFU0/cZ32QCLmeSdmlk84NGM8YbsRcAGQIBQsuHjoanMRx6bmcebpjPuWraqQ+TtOB nq6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=j78jcR9tV33cmMxUEMSA670EjLl/Z13YROBo0MHpA0U=; b=UtxNrP/BxKyIdQ3Tot6EQSwOuMnTfx7jpFaP0Vznl6JUzkVwRrs+85/Xa22PGzHUVH W8DUoBQ+QPimKoZt9y6TRz/Brh/6oORPmXZUKtEgEJRtoJyj8bBl5IXdfzNgXjXuSei9 tAdl5M+IN76xcFiWHkoJR6O3cnJG70lA0AQ8av2d8t/SIpF3yj+J5RKYUtIA0widbbKm rStDIFPuvRV3lhiPY1I6UhXKK7scyELg/I1znahB6RLpPtOnfpyymiIJQko5ayiXbNFy MkG+CJmmKQcwg5+/I5jHUhJRRUZCXGCSci+KZ8CYQwkdLwsrSLSdgIOLULICLPy1pi8V WiLQ== X-Gm-Message-State: APjAAAUGXieZu9/Bq1U29I+WMXmq7wkNUZbtDxpcClrZGoytHWYV3E7a cYllJei1BIGA7U/NF5dcPJE2ryeOIBdqqsQ6Flc= X-Google-Smtp-Source: APXvYqw4qZp4k3JxemIYKxJUhn6AIFBaXdYqmHskUC/RZ/PtMwkjb/p0blX3nueAc3zIYnLDj4GS8r1SsYSid0M6xcY= X-Received: by 2002:a2e:6586:: with SMTP id e6mr25122320ljf.115.1568296001978; Thu, 12 Sep 2019 06:46:41 -0700 (PDT) MIME-Version: 1.0 References: <7c37bae3-f816-e3f0-c070-a908a4af9a07@isode.com> In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Thu, 12 Sep 2019 16:45:43 +0300 Message-ID: To: "cfrg-chairs@ietf.org" , "crypto-panel@irtf.org" Content-Type: multipart/alternative; boundary="00000000000019c5c305925b5ed9" Archived-At: Subject: Re: [Crypto-panel] Soliciting reviews of submitted PAKE algorithms X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 13:46:47 -0000 --00000000000019c5c305925b5ed9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good afternoon, Please find below my own partial reviews (regarding the security proofs and security claims) for the balanced PAKEs - to be taken into account by the Crypto Review Panel members on Stage 5 of the review process. Document: PAKE selection process, Stage 4, balanced PAKEs (reviews of security proofs and claims) Reviewer: Stanislav Smyshlyaev Review Date: 2019-09-12 CPace The CPace protocol is a balanced PAKE protocol based on the same idea as the SPEKE protocol. This protocol is described as a part of the augmented version of the protocol and assumes parties and session identifiers to be negotiated previously. To consider CPace as an independent protocol there is a need to provide a full description of the balanced version including sid, pid (DH group?) negotiation. The authors consider the key differences between CPace and SPEKE protocol. The original SPEKE version is vulnerable to several attacks such as reflection attack, unknown key share attack, exponential equivalence. The CPace protocol was designed having in mind all these attacks. However, the protocols of SPEKE types have the undesirable property called key malleability where an adversary has the possibility to modify both honest parties=E2=80=99 resulting DH keys unless the whole transcript of the commu= nication is used for generating the session key. CPace has this property too. Although this property is believed not to affect security in practice, it is not clear why the authors did not include the transcript of the connection into the session key generation procedure. Including transcription is useful to protect against downgrade and cross-protocol attacks (if the protocol includes a group negotiation phase). Moreover, when using the group with cofactor we have the following property: for any connection with Ya and Yb DH public keys there are another Y=E2=80=99a and = Y=E2=80=99b DH public keys that produce the same session key (e.g. Y=E2=80=99a =3D Ya * T,= where T has the order c (cofactor)). In order to negate these undesirable properties we'd recommend including the whole connection transcript into the session key generation procedure. The protocol security is proven within the UC framework. The simulation-based model is well defined. Due to the UC approach using, the case assuming some users using the same passwords for different protocols and, more generally, the case where passwords are chosen according to some arbitrary distribution are taken. The used assumptions are well-known and well-investigated. The main disadvantage of the security analysis is the absence of quantitative bounds that are very useful for practice. However, the considered ideal functionality allows to state that an adversary can test only one password in a single impersonation. SPEKE The author provided the reference https://eprint.iacr.org/2014/585 to the description of the protocol. The article contains several variants of the SPEKE protocol, so it is not absolutely clear, which variant is nominated. Therefore, the version presented in the article containing the security proof was chosen for the reivew. The provided proof is simulation-based. The proof shows that in a single impersonation attempt an adversary can gain information about at most two possible passwords. The protocol (only for Z*p) security is proven under the hardness of the DIDH problem in the random oracle model. This problem is not well investigated for concrete groups and it was just shown that a lower bound for solving DIDH in the generic model asymptotically matches the lower bound for solving DDH in the generic model. The main element of the protocol is a function that is required to map a string to an element from a large subgroup, such that the discrete logarithm of the point is unknown. Since the protocol is defined only for specific group Z*p with p =3D 2q+1, the mapping function is fixed only for this case and the proof is essentially based on this function (that treated as a random oracle). The protocol security in the general case should be considered for using it with other groups. SPAKE2 The SPAKE2 is a balanced PAKE protocol based on the clear idea to mask the low entropy secret before sending it to the channel. The authors of nomination claim that the protocol does not have a trusted setup needs to be discussed, since the terminology may differ. The protocol uses three generators of the used groups and the discrete logarithm relationship between these group elements in the system setup must be unknown. Note that draft-irtf-cfrg-spake2-08 clearly states this security assumption and contains the description of the algorithm used for point generation. The security is proven in the concurrent indistinguishability-based model. In the model the passwords are assumed to be uniformly distributed, the parties cannot be both client and server, each client has only one password. Also this model does not provide the corruption interface allowing an adversary to adaptively compromise client=E2=80=99s passwords. = Such properties can be treated as model disadvantages. J-PAKE The J-PAKE is a balanced PAKE protocol based on the NIZK proofs. The main disadvantage of the protocol is its inefficiency: two rounds and a lot of group scalar multiplications. However, this protocol does not require any trusted setup and additional Map2Point functions. The protocol security is proven in the concurrent indistinguishability-based model. In the model the passwords are assumed to be uniformly distributed, the parties cannot be both client and server (that can lead to missing reflection attacks), each client has only one password. Such properties can be treated as model disadvantages. The proof states that the protocol is secure under the hardness of the DSDH problem, the existence of computational randomness extractors, and the simulation-sound extractability and unbounded zero-knowledge of the used NIZK proof system. Note that the Schnorr proof, which was recommended for the J-PAKE protocol, satisfies this strong security assumption only in a model with algebraic adversaries and random oracles. So, unlike SPAKE2 and CPace, the J-PAKE protocol requires a lot of trust to the used primitives. Note that including labels (party=E2=80=99s identifiers) only in ZKP protec= ts against UKS and reflection attacks. Nevertheless, we recommend including the whole transcript into the key generation procedure. In addition, the RFC does not explicitly describe how to deal with groups where cofactor is not equal to one. Best regards, Stanislav =D1=81=D1=80, 7 =D0=B0=D0=B2=D0=B3. 2019 =D0=B3. =D0=B2 21:12, Stanislav V.= Smyshlyaev : > Dear Alexey, I would be happy to do this. > > I=E2=80=99d prefer to deal with the balanced ones. > > I=E2=80=99ll do the verification of security proofs of the 4 balanced nom= inated > PAKEs by September, 15th, and I=E2=80=99ll be ready to do the following o= verall > reviews for them afterwards. > > Kind regards, > Stanislav > > =D1=81=D1=80, 7 =D0=B0=D0=B2=D0=B3. 2019 =D0=B3. =D0=B2 20:58, Alexey Mel= nikov : > >> Dear Crypto Review Panel members! >> >> According to the plan, the most important parts of the PAKE selection >> process is done by the Crypto Review Panel members. >> More precisely, the Crypto Review Panel members will need to do the >> following: >> 1) Crypto Review Panel members do the verification of security proofs of >> the candidates and overall security assessment by September 15th 2019. >> 2) Crypto Review Panel members review all gathered materials (including >> independent reviews). If additional explanations are needed, Crypto >> Review Panel members ask for them from the designers. Crypto Review >> Panel members write overall reviews for all candidate PAKEs, based on th= e >> materials that have been gathered and verified. This is to be done by >> October 30th 2019. >> >> We have 8 nominated PAKEs: 4 balanced and 4 augmented. >> Each member is asked to provide reviews for either all 4 balanced or all >> 4 augmented PAKEs (or for all 8 PAKEs, if the member is happy to do that= ). >> >> Please reply to this message and tell the CFRG chairs about your >> willingness to do this and, if yes, would you prefer to deal with 4 >> balanced PAKEs or with 4 augmented PAKEs (or, maybe, with all 8 of them)= . >> >> Best Regards, >> Alexey (on behalf of CFRG chairs) >> > --00000000000019c5c305925b5ed9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good afternoon,

=
Please find below my own partial reviews (regarding the security= proofs and security claims) for the balanced PAKEs - to be taken into acco= unt by the Crypto Review Panel members on Stage 5 of the review process.

Document: PAKE selection= process, Stage 4, balanced PAKEs (reviews of security proofs and claims)

Reviewe= r: Stanislav Smyshlyaev

Review=C2=A0Date: 2019-09-12<= /p>


CPace

The CPace protocol is a balanced PAKE protocol based= on the same idea as the SPEKE protocol. This protocol is described as a pa= rt of the augmented version of the protocol and assumes parties and session= identifiers to be negotiated previously. To consider CPace as an independe= nt protocol there is a need to provide a full description of the balanced v= ersion including sid, pid (DH group?) negotiation. =C2=A0
The authors co= nsider the key differences between CPace and SPEKE protocol. The original S= PEKE version is vulnerable to several attacks such as reflection attack, un= known key share attack, exponential equivalence. The CPace protocol was des= igned having in mind all these attacks. However, the protocols of SPEKE typ= es have the undesirable property called key malleability where an adversary= has the possibility to modify both honest parties=E2=80=99 resulting DH ke= ys unless the whole transcript of the communication is used for generating = the session key. CPace has this property too. Although this property is bel= ieved not to affect security in practice, it is not clear why the authors d= id not include the transcript of the connection into the session key genera= tion procedure. Including transcription is useful to protect against downgr= ade and cross-protocol attacks (if the protocol includes a group negotiatio= n phase). Moreover, when using the group with cofactor we have the followin= g property: for any connection with Ya and Yb DH public keys there are anot= her Y=E2=80=99a and Y=E2=80=99b DH public keys that produce the same sessio= n key (e.g. Y=E2=80=99a =3D Ya * T, where T has the order c (cofactor)). In= order to negate these undesirable properties we'd recommend including = the whole connection transcript into the session key generation procedure. = =C2=A0 =C2=A0 =C2=A0
The protocol security is proven within the UC frame= work. The simulation-based model is well defined. Due to the UC approach us= ing, the case assuming some users using the same passwords for different pr= otocols and, more generally, the case where passwords are chosen according = to some arbitrary distribution are taken. The used assumptions are well-kno= wn and well-investigated. The main disadvantage of the security analysis is= the absence of quantitative bounds that are very useful for practice. Howe= ver, the considered ideal functionality allows to state that an adversary c= an test only one password in a single impersonation.

SPEKE
The au= thor provided the reference https://eprint.iacr.org/2014/585 to the description of = the protocol. The article contains several variants of the SPEKE protocol, = so it is not absolutely clear, which variant is nominated. Therefore, the v= ersion presented in the article containing the security proof was chosen fo= r the reivew.=C2=A0
The provided proof is simulation-based. The proof sh= ows that in a single impersonation attempt an adversary can gain informatio= n about at most two possible passwords. The protocol (only for Z*p) securit= y is proven under the hardness of the DIDH problem in the random oracle mod= el. This problem is not well investigated for concrete groups and it was ju= st shown that a lower bound for solving DIDH in the generic model asymptoti= cally matches the lower bound for solving DDH in the generic model.
The = main element of the protocol is a function that is required to map a string= to an element from a large subgroup, such that the discrete logarithm of t= he point is unknown. Since the protocol is defined only for specific group = Z*p with p =3D 2q+1, the mapping function is fixed only for this case and t= he proof is essentially based on this function (that treated as a random or= acle). The protocol security in the general case should be considered for u= sing it with other groups.
=E2=80=83
SPAKE2
The SPAKE2 is a= balanced PAKE protocol based on the clear idea to mask the low entropy sec= ret before sending it to the channel. The authors of nomination claim that = the protocol does not have a trusted setup needs to be discussed, since the= terminology may differ. The protocol uses three generators of the used gro= ups and the discrete logarithm relationship between these group elements in= the system setup must be unknown. Note that draft-irtf-cfrg-spake2-08 clea= rly states this security assumption and contains the description of the alg= orithm used for point generation.
The security is proven in the concurre= nt indistinguishability-based model. In the model the passwords are assumed= to be uniformly distributed, the parties cannot be both client and server,= each client has only one password.=C2=A0 Also this model does not provide = the corruption interface allowing an adversary to adaptively compromise cli= ent=E2=80=99s passwords. Such properties can be treated as model disadvanta= ges.=C2=A0

J-PAKE
The J-PAKE is a balanced PAKE protocol based on= the NIZK proofs. The main disadvantage of the protocol is its inefficiency= : two rounds and a lot of group scalar multiplications.=C2=A0 However, this= protocol does not require any trusted setup and additional Map2Point funct= ions.
The protocol security is proven in the concurrent indistinguishabi= lity-based model. In the model the passwords are assumed to be uniformly di= stributed, the parties cannot be both client and server (that can lead to m= issing reflection attacks), each client has only one password.=C2=A0 Such p= roperties can be treated as model disadvantages.=C2=A0
The proof states = that the protocol is secure under the hardness of the DSDH problem, the exi= stence of computational randomness extractors, and the simulation-sound ext= ractability and unbounded zero-knowledge of the used NIZK proof system. Not= e that the Schnorr proof, which was recommended for the J-PAKE protocol, sa= tisfies this strong security assumption only in a model with algebraic adve= rsaries and random oracles. So, unlike SPAKE2 and CPace, the J-PAKE protoco= l requires a lot of trust to the used primitives.
Note that including la= bels (party=E2=80=99s identifiers) only in ZKP protects against UKS and ref= lection attacks.=C2=A0 Nevertheless, we recommend including the whole trans= cript into the key generation procedure.=C2=A0
In addition, the RFC does= not explicitly describe how to deal with groups where cofactor is not equa= l to one.=C2=A0
=C2=A0

Best regards,
= Stanislav


=D1=81=D1=80, 7 =D0=B0=D0= =B2=D0=B3. 2019 =D0=B3. =D0=B2 21:12, Stanislav V. Smyshlyaev <smyshsv@gmail.com>:<= br>
Dear Alexey, I would be happy to do this.=C2=A0

I=E2=80=99d prefer to deal with the b= alanced ones.

I=E2=80=99= ll do the verification of security proofs of the 4 balanced nominated PAKEs= by September, 15th, and I=E2=80=99ll be ready to do the following overall = reviews for them afterwards.=C2=A0

Kind regards,
Stanislav

=D1=81=D1=80,= 7 =D0=B0=D0=B2=D0=B3. 2019 =D0=B3. =D0=B2 20:58, Alexey Melnikov <alexey.melnikov@i= sode.com>:
Dear Crypto Review Panel members!

According to the plan, the most important parts of the PAKE selection process is done by the Crypto Review Panel members.
More precisely, the Crypto Review Panel members will need to do the following:
1) Crypto Review Panel members do the verification of security proofs of the candidates and overall security assessment by September 15th 2019.
2)=C2=A0C= rypto Review Panel members review all gathered materials (including independent reviews).=C2=A0If additional explanations are needed, Crypto Review Panel members ask for them from the designers.=C2=A0Crypto Review Panel members write overall reviews for all candidate PAKEs, based on the materials that have been gathered and verified. This is to be done by October 30th 2019.

We have 8 nominated PAKEs: 4 balanced and 4 augmented.
Each member is asked to provide reviews for either all 4 balanced or all 4 augmented PAKEs (or for all 8 PAKEs, if the member is happy to do that).

Please reply to this message and tell the CFRG chairs about your willingness to do this and, if yes, would you prefer to deal with 4 balanced PAKEs or with 4 augmented PAKEs (or, maybe, with all 8 of them).

Best Regards,
Alexey (on behalf of CFRG chairs)
--00000000000019c5c305925b5ed9-- From nobody Fri Sep 20 09:24:57 2019 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2E2120113 for ; Fri, 20 Sep 2019 09:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvkDSJoLwwMH for ; Fri, 20 Sep 2019 09:24:53 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 005C01202DD for ; Fri, 20 Sep 2019 09:24:52 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id j19so6179511lja.1 for ; Fri, 20 Sep 2019 09:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=h0QUT1oAtFhWNiF/b4ZGwW44DKrX/d9/yJ/s6CTluM4=; b=A/kcB/DeMsNoQza6xrSQUy3xcqTc3nwxHw8dtVJVISO38b4mbEzA61NHyXyKdQBXnd XK9d3tdaa98fm+XeF2cQ8oAvggetFtbh4l9mryRGCgyysgRfxSopXx6QNHMtnhDoqdJ9 4KwN31xKNtZ0nM6EdEAdvMoR+Vba7T6/nCFJN4POakFI9vkTPozAC84bQAo/JUfcVPdo 2SueDp25Uum9seM5Rdy4flInQixORnqJmwkkH4bSQqVC42cYpGIANt8UdcDO4iRuky5A c/l2PoY4z94hfIYzFJQY1y8NNP8XhyfK+7D22lFbmpPeJt9kXPWPR8Mf7I4tknzB0Llh OWOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=h0QUT1oAtFhWNiF/b4ZGwW44DKrX/d9/yJ/s6CTluM4=; b=qglFlXttce8UJBIHdVn4b2ORiiSEfOkDZa68bCnZ3QBqsIGGq/P3Mdco9Jmm7dxG2t LPv8jORMqfs6XCK1ekN7h8Kr2ctOSCTv4uZis0FiYL/G5UI+s5cch+XzGCR6ev7cPW7p 1oqMnXN4GfEISJETMZtXRX31mWPiS2hpngHWTt2orklU/eZa42wzgr2X5rb5MerJcUEX 5dd03kTSmSZLiLYKG9ifdUp87Vf4ITM8PYxjVKtQPzWFt6djAiS/JmdaPcZu83n487Vv 2PC5ucBNXBMC6VFrfWJQ7qhCdw7/7xpoWqQM/KYdoUufjVkbmsAijIOw8gbCk/+z0DsS h0GQ== X-Gm-Message-State: APjAAAUjjTCEApTLcyo/LjMp35UEaZUaH+FF7rggqPpkV1ZLzeArSE7R JdyWSeZRZaCe5nVy/HIUMjKk1bug1QsO7SaDkFk= X-Google-Smtp-Source: APXvYqxvek6eF+UMAol6GD2OkscmQ62sptMccklwEPbioYFBURgsaf3wqrT4KD6Ysx4YtbOkU1tR2Nux+aKeZJplkGs= X-Received: by 2002:a2e:309:: with SMTP id 9mr9807154ljd.171.1568996691156; Fri, 20 Sep 2019 09:24:51 -0700 (PDT) MIME-Version: 1.0 From: "Stanislav V. Smyshlyaev" Date: Fri, 20 Sep 2019 19:23:54 +0300 Message-ID: To: Bjoern Tackmann , Scott Fluhrer , Tibor Jager , Russ Housley , Yaron Sheffer Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000006e21cf0592fe8228" Archived-At: Subject: [Crypto-panel] Stage 5 of PAKE selection process X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2019 16:24:55 -0000 --0000000000006e21cf0592fe8228 Content-Type: text/plain; charset="UTF-8" Dear Bjoern, Scott, Russ, Yaron, Tibor (and myself :) ), Many thanks again for volunteering to provide overall reviews for the nominated PAKEs on behalf of the Crypto Review Panel. According to the PAKE selection process plan, at Stage 5 Crypto Review Panel members write overall reviews for all candidate PAKEs, based on the materials that have been gathered and verified. According to the plan, Stage 5 will last until October, 30th. Those materials (including all partial reviews) have been gathered (many thanks, Yaron!) here: https://github.com/cfrg/pake-selection Best regards, Stanislav, CFRG secretary --0000000000006e21cf0592fe8228 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Bjoern, Scott, Russ, Yaron, Tibor (and myself :) ),=

Many thanks again for volunteering to provide ove= rall reviews for the nominated PAKEs on behalf of the Crypto Review Panel.<= /div>

According to the PAKE selection process plan, at S= tage 5=C2=A0Crypto Review Panel members write overall reviews for all candi= date PAKEs, based on the materials that have been gathered and verified. Ac= cording to the plan, Stage 5 will last until October, 30th.

<= /div>
Those materials (including all partial reviews) have been gathere= d (many thanks, Yaron!) here:=C2=A0https://github.com/cfrg/pake-selection

<= div>Best regards,
Stanislav,
CFRG secretary
=
--0000000000006e21cf0592fe8228-- From nobody Mon Sep 23 10:05:44 2019 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C842E120906 for ; Mon, 23 Sep 2019 10:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMP7cQBWz_hl for ; Mon, 23 Sep 2019 10:05:28 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39EA41208D5 for ; Mon, 23 Sep 2019 10:05:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B402E300A91 for ; Mon, 23 Sep 2019 13:05:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id E_-sqvZhjD8f for ; Mon, 23 Sep 2019 13:05:25 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 4025E300AF7; Mon, 23 Sep 2019 13:05:25 -0400 (EDT) From: Russ Housley Message-Id: <83FAAC9C-A56C-43FC-BD68-5E1DB0794D7E@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3785FB0C-B10C-42C8-8819-9F56639AFC52" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 23 Sep 2019 13:05:25 -0400 In-Reply-To: Cc: crypto-panel@irtf.org To: "Stanislav V. Smyshlyaev" References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Crypto-panel] Stage 5 of PAKE selection process X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 17:05:39 -0000 --Apple-Mail=_3785FB0C-B10C-42C8-8819-9F56639AFC52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Stanislav: I just want to make sure that I understand. Is it correct that none of = the algorithms is being dropped or revised based on the proof analysis? Russ > On Sep 20, 2019, at 12:23 PM, Stanislav V. Smyshlyaev = wrote: >=20 > Dear Bjoern, Scott, Russ, Yaron, Tibor (and myself :) ), >=20 > Many thanks again for volunteering to provide overall reviews for the = nominated PAKEs on behalf of the Crypto Review Panel. >=20 > According to the PAKE selection process plan, at Stage 5 Crypto Review = Panel members write overall reviews for all candidate PAKEs, based on = the materials that have been gathered and verified. According to the = plan, Stage 5 will last until October, 30th. >=20 > Those materials (including all partial reviews) have been gathered = (many thanks, Yaron!) here: https://github.com/cfrg/pake-selection = >=20 > Best regards, > Stanislav, > CFRG secretary > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel --Apple-Mail=_3785FB0C-B10C-42C8-8819-9F56639AFC52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Stanislav:

I just want to make sure that I understand.  Is it = correct that none of the algorithms is being dropped or revised based on = the proof analysis?

Russ


On Sep = 20, 2019, at 12:23 PM, Stanislav V. Smyshlyaev <smyshsv@gmail.com> = wrote:

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

Many thanks again for volunteering to provide overall reviews = for the nominated PAKEs on behalf of the Crypto Review Panel.

According to the PAKE = selection process plan, at Stage 5 Crypto Review Panel members = write overall reviews for all candidate PAKEs, based on the materials = that have been gathered and verified. According to the plan, Stage 5 = will last until October, 30th.

Those materials (including all partial = reviews) have been gathered (many thanks, Yaron!) here: https://github.com/cfrg/pake-selection

Best regards,
Stanislav,
CFRG = secretary
_______________________________________________
Crypto-panel= mailing list
Crypto-panel@irtf.org
https://www.irtf.org/mailman/listinfo/crypto-panel

= --Apple-Mail=_3785FB0C-B10C-42C8-8819-9F56639AFC52-- From nobody Mon Sep 23 11:03:52 2019 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6C812004D for ; Mon, 23 Sep 2019 11:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.103, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7i_VySVTCZk for ; Mon, 23 Sep 2019 11:03:48 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF11120020 for ; Mon, 23 Sep 2019 11:03:48 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id i18so14969860wru.11 for ; Mon, 23 Sep 2019 11:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=b4rR71HfQl2vryn2uARTtXeD17g4AIMgTF+jwzzdXWc=; b=ps5Al2nP2CkT65PpnlUT5WY1+04Y/fpl96cMPIaxWWkwKdLkFEMyyvSIzVQuz6Q+e3 rWAr3xpSPgXb1r0gCqzbE2Qyi88bX43With/N+GN0JLxIufdLhhe1TAttnXmcGyyEpk2 kaeEv4EfxSc6hcbjMefS07NWTFMdcAI4LBSeQZeonBVWebZ6dano2ey40FLLuvG3wawC cgGK4Eg1zdU+9wBQnG8M6DoSkOVWDxgxGx8y+5V10Y1A6HshcvHiIlD0tuUxQ8ctV2HJ EKGZJbvO42BSbDjgJncWI1kXKKyrdRZ5lC6bnD26NgAAmWashQ9yCJowdDIs7PsxGt79 ot3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=b4rR71HfQl2vryn2uARTtXeD17g4AIMgTF+jwzzdXWc=; b=ahEBpXlspPR5kuBQ2Mk6iQegpcj3m4Jjqp8eVePNCT00o6maNbBCagTVw+aDJor114 zE/I8U4sHyqtS16DcR2qu/iZnV2FWQ70ialrVNGi0LUdBfAhcCdA7AowlJYE1L8c4Nsm QRTPkj2UeAeZwdb2ppAr9tc+ckiyUG9N8LPq9Szvdvg3kDIUllNXWNrodBcaIbn0dHLK QML06i++PgWMEkgbU5MFw+IGxm2zAb45lYvHlOKPElATSNg2RUgvSsbpnhwyrYxJ9FAJ j8w+owt44e4YOmr6zuF36RWWY69zSQqCmUQgt6j+BR3UQFXU+TZXQx0eSvVG681qxxmX ccJw== X-Gm-Message-State: APjAAAVrXa4wI1FWzksr7hVOw0Cu0D0k+J5tiLlfB7gEvda17wvQX4gc OoBtvqFb8jCtC13HQqhBhV4= X-Google-Smtp-Source: APXvYqwx4A4+Z9sWfDQxifJHPUMT6NhRTkmx32HwN5YK4/D6Ib52r5iui965g7lQwH1NxbEi96muJQ== X-Received: by 2002:a5d:490f:: with SMTP id x15mr453463wrq.375.1569261826980; Mon, 23 Sep 2019 11:03:46 -0700 (PDT) Received: from [10.0.0.148] (bzq-109-67-18-102.red.bezeqint.net. [109.67.18.102]) by smtp.gmail.com with ESMTPSA id 189sm24863899wma.6.2019.09.23.11.03.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Sep 2019 11:03:45 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.1d.0.190908 Date: Mon, 23 Sep 2019 21:03:43 +0300 From: Yaron Sheffer To: Russ Housley , "Stanislav V. Smyshlyaev" CC: Message-ID: <31D078E7-08CD-46F5-AF97-6F2450C5934A@gmail.com> Thread-Topic: [Crypto-panel] Stage 5 of PAKE selection process References: <83FAAC9C-A56C-43FC-BD68-5E1DB0794D7E@vigilsec.com> In-Reply-To: <83FAAC9C-A56C-43FC-BD68-5E1DB0794D7E@vigilsec.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3652117424_527312802" Archived-At: Subject: Re: [Crypto-panel] Stage 5 of PAKE selection process X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 18:03:51 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3652117424_527312802 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable The CPace/AuCPace paper was updated =E2=80=9Cin place=E2=80=9D (in the IACR ePrint repo= ) since the process started. Also, Hugo hinted that OPAQUE needs to be updat= ed, not the base protocol but some of the options. =20 From: Crypto-panel on behalf of Russ Housle= y Date: Monday, 23 September 2019 at 20:05 To: "Stanislav V. Smyshlyaev" Cc: Subject: Re: [Crypto-panel] Stage 5 of PAKE selection process =20 Stanislav: =20 I just want to make sure that I understand. Is it correct that none of the= algorithms is being dropped or revised based on the proof analysis? =20 Russ =20 On Sep 20, 2019, at 12:23 PM, Stanislav V. Smyshlyaev w= rote: =20 Dear Bjoern, Scott, Russ, Yaron, Tibor (and myself :) ), =20 Many thanks again for volunteering to provide overall reviews for the nomin= ated PAKEs on behalf of the Crypto Review Panel. =20 According to the PAKE selection process plan, at Stage 5 Crypto Review Pane= l members write overall reviews for all candidate PAKEs, based on the materi= als that have been gathered and verified. According to the plan, Stage 5 wil= l last until October, 30th. =20 Those materials (including all partial reviews) have been gathered (many th= anks, Yaron!) here: https://github.com/cfrg/pake-selection =20 Best regards, Stanislav, CFRG secretary _______________________________________________ Crypto-panel mailing list Crypto-panel@irtf.org https://www.irtf.org/mailman/listinfo/crypto-panel =20 _______________________________________________ Crypto-panel mailing list C= rypto-panel@irtf.org https://www.irtf.org/mailman/listinfo/crypto-panel=20 --B_3652117424_527312802 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

The CPace/AuCPace paper was updated =E2=80=9Cin place=E2=80=9D= (in the IACR ePrint repo) since the process started. Also, Hugo hinted that= OPAQUE needs to be updated, not the base protocol but some of the options.<= o:p>

 

From: Crypto-panel <crypto-panel-bounces@irtf.= org> on behalf of Russ Housley <housley@vigilsec.com>
Date: <= /b>Monday, 23 September 2019 at 20:05
To: "Stanislav V. Smysh= lyaev" <smyshsv@gmail.com>
Cc: <crypto-panel@irtf.or= g>
Subject: Re: [Crypto-panel] Stage 5 of PAKE selection proces= s

 

Stanislav:

 

I just want to make sure that= I understand.  Is it correct that none of the algorithms is being drop= ped or revised based on the proof analysis?

 

Russ

 



On Sep 20, 2019, at 12:23 PM, Stanislav V. = Smyshlyaev <smyshsv@gmail.com> = wrote:

 

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

<= o:p> 

Many thanks again for volu= nteering to provide overall reviews for the nominated PAKEs on behalf of the= Crypto Review Panel.

 = ;

According to the PAKE selection pro= cess plan, at Stage 5 Crypto Review Panel members write overall reviews= for all candidate PAKEs, based on the materials that have been gathered and= verified. According to the plan, Stage 5 will last until October, 30th.

 

Those materials (including all partial reviews) have been ga= thered (many thanks, Yaron!) here: https://github.com/cfrg/pake-selection

=

 

B= est regards,

Stanislav,

CFRG secretary

__________________________= _____________________
Crypto-panel mailing list
Crypto-panel@irtf.org
https://www.irtf.org/mailman/l= istinfo/crypto-panel

 

___________________________= ____________________ Crypto-panel mailing list Crypto-panel@irtf.org https:/= /www.irtf.org/mailman/listinfo/crypto-panel

--B_3652117424_527312802-- From nobody Mon Sep 23 11:20:33 2019 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672ED1208E5 for ; Mon, 23 Sep 2019 11:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qH--Fu4ERzW for ; Mon, 23 Sep 2019 11:20:27 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC03120958 for ; Mon, 23 Sep 2019 11:20:27 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id l21so14712941lje.4 for ; Mon, 23 Sep 2019 11:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wtGqGeOUuQCUEE8PRx1q2wYfardWP/jsio/GyltOzls=; b=iX9ETCX45LMTNxjifEY5OUA4uShNABHyA4qZdDluxQn7Rcv94p+hbdYEFWZG1MmMwG CvjK+abAHTj2VfmbAAWeV66PFg44GjpefGpAdBRqe+GjEaVvedxYiNzKlvN47Xg/Ciqy zq4OKl87z/iXx5EG/xvxmwQF9jR6wXzac6fdHAd+j97R/ZJVVXQUUfTQhbNQaDm5erZ0 9FyjorBFHu+gNHQFRfI2BW+ppiGWhNSX3IfJ2wPiMnGy8KdhmYA+tJMJPc4LTA7JuKre /IjXAFUVoZW+iwRw5ly0XYmrrJLIXrqzSJjj/pZXTEWT4cJEjgv4Rwad2Bf6nnYfD5/p Dakw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wtGqGeOUuQCUEE8PRx1q2wYfardWP/jsio/GyltOzls=; b=S8o662n7FEg06WXSgRb22gLXxnsZ1LJn9z5pVwksxG3xvGWtNdjUv7ls6eicUrj1te PI2EsF9Ewnps/xTRnoZva34gTBMIShCAB/dyZYeJ4CxDmLKHVULOdj9N8orl5xNLOKpk 4JaQ5PXqz+mBPOVTbIP6YikF11m9EzTiR6+iD0Z4UVWrk0P0LJoJliXYMV729l+XhKgi cX8hUsaZnTL1BdRs83OlQht9Tbe2jTwOE+nqSmWZFLD4uZnhqb4t0jSf2Usq82iMk2aM 38KQbZsZJg2uVolEvk6JiHTGWBYQm360dXykAJeDb5+R/yJ/8FxowwaG5TToUMvmtSPx Lbdg== X-Gm-Message-State: APjAAAWmi77tHVS/QhEEhFIPDiH8tkmX5Z2hF2Jf4fGLAakAMhcNIy8/ TG2WeXFF7ULXQs70YzWYF/4bAAGJw2S5r8N7318= X-Google-Smtp-Source: APXvYqwBhRjEImrc2U/XHVUxWPk9ytBlkQ7BQFsOaIqu7bRCi6M8PirVDhheEQwMIMlgpRZ3bdo7XxsjkrO2SvbEuQA= X-Received: by 2002:a2e:6586:: with SMTP id e6mr391062ljf.115.1569262825320; Mon, 23 Sep 2019 11:20:25 -0700 (PDT) MIME-Version: 1.0 References: <83FAAC9C-A56C-43FC-BD68-5E1DB0794D7E@vigilsec.com> <31D078E7-08CD-46F5-AF97-6F2450C5934A@gmail.com> In-Reply-To: <31D078E7-08CD-46F5-AF97-6F2450C5934A@gmail.com> From: "Stanislav V. Smyshlyaev" Date: Mon, 23 Sep 2019 21:20:14 +0300 Message-ID: To: Yaron Sheffer Cc: Russ Housley , crypto-panel@irtf.org Content-Type: multipart/alternative; boundary="00000000000043345a05933c795f" Archived-At: Subject: Re: [Crypto-panel] Stage 5 of PAKE selection process X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 18:20:31 -0000 --00000000000043345a05933c795f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Russ and Yaron, The security proof reviews were intended only to provide input information for the Crypto Review Members, who are intended to provide overall reviews - thus no PAKEs were dropped in any sense. In the PAKE selection process description it is assumed that during Stage 5 overall reviews are prepared with recommendations (of any kind) - and we have an option that after overall reviews (conducted by the Crypto Review Panel members) the CFRG chairs are not able to come to a decision. In that case at IETF 106 meeting we=E2=80=99ll have a revision of the process (and = decide what to do next). In any case, after a PAKE (or two PAKEs...) is selected, the process of working on a CFRG document on Recommendations for PAKEs in IETF protocols will only start - and then all minor things (like options, parameters, implementation recommendations, etc.) can be handled. So, in my personal opinion, at the current stage we need to reflect the current understanding of pros and cons of each nominated PAKE - and then we=E2=80=99ll see whether this allows the chairs to make any decision (and = move to specifying the winning PAKE in the CFRG document, taking into account all known issues) - or continue the process of selection in some way. Best regards, Stanislav =D0=BF=D0=BD, 23 =D1=81=D0=B5=D0=BD=D1=82. 2019 =D0=B3. =D0=B2 21:03, Yaron= Sheffer : > The CPace/AuCPace paper was updated =E2=80=9Cin place=E2=80=9D (in the IA= CR ePrint repo) > since the process started. Also, Hugo hinted that OPAQUE needs to be > updated, not the base protocol but some of the options. > > > > *From: *Crypto-panel on behalf of Russ > Housley > *Date: *Monday, 23 September 2019 at 20:05 > *To: *"Stanislav V. Smyshlyaev" > *Cc: * > *Subject: *Re: [Crypto-panel] Stage 5 of PAKE selection process > > > > Stanislav: > > > > I just want to make sure that I understand. Is it correct that none of > the algorithms is being dropped or revised based on the proof analysis? > > > > Russ > > > > > > On Sep 20, 2019, at 12:23 PM, Stanislav V. Smyshlyaev > wrote: > > > > Dear Bjoern, Scott, Russ, Yaron, Tibor (and myself :) ), > > > > Many thanks again for volunteering to provide overall reviews for the > nominated PAKEs on behalf of the Crypto Review Panel. > > > > According to the PAKE selection process plan, at Stage 5 Crypto Review > Panel members write overall reviews for all candidate PAKEs, based on the > materials that have been gathered and verified. According to the plan, > Stage 5 will last until October, 30th. > > > > Those materials (including all partial reviews) have been gathered (many > thanks, Yaron!) here: https://github.com/cfrg/pake-selection > > > > Best regards, > > Stanislav, > > CFRG secretary > > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel > > > > _______________________________________________ Crypto-panel mailing list > Crypto-panel@irtf.org https://www.irtf.org/mailman/listinfo/crypto-panel > --=20 =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0=A1=D1=82=D0=B0=D0=BD=D0=B8=D1=81=D0=BB=D0=B0=D0=B2 =D0=A1=D0=BC=D1=8B= =D1=88=D0=BB=D1=8F=D0=B5=D0=B2, =D0=BA.=D1=84.-=D0=BC.=D0=BD., =D0=97=D0=B0=D0=BC=D0=B5=D1=81=D1=82=D0=B8=D1=82=D0=B5=D0=BB=D1=8C =D0=B3= =D0=B5=D0=BD=D0=B5=D1=80=D0=B0=D0=BB=D1=8C=D0=BD=D0=BE=D0=B3=D0=BE =D0=B4= =D0=B8=D1=80=D0=B5=D0=BA=D1=82=D0=BE=D1=80=D0=B0 =D0=9E=D0=9E=D0=9E =C2=AB=D0=9A=D0=A0=D0=98=D0=9F=D0=A2=D0=9E-=D0=9F=D0=A0= =D0=9E=C2=BB --00000000000043345a05933c795f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Russ and Yaron,
The security proof reviews were intended only to = provide input information for the Crypto Review Members, who are intended t= o provide overall reviews - thus no PAKEs were dropped in any sense.=C2=A0<= /div>

In the PAKE selection pr= ocess description it is assumed that during Stage 5 overall reviews are pre= pared with recommendations (of any kind) - and we have an option that after= overall reviews (conducted by the Crypto Review Panel members) the CFRG ch= airs are not able to come to a decision. In that case at IETF 106 meeting w= e=E2=80=99ll have a revision of the process (and decide what to do next).= =C2=A0

In any case, afte= r a PAKE (or two PAKEs...) is selected, the process of working on a CFRG do= cument on Recommendations for PAKEs in IETF protocols will only start - and= then all minor things (like options, parameters, implementation recommenda= tions, etc.) can be handled.

So, in my personal opinion, at the current stage we need to reflect th= e current understanding of pros and cons of each nominated PAKE - and then = we=E2=80=99ll see whether this allows the chairs to make any decision (and = move to specifying the winning PAKE in the CFRG document, taking into accou= nt all known issues) - or continue the process of selection in some way.=C2= =A0

Best regards,
<= div dir=3D"auto">Stanislav


=D0=BF=D0=BD, 23= =D1=81=D0=B5=D0=BD=D1=82. 2019 =D0=B3. =D0=B2 21:03, Yaron Sheffer <yaronf.ietf@gmail.com>:

The CPace/AuCPace paper was updated =E2=80=9Cin place=E2=80=9D (in= the IACR ePrint repo) since the process started. Also, Hugo hinted that OP= AQUE needs to be updated, not the base protocol but some of the options.=

=C2=A0

From: Crypto-panel <crypto-panel= -bounces@irtf.org> on behalf of Russ Housley <housley@vigilsec.com>
D= ate: Monday, 23 September 2019 at 20:05
To: "Stanislav V= . Smyshlyaev" <smyshsv@gmail.com>
Cc: <crypto-panel@irtf.org>
Subject:= Re: [Crypto-panel] Stage 5 of PAKE selection process

=C2=A0

Stanislav:

= =C2=A0

I just want to ma= ke sure that I understand.=C2=A0 Is it correct that none of the algorithms = is being dropped or revised based on the proof analysis?

<= /div>

=C2=A0

Russ

= =C2=A0



=

On Sep 20, 2019, at 12:23 PM, Stanislav V. Smyshlyaev <smyshsv@gmail.com>= wrote:

=C2=A0<= /p>

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

=C2=A0

Many thanks again for volunteering to provide overall reviews for th= e nominated PAKEs on behalf of the Crypto Review Panel.

=C2=A0

According to the PAKE selection process plan, at Stage 5=C2= =A0Crypto Review Panel members write overall reviews for all candidate PAKE= s, based on the materials that have been gathered and verified. According t= o the plan, Stage 5 will last until October, 30th.

<= div>

=C2=A0

Those materials (including all partial reviews) have been gathere= d (many thanks, Yaron!) here:=C2=A0https://github.com/cfrg/pake-selection<= /u>

=C2=A0

Best regards,

Stanislav,

CFRG secretary

_____________________________________________= __
Crypto-panel mailing list
Crypto-panel@irtf.org
https://www.irtf.org/= mailman/listinfo/crypto-panel

=C2=A0

_______________________________________________ Crypto-panel mailing list= Crypto-panel@ir= tf.org https://www.irtf.org/mailman/listinfo/crypto-panel =

--
<= div dir=3D"ltr">

=D0=A1 =D1=83= =D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC,

=D0=A1=D1=82=D0=B0=D0=BD=D0=B8=D1=81=D0=BB=D0=B0=D0=B2 =D0=A1= =D0=BC=D1=8B=D1=88=D0=BB=D1=8F=D0=B5=D0=B2, =D0=BA.=D1=84.-=D0=BC.=D0=BD.,<= /font>

=D0=97=D0=B0=D0=BC=D0=B5=D1=81=D1=82= =D0=B8=D1=82=D0=B5=D0=BB=D1=8C =D0=B3=D0=B5=D0=BD=D0=B5=D1=80=D0=B0=D0=BB= =D1=8C=D0=BD=D0=BE=D0=B3=D0=BE =D0=B4=D0=B8=D1=80=D0=B5=D0=BA=D1=82=D0=BE= =D1=80=D0=B0

=D0=9E=D0=9E=D0=9E =C2=AB= =D0=9A=D0=A0=D0=98=D0=9F=D0=A2=D0=9E-=D0=9F=D0=A0=D0=9E=C2=BB


--00000000000043345a05933c795f--