[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:

github.com

tQsW/webcrypto-curve25519/blob/master/explainer.md

# Curve25519 in WebCrypto

## Problem Statement

Today web developers are getting around the unavailability of
[Curve25519][rfc7748] in browser by either including an implementation of its
operations in JavaScript or compiling a native one into WebAssembly. Aside from
wasting bandwidth shipping algorithms that are already included in browsers that
support TLS 1.3, this practice also has security implications, e.g. side-channel
attacks as studied by [Daniel Genkin et al][key-extraction].

## Support Curve25519 in the Web Cryptography API

We solve the above problem by adding support for Curve25519 algorithms in the
Web Cryptography API, namely the signature algorithm Ed25519 and the key
agreement algorithm X25519.

### Ed25519

The following operations are supported with the recognized algorithm name

This file has been truncated. show original

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.