Re: [Cfrg] PAKE Selection Process: Round 2, Stage 2 Sat, 28 December 2019 18:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F5BB120164; Sat, 28 Dec 2019 10:03:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ajB9ibjGlt1t; Sat, 28 Dec 2019 10:03:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 26977120154; Sat, 28 Dec 2019 10:03:42 -0800 (PST)
Received: from ([]) by (mreueus001 []) 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)
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: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: [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, 28 Dec 2019 18:03:45 -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 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 .
> > 
> > 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
> >
> >
> _______________________________________________
> Cfrg mailing list