X25519 in Web Cryptography

[tantek]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Curve25519 in WebCrypto
• Specification or proposal URL: https://github.com/tQsW/webcrypto-curve25519/blob/master/explainer.md
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): @martinthomson, @jcjones, @beurdouche
• W3C Tag Design Review issue: Curve25519 in Web Cryptography w3ctag/design-reviews#466

Other information

Per @ekr:

We are generally in favor of this effort, however, we request submission to WICG.

We also have some concerns about the specific implementation. In particular, WebCrypto took a real “no seatbelts” design approach which we now think is wrong. That's perpetuated here and we’d like to revisit that.

It would probably be good to add some other algorithms as well (ChaCha/Poly, HPKE).

None of the existing groups really seem appropriate so maybe we need to reboot WebCrypto (whether in W3C or WHATWG). Not sure if this needs incubation, but in the interest of getting it out of a private repo, please submit to WICG while we figure out the rest.

Label: wicg.

(Originally published at: https://tantek.com/2020/045/b1/)

[paulmillr]

What is the reasoning in selecting chacha20 instead of salsa20 or xsalsa20/xchacha20?

[tarcieri]

ChaCha20 provides better diffusion than Salsa20, and has also been standardized by the IETF (i.e. RFC 8439) for use in TLS.

XChaCha20 is interesting, but at present there's only an I-D describing it: draft-arciszewski-xchacha-02

[paragonie-security]

The latest I-D is now at draft-irtf-cfrg-xchacha-03, @tarcieri

[ekr]

ChaCha20/Poly1305 is what is getting embedded in protocols.

[nadimkobeissi]

This is awesome, especially excited to see that an API redesign is in consideration as well.

[galadran]

Suggestion: The standard should specify that implementations of X25519 and Ed25519 must reject elements of small order (i.e. immediately prior to use in scalar multiplication or signature verification).

Security Rationale

Curve25519 is not a prime order curve and hence contains small order elements. In the original descriptions of X25519 and Ed25519, the designer was explicit that these elements do not need to be rejected [1, 2]. However, this choice has had material consequences for security:

• Confinement Attacks on Tendermint, Secure Scuttlebutt [3]
• Unusual signature properties, leading to attacks on SCION and WS Security [4]
• Improved Side Channel Attacks [5]
• Triple Handshake Attacks on TLS [6]

Consequently, the IETF standardisation of X25519 [7] explicitly allows implementations to reject such elements, whilst also warning that many current implementations do not. More recently, NaCl, CIRCL and Go’s Standard Library have altered their APIs to reject small order elements in their relevant Ed25519 and X25519 functions.

Performance and Interoperability

This proposed requirement does not pose any issues for interoperability or performance.

Correct implementations never produce an element of small order, consequently this change is interoperable with implementations that do not reject small order elements. Further, as there are only a limited number of small order elements, they can be efficiently rejected by testing for equality against an explicit list.

--
Dennis Jackson & Cas Cremers

[jcjones]

Suggestion: The standard should specify that implementations of X25519 and Ed25519 must reject elements of small order (i.e. immediately prior to use in scalar multiplication or signature verification).

As a note, there's no specified mechanism in WebCrypto for the relevant algorithms to resolve with appropriate errors: this is among the things we mean when we describe WebCrypto as having no seatbelts. While there are certainly valid use cases for insecure use cases of WebCrypto, perhaps there's room for improvements in the general case.

[galadran]

As a note, there's no specified mechanism in WebCrypto for the relevant algorithms to resolve with appropriate errors: this is among the things we mean when we describe WebCrypto as having no seatbelts.

Hi @jcjones.

I'm confused by this statement. Based on my reading of the WebCrypto API Spec I see two easy places to insert these checks:

• Signature Verification naturally reports a boolean outcome, the proposed check can be implemented as a short circuit which returns false without carrying out the rest of the verification operation.
• For ECDH operations, derive bits is specified in 24.4 step 7 to return OperationError if "performing the operation results in an error". The proposed check can just return OperationError.

Further, the import key method for spki and raw keys is required to reject the identity element. It would be natural to also add the proposed check to this method so that application developers can handle invalid keys early on.

I am surprised to see there is no explicit requirement to reject the identity element for the jwk or pkcs8 methods. Similarly, the raw method does not mention checking the curve equation. Do you know if Firefox performs these checks?

While there are certainly valid use cases for insecure use cases of WebCrypto, perhaps there's room for improvements in the general case.

I'm struggling to parse this sentence. What would be a valid use case for an insecure use of WebCrypto?

[dbaron]

Does the proposal here correspond to a worth prototyping position?

[martinthomson]

Yes, but it sure would be nice to have a real specification that we could reference.