Re: [Crypto-panel] [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: 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 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
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/crypto-panel/lB6dcYHyTiS8Y6vM2snWVgvFFEs>
Subject: Re: [Crypto-panel] [Cfrg] 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: Sat, 21 Dec 2019 01:23:56 -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
- [Crypto-panel] PAKE Selection Process: Round 2, S… Stanislav V. Smyshlyaev
- Re: [Crypto-panel] [Cfrg] PAKE Selection Process:… Watson Ladd
- Re: [Crypto-panel] [Cfrg] PAKE Selection Process:… Stanislav V. Smyshlyaev
- Re: [Crypto-panel] PAKE Selection Process: Round … Stanislav V. Smyshlyaev
- Re: [Crypto-panel] [Cfrg] PAKE Selection Process:… steve
- Re: [Crypto-panel] [Cfrg] PAKE Selection Process:… steve
- Re: [Crypto-panel] PAKE Selection Process: Round … Stanislav V. Smyshlyaev
- Re: [Crypto-panel] PAKE Selection Process: Round … Björn Haase
- [Crypto-panel] Fwd: PAKE Selection Process: Round… Stanislav V. Smyshlyaev
- Re: [Crypto-panel] PAKE Selection Process: Round … Stanislav V. Smyshlyaev