Bug 29005 - Add support for secp256k1 curve

[mwatson2]

Bug 29005:

Bitcoin uses the secp256k1 curve for generating signing keys. Even though this is not a standard NIST curve, it is part of the published specifications by SECG (see: http://www.secg.org/sec2-v2.pdf).

Moreover, a number of browser based (both plugins and web page based) bitcoin wallets use the SJCL (https://crypto.stanford.edu/sjcl/) library for bitcoin transaction creation. This is less desirable than native browser support for cryptographic operations. Adding this curve to the Web Crypto standard would allow browser vendors to include this as part of their standard offering.

[mwatson2]

@sleevi wrote:

This was already discussed on Bug 24444, with some broader (related) discussion on Bug 25839.

You can also see past discussion at https://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Dec/0000.html

At the minimum, the next steps are to write a new specification detailing how it would work and convincing the WG of adoption and vendors to implement.

Speaking purely as a single vendor, there are no plans for Chromium to support this curve.

[mwatson2]

I suggest at this point that we classify this as VNext. Opinions ?

[jimsch]

I would agree - somebody is going to write an updated algorithm set for the CFRG algorithms anyway.

[hhalpin]

I'll take an action item to do that, as I need to update that document before we exit CR, and make the process for suggesting new algorithms for future versions clearer.

[xcthulhu]

@hhalpin I know this is an old thread, but here's my 2¢

Apart from simply supporting secp256k1, BitCoin uses a public-key recovery byte that it bundles with its signatures. This is described in http://www.secg.org/sec1-v2.pdf, page 47. Many other digital currencies also use this curve and rely on this scheme.

After secp256k, the next most commonly used scheme is the twisted Edwards curve ED25519 and EDDSA. This is also supported by NaCl. Perhaps I should open another issue?

BitCoin Core's libsecp256k1 also supports RFC 6979 deterministic nonces for its ECDSA signatures (see here for more details). Other libraries also support this, including elliptic.js, Java's BouncyCastle, and NaCl. It's very hard to know as a security researcher if a vendor's secure random number generator truly is secure without spending a lot of time looking for bias; I am not alone in wanting the ability to ensure this.

BitCoin makes use of RIPEMD160 in and SHA256 in computing addresses from public keys. Ethereum, the second largest digital currency next to BitCoin, uses Keccak256 (not to be confused with NIST's SHA3, which is based on this algorithm) for computing its addresses. Once again, perhaps this is the topic of another issue.

One of profound struggles for cryptographers in JavaScript (both working digital currency and elsewhere) is keeping code performant. It would be a massive boon if many of the common algorithms developers use could find native implementations.

[Janaka-Steph]

Any update?

[paulmillr]

No updates for 4 years — sad!

For now, i've created a cross-platform library for secp256k1. It has no dependencies, is very fast & auditable.

Check it out: https://github.com/paulmillr/noble-secp256k1

[twiss]

I know this is likely to disappoint many, but Chrome has signaled that they are opposed to adding this, and personally, I agree - while secp256k1 is interesting for compatibility with existing applications, it is not an obvious choice for building new secure web apps - which I believe should be the focus of the future additions to the Web Crypto API, as I laid out in #249 (comment). Curve25519 or Curve448 would be a more obvious choice when building a new application, I believe. Irregardless of that, I also think it's unlikely that any of the other implementers would be in favor of adding secp256k1, so I'll close this issue.

[TJKoury]

It is too bad integration is opposed by the core devs as the largest, most secure PKI systems in the world (BTC and ETH) use it. Enabling it would allow revolutionary new cases like decentralized certificate authorities.

[ivica7]

@TJKoury I have to totally agree on that! It would also be very useful for the current consortial blockchain project that we're working on.

[hazae41]

7 years have passed, the good news is Edwards curve is now available in Safari, so Koblitz can maybe come in a few years lol

Koblitz curve is powerful for a number of applications because it can recover a public key from only a signature and a recovery byte

I made a WebAssembly port of RustCrypto's secp256k1, and an adapter for compatibility with @paulmillr's audited secp256k1

https://github.com/hazae41/secp256k1

[cf]

It is a bit perplexing why this issue is closed. At this point secp256k1 secures > $2 trillion dollars of assets, and it seems rather clear that the inclusion of P-256k1 would be useful in many use cases.

[hazae41]

They won't add support for backdoor-less curves

[coldstar1993]

No updates for 8 years — sad!

[twiss]

It is a bit perplexing why this issue is closed. At this point secp256k1 secures > $2 trillion dollars of assets, and it seems rather clear that the inclusion of P-256k1 would be useful in many use cases.

@cf Could you elaborate a bit on what all the "clear" use cases for secp256k1 are? To me, to be frank, it seems that there's only one use case (Bitcoin, and other cryptocurrencies like ETH) although you might of course find that use case very important.

They won't add support for backdoor-less curves

@hazae41 This kind of unfounded speculation is not very helpful. I've been actively working on the draft for adding Curve25519 and Curve448 (and Ed25519 is implemented in Safari now), do you think those are backdoored?

No updates for 8 years — sad!

@coldstar1993 IMHO #82 (comment) was a rather concrete update even you don't like its contents 😅

---

Note also that, despite what I wrote, nothing is stopping anyone from writing a draft for secp256k1 in Web Crypto, and trying to convince implementers to support it. I personally think trying to convince browsers to implement secp256k1 will be tough, especially since one browser has already signalled that they're opposed, but if you want to try, don't let me stop you!

[pkieltyka]

Could you elaborate a bit on what all the "clear" use cases for secp256k1 are? To me, to be frank, it seems that there's only one use case - Bitcoin - although you might of course find that use case very important.

@twiss in addition to Bitcoin, all Ethereum chains (ie. Ethereum mainnet, Arbitrum, Polygon, Optimism, Base, etc...), all use the secp256k1 curve as well. The clear use case is to generate a public-private keypair of a secp256k1 curve where the private key is non-exportable and use it as a signer for clients (aka wallets) interacting with blockchains that rely on secp256k1.

[twiss]

Right, yeah, after going back to read the thread I edited my comment to add ETH after seeing it mentioned. So fair enough.

Nevertheless, all of this still falls under the category of "interoperability with existing applications" - which might still be considered really important applications, of course. But nobody is really advocating or recommending secp256k1 for use in new applications, AFAIK - e.g. there's no IETF RFC for it, and so on.

I went digging a bit and found this thread on the mailing list of the CFRG (Crypto Forum Research Group of the IETF): https://mailarchive.ietf.org/arch/msg/cfrg/iunvB1Ozatx2PrMI1W6bwveJwUs/. The entire thing is worth reading but in particular it links to https://safecurves.cr.yp.to/, which points out that secp256k1 is not a "safe" curve as defined by that page.

Now, it may still be safe for use in Bitcoin and Ethereum, but we shouldn't be endorsing or encouraging its use in new applications, which IMHO adding it to Web Crypto implicitly does.

[paulmillr]

safecurves is marketing material by DJB for his stuff. He picked a bunch of important points and a bunch of irrelevant points - while conveniently forgetting another bunch of important points. DJB's stuff is not safe in many ways: example.

It's also outdated. For secp256k1:

• "complete" and "ind" are now true, not false
• "ladder" is irrelevant bc "complete" is true
• "disc" (discriminant) is irrelevant, because it's actually a feature of secp256k1: the endomorphism. DJB thinks it's unsafe but no one broke these in 30 years. So, security story is straight

[paulmillr]

I don't think we should convince anyone who doesn't believe it's right. Brave is planning to add secp256k1 natively. That's the proper way to do it.

but we shouldn't be endorsing or encouraging its use in new applications

Why not? secp256k1 is not backdoored, allows ecdh and is time-tested. It's implemented in all kinds of hardware modules. nostr social network was created on top of it, just a few years ago.

1. P256 and P384 are speculated to be backdoored. In djb's terms it's "rigidity"
2. ed25519 can't be used for ECDH: you need curve25519. Converting between them is error-prone

[twiss]

DJB's stuff is not safe in many ways: example.

I know that cryptocurrencies have somewhat specific requirements, hence the existence of ZIP215 and ed25519consensus implementations etc. I don't know that that extends to Curve25519 not being safe in general, though. But I understand that DJB's criteria might be considered irrelevant in some cases too, of course.

However.. I think the W3C is not really the right venue to discuss the relative merits of cryptographic algorithms. The CFRG is a better place for that. That's why I would prefer to follow the recommendations of the CFRG in the Web Crypto spec, in general. This has other advantages as well, e.g. implementations can reuse code/libraries between TLS and Web Crypto in many cases.

That being said,

Brave is planning to add secp256k1 natively.

That's news to me :) (Do you have a reference / is this stated publicly somewhere?) If one browser ships it it might be easier to get the others along. It would be great if Brave could write up a draft specifying what they're planning to ship, then.

[hazae41]

@paulmillr

3. It can recover a public key from only a signature and a recovery byte

This is extremely useful