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

From: Christian Lundkvist <[email-masked]>
Date: Fri, 17 Jan 2020 08:02:55 -0500

Hi Uri,

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.

What is the reason you feel that this curve is worth supporting and the curve secp256k1 is not? Is it only due to the relative security considerations of these curves? Can you point us to any specific security weaknesses or exploits of the curve secp256k1 that you feel would make it unsuitable for digital signature use?

Best regards,
Christian Lundkvist
On Dec 19, 2019, 12:06 -0500, Oliver Terbu <[email-masked]>, wrote:
> Looping in Christian who is our cryptographer.
>
> Christian, could you please follow up?
>
> Thanks,
> Oliver
>
> > On Thu, Dec 19, 2019 at 5:27 PM Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
> > > Sorry, I've said all I could (in a short email ;).
> > >
> > > Regards,
> > > Uri
> > >
> > > Sent from my iPhone
> > >
> > > > On Dec 19, 2019, at 11:09, Dan Burnett <[email-masked]> wrote:
> > > >
> > > > Thank you.  Can you say more?  The standard argument of "strongest is best" I already get, but I suspect you have other arguments than that in mind.  I have cc'd Oliver Terbu, who worked on this doc, in case he has more specific questions for you.
> > > >
> > > > -- dan
> > > >
> > > >
> > > > > On Thu, Dec 19, 2019 at 10:57 AM Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
> > > > > > In my humble opinion it is not.
> > > > > >
> > > > > > Regards,
> > > > > > Uri
> > > > > >
> > > > > > Sent from my iPhone
> > > > > >
> > > > > > > On Dec 19, 2019, at 10:49, Dan Burnett <[email-masked]> wrote:
> > > > > > >
> > > > > > > Out of politeness I don't want to dump the whole summary into the email, but the brief answer is for products and solutions using Bitcoin, Ethereum, etc.  The question is whether it is strong enough to include, not whether it is weaker than something else.
> > > > > > >
> > > > > > > -- dan
> > > > > > >
> > > > > > >
> > > > > > > > On Thu, Dec 19, 2019 at 10:37 AM Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
> > > > > > > > > Why would I want another curve (secp256k1) that is weaker than the currently used secp256r1?
> > > > > > > > >
> > > > > > > > > From: Cfrg <[email-masked]> on behalf of Dan Burnett <[email-masked]>
> > > > > > > > > Date: Thursday, December 19, 2019 at 10:31 AM
> > > > > > > > > To: CFRG <[email-masked]>
> > > > > > > > > Subject: [Cfrg] Recommending secp256k1 in FIPS 186-5
> > > > > > > > >
> > > > > > > > > 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] https://www..federalregister.gov/documents/2019/10/31/2019-23742/request-for-comments-on-fips-186-5-and-sp-800-186
> > > > > > > > > [2] https://docs.google.com/document/d/1wygRHPMGhhanDev7iZSn_AlXw6FZdTK-cIh4fXD77jk/edit#heading=h.1xljt59f35x5
> > > > > > > > >

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 17 Jan 2020 14:10:38 +0000

There were several publications a while ago that described attacks on this type of curves, which I don't have time (or desire) to dig out. Do a search.
There are other reasons as well that I choose not to go into here and now.

Suffices to say that the consensus was - we do not want to support this curve.

You like it - use it. Don't ask us to.

Thanks

Regards,
Uri

> On Jan 17, 2020, at 08:03, Christian Lundkvist <[email-masked]> wrote:
> 
> 
> Hi Uri,
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: Jeff Burdges <[email-masked]>
Date: Fri, 17 Jan 2020 09:49:39 -0500

> On 17 Jan 2020, at 08:02, Christian Lundkvist <[email-masked]> wrote:

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.