Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Request for Mozilla Position on an Emerging Web Specification
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.
(Originally published at: https://tantek.com/2020/045/b1/)
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).
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:
Consequently, the IETF standardisation of X25519  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.
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.
I'm confused by this statement. Based on my reading of the WebCrypto API Spec I see two easy places to insert these checks:
Further, the import key method for
I am surprised to see there is no explicit requirement to reject the identity element for the
I'm struggling to parse this sentence. What would be a valid use case for an insecure use of WebCrypto?