[Crypto-panel] Forwarding a message from Bjoern Haase

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Mon, 10 February 2020 14:15 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 327C6120122 for <crypto-panel@ietfa.amsl.com>; Mon, 10 Feb 2020 06:15:47 -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 DU1KKXtpo5R7 for <crypto-panel@ietfa.amsl.com>; Mon, 10 Feb 2020 06:15:44 -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 6AAF41200F5 for <crypto-panel@irtf.org>; Mon, 10 Feb 2020 06:15:43 -0800 (PST)
Received: by mail-lj1-x231.google.com with SMTP id f25so7292873ljg.12 for <crypto-panel@irtf.org>; Mon, 10 Feb 2020 06:15:43 -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=V15GcVbEuqeVXuAcehHo+W0qlkQVmplchkqfXOufU+U=; b=QTO3QJgXoDpHqqry1BrOq3wusyF6sa7wZqvZ4jTZrt6Z2NCzoK6gr88TWU9MuCFBtI j8kEmOL03Mq019PMwR+lBcRGXrFLhYRAbevJRR3fLCAHETUpKVoNKK8RN7p2iWDmymY2 Yl18nFCS6tRnKEibtS9bjXGl7XTFF/cr4h26dwmcO2FAgHtXFRaZA2jjeTEBW75uJE7V Xts7K3m7gPN7ZlUXQV+ngiBaGDNHk2YP9Rld2jBHfC7YXYDnpblo53Qfxhynfz5rJN0M WqC+Ux5gonQYKmpNfvYdopHZb0PCYoW177OaVb35j5nmt4+L7Yhl86u8+9wEDm3WAwzq j6MQ==
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=V15GcVbEuqeVXuAcehHo+W0qlkQVmplchkqfXOufU+U=; b=eDhhg05tT1pWJeezK/ReYxPq75goIQOjIejZbwFTNw1+10jGUKM9IeCAPfcfVP+Wqx PhBCOV22QpY77QnAxNFjcxMolusAxBRslYhdZJQoFJgXZoO1vLdLqJQ769E5gyWFAqiL 1CsIWtOOHNoRcDc5eunyH1C9lyJqJjGyKPtMqpgxnLsqQFwe9uOpBhhlynQTcguFsGCK fMazDZN9JB0MJIwVcNOUnW97bZEBzYYIGTIfCOk02NqHC8CVF4Hsn4AZ/WT+oLMY6XVp ROi7ZWRgyEm9hbCDCEFoYrhzg14m5PSufadcBjIb5VVlW2zvMhbhkztagHNI+ZoWLFeZ RVJg==
X-Gm-Message-State: APjAAAV/OT1dnDochpfdRmeSL1sqEqSVbjRrfuYjvW2VItudIp9lw7Iw XDhfBa8klF/4Y9SDtziMPQozUVd++TvAycpVro0fJheD
X-Google-Smtp-Source: APXvYqxYY+ldKVPSiKzoFWtTR5Ct2tkiJXFlysa+AyCvLpJWsIZwwuW9gK8N0tLuCkEbixyAOKoHxj48AteBfAXW6ys=
X-Received: by 2002:a2e:8758:: with SMTP id q24mr1074336ljj.157.1581344141040; Mon, 10 Feb 2020 06:15:41 -0800 (PST)
MIME-Version: 1.0
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Mon, 10 Feb 2020 17:16:48 +0300
Message-ID: <CAMr0u6=PDPbmTRor_CCZK-f-MQxKxtuXPodgB4rtQg2Kdead0A@mail.gmail.com>
To: crypto-panel@irtf.org
Content-Type: multipart/alternative; boundary="000000000000cb5e55059e395f36"
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/gGRp5_93LKBeIZ9go_AZmvk0IYw>
Subject: [Crypto-panel] Forwarding a message from Bjoern Haase
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 14:15:47 -0000

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