A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

[Proposal] Add curve 25519 and cruve 448 to the web cryptography api


Hey, Wicg discourse group members!

It seems that web cryptography api development could be done inside Wicg. I want to propose adding two curves: 25519 and 448 to the webCrypto api.

For the former curve, there exists a written proposal, albeit incomplete https://github.com/trevp/curve25519_webcrypto. Also, there was a formal voting with most votes against this; the main reason was that these curves were not included in the CFRG or TLS standards (an example vote is here https://lists.w3.org/Archives/Public/public-webcrypto/2014Aug/0107.html).

Now both curves are included in CFRG standard https://tools.ietf.org/html/rfc7748 and in the TLS one https://tools.ietf.org/html/rfc8446, therefore, it seems that including these curves now in the web crypto API is a reasonable choice.

Motivation for this is following: Those curves allow fast and secure implementations https://link.springer.com/chapter/10.1007/978-3-642-23951-9_9. This would advance end-to-end encryption for the web messaging and storage.

My name is Ilya Chesnokov and I represent here Proton Technologies AG, company behind Protonmail. All response are welcome. Especially from those who are responsible for the Web Cryptography maintenance and implementation.


I also want to see curve secp256k1 support in the spec!


Hmm, I think it is does not have same amount of specification. Do you want to work on the specification for this curve?


Someone has been pushing for 25519 as part of the TAG review repo:

I’ve filed an issue in the github repo of the WebCrypto API for that request - maybe worth filing a similar ones for the other curves:


Thanks for doing this Dom. This is something we have wanted to do for a while. I think that we lack Ed25519 support in gecko, which is a slight impediment, but that’s something we have plans to correct.


(Not sure if this is the right place to comment, and sorry if this is already addressed by the draft and I missed it.)

I think it’s important for modern X25519 APIs to explicitly reject low order points (which lead to all zero outputs), and I think the specification should require this.

See for example the new Go X25519 API.