Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

X25519 in Web Cryptography #271

Closed
tantek opened this issue Feb 15, 2020 · 10 comments
Closed

X25519 in Web Cryptography #271

tantek opened this issue Feb 15, 2020 · 10 comments
Labels

Comments

@tantek
Copy link
Member

@tantek tantek commented Feb 15, 2020

Request for Mozilla Position on an Emerging Web Specification

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

This comment has been minimized.

Copy link

@paulmillr paulmillr commented Feb 16, 2020

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

@tarcieri

This comment has been minimized.

Copy link

@tarcieri tarcieri commented Feb 16, 2020

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

This comment has been minimized.

Copy link

@paragonie-security paragonie-security commented Feb 16, 2020

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

@dbaron dbaron added the wicg label Feb 16, 2020
@ekr

This comment has been minimized.

Copy link
Contributor

@ekr ekr commented Feb 16, 2020

ChaCha20/Poly1305 is what is getting embedded in protocols.

@kaepora

This comment has been minimized.

Copy link

@kaepora kaepora commented Feb 17, 2020

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

@galadran

This comment has been minimized.

Copy link

@galadran galadran commented Feb 18, 2020

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

This comment has been minimized.

Copy link
Contributor

@jcjones jcjones commented Feb 18, 2020

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

This comment has been minimized.

Copy link

@galadran galadran commented Feb 18, 2020

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

This comment has been minimized.

Copy link
Member

@dbaron dbaron commented Feb 21, 2020

Does the proposal here correspond to a worth prototyping position?

@martinthomson

This comment has been minimized.

Copy link
Member

@martinthomson martinthomson commented Feb 22, 2020

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

dbaron added a commit to dbaron/standards-positions that referenced this issue Mar 20, 2020
@dbaron dbaron closed this in #296 Mar 23, 2020
dbaron added a commit that referenced this issue Mar 23, 2020
Fixes #271.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

10 participants
You can’t perform that action at this time.