Re: [Cfrg] PAKE Selection Process: Round 2, Stage 2 Sat, 21 December 2019 01:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 670AD1209F1; Fri, 20 Dec 2019 17:23:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xcDnX28Us3ip; Fri, 20 Dec 2019 17:23:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 636C81209EE; Fri, 20 Dec 2019 17:23:53 -0800 (PST)
Received: from ([]) by (mreueus001 []) 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)
To: CFRG <>,
Message-ID: <>
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: [Cfrg] PAKE Selection Process: Round 2, Stage 2
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 21 Dec 2019 01:23:55 -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 .
> 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

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
> have been lost or misinterpreted (or something needs to be added).
> Best regards,
> Stanislav,
> CFRG Secretary
> _______________________________________________
> Cfrg mailing list