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

[mary-ext]

Seems rather unfortunate that the move is on "future new apps" rather than existing apps, 3 years since the issue being closed there are still new software being put out that makes use of secp256k1 like AT Protocol.

[coolaj86]

We're literally talking about a standard that's already universally supported on every device and platform.

It's not like anyone has to reimplement it or do any real head-scratching, right?

This is a simple matter of passing the string or int representing the name and algo down with the bytes to openssl or whatever OS lib it's binding to and then pass the result back up. Copy/paste a few lines from the currently supported ECDSA, right?

Or am I wrong?
(and maybe I am wrong, but I was just looking at openssl bindings in postgres a few days ago, so I don't think I am)

I'm all for cleaning up cruft, but as a person who is not a "crypto bro", I still have to deal with it and interop, and as much as I hugely appreciate and depend on @paulmillr's excellent work, I'd rather not carry around all that extra JS. Push it back down into the depths of the C++ binding where it belongs.

Like it or not (and I'm in the "not" category myself), secp256k1 is going to continue to be used to build new applications on the web for a long while yet - so let's swallow the [pride / politics / wrong-side-of-bedness / whatever-it-is] and accept that it's a vital algorithm that isn't going away.

P.S. Where is the idea that "no new applications are being built with it" coming from? This is patently false. It's so absurdly false that even talking about it seems to give more credence to the idea than it's worth. But just so we're all clear, the latest application being developed out in the open was updated 35 seconds ago: https://github.com/search?q=secp256k1&type=repositories&s=updated&o=desc

[saurik]

I find the premise that our platforms should only ever support developing new platforms and not ever try to provide support for existing ones extremely confusing.

If we are to take this to heart as correct, no one would ever bother to implement software that interpreted with any existing prior standard, as no standard is perfect.

Clearly we don't do this: new protocols and standards come out all the time that don't hesitate to interoperate with such sad stories as HTTP (even 1.x) and IPv4.

So, maybe people are trying to claim that cryptography libraries are special and particularly sensitive and so should accept usability tradeoffs to protect developers?

If that were the case, this also makes no sense, as the security world has pretty universally decided that low-level crypto APIs -- such as WebCrypto! -- are harmful.

Like, this entire discussion is coming from a place that feels a bit ridiculous: the only reason to use WebCrypto at all is to interoperate with custom older cryptography.

If you are building a new application, one should use a high-level cryptography API, and the browser is frankly filled with them: APIs that are secure and "just work".

As it is, there is a maybe-confusingly-popular set of platforms out there that people happen to want to interoperate with; the cost to WebCrypto is almost nil... what gives? :(

[twiss]

OK, let me explain a bit better where I'm coming from.

The Web Crypto API is currently severely lacking secure and modern algorithms in several categories. (The most severe example IMHO is that PBKDF2 is the only password hashing function available, but there are other examples.) This is encouraging and incentivizing developers who are creating a new web app using cryptography from scratch (and not using an existing standard or library) to use those algorithms that are available in Web Crypto, because it leads to the best performance and the least work, but does not lead to the best security. IMHO, that is the most urgent problem with Web Crypto today (which is why I wrote the Modern Algorithms in the Web Cryptography API draft), although it is not the only problem (not having a high-level API is another one).

In the category of elliptic curves, the situation was not quite as bad as with password hashing functions, but using Curve25519 or Curve448 in new applications would still be better, so that's why I wrote the Secure Curves in the Web Cryptography API draft, specifying both. But note that so far, browsers have only implemented Curve25519, not Curve448, despite me proposing both. So it's not really me you have to convince, but the implementers :)

All of this is not to say that adding algorithms to serve existing applications and protocols to Web Crypto is not worthwile, I just think it's not the highest priority at the current moment.

Personally I think that even if I write a draft proposing the addition of secp256k1, browsers won't implement it; so I won't. But you're still free to write the draft and try to convince implementers to add it :)

---

Finally, to those saying that it should be easy to implement and has no cost; AFAIK neither BoringSSL (used in Chromium) nor NSS (used in Firefox) have support for secp256k1. They don't need it since TLS doesn't use it (unlike Curve25519 and Curve448). Proposing to add something not used in TLS is always a taller order because it leads to additional code and maintenance burden for the implementers. That's not to say it can't be done but it's an additional reason that I personally think it's unlikely to happen anytime soon.