Re: [Cfrg] hash-to-curve updates and suite reduction

Mike Hamburg <> Fri, 01 May 2020 23:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 142EA3A1545 for <>; Fri, 1 May 2020 16:52:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2SIIhmfh1dRk for <>; Fri, 1 May 2020 16:52:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5D3213A154A for <>; Fri, 1 May 2020 16:52:38 -0700 (PDT)
Received: from [] (unknown []) (Authenticated sender: mike) by (Postfix) with ESMTPSA id 6AEBD798; Fri, 1 May 2020 16:52:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=sldo; t=1588377157; bh=Wz1xXyyEMVWwfZuXYq5zGa9gQ6lGo2v5sDdMDkB1ijE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=SfIf5dQ6G++HG6uM6ZaNvfcNglM/tfGzBN3tUZRodZe/5C9AC8YFosPg5fHK+mgON LmLLgwmqnq4rI5KOtbpP+nGu29U05VpswChNp6JAdfwpw9iTTnqsmgn8EAgWCvdS1Y 9BOIuuFmjMN1i9ZFd5lC2v/cRyxeD4yc5WfK5vqE=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Mike Hamburg <>
In-Reply-To: <>
Date: Fri, 01 May 2020 16:52:36 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Christopher Wood <>
X-Mailer: Apple Mail (2.3608.
X-Virus-Scanned: clamav-milter 0.102.2 at
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [Cfrg] hash-to-curve updates and suite reduction
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: Fri, 01 May 2020 23:52:46 -0000

Hello Christopher,

Sorry to be so late in the game on this, but I have a concern about Elligator 2 as defined in hash-to-curve.

One of the nice properties of Elligator 2 is that it’s an injective map on [0..(p-1)/2], which is useful for canonically inverting the map.  However, the draft version is not injective on this domain.  Wouldn’t it be better to choose sgn(t) according to is_square(gx1) instead of according to sgn(u)?  That would also make it match the paper, except for the different definitions of sgn().

— Mike

> On Apr 28, 2020, at 5:39 AM, Christopher Wood <> wrote:
> Hi folks,
> The hash-to-curve authors spun draft-irtf-cfrg-hash-to-curve-07 recently [1]. Some of the major changes focus on how we handle DSTs for domain separation in hash_to_field. If you have some spare cycles, please have a look and provide feedback! 
> In addition to this change, I'd also like to call attention to the section on suites [2]. We've heard criticism that there are currently too many suites defined, which can complicate implementations and protocols [3]. The list should likely be reduced. In particular, the document should probably specify at most one recommended suite covering both the RO and NU cases for each curve. (Alternatives could be defined elsewhere, i.e., in separate documents if needed.) 
> In this interest of document clarity and ease of use by the community, we'd like to know what folks think about this proposal. Some questions to consider are:
> - What should be the preferred mapping function for each curve? For example, P-256 specifies P256_XMD:SHA-256_SSWU_RO_  and P256_XMD:SHA-256_SVDW_RO_, which use the Simplified SWU (SSWU) and Shallue-van de Woestijne maps, respectively. Considering libraries that might implement the Shallue-van de Woestijne for more than one curve, should we err towards code re-use or stick with the less-general SSWU map?
> - Should each curve have one suite for the RO case and another for the NU case? Doing so assumes implementers know when and how to choose between these two variants. This is something the document mostly skips over, saying simply, "When the required encoding is not clear, applications SHOULD use a random oracle."
> Thanks in advance for your time and consideration.
> Best,
> Chris
> [1]
> [2]
> [3]
> _______________________________________________
> Cfrg mailing list