Re: [CFRG] Small subgroup question for draft-irtf-cfrg-hash-to-curve
Russ Housley <housley@vigilsec.com> Fri, 09 April 2021 16:25 UTC
Return-Path: <housley@vigilsec.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 2501C3A2693 for <cfrg@ietfa.amsl.com>; Fri, 9 Apr 2021 09:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 9g3rZM1rpz_j for <cfrg@ietfa.amsl.com>; Fri, 9 Apr 2021 09:25:20 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D9373A26CF for <cfrg@irtf.org>; Fri, 9 Apr 2021 09:25:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4F112300BBD for <cfrg@irtf.org>; Fri, 9 Apr 2021 12:25:17 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ElOhBolRtR5K for <cfrg@irtf.org>; Fri, 9 Apr 2021 12:25:14 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id ED86F300BD0; Fri, 9 Apr 2021 12:25:13 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <58DC133A-AD85-4A66-BD18-60974486DC6D@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9016E482-39B6-4F12-8CC2-67D6BBDE1F78"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Fri, 09 Apr 2021 12:25:15 -0400
In-Reply-To: <VI1SPR01MB0357AE729116A79C8DF70516D6739@VI1SPR01MB0357.eurprd01.prod.exchangelabs.com>
Cc: IRTF CFRG <cfrg@irtf.org>
To: "Hao, Feng" <Feng.Hao@warwick.ac.uk>
References: <e270e62d-941d-0a87-7dc9-cf80f73b5aeb@jacaranda.org> <d0778523-5f5d-4327-b795-279918c1899c@www.fastmail.com> <CAMr0u6=PBX1W5zQFmpxKQ=ViUXN9QK00BREL4M0=2HOkaXaiZw@mail.gmail.com> <VI1SPR01MB03573585C37B871D200ECC23D6739@VI1SPR01MB0357.eurprd01.prod.exchangelabs.com> <4590aaa512acf5a482c9890ebe48f1760e5831a5.camel@loup-vaillant.fr> <F9593D27-3244-470E-89BE-85215B2DC9E7@shiftleft.org> <VI1SPR01MB0357AE729116A79C8DF70516D6739@VI1SPR01MB0357.eurprd01.prod.exchangelabs.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/EY8eUxGtTAOxLZdEXiUjxd_M-As>
Subject: Re: [CFRG] Small subgroup question for draft-irtf-cfrg-hash-to-curve
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: Fri, 09 Apr 2021 16:25:32 -0000
Isn't the best solution to talk about this in the Security Considerations? This gives ample opportunity to describe the likelihood of landing in a small subgroup, and what, if any, actions an implementor wants to take. Russ > On Apr 9, 2021, at 12:18 PM, Hao, Feng <Feng.Hao=40warwick.ac.uk@dmarc.ietf.org> wrote: > > Hi Loup and Mike, > > Thanks for the comments. As your arguments have something in common, so I will reply together. > > First, let me re-iterate my two main questions: > > Do we agree we need an algorithm specification be “complete”, covering all usual and edge cases? In the current hash-to-curve draft, there is a failure mode that is non-recoverable. I’m concerned about this as I haven’t come across something like this before. My question is not on the probability, but the “completeness” of an algorithm specification. > If a protocol is provably secure under some assumption, do we agree the assumption should be “precise”? There is a clear discrepancy in what’s assumed in the CPace, OPAQUE and maybe other protocols and what’s actually provided by the concrete construction. Either should the assumption in the security proof be modified to fit the real construction, or the construction modified to fit the actual assumption in the proof. > > Both of you mention that the probability of falling into a small subgroup in common elliptic curves is negligible, and hence should be ignored. However, we should be aware of the function creep once the map-to-curve functions are deployed at scale. For example, if a user already has an input value in F_p, does he still have to go through the hash_to_field step (which is complex on its own)? A conscious implementer will quite likely skip this step. But that will give more freedom to an attacker to engineer the input such that the output falls into a small subgroup. The negligible probability in your analysis will no longer hold. For a safe implementation, precluding small-group points should be built into the map-to-curve function itself (in constant time of course). I know that’s hard, but that’s exactly why the hash-to-curve function has remained so tricky to get right in PAKE since early 2000s. > > Cheers, > Feng > > > My opinion as an implementer is two fold: > > > > 1. Excluding low-order points is quite the hassle, and it's not > > clear how I could do it in constant time. > > 2. We never generate those points to begin with. > > > > I don't want to deal with (1), which makes (2) very convenient for me. > > > So I'll just justify (2), using Curve25519 as an example: > > > > - The order of the prime subgroup is a little over 2^252. > > - The cofactor is 8. > > - Therefore, Curve25519 has a little over 2^255 points. > > - Selecting a point at random will give a low-order point about > > once every 2^252 trials. That means never. > > > > The security of a curve is basically the square root of its prime > > order. Here, 2^125 or so. Breaking it with standard brute force methods > > is incommensurately easier than stumbling upon a low-order point by > > chance. > > > > In security parlance, a probability of 1/2^255 isn't just "extremely > > small", it's "flat out impossible". I can therefore justify my laziness > > and chose not to check for that event. > > > > --- > > > > Note that generating a small-subgroup point *on purpose* will not work > > either: Curve25519 has 8 low-order points, and a maximum of 16 > > representatives for those points (maybe a couple more if we allow > > representatives over 2^255 - 19). The inputs are hashed before we map > > the hash to the curve. So it's not enough to pick a matching > > representative, we need to pick a hash whose image is one of those > > representatives. > > > > To do this, we need to conduct a multi-preimage attack on a 2^255-bit > > hash, with 16 images. The difficulty of that attack is roughly 2^251. > > Again, this is impossible if the hash is secure. > > > > As a consequence, I cannot generate test vectors that account for this > > edge case even if I wanted to. Even if I wasn't lazy, accounting for > > low-order points means writing code I cannot trigger even if I want to > > —dead code. That will only harm security in practice. > > > > > >> In CPace and OPAQUE, both protocols use the output of hash-to-curve > >> as a base generator. The implicit assumption is that the returned > >> value from hash-to-curve must be a non-identity point in a subgroup > >> of the large prime order. > > > > This assumption is correct as far as I can tell: yes, in *theory*, we > > have a couple exceptions. In *practice*, those exceptions will never > > occur. The probabilities are low enough to be considered negligible. > > > > > >> Has this issue been considered? Apologies if I missed any discussion > >> on this before. > > > > Likely. I haven't followed past discussions though, so I cannot say. > > > > Loup. > > Yeah, the usual answer is: if an event happens with negligible probability, > and an adversary can’t cause it to happen more often, and it only breaks > one thing, then it doesn’t affect security. Any reasonable adversarial > strategy has some chance to break the protocol anyway (e.g. just guess > someone’s private key), and this unlikely event doesn’t significantly > contribute to that chance. I haven’t checked the details for CPace and > OPAQUE, but for cases I’ve looked at it’s been fine. > > Of course, implementations will not be fully compliant with the spec > unless they can properly handle the identity point. They would have to > do another analysis to see whether this sort of non-compliance is itself > a security issue, but the answer would probably again be: not unless > an adversary can cause it to happen. > > Cheers, > — Mike > > _______________________________________________ > CFRG mailing list > CFRG@irtf.org <mailto:CFRG@irtf.org> > https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg>
- [CFRG] Comment on draft-irtf-cfrg-hash-to-curve-10 Daira Hopwood
- Re: [CFRG] Comment on draft-irtf-cfrg-hash-to-cur… Daira Hopwood
- Re: [CFRG] Comment on draft-irtf-cfrg-hash-to-cur… Christopher Wood
- Re: [CFRG] Comment on draft-irtf-cfrg-hash-to-cur… Stanislav V. Smyshlyaev
- [CFRG] Small subgroup question for draft-irtf-cfr… Hao, Feng
- Re: [CFRG] Small subgroup question for draft-irtf… Loup Vaillant-David
- Re: [CFRG] Small subgroup question for draft-irtf… Mike Hamburg
- Re: [CFRG] Small subgroup question for draft-irtf… Hao, Feng
- Re: [CFRG] Small subgroup question for draft-irtf… Russ Housley
- Re: [CFRG] Small subgroup question for draft-irtf… Richard Outerbridge
- Re: [CFRG] Small subgroup question for draft-irtf… Mike Hamburg
- Re: [CFRG] Small subgroup question for draft-irtf… Hao, Feng
- Re: [CFRG] Small subgroup question for draft-irtf… Scott Fluhrer (sfluhrer)
- Re: [CFRG] Small subgroup question for draft-irtf… Scott Fluhrer (sfluhrer)
- Re: [CFRG] Small subgroup question for draft-irtf… Rene Struik
- Re: [CFRG] Small subgroup question for draft-irtf… Hao, Feng
- Re: [CFRG] Small subgroup question for draft-irtf… Scott Fluhrer (sfluhrer)
- Re: [CFRG] Small subgroup question for draft-irtf… Armando Faz
- Re: [CFRG] Small subgroup question for draft-irtf… Loup Vaillant-David
- Re: [CFRG] Small subgroup question for draft-irtf… Hao, Feng
- Re: [CFRG] Small subgroup question for draft-irtf… Hao, Feng
- Re: [CFRG] Small subgroup question for draft-irtf… rsw
- Re: [CFRG] Small subgroup question for draft-irtf… Björn Haase
- Re: [CFRG] Small subgroup question for draft-irtf… Hao, Feng
- Re: [CFRG] Small subgroup question for draft-irtf… Mike Hamburg
- Re: [CFRG] Small subgroup question for draft-irtf… Hao, Feng
- Re: [CFRG] Small subgroup question for draft-irtf… Mike Hamburg
- Re: [CFRG] Small subgroup question for draft-irtf… rsw
- [CFRG] please use real names (was: Re: Small subg… Rene Struik
- Re: [CFRG] Small subgroup question for draft-irtf… Hugo Krawczyk
- Re: [CFRG] Small subgroup question for draft-irtf… Rene Struik
- Re: [CFRG] Small subgroup question for draft-irtf… Watson Ladd
- Re: [CFRG] Small subgroup question for draft-irtf… Mike Hamburg
- Re: [CFRG] Small subgroup question for draft-irtf… Hao, Feng
- Re: [CFRG] Small subgroup question for draft-irtf… Hao, Feng
- Re: [CFRG] Small subgroup question for draft-irtf… Rene Struik
- Re: [CFRG] Small subgroup question for draft-irtf… Mike Hamburg
- Re: [CFRG] Small subgroup question for draft-irtf… Mike Hamburg
- Re: [CFRG] Small subgroup question for draft-irtf… Mike Hamburg
- Re: [CFRG] Small subgroup question for draft-irtf… Hao, Feng
- Re: [CFRG] Small subgroup question for draft-irtf… Watson Ladd
- Re: [CFRG] Small subgroup question for draft-irtf… rsw
- Re: [CFRG] Small subgroup question for draft-irtf… Loup Vaillant-David
- Re: [CFRG] Small subgroup question for draft-irtf… Riad S. Wahby
- Re: [CFRG] please use real names (was: Re: Small … Filippo Valsorda
- Re: [CFRG] please use real names (was: Re: Small … Scott Arciszewski
- Re: [CFRG] please use real names (was: Re: Small … Daniel Franke
- Re: [CFRG] please use real names (was: Re: Small … Watson Ladd
- Re: [CFRG] please use real names (was: Re: Small … Michael StJohns
- Re: [CFRG] please use real names (was: Re: Small … Henry de Valence
- Re: [CFRG] please use real names (was: Re: Small … Dan Harkins
- Re: [CFRG] Small subgroup question for draft-irtf… Hugo Krawczyk
- Re: [CFRG] please use real names (was: Re: Small … Peter Gutmann
- Re: [CFRG] Small subgroup question for draft-irtf… Hao, Feng
- Re: [CFRG] please use real names (was: Re: Small … Squeamish Ossifrage
- Re: [CFRG] please use real names (was: Re: Small … Blumenthal, Uri - 0553 - MITLL
- Re: [CFRG] Small subgroup question for draft-irtf… Stanislav V. Smyshlyaev
- Re: [CFRG] Small subgroup question for draft-irtf… Björn Haase
- Re: [CFRG] please use real names (was: Re: Small … Soatok Dreamseeker
- Re: [CFRG] please use real names (was: Re: Small … Blumenthal, Uri - 0553 - MITLL
- Re: [CFRG] please use real names (was: Re: Small … Soatok Dreamseeker
- Re: [CFRG] Small subgroup question for draft-irtf… Mike Hamburg
- Re: [CFRG] please use real names (was: Re: Small … Daniel Franke
- Re: [CFRG] please use real names (was: Re: Small … Mike Hamburg
- Re: [CFRG] Small subgroup question for draft-irtf… Mike Hamburg
- Re: [CFRG] please use real names (was: Re: Small … Colin Perkins
- Re: [CFRG] please use real names (was: Re: Small … Blumenthal, Uri - 0553 - MITLL
- Re: [CFRG] please use real names (was: Re: Small … Soatok Dreamseeker
- Re: [CFRG] please use real names (was: Re: Small … Mike Hamburg
- Re: [CFRG] please use real names (was: Re: Small … Michael StJohns
- Re: [CFRG] Small subgroup question for draft-irtf… Hao, Feng
- Re: [CFRG] please use real names (was: Re: Small … Michael Sierchio
- [CFRG] Closure (was Re: Small subgroup question f… Hao, Feng
- Re: [CFRG] please use real names (was: Re: Small … Phillip Hallam-Baker
- Re: [CFRG] please use real names (was: Re: Small … Peter Gutmann
- Re: [CFRG] please use real names (was: Re: Small … David Jacobson
- Re: [CFRG] please use real names (was: Re: Small … Julia Hesse
- Re: [CFRG] Closure (was Re: Small subgroup questi… Armando Faz
- Re: [CFRG] Closure (was Re: Small subgroup questi… Hao, Feng
- Re: [CFRG] Closure (was Re: Small subgroup questi… Mike Hamburg
- Re: [CFRG] thoughts on clearing the cofactor in h… Loup Vaillant-David
- Re: [CFRG] Comment on draft-irtf-cfrg-hash-to-cur… Stanislav V. Smyshlyaev
- Re: [CFRG] Comment on draft-irtf-cfrg-hash-to-cur… Daira Hopwood
- Re: [CFRG] Comment on draft-irtf-cfrg-hash-to-cur… Riad S. Wahby
- [CFRG] (suggested language re mixing square roots… Rene Struik
- Re: [CFRG] Comment on draft-irtf-cfrg-hash-to-cur… Loup Vaillant-David
- Re: [CFRG] Comment on draft-irtf-cfrg-hash-to-cur… Daira Hopwood
- Re: [CFRG] (suggested language re mixing square r… Daira Hopwood
- Re: [CFRG] (suggested language re mixing square r… Rene Struik
- Re: [CFRG] please use real names (was: Re: Small … isis agora lovecruft