Hey @panva, thanks, good questions. I'll start with the good news; I've reached out to the browser vendors re. Curve25519 and Curve448, and have received some positive signals regarding those. I'm planning to push that forward myself, and then move on to gathering signals re. more secure/modern ciphers and algorithms (e.g. a KDF, and an AEAD algorithm). New features (e.g. #73, #270) are last on my list. Then, for some bad news, I've received negative signals re. secp256k1, so it's not on the list.

This repository's issue board is not a bad place to post proposals, but another option (or, perhaps, good next step) is the WICG Discourse board. In general, any major additions to this spec should go through the WICG (i.e. post to the discourse with a proposal, then create a repo with an explainer document, collect feedback, etc.). I will do so for Curve25519&Curve448, if you want to take up any of the others, please feel free to (or if you care about and want to push forward one from the list above let me know, I can reach out to the browser vendors about interest). One other example that did so is crypto.randomUUID(), which is expected to be merged into the Web Crypto spec.

Re. Node.js's and Deno's implementations, I was aware of them and consider them important. I wasn't aware of the implementation in Cloudflare Workers, thanks for that. I think it would still be good to get interest from the browser vendors, though. Hopefully the above gives you some confidence that that might be possible ^.^

Thank you so much for your answer here. I will do my best to digest and maybe shoot a couple of follow up questions.

Then, for some bad news, I've received negative signals re. secp256k1, so it's not on the list.

Interesting, a hypothetical exercise - all non-browser implementors would show positive signals on it, what then?

cc'ing @jasnell (Cloudflare Workers & Node collaborator), @lucacasonato (Deno core team), @littledivy (Deno contributor) for visibility. Myself also Node collaborator.

Interesting, a hypothetical exercise - all non-browser implementors would show positive signals on it, what then?

I'm not sure. For secp256k1, as I mentioned in #82 (comment), I think there are good reasons not to add it, and I think we should push users towards Curve25519 and Curve448 instead wherever possible. If you disagree, we can discuss that in that issue.

For any other hypothetical case, I think it's a bit hard to discuss in the abstract; if it's e.g. one of the other issues I listed, I'm happy to go and try to convince the browser vendors that it should be implemented. I think we should try that before considering other options. The goal of the spec is to have interoperability between all implementations, so if all browsers are opposed, then it would be difficult to achieve that, and it may be sign that the feature somehow isn't a good fit for the web platform. If that's not the case and the signals are "neutral", e.g. due to a lack of bandwidth, then that may be a different story.

@twiss I for one will help you make a case for including secp256k1, and recommend that you reopen that issue. The SafeCurves exclusion issue is way overblown and a nitpick at best.

It’s clearly a secure curve in practice, backed by an over $2T ecosystem (at the time of this comment) including Bitcoin. I don’t think anyone in this space is saying Bitcoin is going away, and if the Bitcoin Core devs decide to use a different curve for security reasons, it would be trivial to deprecate.

What everyone seems to be thinking but is too polite to say out loud is the appearance of big tech companies fighting decentralization and not supporting it with their products (like Chrome).

@TJKoury Thanks for the offer, but - not to seem too pessimistic, but - I'm currently already having some trouble getting engagement from implementers on the Secure Curves in WebCrypto draft, which adds Curve25519 and Curve448. I got more positive signals from implementers about those curves than about secp256k1, so - if we can't get Curve25519 and Curve448 added, then - frankly - secp256k1 has no chance. To phrase that in a more positive way, if you want to help, please also help by championing Curve25519 and Curve448.

To be honest, I think at this point, what we really need is someone willing to implement these curves, in some or all open source implementations. This is not an easy task, but may be helped by existing implementations for TLS - though most browsers currently only support X25519, not Ed25519 nor X448 and Ed448 (see https://bugzilla.mozilla.org/show_bug.cgi?id=1325335 and https://bugzilla.mozilla.org/show_bug.cgi?id=1597057 for Firefox bugs on that). If someone is willing to write patches for these, and the browsers are willing to accept them, that would be the strongest signal possible to show implementer interest :)

@twiss

I'm currently already having some trouble getting engagement from implementers

Curve25519 and Curve448 can be added, relatively fast, to Node, Deno, and Cloudflare Workers (with it also Vercel Edge Functions). Which I believe was signalled clearly.

I asked previously

Interesting, a hypothetical exercise - all non-browser implementors would show positive signals on it, what then?

And it, indeed, seems like even very positive signals or intents to implement from non-browser implementors weigh very little here.

@twiss Unless there’s some sort of issue we can use the OpenSSL implementations of all these curves.

(Sorry for the delay.) @panva I understand and partly share your frustration. However, looking at WICG/proposals#46, it may not be totally obvious that there are intents to implement. Could you (and maybe @lucacasonato and @jasnell) leave a comment there stating as much, perhaps? Then I'll try to ping some people from the W3C and hopefully get this moved to the WICG.

@TJKoury Not every implementation uses OpenSSL. Deno uses ring (I believe), Firefox uses NSS, Chrome uses BoringSSL (which admittedly is a fork of OpenSSL), and none of those include an implementation of Curve448, for example (though perhaps OpenSSL's implementation of Curve448 could be added to BoringSSL). In any case, it's not entirely trivial, and I believe that for the implementations that haven't signaled an intent to implement yet, it's mainly about lack of bandwidth to implement, not any opposition to doing so.

cc @littledivy Please see @twiss message ☝️

@twiss My point was and remains that OpenSSL is well tested, open source, has a permissive license, and contains everything that is required. It’s a good starting point.

Not every implementation uses OpenSSL (...). In any case, it's not entirely trivial

I think a major pain point with Web Crypto is the extremely limited set of algorithms with no useful extensibility. For example, Deno (in the extended Web Crypto interface in std/crypto, not the built-in one) and Cloudflare Workers both provide MD5 as a non-standard extension because the reality is that many applications still need MD5. The argument that it was excluded from Web Crypto because it is cryptographically weak barely holds, given that SHA-1 was included in Web Crypto. (And, conversely, no SHA3 hash functions are available through Web Crypto either.)

It's not great that Web Crypto lacks feature detection beyond trial and error, but for some widely used algorithm to be included in the specification, it should not be a requirement that it is implemented in every runtime.

And it is not, as the existing spec says:

In addition to providing a common interface to perform cryptographic operations, by way of the SubtleCrypto interface, this specification also provides descriptions for a variety of algorithms that authors may wish to use and that User Agents may choose to implement.

Aside from Curve25519 and Curve448, AES-CCM, AES-OCB, ChaCha20, ChaCha20-Poly1305, Salsa20, Poly1305, SHA-3, BLAKE2b, scrypt, Argon2, etc., are all widely used algorithms, and if Web Crypto is supposed to be a relevant standard, it must go beyond the existing, extremely limited set of features, even if some user agents have no intention of implementing some or all of these algorithms.

(Thanks @tniessen, @panva and @lucacasonato for leaving a comment!)

I think a major pain point with Web Crypto is the extremely limited set of algorithms with no useful extensibility.

I definitely agree that the limited set of algorithms is a pain, however, I'm not sure I agree on the extensibility. The Web Crypto standard wants all algorithms to be documented in a standard, and I also think that's a good thing to have. It's just that, so far, there was no Working Group for doing so, and technically there still isn't, though proposals can still be submitted to the WICG in the meantime. WICG/proposals#46 is a bit of a "trial" for doing so, which only adds Curve25519 and Curve448, but I agree that that doesn't go far enough, and I hope that if it goes well, we can add other algorithms using a similar process in the future (though personally, I would prefer to focus on algorithms that are more secure than the ones we already have, not less secure).

It's not great that Web Crypto lacks feature detection beyond trial and error

(FWIW, I also agree on this. We could think about a crypto.subtle.isAlgorithmSupported function, or something like that.)

+1 for secp256k1

Who is calling the shots around here, browser vendors or javascript developers?

+1 for secp256k1

Who is calling the shots around here, browser vendors or javascript developers?

It’s obviously the powerful JavaScript Developers Union. 😂

Who is calling the shots around here, browser vendors or javascript developers?

It doesn't really matter who is calling the shots regarding including something in the specification, because the end goal of specifying something is getting it implemented everywhere, and in the end the implementers (obviously) decide whether to implement something or not.

I don't want to speak for all the implementers here (and certainly there are some implementers that do want to implement secp256k1), but there are some implementations that have a goal of minimizing the amount of attack surface of their cryptography API, to make it more easily auditable. Similarly, Firefox has a formally verified implementation of X25519 (from HACL*) - adding the same for other curves takes work and time. I'm not saying that that work and time is not worth it, but personally I think it makes more sense to focus first on (exposing that implementation to web developers and then) adding X448, for example, which offers meaningfully increased safety margins, compared to secp256k1, which is mainly interesting for compatibility with existing protocols. That's one of the reasons why I decided to start with Curve25519 and Curve448 in WICG/webcrypto-secure-curves.

But, that being said, there's nothing preventing anyone from writing another document specifying the use of secp256k1 in the Web Crypto API, and proposing it to the WICG. Personally I feel that there are other algorithms that are more sorely missed by more web developers (e.g., a more secure alternative to PBKDF2), but if you disagree, you should in fact feel free to do so ☺️
My first comment in this issue has some pointers for how to do so, e.g. this link on contributing new proposals to the WICG.

A bit of good news: the new charter of the WebAppSec Working Group has been adopted. It states that

The WG may adopt well-supported proposals from incubation for maintenance of the Web Cryptography API.

which basically means that new proposals should be submitted to the WICG, and can then be merged here once they're widely supported. Of course this was essentially already the case (and already happened with randomUUID and hopefully soon Curve25519 and Curve448), but now it's official 😊

In hopes that that sufficiently answers the title question of this issue, I'll close this issue, but I'll leave it pinned to make it easy to find.