Re: [Cfrg] PAKE Selection Process: Round 2, Stage 2

steve@tobtu.com Sat, 21 December 2019 01:23 UTC

Return-Path: <steve@tobtu.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@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 <cfrg@irtf.org>, crypto-panel@irtf.org
Message-ID: <355650937.279614.1576891431019@email.ionos.com>
In-Reply-To: <CAMr0u6=hOG1Jw_3iafiC+0U4F6OX6Dnx78+4zamk7GmdgvvfGw@mail.gmail.com>
References: <CAMr0u6=hOG1Jw_3iafiC+0U4F6OX6Dnx78+4zamk7GmdgvvfGw@mail.gmail.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: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: <https://mailarchive.ietf.org/arch/msg/cfrg/DzmwtRkNeMqW5xlj-GC9AtZ2go8>
Subject: Re: [Cfrg] PAKE Selection Process: Round 2, Stage 2
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=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" <smyshsv@gmail.com> 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