Re: [CFRG] Attack on a Real World SPAKE2 Implementation
steve@tobtu.com Sun, 09 May 2021 19:03 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 2B0423A1B42 for <cfrg@ietfa.amsl.com>; Sun, 9 May 2021 12:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[SPF_NONE=0.001, URIBL_BLOCKED=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 3eUle7ZVnGS3 for <cfrg@ietfa.amsl.com>; Sun, 9 May 2021 12:03:00 -0700 (PDT)
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 1DDF33A1B3D for <cfrg@irtf.org>; Sun, 9 May 2021 12:02:59 -0700 (PDT)
Received: from oxuslxaltgw01.schlund.de ([10.72.76.57]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MS4Ue-1m4bsX0G0g-00T9HJ for <cfrg@irtf.org>; Sun, 09 May 2021 21:02:59 +0200
Date: Sun, 09 May 2021 14:02:58 -0500
From: steve@tobtu.com
To: cfrg@irtf.org
Message-ID: <1662280882.109662.1620586978685@email.ionos.com>
In-Reply-To: <e47d0509-2b47-b811-7fd5-8846c11dc055@web.de>
References: <2bfbd767-b93a-42bd-be7d-1dae9e32e555@ruben-gonzalez.de> <SY4PR01MB625110F1F7633D989FCF183EEE579@SY4PR01MB6251.ausprd01.prod.outlook.com> <e88bae26-ff1f-42e3-babf-c5de3ee1d781@www.fastmail.com> <e47d0509-2b47-b811-7fd5-8846c11dc055@web.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.4-Rev22
X-Originating-Client: open-xchange-appsuite
X-Provags-ID: V03:K1:gwO4QFtVWB13CMtOSU5GBGRJ5K298DrpsYOqZe4FLuEfBjYhHfc k9SnNXyp8ivIvrvJfakRaoDMP+t4nVIfPVEgATNOzPb45AxMulzF919mDHrxt4DbXUqj9U+ LDmMgJDh8R7eaeKTR7p5ZAB/X6/bnE29ksmG8MjBw6TOEoX+0Npt73AOMr+gjBxa8V8iDBI vPtGtVRIyp0NF2rzES+Sw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:kXQwYs5AnMQ=:l4M3JlKNTLmcQp4oYU/sPN 5XM/JtIvqkpQbCYMmFyYaN5iR7/JVunk6DQ0WbTFdDRQxlr0Fx5arNlWY21x8MnHushbH/fW6 wytrxrxl6+RHqfqyOY4jfnnxvbZUbHEn5XE1olU/OOyYVST4SZBPn+9vUCXMnWH5UD0w6ckJr CNzzFhjMWWABvBw885WMykueOUwmGMAidf8qe5YcVsWYicWqkdY2zz2BqHe1CK7ouPsEx+gH+ mDwdEscJHz1dUeqcz8Slr/yfHDiK+JpTiMryq/eNJnUd7cSW2QyECnDkZkNjjGVa2kh6MdYew yXMbt56FJxMhXVYD7ESMvVFuD3Ao57M14SdJZRcHnQXkE52eMmChOry8yoPScTcREAKQKqrTu 0pHj6fVUos0C/QvwoNI0YSMjYzpnqBN97fugL9QPGUJsc2WyIXnQHm47oKnheq3gykIsMSQum CRDniiZGJ4haYHf56FTxCn6s7s1kALvW8j6ckujWUpuBqeeyF0xUqbMiz6lrZdBDaicAL7NVi i/tvhPPsU+Hty3JzrEUAWY=
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/HgGqOJm6juouqukVbxMVPIyt6cs>
Subject: Re: [CFRG] Attack on a Real World SPAKE2 Implementation
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: Sun, 09 May 2021 19:03:05 -0000
By the way, they state where the algorithm details came from "This protocol is derived from Dan Boneh and Victor Shoup's cryptography book [https://crypto.stanford.edu/~dabo/cryptobook/BonehShoup_0_4.pdf] (pg 789, 'PAKE2 protocol')." So we should look at that to see how to improve descriptions. I think it's really people not knowing that "hash to curve" or "a random point on the curve" are not normal things and very important. I know of someone who read about "hash to curve" in I think OPAQUE and thought that it was "H(value)*G". So we need to make special notes on these things. > On 05/09/2021 11:05 AM Björn Haase <bjoern.m.haase@web.de> wrote: > > > Hello All, > > > > I think we should be be careful with biased wordings such as "sharing the blame" and assumptions such as "snake oil" which implies fraudulent intentions. > IMO, we just don't know all of the details and it might be more constructive not to speculate too much. > > (When writing this: Even though my professional experience taught me to never under-estimate the power of foolishness, I think that it should be considered to be truly remarkable how many things have gone wrong here simultaneously. ) > > For the same reason, I don't think that one should be careful of "blaming" the authors of the SPAKE2 for anything that has gone wrong here. > Regarding possible improvements of the draft I still would like to come up with a suggestion: > > What about adding a clear and *mandatory* specification for conforming implementations of SPAKE2 on any curve on how to generate the "nothing upon my sleeve" inputs M,N? > > I would recommend mandating a procedure that refers to the current draft version of the h2c draft as it is today. > > Alternatively, if one would like to avoid references to the h2c draft (in order to make M,N independent of possible future changes in the h2c draft), one could consider using a specification in the style of appendix A in https://eprint.iacr.org/2018/286.pdf, where similar "nothing upon my sleeve" points "A, C" were needed. > At any rate, I believe that there seems to be need for a mandatory trustworthy way for generating M, N for *any* curve. > > Yours, > Björn > P.S.: > Actually, I just noticed that its not really explicit how the points M, N in the current SPAKE2 draft 18 are calculated for the curves where test vectors are provided. I presume that the uniform h2c map was used for the given seed inputs? > > > Am 08.05.2021 um 01:51 schrieb Filippo Valsorda: > > > 2021-05-07 04:17 GMT-04:00 Peter Gutmann <pgut001@cs.auckland.ac.nz>: > > > > > Ruben Gonzalez <in+lists@ruben-gonzalez.de> writes: > > > > > > > > > > > > >We did not attack SPAKE2 directly, but a faulty implementation. > > > > > > > > > > > > Nice work! This is an example of what I once referred to as second-order > > > > > > snake oil crypto, good crypto applied badly (first-order is bad crypto). > > > > > > > > > Snake oil is fraudulent. This is a broken implementation, for which specification authors should at least consider sharing the blame. How did the spec fail the implementers, who presumably were not trying to implement something in a broken way? > > > > > > > > (I know, I know, SPAKE2 is a draft, not an RFC! But it's been a draft for almost 7 years, and at some point people need to implement stuff.) > > > > > > > > _______________________________________________ > > CFRG mailing list > > CFRG@irtf.org > > https://www.irtf.org/mailman/listinfo/cfrg > > > _______________________________________________ CFRG mailing list CFRG@irtf.org https://www.irtf.org/mailman/listinfo/cfrg
- [CFRG] Attack on a Real World SPAKE2 Implementati… Ruben Gonzalez
- Re: [CFRG] Attack on a Real World SPAKE2 Implemen… Peter Gutmann
- Re: [CFRG] Attack on a Real World SPAKE2 Implemen… steve
- Re: [CFRG] Attack on a Real World SPAKE2 Implemen… Dan Harkins
- Re: [CFRG] Attack on a Real World SPAKE2 Implemen… Filippo Valsorda
- Re: [CFRG] Attack on a Real World SPAKE2 Implemen… steve
- Re: [CFRG] Attack on a Real World SPAKE2 Implemen… Watson Ladd
- Re: [CFRG] Attack on a Real World SPAKE2 Implemen… Björn Haase
- Re: [CFRG] Attack on a Real World SPAKE2 Implemen… steve
- Re: [CFRG] Attack on a Real World SPAKE2 Implemen… Loup Vaillant-David
- Re: [CFRG] Attack on a Real World SPAKE2 Implemen… Filippo Valsorda
- [CFRG] Modifying SPAKE2 draft for more curves (wa… Watson Ladd
- Re: [CFRG] Modifying SPAKE2 draft for more curves… Hao, Feng
- Re: [CFRG] Modifying SPAKE2 draft for more curves… Hao, Feng