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

ilya.chesnokov
2019-12-16

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.

Jack-Works
2019-12-27

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

ilya.chesnokov
2020-01-16

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

dontcallmedom
2020-01-28

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:

martinthomson
2020-01-28

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.

FiloSottile
2020-02-03

(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.