From nobody Mon Dec 2 00:19:12 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 8DA1412083F for ; Mon, 2 Dec 2019 00:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 f-RSUrOIDznH for ; Mon, 2 Dec 2019 00:19:06 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 09B5F12083D for ; Mon, 2 Dec 2019 00:19:06 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id d20so9153083ljc.12 for ; Mon, 02 Dec 2019 00:19:05 -0800 (PST) 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=Ld1JqXMftW0KojxEqvYn9dsw62RvrKdcOtbuwEm0hzo=; b=MXF9HmouKme6ZhLpvMURgrsIop9PYabeaA7zIIWZjYKIdSgdEAazwTblcY3ETRwjrx 3w/P6hbOU11X9o8c5unGSz08A1mc6meRzffcixGkK0vnCLyl/o5LABot9ZWyPrjF8PGe UQLO0eXtUriks8Lj2wXr+JT4T6+05L+R+ZOCQfLpjMrq5DiekfMf8PG5qS+PqqTiOp1U bWgNAuVVvnsVCCruedfdJKon+lKE5mBQtNVn14We52y95tjwc8grCqKGKf0ZdzgHK1Ti rFpuV0BYkO3QXUw9okYMbfqDwxtCasbWF0PGde42mQ4SR8FrWKH9mZ0e/FTiHohkK4sd UIGQ== 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=Ld1JqXMftW0KojxEqvYn9dsw62RvrKdcOtbuwEm0hzo=; b=oVyVSC3flkkfCfQOv8YS8r7HNtkVbhy5Sxh+DR5VS7I7quztJ5zy81HSK6m0A6HjH9 jw9G2kr33Ww4fbWvwcAEuQBj9kIqPGQjhAwen6JPOdI0CpdhUIMITWjypGBi4Nf1yqmb YJDmn/QveOPoOqQqhmPVt3JUiEowN1PhDDXwvrp3OzCO8yZrXv/T/Ii1QZbJzxJ4EIHj LynCBS9r63ieSBd/jAzga6pYNcXdg7ZgbTM1bR//VnNSvef5IiaR42YAvVURLWtT8XJd 8bgBfelQxAwvdY0QkZo728ZOq9ZrY2O6sVuoHm6BcEGBbSRZCjbj2prwcWHqB8XjLM/D 4tRw== X-Gm-Message-State: APjAAAW+LwYhL0Ea+RmX57CQCr0O1y7kbgBXWlQyLbLxTdjg3J4Uz480 2Blx0RX4C+IIyjnozzrt9F2d5MNxwmdFGU472b19OXk/ X-Google-Smtp-Source: APXvYqxk2JP8cpuBKxZPO7xmthtuwR4IKWFVzLJihPO6HCd00xqMs9FRlc03QgcL3rMtQLmBNeuei9WpH/gpXxm3yDs= X-Received: by 2002:a2e:8508:: with SMTP id j8mr44835232lji.136.1575274743226; Mon, 02 Dec 2019 00:19:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Mon, 2 Dec 2019 11:18:53 +0300 Message-ID: To: crypto-panel@irtf.org Content-Type: multipart/alternative; boundary="0000000000007e66da0598b43b85" Archived-At: Subject: [Crypto-panel] Fwd: A question to be added to the Round 2 questions list for nominated PAKEs 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, 02 Dec 2019 08:19:11 -0000 --0000000000007e66da0598b43b85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Forwarding a question for consideration during Round 2 of the PAKE selection process from Bj=C3=B6rn Haase. Regards, Stanislav ---------- Forwarded message --------- =D0=9E=D1=82: Bj=C3=B6rn Haase Date: =D0=BF=D0=BD, 2 =D0=B4=D0=B5=D0=BA. 2019 =D0=B3. =D0=B2 11:15 Subject: WG: A question to be added to the Round 2 questions list for nominated PAKEs To: Stanislav V. Smyshlyaev Dear Stanislav, Find enclosed a CC of my post to the crypto-panel mailing list. It seems that my mail did not get through the filters. Yours, Bj=C3=B6rn. Mit freundlichen Gr=C3=BC=C3=9Fen I Best Regards Dr. Bj=C3=B6rn Haase ------------------------------ Senior Expert Electronics | TGREH Electronics Hardware Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany Phone: +49 7156 209 377 | Fax: +49 7156 209 221 bjoern.haase1@endress.com | www.conducta.endress.com ------------------------------ Endress+Hauser Conducta GmbH+Co.KG Amtsgericht Stuttgart HRA 201908 Sitz der Gesellschaft: Gerlingen Pers=C3=B6nlich haftende Gesellschafterin: Endress+Hauser Conducta Verwaltungsgesellschaft mbH Sitz der Gesellschaft: Gerlingen Amtsgericht Stuttgart HRA 201929 Gesch=C3=A4ftsf=C3=BChrer: Dr. Manfred Jagiella ------------------------------ Gem=C3=A4ss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben. Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis nach. ------------------------------ Disclaimer: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such. *Von:* Bj=C3=B6rn Haase *Gesendet:* Montag, 2. Dezember 2019 09:11 *An:* crypto-panel@irtf.org *Betreff:* A question to be added to the Round 2 questions list for nominated PAKEs Dear CFRG chairs and Crypto Review Panel members, I am concerned that PAKE implementations might become hampered by patents. Specifically because it seems that exceptionally one important patent period has been recently extended by additional 3 years yielding a total duration of 23 years. (A recent patent scan has pointed out that the PAK patent U.S. Patent 7,047,408 will not expire as expected in march 2020 but only in march 2023.) Please add the following question to the list of additional questions to be asked at Round 2 of the PAKE selection process. - Can the nominators/developers of the protocols please re-evaluate possible IPR conflicts between their candidates protocols and own and foreign patents? Specifically, can you discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th of march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, expected expiration October 2026) on the free use of the RFC-drafts for OPAQUE? --0000000000007e66da0598b43b85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">
Forwardi= ng a question for consideration during Round 2 of the PAKE selection proces= s from Bj=C3=B6rn Haase.

R= egards,
Stanislav



---------- Forwarded message ---------
=D0=9E=D1= =82: Bj=C3=B6rn Haase <bjoern.haase1@endress.com>
Date: =D0=BF=D0= =BD, 2 =D0=B4=D0=B5=D0=BA. 2019 =D0=B3. =D0=B2 11:15
Subject: WG: A ques= tion to be added to the Round 2 questions list for nominated PAKEs
To: S= tanislav V. Smyshlyaev <smyshsv@gmail.com>


Dear Stanislav,

=C2=A0

Find enclosed a CC of my p= ost to the crypto-panel mailing list. It seems that my mail did not get thr= ough the filters.

=C2=A0

Yours,

=C2=A0

Bj=C3=B6rn.<= /span>

=C2=A0

Mit freundlichen Gr=C3=BC=C3=9Fen I Best Regards

Dr= . Bj=C3=B6rn Haase

Senio= r Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Conduct= a GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: +49 7= 156 209 377 | Fax: +49 7156 209 221
bjoern.haase1@endress.com | www.conducta.endress.com=

Endress+Hauser Conduct= a GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: = Gerlingen
Pers=C3=B6nlich haftende Gesellschafterin:
Endress+Hauser C= onducta
Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen<= br>Amtsgericht Stuttgart HRA 201929
Gesch=C3=A4ftsf=C3=BChrer: Dr. Manfr= ed Jagiella

Ge= m=C3=A4ss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informie= ren, wenn wir personenbezogene Daten von Ihnen erheben.

Di= eser Informationspflicht kommen wir mit folgendem Datenschutzhinweis nach.

=C2=A0

Disclaimer:

The information transmi= tted is intended only for the person or entity to which it is addressed and= may contain confidential, proprietary, and/or privileged
material. Any = review, retransmission, dissemination or other use of, or taking of any act= ion in reliance upon, this information by persons or entities
other than= the intended recipient is prohibited. If you receive this in error, please= contact the sender and delete the material from any computer.
This e-ma= il does not constitute a contract offer, a contract amendment, or an accept= ance of a contract offer unless explicitly and conspicuously designated or = stated as such.

=C2=A0

Von: Bj=C3=B6rn Haase
Gesendet: Montag, 2. Dezember 2019 09:11
An: crypt= o-panel@irtf.org
Betreff: A question to be added to the Round 2 questions list for no= minated PAKEs

=C2=A0

Dear CFRG chairs = and Crypto Review Panel members,

=C2=A0<= /u>

I am concerned th= at PAKE implementations might become hampered by patents. Specifically beca= use it seems that exceptionally one important patent period has been recently extended by ad= ditional 3 years yielding a total duration of 23 years. (A recent patent sc= an has pointed out that the PAK patent U.S. Patent 7,047,408 will not expire as expected in march 202= 0 but only in march 2023.)

=C2=A0<= /u>

=C2=A0<= /u>

Please add the fo= llowing question to the list of additional questions to be

asked at Round 2 = of the PAKE selection process.

=C2=A0

- Can the nominators/developers of the protoco= ls please re-evaluate possible IPR conflicts between their candidates proto= cols and own and foreign patents? Specifically, can you discuss the impact of U.S. Patent 7,047,408 (expected expiration 1= 0th of march 2023) on free use of SPAKE2 and the impact of EP184= 7062B1 (HMQV, expected expiration October 2026) on the free use of the RFC-= drafts for OPAQUE?

--0000000000007e66da0598b43b85-- From nobody Mon Dec 2 00:26:13 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 02A6A12023E for ; Mon, 2 Dec 2019 00:26:12 -0800 (PST) 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 wit5Mh0hPsEo for ; Mon, 2 Dec 2019 00:26:10 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 6A64E120154 for ; Mon, 2 Dec 2019 00:26:10 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id 21so7323777ljr.0 for ; Mon, 02 Dec 2019 00:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=S4/WO3dYYNHj/ey92tGrIIBDpuf0qLcneFRga3w+T7U=; b=BczNgv8NsWO4lz1SaX4NzrDyGTXQKqh8B4iM0VzzPdFNOGc8gy4NmJ23t8JdfFv83/ e+k2fKIlTlSIc+0vW5jCLCxKWEsrRdBjOc9+otcdY6kOSOR+bEBy7rYt1ZW74+cHRq1n u63c0c6pz8aaH9FMnxdWscevHwS4sZUydwc2cK9HqCUOcAl5MlCYrWc15I1MLNZ//Psp YqGoKO3WnTjUPjExyFkGeVm3DZCKVNwS3J8Umt8p2uOjEWpVMt1mKWbLK4LZbB0jedkB XrQSgRQ+YDVjCGEq0eRXOqRrhLdr4nBftrHZt3JRy2WdmXO2Sxtwgy8SdPWtlUY63aIA KLoQ== 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; bh=S4/WO3dYYNHj/ey92tGrIIBDpuf0qLcneFRga3w+T7U=; b=Y3HY0hPoU5GMutFxEHg2Nvp389Zay/ljK2VBbHhTKPprURxmiauOAA4pwBqSGPiP6B 7Q1w4Do8CLa4U2GYQqZJnNifqkkoZaTZ6jtlFfEC73yrztujPthNN19tpZWJpegjfUSj J4YZmsR6eK75Vdqbe2lp53KzqslJjZumMkbZq9XTndqVjNDS9MqHH69+eeMPQRWEuT1z c/ECD4TBAHDGNErWKBxaVUMMCwgE1Y4D6+Tv8y5Hgtl783ytkiq1orZwBVCVeAs2DbNe MzU+Th4RfntqILDlTOXNk9R2+4zzxjXYn6fJ6Lr2FVc5m/d30S8NZRcM0Li0kYTHJTh4 nioQ== X-Gm-Message-State: APjAAAXFL79blPJvDOSj1iojS+rlNTv99qrs/V5RYx8wwvEP957EmyMX JhgMCyzbCzNgEtZMCvtKjDsjB+b+Fmmihn5rSaD/xVo2yqU= X-Google-Smtp-Source: APXvYqxEmJpWTvs74m4iCXEetGol3ntr6FR5et1m8oamvqrjddGXSefjpAgnysfEXgoqKcAKkAAqxeyt0kVzUIURWXY= X-Received: by 2002:a2e:9a55:: with SMTP id k21mr40509005ljj.85.1575275168460; Mon, 02 Dec 2019 00:26:08 -0800 (PST) MIME-Version: 1.0 From: "Stanislav V. Smyshlyaev" Date: Mon, 2 Dec 2019 11:25:58 +0300 Message-ID: To: crypto-panel@irtf.org Content-Type: multipart/alternative; boundary="000000000000d6f44a0598b45443" Archived-At: Subject: [Crypto-panel] A question to be considered at Round 2 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, 02 Dec 2019 08:26:12 -0000 --000000000000d6f44a0598b45443 Content-Type: text/plain; charset="UTF-8" I would ask to add the following question to be considered during Round 2 of the PAKE selection process - the question which was discussed in the CFRG mailing list before IETF 106. To each of the remaining 4 PAKEs: - Quantum annoyance of the PAKE? - Post-quantum preparedness of the PAKE? Best regards, Stanislav --000000000000d6f44a0598b45443 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would ask to add the following= question to be considered during Round 2 of the PAKE selection process - t= he question which was discussed in the CFRG mailing list before IETF 106.

To each of the remaining 4 PAKEs:
- Quant= um annoyance of the PAKE?
- Post-quantum preparedness of the PAKE= ?

Best regards,
Stanislav
--000000000000d6f44a0598b45443-- From nobody Mon Dec 2 16:43: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 A6B9D12008F for ; Mon, 2 Dec 2019 16:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=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 Jtaov1TrEvyV for ; Mon, 2 Dec 2019 16:43:29 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 A020312001A for ; Mon, 2 Dec 2019 16:43:29 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id k1so678428pgg.12 for ; Mon, 02 Dec 2019 16:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=nl/EIvoluuWiCSjeL6xa4zYjU/M+dJWrgcflkPvTUxM=; b=k8Z22F3CFt1Iy6Qh9Q0GaFP5Ake6VbvxfqnGlXlRgB5rXRqwHo/RNfUJpTuypvYS5D xrCTchEsNex2o+w/4/H4ZKEdZAjUp4M5yQlEhQmmqcY6fJ1K1PcXyS9XUZi2DrJiFFnB QxXwTZgkOQ69AnZbke2KfXvKI5AWjZA23jQxqxfXgd7kjACcLIODcyzlZYQB8t6mMbcj Gr5fvZq/0IG1f+iqrUKPMb5i0v63w6Q7dnxb/xcOTn1zjMnpUwM+41FBTBBzXx4QMF6u 6N1yMban6hKI2E42erjrqEVM0YYJ62cXYvGD14Q5nH1BRl7wFSBdF+GrNDb9rEozsDwx JKnA== 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:message-id :thread-topic:references:in-reply-to:mime-version; bh=nl/EIvoluuWiCSjeL6xa4zYjU/M+dJWrgcflkPvTUxM=; b=Fk1d19uyhoth49F+QO/RWUA/UJTfx7atg3w8vUsCfggDco7CIiU3gN5xua1nuG9CbM 6r3MM5vs9+KRCSGugH+72JpJtWGRGil4/IiVYN4oR4y0emKvC3/e0sHiKxoQUz+n6Zdq /9hzbWk4mWZMi7P9ix9yBNgUDnkqNbAK5PbnDxM4BZU+2pmg5VyHXR9DBRnDQVJteji5 /Czg8GjZ5bJzgbAsBi8k4BroyiDIDWqrgEUZEh5br3gtzpzZ/o7AGgHYJwsWpl2pXqVM fYri4X3GprQcEzXwOEXLUDVawJKmDwUxWmmhod17wHECqAGUgGKfwb/OdK4jGSV0/ggl FMUw== X-Gm-Message-State: APjAAAXsjPVIWtpaZed+REFPj7He88kGLl+TKxby+q7VyRNezGCAjGZa Y7I764Z//WU2NDzSjksWqqA= X-Google-Smtp-Source: APXvYqzAnG/y1vuYveBcgulnpr31fONqdooKlnKtXyq2kc93yqlbVQ2RBSFutIlXW4PEg07o0zplNQ== X-Received: by 2002:a62:f94d:: with SMTP id g13mr1761759pfm.60.1575333809060; Mon, 02 Dec 2019 16:43:29 -0800 (PST) Received: from [172.28.48.96] (pub-corp-162-8.intuit.com. [207.207.162.8]) by smtp.gmail.com with ESMTPSA id a19sm708287pfn.144.2019.12.02.16.43.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Dec 2019 16:43:27 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.1f.0.191110 Date: Mon, 02 Dec 2019 16:43:27 -0800 From: Yaron Sheffer To: "Stanislav V. Smyshlyaev" , Message-ID: Thread-Topic: [Crypto-panel] A question to be considered at Round 2 References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3658149807_142803354" Archived-At: Subject: Re: [Crypto-panel] A question to be considered at Round 2 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: Tue, 03 Dec 2019 00:43:32 -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_3658149807_142803354 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Stanislav, =20 Can you please add a definition of =E2=80=9Cquantum annoyance=E2=80=9D, or let me know = if you concur with my definition: =E2=80=9Can attacker with a quantum computer nee= ds to =C2=A0=C2=A0 solve [one or more] DLP per password guess.=E2=80=9D=20 =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Crypto-panel on behalf of "Stanislav = V. Smyshlyaev" Date: Monday, December 2, 2019 at 00:26 To: Subject: [Crypto-panel] A question to be considered at Round 2 =20 I would ask to add the following question to be considered during Round 2 o= f the PAKE selection process - the question which was discussed in the CFRG = mailing list before IETF 106. =20 To each of the remaining 4 PAKEs: - Quantum annoyance of the PAKE? - Post-quantum preparedness of the PAKE? =20 Best regards, Stanislav _______________________________________________ Crypto-panel mailing list C= rypto-panel@irtf.org https://www.irtf.org/mailman/listinfo/crypto-panel=20 --B_3658149807_142803354 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Stanislav,

 

Can you please add a definition= of =E2=80=9Cquantum annoyance=E2=80=9D, or let me know if you concur with my definition= : =E2=80=9Can attacker with a quantum computer needs to

=C2=A0=C2=A0 solve [one or more] DLP per password guess.=E2=80=9D

 

Thanks,<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

From: Crypto-panel <crypto-panel-bounces@irtf.org> on behalf= of "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date= : Monday, December 2, 2019 at 00:26
To: <crypto-panel@irtf.= org>
Subject: [Crypto-panel] A question to be considered at Rou= nd 2

 

I would ask to add the followi= ng question to be considered during Round 2 of the PAKE selection process - = the question which was discussed in the CFRG mailing list before IETF 106.

 

<= p class=3DMsoNormal>To each of the remaining 4 PAKEs:

- Quantum annoyance of the PAKE?

- Post-quantum preparedness of the PAKE?

=

 

Best regards,

Stanislav

______________________= _________________________ Crypto-panel mailing list Crypto-panel@irtf.org ht= tps://www.irtf.org/mailman/listinfo/crypto-panel

--B_3658149807_142803354-- From nobody Tue Dec 3 04:24:08 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 2DEBF1200B1 for ; Tue, 3 Dec 2019 04:24:06 -0800 (PST) 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 GzDbNXXeOT0r for ; Tue, 3 Dec 2019 04:24:04 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 AAA3D12008D for ; Tue, 3 Dec 2019 04:24:03 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id m30so2759280lfp.8 for ; Tue, 03 Dec 2019 04:24:03 -0800 (PST) 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=QuOV921UNi8+AQGypEscR9eOJpgmJyFdko5/fA4pF4M=; b=KH/LcbtolA8h+cbX4kBaZpouvsQkL2Q0bseyUqo2Brz6Bnm+MazLOSaqD0CiRFVBX8 R7yC4GHJ1FixI0rADNiRm3xjnLytzQQpiMwmb4eQ5HG1QEaKIhL6L1JrYFRMedKQNYKM V5j4TvrdYCtriUAYBviufrsKO3jdScBWY9Xp842aQy6G7mqqYKgYdWzxxx3DdD58Jgvp kXBFMKKXyPigL/8PVEzCf08qIgl8Xm4u2Z8VqeUC8jI1EobjOkKENTY7fdx7kE5NqVFn 7JyY8duaRssZ5InvVz0xzfzDfowtZZNBQdWcF6vrJuwB2LQ4W+xm6efZ80sGFwN28PDm trCQ== 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=QuOV921UNi8+AQGypEscR9eOJpgmJyFdko5/fA4pF4M=; b=OMuUkQYUhaPvB07QZpIeqRdWyf+fFPgmxJwa2GbVSJoSWK7tKo1XDtiWQiL9r9NKUV iPH62JPqNmY1Swg20SMVzSStQhXhh0dnlrRuP4+K9+4YhHaWCvP/XabP2QYKt6wUYfyJ NaXx7IlBteM/ZEqfjiy2tVYjQP8WFLIz0y4BksHpsTNCrl38WMC+K5xTcjlzQDIV/BmR QPU4Onys724NX6aer7mqCcTqQstSR8gmMdbugHiBfoIiUVe0iJRe3KJVo/Bb0sXJM2Ir kIRFnSNR9SVA+WwbkbGHyqFsBSTsIBPD2elK+51nPbzZJgYgjnYMV2SEgfkPWw2fsw5Q OBpw== X-Gm-Message-State: APjAAAWSEs9Cz/C4Q9pxlrQtsgbH8652d4JUDhUm1PMe1TUp0zRPhRkK tlQDSglXNplW4uv2RxI+XSFqJRQqWz12/Vg9Wdo= X-Google-Smtp-Source: APXvYqyZwkeVk0y26amzrQHSwpTnG7CwzFixAF/IkXs0dHXntawOkMuTeReLAfYNcMNbgQqj7V9YYjTAiOuwZiP8j2M= X-Received: by 2002:ac2:48bc:: with SMTP id u28mr2470737lfg.161.1575375841608; Tue, 03 Dec 2019 04:24:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Tue, 3 Dec 2019 15:23:52 +0300 Message-ID: To: Yaron Sheffer Cc: crypto-panel@irtf.org Content-Type: multipart/alternative; boundary="0000000000006d4c360598cbc559" Archived-At: Subject: Re: [Crypto-panel] A question to be considered at Round 2 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: Tue, 03 Dec 2019 12:24:06 -0000 --0000000000006d4c360598cbc559 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Yaron, >> if you concur with my definition: =E2=80=9Can attacker with a quantum co= mputer needs to solve [one or more] DLP per password guess.=E2=80=9D I concur with this definition - maybe it is not the only one possible, but in any case the authors of the PAKEs will be able to express their extended opinion on this. Regards, Stanislav =D0=B2=D1=82, 3 =D0=B4=D0=B5=D0=BA. 2019 =D0=B3. =D0=B2 03:43, Yaron Sheffe= r : > Hi Stanislav, > > > > Can you please add a definition of =E2=80=9Cquantum annoyance=E2=80=9D, o= r let me know if > you concur with my definition: =E2=80=9Can attacker with a quantum comput= er needs to > > solve [one or more] DLP per password guess.=E2=80=9D > > > > Thanks, > > Yaron > > > > *From: *Crypto-panel on behalf of > "Stanislav V. Smyshlyaev" > *Date: *Monday, December 2, 2019 at 00:26 > *To: * > *Subject: *[Crypto-panel] A question to be considered at Round 2 > > > > I would ask to add the following question to be considered during Round 2 > of the PAKE selection process - the question which was discussed in the > CFRG mailing list before IETF 106. > > > > To each of the remaining 4 PAKEs: > > - Quantum annoyance of the PAKE? > > - Post-quantum preparedness of the PAKE? > > > > Best regards, > > Stanislav > > _______________________________________________ Crypto-panel mailing list > Crypto-panel@irtf.org https://www.irtf.org/mailman/listinfo/crypto-panel > --0000000000006d4c360598cbc559 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Yaron,

>>= if you concur with my definition: =E2=80=9Can attacker with a quantum comp= uter needs to solve [one or more] DLP per password guess.=E2=80=9D
I concur with this definition - maybe it is not the only one = possible, but in any case the authors of the PAKEs will be able to express = their extended opinion on this.

Regards,
Stanislav



=D0=B2=D1=82, 3 =D0=B4=D0=B5=D0=BA. 2019 =D0= =B3. =D0=B2 03:43, Yaron Sheffer <yaronf.ietf@gmail.com>:

Hi Stanislav,

=C2=A0

Can you= please add a definition of =E2=80=9Cquantum annoyance=E2=80=9D, or let me = know if you concur with my definition: =E2=80=9Can attacker with a quantum = computer needs to

=C2=A0=C2=A0 solv= e [one or more] DLP per password guess.=E2=80=9D

=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

=

=C2=A0

From: Crypto-panel <crypto-panel-bounces@irtf.org> on behalf of "Stanis= lav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Monday, December 2, 2019 = at 00:26
To: <crypto-panel@irtf.org>
Subject: [Crypto-panel]= A question to be considered at Round 2

=

=C2=A0

I would ask to add the following question to be consid= ered during Round 2 of the PAKE selection process - the question which was = discussed in the CFRG mailing list before IETF 106.

=

=C2=A0

To each of the remaining 4 PAKEs:

- Quantum annoyance of the PAKE?

- Post-quantum preparedness of the PAKE?

=C2=A0

Best regards,

Stanislav

_______________________________________________ Crypto-p= anel mailing list Crypto-panel@irtf.org https://www.irtf.org/mailman/listinfo/cry= pto-panel

--0000000000006d4c360598cbc559-- From nobody Mon Dec 9 04:43:56 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 C99711200B2; Mon, 9 Dec 2019 04:43:48 -0800 (PST) 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 OsasMILBesRN; Mon, 9 Dec 2019 04:43:46 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 7A93E1200A3; Mon, 9 Dec 2019 04:43:46 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id m6so15481871ljc.1; Mon, 09 Dec 2019 04:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=rBKBWRmB9COCgC9f9itgS49xL1WrnnP0XA/+ERgoX1M=; b=EaMdu4+Csta2ZTBq12383ouoNMnCsifnWRgr6orjoMymJBl2w4UUFjrs6PGgaATtPj f4QD0DXIT0fukszWX1dXqRc74JaXMsAVgVDfHeGfl+8vicyABlMtFmg7Mi0AauUGmdlv 780QfKKrgKwNf6jvNjLVmb+G1j7i0+396XdTuYMH/eFs+VXu1kbSnUpl3QUAji0oVA7g urH2C1GEx6dIUUy2ZTSUHRz/SdhHWmkulIuAxSlDPkXoqjn60BBu7boretuR9sE/om+T 9RVWxETEj1bWjMhlUZguKS6det5Xmt8okIWTa8ZKLPphX8ObPCwoKfd9ITXd4rcPJ5U5 6O/w== 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; bh=rBKBWRmB9COCgC9f9itgS49xL1WrnnP0XA/+ERgoX1M=; b=pEJsIiK9fybbHoUuryi1Q7MEV+OCVL9D8rSb7B+EH125v7HNzbKaI4J+GpN7O9n4kH Pdu3ez2l/aH6X71Kne9pW0i5qj0ENPLVC2yXtpxfb+8KpCCX9h8TJsak6+PYjD2g9DRy g5n9JzwJEWOnUQ6zEWRUZvg0QcMoO25Tc24N+A5cQNedbq7zS170ofWDfGVaahjJy9RR KFOx6dZ5er2RJbR0uV33uh6NfvCfVlJzmUVlN/nbsWfFrx3aaL+YOtjRBWwPyYQTqMZ4 QSv0WjEJL86BdiIJhJUudbqHmRqHNa191zXqhhanrlz2AuhvZs2w1Gck2d4dKzWFY1P/ Yj9w== X-Gm-Message-State: APjAAAXS48N2A0o4bojZA3LL7eUE9Yo5nUECPhV7ZC9ap7KXujAZx7mn B3KWKHXeoGpM6LnW4wBJA4N/+p8wEimi4NSZAvogvTg2 X-Google-Smtp-Source: APXvYqzCWwdM3rTcDuymDSk8RzXAVu9aRYs6EHJ4lcEkhoucCogMlrRmB1AATbwDfZatCcHgKM2M3Bww8/D6B7RRg4U= X-Received: by 2002:a2e:859a:: with SMTP id b26mr16724845lji.137.1575895424215; Mon, 09 Dec 2019 04:43:44 -0800 (PST) MIME-Version: 1.0 From: "Stanislav V. Smyshlyaev" Date: Mon, 9 Dec 2019 15:43:35 +0300 Message-ID: To: CFRG , crypto-panel@irtf.org Content-Type: multipart/alternative; boundary="000000000000f6aea3059944be4a" Archived-At: Subject: [Crypto-panel] PAKE Selection Process: Round 2, Stage 2 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, 09 Dec 2019 12:43:49 -0000 --000000000000f6aea3059944be4a Content-Type: text/plain; charset="UTF-8" Dear CFRG, According to the plan of Round 2 of the PAKE selection process, additional questions for all four remaining candidates have been collected from CFRG participants (and Crypto Review Panel members) via crypto-panel@irtf.org . We've obtained the following list of questions: 1) (to SPAKE2): Can you propose a modification of SPAKE2 (preserving all existing good properties of PAKE2) with a correspondingly updated security proof, addressing the issue of a single discrete log relationship necessary for the security of all sessions (e.g., solution based on using M=hash2curve(A|B), N=hash2curve(B|A))? 2) (to CPace and AuCPace): Can you propose a modification of CPace and AuCPace (preserving all existing good properties of these PAKEs) with a correspondingly updated security proof (maybe, in some other security models), addressing the issue of requiring the establishment of a session identifier (sid) during each call of the protocol for the cost of one additional message? 3) (to all 4 remaining PAKEs) : Can the nominators/developers of the protocols please re-evaluate possible IPR conflicts between their candidates protocols and own and foreign patents? Specifically, can you discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th of march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, expected expiration October 2026) on the free use of the RFC-drafts for OPAQUE? 4) (to all 4 remaining PAKEs) What can be said about the property of "quantum annoyance" (an attacker with a quantum computer needs to solve [one or more] DLP per password guess) of the PAKE? 5) (to all 4 remaining PAKEs) What can be said about "post-quantum preparedness" of the PAKE? Please let the chairs and the Crypto Review Panel members know (before December, 17th) if any questions (collected via crypto-panel@irtf.org) have been lost or misinterpreted (or something needs to be added). Best regards, Stanislav, CFRG Secretary --000000000000f6aea3059944be4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear CFRG,

According to the pla= n of Round 2 of the PAKE selection process, additional questions for all fo= ur remaining candidates have been collected from CFRG participants (and Cry= pto Review Panel members) via cryp= to-panel@irtf.org .

We've obtained the fol= lowing list of questions:
1) (to SPAKE2): Can you propose a modif= ication of SPAKE2 (preserving all existing good properties of PAKE2) with a= correspondingly updated security proof, addressing the issue of a single d= iscrete log relationship necessary for the security of all sessions (e.g., = solution based on using M=3Dhash2curve(A|B), N=3Dhash2curve(B|A))?
2) = (to CPace and AuCPace): Can you propose a modification of CPace and AuCPace= (preserving all existing good properties of these PAKEs) with a correspond= ingly updated security proof (maybe, in some other security models), addres= sing the issue of requiring the establishment of a session identifier (sid)= during each call of the protocol for the cost of one additional message?
3)=20 (to all 4 remaining PAKEs) : Can the nominators/developers of the protocols please re-evaluate possibl= e IPR conflicts between their candidates protocols and own and foreign pate= nts? Specifically, can you discuss the impact of U.S. Patent 7,047,408 (exp= ected expiration 10th of march 2023) on free use of SPAKE2 and the impact o= f EP1847062B1 (HMQV, expected expiration October 2026) on the free use of t= he RFC-drafts for OPAQUE?
4) (to all 4 remaining = PAKEs) What can be said about the property of "quantum annoyance"= (an attacker with a quantum computer needs to solve [one or more] DLP per = password guess) of the PAKE?
5)=20 (to all 4 remaining PAKEs)=20 What can be said about "post-quantum preparedness" of the PAKE?

Please let the chairs and the = Crypto Review Panel members know (before December, 17th) if any questions (= collected via=C2=A0 crypto-panel@irtf.org) have be= en lost or misinterpreted (or something needs to be added).

<= /div>
Best regards,
Stanislav,
CFRG Secretary
=
--000000000000f6aea3059944be4a-- From nobody Mon Dec 9 07:41:39 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 1FEBE1200D5; Mon, 9 Dec 2019 07:41:34 -0800 (PST) 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 6lEwdp8kdi1R; Mon, 9 Dec 2019 07:41:32 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 8EBE11200B6; Mon, 9 Dec 2019 07:41:31 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id u17so16175166lja.4; Mon, 09 Dec 2019 07:41:31 -0800 (PST) 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=/Z2IwcRfTn6aIbFhGGY8LKnGZtzPbn4tsiXBiXA2Il4=; b=jNTlpKcy2BFqjEuUDe8iYUK6aQnHVyZrmdnnxScLCM2w8B7FdhfWqFPa8+xBdHkY9x zm5ZCfh8MjdyiNjnz75mZfvIP36ONMpHuqKkZ02CjIEE4ScVvvbIS/5CDtGLlv5G9C4Y tQG95vLfB1TskFUccm2tgG4V5BxutkPHyt8N4ZBT73xdlndBaGA08fqAgWdyxp6YWvj1 RVzSycRT3ad4VZeX3ecl1YfhyjRkToG0SV7mTj020shYWKA95q0/nbdRtm7svotNFTOf Sue3Fxkra9d4qMzbe2PAUIdmRvzjzVq7dAG1sNMcYfcKSFRLjouyZNMl2BNfWYd66fIm bXBA== 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=/Z2IwcRfTn6aIbFhGGY8LKnGZtzPbn4tsiXBiXA2Il4=; b=OR17dhhbew2nRHwZJPM0BJTbIHAhqgfZ2g0Mfuru0z6zFBPkrjOesPuvaSsXYd32dP eSdQXzUB8aYcpyIpG4ljwTObQZ2ilOqcVZwoQXzPW0X3mmevWfqfJz9sW4oNw6+W7w5A NbJ4DtpGLbJAKyn9RTiy2natMIwFWIji+GY2YvKWl4Gz+ok2GZFZFXOLsJuJb6Njahyc vI1HGsMr5GF8pSJEOc2fhJOTHOeD6ks/8ghU/vomYsC+uI9cPljA6jvk3IQJs6YV0Ak/ MhsapUO3pNNtdGsZsm0fAAE6fuOykwYuNlCa/+/E+TNn8mlB3y0AGz07nELA8YDW8x1A 1RqA== X-Gm-Message-State: APjAAAXyWmTL/b2jgkjhEWOpqJbSNnXLT0gsrbrE44iSVRfRV4q5MhTH 7FftFBUL2RQtcik7vzf6LBMpyiEyrcjcJdcbEKM= X-Google-Smtp-Source: APXvYqyhyFdmLYFNA2PAsyH3smLjcviK2c9U/CTBoNnjixNLNKAqP1V+XZnz+gFZkcsE4RxZl1ctJvhCgozzQ+kvfAY= X-Received: by 2002:a2e:80cc:: with SMTP id r12mr3890014ljg.154.1575906089742; Mon, 09 Dec 2019 07:41:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Watson Ladd Date: Mon, 9 Dec 2019 07:41:17 -0800 Message-ID: To: "Stanislav V. Smyshlyaev" Cc: CFRG , crypto-panel@irtf.org Content-Type: multipart/alternative; boundary="000000000000adb6b20599473ad4" Archived-At: Subject: Re: [Crypto-panel] [Cfrg] PAKE Selection Process: Round 2, Stage 2 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, 09 Dec 2019 15:41:34 -0000 --000000000000adb6b20599473ad4 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 9, 2019 at 4:44 AM Stanislav V. Smyshlyaev wrote: > Dear CFRG, > > According to the plan of Round 2 of the PAKE selection process, additional > questions for all four remaining candidates have been collected from CFRG > participants (and Crypto Review Panel members) via crypto-panel@irtf.org . > > We've obtained the following list of questions: > 1) (to SPAKE2): Can you propose a modification of SPAKE2 (preserving all > existing good properties of PAKE2) with a correspondingly updated security > proof, addressing the issue of a single discrete log relationship necessary > for the security of all sessions (e.g., solution based on using > M=hash2curve(A|B), N=hash2curve(B|A))? > Yes: See https://github.com/kaduk/spake2/pull/10 and for the security proof, https://eprint.iacr.org/2019/1194. I'll submit it shortly, but this should indicate where we are going. 2) (to CPace and AuCPace): Can you propose a modification of CPace and > AuCPace (preserving all existing good properties of these PAKEs) with a > correspondingly updated security proof (maybe, in some other security > models), addressing the issue of requiring the establishment of a session > identifier (sid) during each call of the protocol for the cost of one > additional message? > 3) (to all 4 remaining PAKEs) : Can the nominators/developers of the > protocols please re-evaluate possible IPR conflicts between their > candidates protocols and own and foreign patents? Specifically, can you > discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th of > march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, > expected expiration October 2026) on the free use of the RFC-drafts for > OPAQUE? > I'm not a patent lawyer, or any kind of lawyer. This sounds like a question for a patent lawyer, rather then uninformed speculation on the list. 4) (to all 4 remaining PAKEs) What can be said about the property of > "quantum annoyance" (an attacker with a quantum computer needs to solve > [one or more] DLP per password guess) of the PAKE? > I'll have to look at the papers some more. Will answer in a few days. 5) (to all 4 remaining PAKEs) What can be said about "post-quantum > preparedness" of the PAKE? > There isn't a great answer here for SPAKE2 AKAIK. Postquantum primitives don't smoothly translate point addition or group laws. > Please let the chairs and the Crypto Review Panel members know (before > December, 17th) if any questions (collected via crypto-panel@irtf.org) > have been lost or misinterpreted (or something needs to be added). > > Best regards, > Stanislav, > CFRG Secretary > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --000000000000adb6b20599473ad4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 9, 2019= at 4:44 AM Stanislav V. Smyshlyaev <smyshsv@gmail.com> wrote:
=
Dear CFRG,

According to the plan of = Round 2 of the PAKE selection process, additional questions for all four re= maining candidates have been collected from CFRG participants (and Crypto R= eview Panel members) via crypto-panel@irtf.org .

We've obtained the following list of questions:
1) (to = SPAKE2): Can you propose a modification of SPAKE2 (preserving all existing = good properties of PAKE2) with a correspondingly updated security proof, ad= dressing the issue of a single discrete log relationship necessary for the = security of all sessions (e.g., solution based on using M=3Dhash2curve(A|B)= , N=3Dhash2curve(B|A))?

Yes: See https://github.com/kaduk/spak= e2/pull/10 and for the security proof,=C2=A0 https://eprint.iac= r.org/2019/1194. I'll submit it shortly, but this should indicate w= here we are going.

2) (to CPace and AuCPace): Can= you propose a modification of CPace and AuCPace (preserving all existing g= ood properties of these PAKEs) with a correspondingly updated security proo= f (maybe, in some other security models), addressing the issue of requiring= the establishment of a session identifier (sid) during each call of the pr= otocol for the cost of one additional message?
3)=20 (to all 4 remaining PAKEs) : Can the nominators/developers of the protocols please re-evaluate possibl= e IPR conflicts between their candidates protocols and own and foreign pate= nts? Specifically, can you discuss the impact of U.S. Patent 7,047,408 (exp= ected expiration 10th of march 2023) on free use of SPAKE2 and the impact o= f EP1847062B1 (HMQV, expected expiration October 2026) on the free use of t= he RFC-drafts for OPAQUE?

I'm not a patent lawyer, or any kind of lawyer. = This sounds like a question for a patent lawyer, rather then uninformed spe= culation on the list.

4) = (to all 4 remaining PAKEs) What can be said about the property of "qua= ntum annoyance" (an attacker with a quantum computer needs to solve [o= ne or more] DLP per password guess) of the PAKE?

I'll have to look at the papers some more. Will answer in a few da= ys.

5)=20 (to all 4 remaining PAKEs)=20 What can be said about "post-quantum preparedness" of the PAKE?

There isn't a great answer here for S= PAKE2 AKAIK. Postquantum primitives don't smoothly translate point addi= tion or group laws.


Please= let the chairs and the Crypto Review Panel members know (before December, = 17th) if any questions (collected via=C2=A0 crypto-panel@irtf.org) have been lost or misinterpreted (or somethin= g needs to be added).

Best regards,
Stan= islav,
CFRG Secretary
_______________________________________________
Cfrg mailing list
Cfrg@= irtf.org
https://www.irtf.org/mailman/listinfo/cfrg<= br>
--000000000000adb6b20599473ad4-- From nobody Mon Dec 9 07:45:38 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 688CB120866; Mon, 9 Dec 2019 07:45:36 -0800 (PST) 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 ueA-NPIoA-a7; Mon, 9 Dec 2019 07:45:34 -0800 (PST) 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 B7F45120828; Mon, 9 Dec 2019 07:45:33 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id d20so16133262ljc.12; Mon, 09 Dec 2019 07:45:33 -0800 (PST) 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=hHH9ivuuaopxSe/q/0VqYBC+yrvvh/tjpckSULUIAA4=; b=ZgEkPs79cxmI24BVcM9zV+Jnh6Rf/E9lvfh40ZnDUA9sTQxrFbw3ZCtzRklOLnWRUq knYzT+ueFPUYv8j5ccrN80TYBXcnW0SyjVJYVti4/oUXDIiaMSxQapcICf9rBvQaFiib bZL/kczXg+bsx1IcDb7jl65JTxEbbR5TF9/fHjSNheDp8jdsOFazHDvuZlf19AjOSyIe oWhGIs3Q7LFLALCYZpUHZysuprvMHR4Mj4rKKJsS7YTfU51EasTN0H7BVEi5K9Sj2s5X Ye4ZkifqJ+gJvx0zljesxvYCKy73PNQZXXRV7i4nNW3eYkASQ7xY13uJeDgm1xpyleem fHyg== 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=hHH9ivuuaopxSe/q/0VqYBC+yrvvh/tjpckSULUIAA4=; b=YH5RrA/Fg9EynHqrUGSVM0dsRDFMyjVuHFTUaOIXVJyENqRzKjlshHJlqNA8GQ1dJj S1G/QuM+2crdsLu3bRqylODnIrSMqZjT3hQHw5T6p2+GisbGZtJ28CPQf2oiGT59wBZ5 nAuA+EEqaDn86QTIsOVkXdVxvjv48LEkRaXJO6qOjiR4jxYtVlHUUlSPnPq2TeyOvS18 hzONutXR6hOjpPGS9sl9X/2fOHSdkJrQ7srVlJFaX458h8FMnj9Ng54l4ZOvhW89gjVt KvF+HHVD7fXHF5Xke87AtXAtEkufwkIrRCYVA/l5FIPXQ4xWYppl0gskw0xQHWb0wA2m iTAA== X-Gm-Message-State: APjAAAUuE9/Ji3C6Ma9IXOLarAxkruuV6LssHwSo+SNsGe8wu7TaQ4jw 2sgpkMnRcvrFdvVjD3mWOwUw1T6hAZnwKnlMP60= X-Google-Smtp-Source: APXvYqy9yt2EQbn0f1bipoNQfZPNok1qGJU8SMWovh0iTDGDeboiycZSbthl/tsrrQIxmso1/PmxayESmlRfEeRELRk= X-Received: by 2002:a05:651c:152:: with SMTP id c18mr17116538ljd.146.1575906331930; Mon, 09 Dec 2019 07:45:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Mon, 9 Dec 2019 18:45:23 +0300 Message-ID: To: Watson Ladd Cc: CFRG , crypto-panel@irtf.org Content-Type: multipart/alternative; boundary="0000000000001d324e05994749e9" Archived-At: Subject: Re: [Crypto-panel] [Cfrg] PAKE Selection Process: Round 2, Stage 2 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, 09 Dec 2019 15:45:36 -0000 --0000000000001d324e05994749e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Watson, Thanks, but we're still collecting the questions, the authors (including you for SPAKE2) will have time at Stage 3 (December 25th - February, 10th) to prepare the replies (Stage 3: "The authors of the candidates prepare their replies to the additional questions/requested clarifications."). =D0=BF=D0=BD, 9 =D0=B4=D0=B5=D0=BA. 2019 =D0=B3. =D0=B2 18:41, Watson Ladd = : > > > On Mon, Dec 9, 2019 at 4:44 AM Stanislav V. Smyshlyaev > wrote: > >> Dear CFRG, >> >> According to the plan of Round 2 of the PAKE selection process, >> additional questions for all four remaining candidates have been collect= ed >> from CFRG participants (and Crypto Review Panel members) via >> crypto-panel@irtf.org . >> >> We've obtained the following list of questions: >> 1) (to SPAKE2): Can you propose a modification of SPAKE2 (preserving all >> existing good properties of PAKE2) with a correspondingly updated securi= ty >> proof, addressing the issue of a single discrete log relationship necess= ary >> for the security of all sessions (e.g., solution based on using >> M=3Dhash2curve(A|B), N=3Dhash2curve(B|A))? >> > > Yes: See https://github.com/kaduk/spake2/pull/10 and for the security > proof, https://eprint.iacr.org/2019/1194. I'll submit it shortly, but > this should indicate where we are going. > > 2) (to CPace and AuCPace): Can you propose a modification of CPace and >> AuCPace (preserving all existing good properties of these PAKEs) with a >> correspondingly updated security proof (maybe, in some other security >> models), addressing the issue of requiring the establishment of a sessio= n >> identifier (sid) during each call of the protocol for the cost of one >> additional message? >> 3) (to all 4 remaining PAKEs) : Can the nominators/developers of the >> protocols please re-evaluate possible IPR conflicts between their >> candidates protocols and own and foreign patents? Specifically, can you >> discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th of >> march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, >> expected expiration October 2026) on the free use of the RFC-drafts for >> OPAQUE? >> > > I'm not a patent lawyer, or any kind of lawyer. This sounds like a > question for a patent lawyer, rather then uninformed speculation on the > list. > > 4) (to all 4 remaining PAKEs) What can be said about the property of >> "quantum annoyance" (an attacker with a quantum computer needs to solve >> [one or more] DLP per password guess) of the PAKE? >> > > I'll have to look at the papers some more. Will answer in a few days. > > 5) (to all 4 remaining PAKEs) What can be said about "post-quantum >> preparedness" of the PAKE? >> > > There isn't a great answer here for SPAKE2 AKAIK. Postquantum primitives > don't smoothly translate point addition or group laws. > > >> Please let the chairs and the Crypto Review Panel members know (before >> December, 17th) if any questions (collected via crypto-panel@irtf.org) >> have been lost or misinterpreted (or something needs to be added). >> >> Best regards, >> Stanislav, >> CFRG Secretary >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> > --0000000000001d324e05994749e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Watson,

Thanks, but we're still collecting the questions, the authors= (including you for SPAKE2) will have time at Stage 3 (December 25th - Febr= uary, 10th) to prepare the replies (Stage 3: "The authors of the candi= dates prepare their replies to the additional questions/requested clarifica= tions.").

=

=D0=BF=D0=BD, 9 =D0=B4=D0=B5=D0=BA. 2019 =D0=B3. =D0=B2 18:41, Watson L= add <watsonbladd@gmail.com&= gt;:


On Mon, Dec 9, 2019 at 4:44 AM= Stanislav V. Smyshlyaev <smyshsv@gmail.com> wrote:
Dear CFRG,

According to the plan of Round 2 of t= he PAKE selection process, additional questions for all four remaining cand= idates have been collected from CFRG participants (and Crypto Review Panel = members) via crypto-panel@irtf.org .

We'= ;ve obtained the following list of questions:
1) (to SPAKE2): Can= you propose a modification of SPAKE2 (preserving all existing good propert= ies of PAKE2) with a correspondingly updated security proof, addressing the= issue of a single discrete log relationship necessary for the security of = all sessions (e.g., solution based on using M=3Dhash2curve(A|B), N=3Dhash2c= urve(B|A))?

=
Yes: See https://github.com/kaduk/spake2/pull/10 and for the security proof,=C2=A0 https://eprint.iacr.org/2019/1= 194. I'll submit it shortly, but this should indicate where we are = going.

<= div dir=3D"ltr">
2) (to CPace and AuCPace): Can you propose= a modification of CPace and AuCPace (preserving all existing good properti= es of these PAKEs) with a correspondingly updated security proof (maybe, in= some other security models), addressing the issue of requiring the establi= shment of a session identifier (sid) during each call of the protocol for t= he cost of one additional message?
3)=20 (to all 4 remaining PAKEs) : Can the nominators/developers of the protocols please re-evaluate possibl= e IPR conflicts between their candidates protocols and own and foreign pate= nts? Specifically, can you discuss the impact of U.S. Patent 7,047,408 (exp= ected expiration 10th of march 2023) on free use of SPAKE2 and the impact o= f EP1847062B1 (HMQV, expected expiration October 2026) on the free use of t= he RFC-drafts for OPAQUE?

I'm not a patent lawyer, or any kind of lawyer. = This sounds like a question for a patent lawyer, rather then uninformed spe= culation on the list.

4) = (to all 4 remaining PAKEs) What can be said about the property of "qua= ntum annoyance" (an attacker with a quantum computer needs to solve [o= ne or more] DLP per password guess) of the PAKE?

I'll have to look at the papers some more. Will answer in a few da= ys.

5)=20 (to all 4 remaining PAKEs)=20 What can be said about "post-quantum preparedness" of the PAKE?

There isn't a great answer here for S= PAKE2 AKAIK. Postquantum primitives don't smoothly translate point addi= tion or group laws.


Please= let the chairs and the Crypto Review Panel members know (before December, = 17th) if any questions (collected via=C2=A0 crypto-panel@irtf.org) have been lost or misinterpreted (or somethin= g needs to be added).

Best regards,
Stan= islav,
CFRG Secretary
_______________________________________________
Cfrg mailing list
Cfrg@= irtf.org
https://www.irtf.org/mailman/listinfo/cfrg<= br>
--0000000000001d324e05994749e9-- From nobody Wed Dec 18 07:28:24 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 A03E41207FD for ; Wed, 18 Dec 2019 07:28:23 -0800 (PST) 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=unavailable 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 ioB-uNw03y8r for ; Wed, 18 Dec 2019 07:28:21 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 BC94D120274 for ; Wed, 18 Dec 2019 07:28:20 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id k1so1952940ljg.1 for ; Wed, 18 Dec 2019 07:28:20 -0800 (PST) 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=I6VpCm+w8+qcgWfYoCmcV1vpIKkppb7dDDS5+UfO4Nk=; b=Tr3hGG3uvZQIXZN+KyiScipRp8xSihpHh8KMUarYtlLGy8Kk5/uBZfFxl2gsKzeafC LSLcAE/KWHejXh+lkNHDlsqXUQAVOsRcXzxgC/XYw2w+ZaziOrKyqaik3bUitz1IqcUK 2d3D3PWVLTxtlFg9EpwcmRsx2p1BvlPh+mXQL31MA0KrGKV7s568X1jW2si0tYG92Idi yCMXVOHVKnQAU2WYNP9KXeI7xH7+SjrmrrQ/C2ZZlpVFYpouJ72pJdaaQD23Z+GcjWjK bnMM1mt+sXi7Rf69iVHcxXWmWaoZ6sWf1gro9OByEqiq4WLPq4/Q+DNn+Z+U1TxEeVRy pb7w== 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=I6VpCm+w8+qcgWfYoCmcV1vpIKkppb7dDDS5+UfO4Nk=; b=oe2d2QY8BEZPaEFutGpPJ+KPtWnvDgx9PPFUx9eiRnMD2w81bFeBrgweX1VzBLR0kd W5ReLltM5/+TlbHDA2HIDLxge+pUTUeZWCwB03RrirkyjfZD0ugV3sLj2enQ4hxcznFt u/5H5VjJp9jFust7m80cR8cSV42dpoX9pRn+uK66jl8BvcUZNN2ynI5bg/APN1If0Yxh YuePhkk7esFvNNilA4b8fdM+VyEGMDKIAAWU4ffLV2h/lEYIpBjP1y5OXEz5aA7PODmo wsxByTkGXhj4aPn8WxOwin7ZAbjjvzn79/jjRip1vA3AEeYimPLiB7svcIPzS5vKRwsv osfA== X-Gm-Message-State: APjAAAUHiGjLsHQFx6tRMsbvYVP7KhnvN1506+A2WDahdC7wE6ZyncAf 4lAfq1Tg+0wMQqpN3JJtliY7qnHNF6aLI+/pjEM= X-Google-Smtp-Source: APXvYqwOiSz+lu8bsnLssodzVkvxgCyJ3t7fq7ibMpsbEZYR99iam+Wi8ilmJh3cHCHyNHbVvJFRkK/UOgeCP4kfPaI= X-Received: by 2002:a2e:2a86:: with SMTP id q128mr2246956ljq.241.1576682898623; Wed, 18 Dec 2019 07:28:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Wed, 18 Dec 2019 18:28:11 +0300 Message-ID: To: Watson Ladd , Hugo Krawczyk , Hugo Krawczyk , =?UTF-8?B?QmrDtnJuIEhhYXNl?= , =?UTF-8?B?QmrDtnJuIEhhYXNl?= , Benjamin Kaduk Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000001891ad0599fc184c" Archived-At: Subject: Re: [Crypto-panel] PAKE Selection Process: Round 2, Stage 2 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: Wed, 18 Dec 2019 15:28:24 -0000 --0000000000001891ad0599fc184c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Watson and Ben, Hugo, Bj=C3=B6rn, Now we're at Stage 3 of the second round of the PAKE selection process. Please provide your replies for the questions (related to your PAKEs) for Round 2 listed at https://github.com/cfrg/pake-selection#questions-for-round-2. Please do that until February, 10th and send your replies to crypto-panel@irtf.org. I believe that it will be good if you make your answers detailed enough, so that there won't be many additional clarifying questions from the reviewers= . Best regards, Stanislav, CFRG Secretary =D0=BF=D0=BD, 9 =D0=B4=D0=B5=D0=BA. 2019 =D0=B3. =D0=B2 15:43, Stanislav V.= Smyshlyaev : > Dear CFRG, > > According to the plan of Round 2 of the PAKE selection process, additiona= l > questions for all four remaining candidates have been collected from CFRG > participants (and Crypto Review Panel members) via crypto-panel@irtf.org = . > > We've obtained the following list of questions: > 1) (to SPAKE2): Can you propose a modification of SPAKE2 (preserving all > existing good properties of PAKE2) with a correspondingly updated securit= y > proof, addressing the issue of a single discrete log relationship necessa= ry > for the security of all sessions (e.g., solution based on using > M=3Dhash2curve(A|B), N=3Dhash2curve(B|A))? > 2) (to CPace and AuCPace): Can you propose a modification of CPace and > AuCPace (preserving all existing good properties of these PAKEs) with a > correspondingly updated security proof (maybe, in some other security > models), addressing the issue of requiring the establishment of a session > identifier (sid) during each call of the protocol for the cost of one > additional message? > 3) (to all 4 remaining PAKEs) : Can the nominators/developers of the > protocols please re-evaluate possible IPR conflicts between their > candidates protocols and own and foreign patents? Specifically, can you > discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th of > march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, > expected expiration October 2026) on the free use of the RFC-drafts for > OPAQUE? > 4) (to all 4 remaining PAKEs) What can be said about the property of > "quantum annoyance" (an attacker with a quantum computer needs to solve > [one or more] DLP per password guess) of the PAKE? > 5) (to all 4 remaining PAKEs) What can be said about "post-quantum > preparedness" of the PAKE? > > Please let the chairs and the Crypto Review Panel members know (before > December, 17th) if any questions (collected via crypto-panel@irtf.org) > have been lost or misinterpreted (or something needs to be added). > > Best regards, > Stanislav, > CFRG Secretary > --0000000000001891ad0599fc184c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">
Dea= r Watson and Ben, Hugo, Bj=C3=B6rn,

Now we'= ;re at Stage 3 of the second round of the PAKE selection process.
=
Please provide your replies for the questions (related to your PAKEs)= for Round 2 listed at=C2=A0https://github.com/cfrg/pake-se= lection#questions-for-round-2. Please do that=C2=A0until=C2=A0February,= 10th and send your replies to cry= pto-panel@irtf.org.

I believe that it will be = good if you make your answers detailed enough, so that there won't be m= any additional clarifying questions from the reviewers.

<= /div>
Best regards,
Stanislav,
CFRG Secretary
=



=
=D0= =BF=D0=BD, 9 =D0=B4=D0=B5=D0=BA. 2019 =D0=B3. =D0=B2 15:43, Stanislav V. Sm= yshlyaev <smyshsv= @gmail.com>:
Dear CFRG,

Acc= ording to the plan of Round 2 of the PAKE selection process, additional que= stions for all four remaining candidates have been collected from CFRG part= icipants (and Crypto Review Panel members) via crypto-panel@irtf.org .

We've obtained the following list of questions:
1) (= to SPAKE2): Can you propose a modification of SPAKE2 (preserving all existi= ng good properties of PAKE2) with a correspondingly updated security proof,= addressing the issue of a single discrete log relationship necessary for t= he security of all sessions (e.g., solution based on using M=3Dhash2curve(A= |B), N=3Dhash2curve(B|A))?
2) (to CPace and AuCPace): Can you propose = a modification of CPace and AuCPace (preserving all existing good propertie= s of these PAKEs) with a correspondingly updated security proof (maybe, in = some other security models), addressing the issue of requiring the establis= hment of a session identifier (sid) during each call of the protocol for th= e cost of one additional message?
3)=20 (to all 4 remaining PAKEs) : Can the nominators/developers of the protocols please re-evaluate possibl= e IPR conflicts between their candidates protocols and own and foreign pate= nts? Specifically, can you discuss the impact of U.S. Patent 7,047,408 (exp= ected expiration 10th of march 2023) on free use of SPAKE2 and the impact o= f EP1847062B1 (HMQV, expected expiration October 2026) on the free use of t= he RFC-drafts for OPAQUE?
4) (to all 4 remaining = PAKEs) What can be said about the property of "quantum annoyance"= (an attacker with a quantum computer needs to solve [one or more] DLP per = password guess) of the PAKE?
5)=20 (to all 4 remaining PAKEs)=20 What can be said about "post-quantum preparedness" of the PAKE?

Please let the chairs and the = Crypto Review Panel members know (before December, 17th) if any questions (= collected via=C2=A0 crypto-panel@irt= f.org) have been lost or misinterpreted (or something needs to be added= ).

Best regards,
Stanislav,
CF= RG Secretary
--0000000000001891ad0599fc184c-- From nobody Fri Dec 20 17:24:02 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 670AD1209F1; Fri, 20 Dec 2019 17:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 xcDnX28Us3ip; Fri, 20 Dec 2019 17:23:53 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636C81209EE; Fri, 20 Dec 2019 17:23:53 -0800 (PST) Received: from oxuslxaltgw05.schlund.de ([10.72.76.61]) by mrelay.perfora.net (mreueus001 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Mgv3O-1iMOH92nyK-00M6FF; Sat, 21 Dec 2019 02:23:51 +0100 Date: Fri, 20 Dec 2019 19:23:51 -0600 (CST) From: steve@tobtu.com To: CFRG , crypto-panel@irtf.org Message-ID: <355650937.279614.1576891431019@email.ionos.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.1-Rev25 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:bZwU+75G4cXj70VxqGaBoNGiFOVGzptElSqjBdBNDRzmqwlWDU+ +5sPsgubE52No5fLXi3Opth8EsjMl3KXo95d6ocw2q9RZv+OryThvPf0CpRWJlSPn3gHQfc wyWT/ahyGuINagLZwqnqj8EYCYAIGuO9pcpLdVvS78s2hx2yoF1Z4WM+H/rjHzemFbVTw8n VBVcMvAFL8hY00TTyclSA== X-UI-Out-Filterresults: notjunk:1;V03:K0:cC8//Nbp4dI=:D0UTYNbe7D4OXT9tDF7NyN KIVg/bnfAOrGFvAHrIhCM98Ji/IySFFqZ0ys3ti9r/uEro4ZuQrSQDd87GDXO1RfBN1yfobGh zFZUb9XMq+vBt2EGMiFsOOFi+QC+s/ZL4RlopBvbHgvctZK3FQpJIoQ9RR6cvlKoDsSpAURGN 7TZ++Ko4QSvUSwvjeZzCEI+IAtPyloeA/tkKVjr4vehFuGJnqvIDhrdkJopImdT2gjAq6v80e vIAVkNeYeO1myrzRHCAEIV2Fil2uMROR6NXZfz0VsixZttwckfZkTwZGa06wDnGyTZe4cLgR2 M/IT5I0erbl7dOdC7VJS3PX1+hiqsJuc07efBNybAjPWX+fi7szzeJ0Ui0AwutX8yQtQrTNni eRxsxJ09TzoSR4Xq7hE/0APcNfiwcQ/d0paKbOEZg7PnwXRvvVK7rQzudD6D4/HncZQNgS1rF UwPZT2SV4C/fLt6oBsVVEoxBPy1X6u0V6dZjKDMNyDg3ejh70lwYUz0Zt7/jlYfJysDzbY1vJ CTTxMzT5mvGkr3KxJy/zietMmxw1QsF4vf59sZakRpJHoABSg3ZlWUQBIbvwnG8Dc3ESLHr/k DmfLOyVNq95fQSX8DW7yx0puO200Vsa256f1TM7idaHNnDAbFgdTKEtY3AiGHECreCBWKBlSQ tucmhSmYrcwyjZijlIAYwJCqt0cN+s6eTPk/+9Jo5YRG8RJ23WokVBrZFeBicWpXLrrQZ9XAj dpNJoqQoB6FOGnSn2X9nJIC+AdJcflvnCXCXIHIoFKrDs44xBcZEuPMqREgz5uNW8FiI70Awj dERRlHO7Vc/rA6MQHQouZDc4aju4wsTorpRIvqxe52RsJgWrZ2vTIaXVogOCc7yKfRfYSjROy eNWQOhAaP8SV0gYl5y1A== Archived-At: Subject: Re: [Crypto-panel] [Cfrg] PAKE Selection Process: Round 2, Stage 2 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: Sat, 21 Dec 2019 01:23:56 -0000 I am not affiliated with the remaining candidates or the panel, but here are my answers to aid the remaining candidates (except #3 because I don't know patents). > On December 9, 2019 at 6:43 AM "Stanislav V. Smyshlyaev" wrote: > > > Dear CFRG, > > According to the plan of Round 2 of the PAKE selection process, additional > questions for all four remaining candidates have been collected from CFRG > participants (and Crypto Review Panel members) via crypto-panel@irtf.org . > > We've obtained the following list of questions: > 1) (to SPAKE2): Can you propose a modification of SPAKE2 (preserving all > existing good properties of PAKE2) with a correspondingly updated security > proof, addressing the issue of a single discrete log relationship necessary > for the security of all sessions (e.g., solution based on using > M=hash2curve(A|B), N=hash2curve(B|A))? There is an Elligator edition for SPAKE2 called SPAKE2-EE (not to be confused with SPAKE2+EE the augmented PAKE versions). Most implementations will likely have A as "A", "Alice", or other fixed value and B as "B", "Bob", or other fixed value making "M=hash2curve(A|B)" pointless. Also SPAKE2-EE would be faster: "A = a * G + hashToPoint(k1)" vs "A = a * G + k1 * hashToPoint(A|B)". Lastly SPAKE2-EE is quantum annoying while SPAKE2 and suggested change are not. Note Elligator edition is a misleading name because you can use SWU or other hash to point algorithms. > 2) (to CPace and AuCPace): Can you propose a modification of CPace and > AuCPace (preserving all existing good properties of these PAKEs) with a > correspondingly updated security proof (maybe, in some other security > models), addressing the issue of requiring the establishment of a session > identifier (sid) during each call of the protocol for the cost of one > additional message? Only CPace has an extra message. AuCPace with or without sid is the same number of messages. Also I don't see the point of sid in AuCPace since it's acting as a salt but since it's an aPAKE there's already a salt. This is why I say B-SPEKE is better than AuCPace. For CPace the sid I believe is needed. I'm pretty sure I've implemented SPAKE2-EE with a "sid" because I wanted a salt for the password KDF. > 3) (to all 4 remaining PAKEs) : Can the nominators/developers of the > protocols please re-evaluate possible IPR conflicts between their > candidates protocols and own and foreign patents? Specifically, can you > discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th of > march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, > expected expiration October 2026) on the free use of the RFC-drafts for > OPAQUE? I didn't read the patents, but SPEKE is prior art for CPace and AuCPace circa October 1996. Since CPace and AuCPace are just salted SPEKE. > 4) (to all 4 remaining PAKEs) What can be said about the property of > "quantum annoyance" (an attacker with a quantum computer needs to solve > [one or more] DLP per password guess) of the PAKE? CPace and AuCPace have quantum annoyance. If SPAKE2 is modified to use the Elligator edition (SPAKE2-EE), then it will have quantum annoyance. Note Elligator edition is a misleading name because you can use SWU or other hash to point algorithms. OPAQUE needs a complete redesign to gain quantum annoyance. **** Important **** This is because OPAQUE has a property I call fragile. Which means if one can solve a static DH oracle (which is the easiest way to attack DH), then it breaks. Also OPAQUE is the worst in a PQ world since you don't need to observe a successful exchange. An attacker acts like they are guessing a wrong password, collect messages, solve the OPRF DLP, and guess passwords offline against the encrypted blob. **** Important **** > 5) (to all 4 remaining PAKEs) What can be said about "post-quantum > preparedness" of the PAKE? Given a PQ OPRF, all these PAKEs are PQ. Also note you can do both a PQ OPRF and a classical OPRF just in case the PQ OPRF turns out to not be secure. For balanced PAKEs, you only need a PQ OPRF. > > Please let the chairs and the Crypto Review Panel members know (before > December, 17th) if any questions (collected via crypto-panel@irtf.org) > have been lost or misinterpreted (or something needs to be added). > > Best regards, > Stanislav, > CFRG Secretary > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Sat Dec 28 10:03:47 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 5F5BB120164; Sat, 28 Dec 2019 10:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 ajB9ibjGlt1t; Sat, 28 Dec 2019 10:03:42 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 26977120154; Sat, 28 Dec 2019 10:03:42 -0800 (PST) Received: from oxuslxaltgw02.schlund.de ([10.72.76.58]) by mrelay.perfora.net (mreueus001 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MbyqG-1j1Hv013oc-00JLD7; Sat, 28 Dec 2019 19:03:40 +0100 Date: Sat, 28 Dec 2019 12:03:39 -0600 (CST) From: steve@tobtu.com To: CFRG , crypto-panel@irtf.org Message-ID: <1500228730.557647.1577556219650@email.ionos.com> In-Reply-To: <355650937.279614.1576891431019@email.ionos.com> References: <355650937.279614.1576891431019@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.1-Rev25 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:faDAMART5M4TDP0EeJ0GEyjpMAUpKc7DaUX5BJWf6Uge6QJ/kiQ wxw+k3lofwYGmxkKlDf+B/+RrXwwAcE4+Cz/vtV82JbBO05+e52s9onCThq5TTPR8LzczVu MK0/eGcox2SYzn5IuOr1CBuR9gmPwAXa9gLiug+h7hsiKEWZHv+wl5uwY+FkLS9NH2cJiVw l95/V/EddvOBhRct+UoDA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Msb2daLGCvg=:54N9oQketR2eF31pWPOfsA PjfB7DlB7JizpU5LGACuxa2zJv/hMhCjA3gt1V26KINET/OKd1Ze0FYmqzfYdeJOSCZSAd+3Q LMjIxO/MBEEagsLDuRpaChW5sJS6IGlmMJN3dDy+dXOuyewwYWK5a8ibgmzHNkpQuzM3R5Wj/ 8nFY+JROcvdX86IFb2bCSfrqJiadjiqdh/QWoVNzHHfSYp6Z+u56TODdRXNd6nboK3dvb6aEd DFVOILFLjFbXDVA5MAKhBNTmmOedvjA6+cu+YESO0T/5ZxNvFvxofLmASp2YQO+Npwm7IqqZF 0rVydIFXQ0YkJSf8hCKp8gKP0gGS1vrxFVRd1o1kDhGy743kRD1HMXeoU/FHUNs3cDOtnAzJ6 jPjYZ8KoNQbREMxkhkq11Bd4IhQhBUqWb/bWW/awxWFp6Lb/KT2T9soLMehabv92O41kqIt49 a+q79f1zn9BMY2ITL9GRBMWKMbRLCIsgLnh+J6cown6G5dsF/g52xgmj4e015hDXq3FwyKEWB I3hmwB0aZb7x29azGp9zZlkfEfI1nRvVDmOwEywWcFYhWDKw2iRn3nAAseVrMLrx9TQuGtLjG XK/TpSfhd5/dSx+NoTh6CXscWdP2oCcnupZpXbfSTRemZCkBKTiJvNFPffYTUEeCgqqbb5Sqx Pq+mIGMYscgSeIYOKCZNl4Ovh9NjemyNEu9RFTumGwlq9ty4Dz7Yi7l2NYqM73NA7aQa3g/LD J49tCKlszQ6/3t7tN+6Nohkvvd0tU7sXqIoogfefcutuK8fZzVZPmuBqTd1Z+/Crsi4EgouxF gKyTYng9W9CHKaeAiuHoK7HXj4hs5nmhAsIQ3IKAbI8vUMWqiCN/417xuzu/1iB+Jl7MAGI54 XlKrsZFwT6988+vRQSBw== Archived-At: Subject: Re: [Crypto-panel] [Cfrg] PAKE Selection Process: Round 2, Stage 2 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: Sat, 28 Dec 2019 18:03:44 -0000 Minor note on #5 by "Given a PQ OPRF, all these PAKEs are PQ." I mean over the wire PQ. The server data is not PQ. The balanced PAKEs are fully PQ, but the augmented PAKEs are only over the wire PQ. Since the server verifier (or what not) are a solved DLP away from an attacker being able to masquerade as a client. > On December 20, 2019 at 7:23 PM steve@tobtu.com wrote: > > > I am not affiliated with the remaining candidates or the panel, but here are my answers to aid the remaining candidates (except #3 because I don't know patents). > > > > On December 9, 2019 at 6:43 AM "Stanislav V. Smyshlyaev" wrote: > > > > > > Dear CFRG, > > > > According to the plan of Round 2 of the PAKE selection process, additional > > questions for all four remaining candidates have been collected from CFRG > > participants (and Crypto Review Panel members) via crypto-panel@irtf.org . > > > > We've obtained the following list of questions: > > 1) (to SPAKE2): Can you propose a modification of SPAKE2 (preserving all > > existing good properties of PAKE2) with a correspondingly updated security > > proof, addressing the issue of a single discrete log relationship necessary > > for the security of all sessions (e.g., solution based on using > > M=hash2curve(A|B), N=hash2curve(B|A))? > > There is an Elligator edition for SPAKE2 called SPAKE2-EE (not to be confused with SPAKE2+EE the augmented PAKE versions). Most implementations will likely have A as "A", "Alice", or other fixed value and B as "B", "Bob", or other fixed value making "M=hash2curve(A|B)" pointless. Also SPAKE2-EE would be faster: "A = a * G + hashToPoint(k1)" vs "A = a * G + k1 * hashToPoint(A|B)". Lastly SPAKE2-EE is quantum annoying while SPAKE2 and suggested change are not. > > Note Elligator edition is a misleading name because you can use SWU or other hash to point algorithms. > > > > 2) (to CPace and AuCPace): Can you propose a modification of CPace and > > AuCPace (preserving all existing good properties of these PAKEs) with a > > correspondingly updated security proof (maybe, in some other security > > models), addressing the issue of requiring the establishment of a session > > identifier (sid) during each call of the protocol for the cost of one > > additional message? > > Only CPace has an extra message. AuCPace with or without sid is the same number of messages. Also I don't see the point of sid in AuCPace since it's acting as a salt but since it's an aPAKE there's already a salt. This is why I say B-SPEKE is better than AuCPace. For CPace the sid I believe is needed. I'm pretty sure I've implemented SPAKE2-EE with a "sid" because I wanted a salt for the password KDF. > > > > 3) (to all 4 remaining PAKEs) : Can the nominators/developers of the > > protocols please re-evaluate possible IPR conflicts between their > > candidates protocols and own and foreign patents? Specifically, can you > > discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th of > > march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, > > expected expiration October 2026) on the free use of the RFC-drafts for > > OPAQUE? > > I didn't read the patents, but SPEKE is prior art for CPace and AuCPace circa October 1996. Since CPace and AuCPace are just salted SPEKE. > > > > 4) (to all 4 remaining PAKEs) What can be said about the property of > > "quantum annoyance" (an attacker with a quantum computer needs to solve > > [one or more] DLP per password guess) of the PAKE? > > CPace and AuCPace have quantum annoyance. > > If SPAKE2 is modified to use the Elligator edition (SPAKE2-EE), then it will have quantum annoyance. Note Elligator edition is a misleading name because you can use SWU or other hash to point algorithms. > > OPAQUE needs a complete redesign to gain quantum annoyance. > **** Important **** > This is because OPAQUE has a property I call fragile. Which means if one can solve a static DH oracle (which is the easiest way to attack DH), then it breaks. Also OPAQUE is the worst in a PQ world since you don't need to observe a successful exchange. An attacker acts like they are guessing a wrong password, collect messages, solve the OPRF DLP, and guess passwords offline against the encrypted blob. > **** Important **** > > > > 5) (to all 4 remaining PAKEs) What can be said about "post-quantum > > preparedness" of the PAKE? > > Given a PQ OPRF, all these PAKEs are PQ. Also note you can do both a PQ OPRF and a classical OPRF just in case the PQ OPRF turns out to not be secure. For balanced PAKEs, you only need a PQ OPRF. > > > > > > Please let the chairs and the Crypto Review Panel members know (before > > December, 17th) if any questions (collected via crypto-panel@irtf.org) > > have been lost or misinterpreted (or something needs to be added). > > > > Best regards, > > Stanislav, > > CFRG Secretary > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > https://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg