Curve25519 in Web Cryptography

[tQsW]

Hello TAG!

I'm requesting a TAG review of adding support for Curve25519 in WebCrypto.

Today web developers are getting around the unavailability of Curve25519 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.

• Explainer (minimally containing user needs and example code): https://github.com/tQsW/webcrypto-curve25519/blob/master/explainer.md
• Security and Privacy self-review: https://github.com/tQsW/webcrypto-curve25519/issues/1
• GitHub repo (if you prefer feedback filed there): https://github.com/tQsW/webcrypto-curve25519
• Primary contacts (and their relationship to the specification):
  • Qingsi Wang @tqsw, Google
• Organization/project driving the design: WebCrypto
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): Not yet available

Further details:

• [x] I have reviewed the TAG's API Design Principles
• The group where the work on this design is being done (or is intended to be done in the future): WebCrypto WG
• Existing major pieces of multi-stakeholder review or discussion of this design: N/A
• Major unresolved issues with or opposition to this design: N/A
• This work is being funded by: N/A

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[dbaron]

What's the plan for standardizing this? (I ask particularly given that the Web Cryptography Working Group is closed.

[alice]

Chrome Status: https://www.chromestatus.com/feature/4913922408710144 Tracking Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1032821 Intent to prototype: https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!msg/blink-dev/PgBVW4ru1EQ/5dllcdVoDgAJ

[torgo]

Pinging @wseltzer.

[wseltzer]

If there's sufficient interest, we can start a WG or add it to the scope of an existing WG. Expressions of interest welcome to help us figure that out.

[plinss]

I think the main concern was ensuring that curve25519 is covered under the patent policy. My understanding is that it's sufficiently open-source/public domain that additional coverage under the patent policy isn't necessary. We'd like to get confirmation of that.

[armfazh]

Does the proposal targets both X25519 and Ed25519? I have interest on moving this forward.

[tQsW]

Does the proposal target both X25519 and Ed25519?

Yes, this proposal targets both algorithms.

[sleevi]

If there's sufficient interest, we can start a WG or add it to the scope of an existing WG. Expressions of interest welcome to help us figure that out.

Right, the steps forward for the Web Crypto API had previously been discussed in https://github.com/w3c/webcrypto/issues/181 where the suggestion had been to move into WICG , to also facilitate other spec maintenance

[dbaron]

We (me, @plinss, @sangwhan, @ylafon) are looking at this again at our Wellington Face-to-Face. We don't have any concerns from a technical perspective, and while we realize there may be some discussion of which other algorithms may or may not be appropriate to add, we're probably not the right set of people to evaluate those.

At the same time, we'd strongly encourage that whatever does happen here have an appropriate standardization path.

[plinss]

Especially if the W3C winds up spinning up a WG just to do this work, we'd encourage that the WG also evaluates other curves such as 448

[paulmillr]

yeah 448 should be added to be future-proof. NSA already suggests only using curves that have at least 192 bits of security. which ain't 25519 (only ~126 bits).