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

Jeff Burdges <> Fri, 17 January 2020 14:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3E46120828 for <>; Fri, 17 Jan 2020 06:49:49 -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 XU0VEHkjLDX0 for <>; Fri, 17 Jan 2020 06:49:47 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 96B2D1201DB for <>; Fri, 17 Jan 2020 06:49:47 -0800 (PST)
Received: from [] ( [IPv6:2001:4ca0:2001:42:225:90ff:fe6b:d60]) by (Postfix) with ESMTP id 99FC41C00D2 for <>; Fri, 17 Jan 2020 15:53:06 +0100 (CET)
From: Jeff Burdges <>
Content-Type: multipart/signed; boundary="Apple-Mail=_ABB1545C-EBEA-4CD8-B9E6-24290750C2E4"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 17 Jan 2020 09:49:39 -0500
References: <> <> <> <100b35bb-5ed6-4cca-80ee-5b2dda90fbbf@Spark>
To: "" <>
In-Reply-To: <100b35bb-5ed6-4cca-80ee-5b2dda90fbbf@Spark>
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: Fri, 17 Jan 2020 14:49:52 -0000

> On 17 Jan 2020, at 08:02, Christian Lundkvist <> wrote:
> Thanks for your response! As I understand it NIST is considering adopting support for the curve Ed25519. A large part of this is because this curve has seen fairly widespread use in the industry.

Ed25519 is considered stronger and safer to implement and use than comparable NIST curves.  Ed25519 should be encouraged over those other NIST options.

> What is the reason you feel that this curve is worth supporting and the curve secp256k1 is not?

secp256k1 usage otoh should be discouraged.  Aside from secp256k1’s theoretical weaknesses, secp256k1 is much harder to implement, and worse many insecure implementations of sep256k1 and protocols using it exist.

We literally avoid a whole ecosystem foot guns by not touching secp256k1:  SECIO has serious problems.  BIP32 is poorly conceived and miss-use prone.  ecRecover+BIP32 might interact poorly with other protocols.  We all know many secp256k1 ECDSA implementations handle randomness poorly, but that problem is hardly resolved..  I just today recommended rejecting a grant applicant that believed signers could safely precompute nonces in a multi-signature.

secp256k1 is not a case of industry usage, but of industry miss usage.

Now if someone wants to use secp256k1 with existing blockchains then yes of course they can manage the risks, but standards bodies should not rubber stamp poor practices by industry, and should not be distracted by all the mess in the secp256k1 ecosystem.


p.s.  At this point EdDSA should be favoured over ECDSA too, so I’d argue against standardising any new curves with significant ECDSA deployments.