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

[Jeff Burdges <[e-mail]>]

> On 17 Jan 2020, at 08:02, Christian Lundkvist <[e-mail]> 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.

Jeff

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.