[Crypto-panel] Fwd: PAKE Selection Process: Round 2, Stage 2

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Mon, 10 February 2020 12:37 UTC

Return-Path: <smyshsv@gmail.com>
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 BC3FD1201E0 for <crypto-panel@ietfa.amsl.com>; Mon, 10 Feb 2020 04:37:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 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, LOTS_OF_MONEY=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 AxnjafX-g8n4 for <crypto-panel@ietfa.amsl.com>; Mon, 10 Feb 2020 04:37:14 -0800 (PST)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 DBC801201DE for <crypto-panel@irtf.org>; Mon, 10 Feb 2020 04:37:13 -0800 (PST)
Received: by mail-lf1-x12c.google.com with SMTP id y19so4061843lfl.9 for <crypto-panel@irtf.org>; Mon, 10 Feb 2020 04:37:13 -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=apGsNBauzrD/jgYf8VwGkwLjXxoBWwmj1BJ7lzhwgzY=; b=J3J6P4ytXPH+3NarcXyO6xN0anRsOzW8zF6+RqSN6pPwsuv0lGsZCqjgCVIaeVE8MY /SuKakBOk39uw+JyeYV9vxKk2wN0/xRI4VQyYegTR2LEXgSXvKqs5ByJouKqUlI/hDZM G8LD5ZfInok3l96GC0MIV/SAPgA4F6AqoXvArwDto53gP4waRO4DGYHZYrHSvRf+AtaG FCGNhqHAkEQVU59lWOUEv2n5MueWI8MN9C6c3TYvtTDWPTQT290o3pwV+ph5kC8FQyal p8tEHnqJusnLuAXAui71LWEfaNMJXS0nR9rQkAz1aunJIzOitn2EqJ5mrZsc6SqIJH5f AHRg==
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=apGsNBauzrD/jgYf8VwGkwLjXxoBWwmj1BJ7lzhwgzY=; b=LEbb7+QaNS4Bnwr835VoC6HlzwMKmnUYSt2QrKyEyKO2OQzqscWpiN5I26u1rgDXTk db7D7KNzKY1oO6m+b4wwp9Ls9qSuNOOM3QoDU4MBhy5nOL2JilnHYROKF05YuUWlGLdE owSGyMlH66Hug/Ue2K+bX5pfnA8FI0yqtL7BgcPTdPnMFN+yDbeHeHdaiiHF8QQ+/F1U 0NTptrf3UbFW2ZfGGg2/DhhLzVV/Bm2U4evfPsZGOs1e8XZHJaxzYTG8ix1kIlBl2CFG a7Nfvp6/qZ/eZ5aVtEN+wPmQulNQPXNMqxfQeIORCPDkW8AGA0YZkQAOTW/jdvgftlVv A/oQ==
X-Gm-Message-State: APjAAAVs2paTf1VtXnSksBDcvpoEYmclC2kUThQqbg3w9IiK9nbIq+OV FtCuygZSt06XeuyzGu8frMrar+0/6BBqU0HzUD79lIpf
X-Google-Smtp-Source: APXvYqwNJxYXFnWtcGj9omqYwCdhNUEmCWM0eCdrI1c+AoVBH5Q5B9fFNF7a1BwIEnl42Lrw0LcWj1qp6oFTUOLeUEM=
X-Received: by 2002:ac2:4c84:: with SMTP id d4mr692950lfl.64.1581338231425; Mon, 10 Feb 2020 04:37:11 -0800 (PST)
MIME-Version: 1.0
References: <CAMr0u6=hOG1Jw_3iafiC+0U4F6OX6Dnx78+4zamk7GmdgvvfGw@mail.gmail.com> <CAMr0u6mYg3np5vj-GNo4ZWccxQ5QMEmqTzzSJ_WcNU1Hf9NbPg@mail.gmail.com> <CAMr0u6kv2qBLAXJS-SvQOVg67XTzhBdZYAyeN+ybnS8wsAB0Bg@mail.gmail.com> <AM0PR05MB478645E867992D0297245ED483190@AM0PR05MB4786.eurprd05.prod.outlook.com>
In-Reply-To: <AM0PR05MB478645E867992D0297245ED483190@AM0PR05MB4786.eurprd05.prod.outlook.com>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Mon, 10 Feb 2020 15:38:18 +0300
Message-ID: <CAMr0u6kJ_qJuEOvyRoEOhmiX3WfXkYmh-cy-vw5oq74U-qEs7A@mail.gmail.com>
To: crypto-panel@irtf.org
Content-Type: multipart/alternative; boundary="0000000000008dcefe059e37ff32"
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/sEo2dC4h0ALO0dkZBk5tI9Z2yXM>
Subject: [Crypto-panel] Fwd: PAKE Selection Process: Round 2, Stage 2
X-BeenThere: crypto-panel@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <crypto-panel.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/crypto-panel/>
List-Post: <mailto:crypto-panel@irtf.org>
List-Help: <mailto:crypto-panel-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Feb 2020 12:37:18 -0000

Forwarding a message from Björn Haase.

---------- Forwarded message ---------
From: Björn Haase <bjoern.haase@endress.com>
Date: Mon, 10 Feb 2020 at 11:36
Subject: AW: PAKE Selection Process: Round 2, Stage 2
To: crypto-panel@irtf.org <crypto-panel@irtf.org>
Cc: Stanislav V. Smyshlyaev <smyshsv@gmail.com>


Dear CFRG,

as requested for the beginning of stage 4 of the second round of the PAKE
selection process, I have compiled the additional documentation at the
following places.

Paper:
https://github.com/BjoernMHaase/AuCPace/blob/master/aucpace_security_analysis_20200208.pdf

Internet Drafts:
https://tools.ietf.org/html/draft-haase-aucpace-01
https://tools.ietf.org/html/draft-haase-cpace-01

Reference implementations:
https://github.com/BjoernMHaase/AuCPace


Please find a short version of my replies below:

Question 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?"

Reply to 2) :
I have re-reviewed this issue and integrated the alternative approach as
suggested by Ran Canetti on the CFRG list in the paper and security
analysis (see “paper” link above). The specification in the CPace and
AuCPace internet drafts now also correspond to this approach. With this
method, there is no longer the need for an additional communication round.

Question 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?"

Reply to 3):
I have re-visited all patents and did not find any IPR that might generate
conflicts with CPace and AuCPace. The topic of the mapping algorithms is
resolved in my opinion with the latest changes in the hash_to_curve draft
(which avoids the “-1 non-s       quare” topic and the “three-polynomial”
issue for SSWU).

In contrast, in the course of this research I came to the conclusion that
SPAKE2 is probably affected by US 7,047,408. The exceptional feature is
that the duration of this patent seems to have been extended to a period of
exceptional 23 years instead of 20 years! I have double-checked and that
seems indeed to be legally possibly in the US. I have just filed a
corresponding IPR disclosure.

Question 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?"

Reply to 4):

As previously noted also by “Steve Thomas”, for CPace an active adversary
needs to solve at least one DLP per password guess this also holds for the
conventionally augmented AuCPace variant.

The additional guarantee of “pre-computation attack resistance” provided by
the OPRF construction of strong AuCPace, however will not be preserved.
This means that the *strong* AuCPace protocol will fall back the
conventionally augmented AuCPace in the post-quantum world, which itself is
again quantum annoying.  (This comes as a consequence of the issue with the
"static Diffie-Hellmann oracle topic" regarding the OPAQUE OPRF, as brought
up recently by Steve Thomas recently on the crypto panel list).

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

Reply to 4):

In the Internet Drafts regarding CPace and AuCPace I have added a short
discussion on this topic.

I believe that the fact that CPace and AuCPace don’t actually require a
full group structure but only operations in a "group modulo negation" might
provide a path for using isogeny-based cryptography as kind of a drop-in
replacement for the Diffie-Hellmann substeps.

While primitives such as SIKE and CSIDH provide functionality similar to a
DH secret establishment (where both parties contribute to the key), there
is no such equivalent of “point addition” in the isogeny world. In my
opinion, for the augmentation layer of AuCPace, the mechanisms on isogenies
for Diffie-Hellmann-style secret establishment could already be used as-is.
For the application in CPace (with the need of an isogeny-equivalent of a
secret password-derived base point), there is ongoing research which is,
however, not yet stabilized and mature in my opinion. Here I have added a
links regarding possible migration paths regarding CPace in the security
considerations section of the internet draft.

Additionally, the modularized security analysis of CPace as a building
block of AuCPace allows for replacing the CPace component by any future
balanced post-quantum PAKE (in the style that Hugo suggests for OPAQUE).
 For instance, I believe it to be promising to consider constructions based
on the LWE problem where the matrices are kept secret and derived from a
password and an ephemeral session id, in the style of "New hope" which uses
SHAKE for generation of ephemeral LWE matrices. Still again, this topic,
just as the isogenies, would require significant future research in my
opinion.

I am unfortunately not aware of any current concept regarding a post
quantum primitive for the OPRF construction as needed for *strong* AuCPace.

Yours,

Björn Haase


P.S.: A compilation regarding my personal view on the current state of the
selection process is found at

https://github.com/BjoernMHaase/fe25519/blob/master/Slides_PAKE_selection_at_CFRG_Brainpool_20200115.pdf

I tried to be as objective as one could reasonably be expecting from an
individual having own nominations running.


Mit freundlichen Grüßen I Best Regards

Dr. Björn 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.haase@endress.com |  www.conducta.endress.com



Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella


Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu
informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (
https://www.endress.com/de/cookies-endress+hauser-website) 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.