Re: [Cfrg] Recommending secp256k1 in FIPS 186-5

Jeff Burdges <> Thu, 19 December 2019 17:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7056812002E for <>; Thu, 19 Dec 2019 09:14:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.531
X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JCEDYqFrcBby for <>; Thu, 19 Dec 2019 09:14:09 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9EEB120170 for <>; Thu, 19 Dec 2019 09:14:08 -0800 (PST)
Received: from [] ( [IPv6:2001:4ca0:2001:42:225:90ff:fe6b:d60]) by (Postfix) with ESMTP id 1C2651C00D2 for <>; Thu, 19 Dec 2019 18:17:05 +0100 (CET)
From: Jeff Burdges <>
Content-Type: multipart/signed; boundary="Apple-Mail=_6D900478-FE80-493C-BAC6-60C03CAB2171"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 19 Dec 2019 18:13:59 +0100
References: <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [Cfrg] Recommending secp256k1 in FIPS 186-5
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: Thu, 19 Dec 2019 17:14:11 -0000

At the high level, there is a good summary of this conversation at  but three key points:

First, secp256k1’s usage in bitcoin and ethereum provides no reason to recommend its use elsewhere.

Second, existing recommendations for curves like P256 provides no reason to recommend additional other less than perfect curves.  In fact, I’d hope future discussions turned towards revoking existing recommendations, like P256, and replacing them with more modern alternatives like Decaf/Ristretto, and curves with more utility, like ZCash’s JubJub.

Third, there are many poorly designed, or outright insecure, protocols like SECIO are built on secp256k1 whose usage should not be encouraged.  Any recommendation for secp256k1 makes these protocols might encourage their usage.  We should also be wary of nasty interactions between existing secp256k1 protocols like BIP32 and ECDSA multisigs.

It’s possible that secp256k1 might become more interesting if any future protocols exploit its mirror curve, but this does not sound like a reason for recommending it now.  I think Blockstream put serious effort into exploiting this, but I’m not sure if anything really emerged.


> On 19 Dec 2019, at 16:29, Dan Burnett <> wrote:
> Hello,
> I have been a participant in several IETF Working Groups over the years, most recently RTCWEB (and W3C's WebRTC), but not this RG in particular.  However, I frequently recommend this group as highly knowledgeable when it comes to wise choices in cryptographic recommendations.  I learn something new every time I sit in on this group's sessions at IETF meetings.
> As mentioned in another thread, NIST is seeking feedback on their recently-released draft of FIPS 186-5. [1]
> My company and others are concerned about the lack of endorsement for secp256k1 in this standard and have drafted a request for its addition.[2]  We would welcome any comments and/or support from this group and/or any of its members (directly in the Google Doc linked below).  All comments are welcome, including those arguing against this request :)
> Thanks,
> Dan Burnett
> ConsenSys
> [1]
> [2]
> _______________________________________________
> Cfrg mailing list