#466: Curve25519 in Web Cryptography

Visit on Github.

Opened Jan 23, 2020

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.

Further details:

  • 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

Discussions

Comment by @dbaron Jan 31, 2020 (See Github)

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

Comment by @alice Feb 5, 2020 (See Github)

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

Comment by @torgo Feb 5, 2020 (See Github)

Pinging @wseltzer.

Comment by @wseltzer Feb 8, 2020 (See Github)

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.

Comment by @plinss Feb 8, 2020 (See Github)

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.

Comment by @armfazh Feb 9, 2020 (See Github)

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

Comment by @tQsW Feb 10, 2020 (See Github)

Does the proposal target both X25519 and Ed25519?

Yes, this proposal targets both algorithms.

Comment by @sleevi Feb 14, 2020 (See Github)

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

Comment by @dbaron Mar 2, 2020 (See Github)

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.

Comment by @plinss Mar 2, 2020 (See Github)

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

Comment by @paulmillr Dec 21, 2020 (See Github)

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