-
Notifications
You must be signed in to change notification settings - Fork 13
2026 Web Cryptography API
Manuel Rego edited this page Jul 15, 2026
·
1 revision
- GitHub issue: https://github.com/Igalia/webengineshackfest/issues/87
- URL: https://meet.jit.si/WEH2026-web-crypto
- Daniel intro:
- All the algorithms in the draft are recommended by NIST or the IETF CFRG (crytography research group).
- ChaCha20-Poly1305 one of the most requested ones.
- SHA3 also useful to combine ML-KEM + X25519, but Chrome has shown some concerns on exposing an API for this (they want to expose the combination directly instead).
- Anna: Why we include algs in the draft not considered to be implemented yet? Suggests to have 2 separate drafts, with one left for nice-to-have algs
- Daniel: Some of these algorithms would be integrated eventually into the Web Crypto spec
- Anna: What's the criteria to make them become an accepted standard?
- Daniel: The criteria wold be "being widley supported"
- Anna: Only targetting main browser vendors
- James: there are other criteria that we can apply, creating a registry of algorithms showing their implementation status.
- Daniel: I'll create an issue to discuss about an "adoption guidance"
- James: SHAKE256 would be fine, cSHAKE is the one with concerns about
- Anna: Asks about submitting isues in the spec and engange with other browser vendors
- James: the concern about SHA3 is to avoid additional dependencies
- Anna: I'm mostly the one pushing for SHA3, because SHA2 is likely to be broken, so we need an alternative
- Anne: CryptoKit are only concerned about Argon2, not sure about SHA3
- James: We could support SHA3 if we figure out how to deal with the new API
- Anne: pascoej expressed support for SHA3 in the standard position request
- Anne: Some of the concerns are related to how an algorithm work in the different HW, not only in the Apple specific archs
- James: If we can not guarantee a minimum level of performance, we may create a new problem allowing those algs.
- Daniel: PBKDF2 is very bad, Argon2 may still be better even at low memory usage
- Anna: Should we deprecatate SHA1
- Daniel: I think most of the browsers are showing warnings already
- Daniel: There is an old IETF draft where it's described which algorithms should be used for the different use cases
- Anna: The spec should mention it, not just via warnings
- Anne: Removing algs is possible, but we need to ensure compatibility; there are other specs where using legacy features is discouraged, but still present in the spec due to back compatibilty
- Anna: Very concerned about the spec still keeping deprecated / unsecure algorithms
- Anna: Fine with moving them to its own section and warning in the spec about "use at your own risk"
- Daniel: We could potentially have a separate API for non-cryptographic (usages of) hash algorithms, and still allow SHA-1 there
- Daniel: Async API causes overhead (create the promises, ...), might want a sync one
- James: Our implementation is fully sync, despite the API being async
- Daniel: I have created a PR with tests to evaluate how the different engines implement the operations sync vs async
- Daniel: The spec states clearly that the operation must be async, and the implementation being sync are not compliant
- Anne: Independently of the implementation, returning a promise because it's what the API spec shouldn't be a problem.
- Anne: Move the operations to the main thread but queieng the task would be still compliant
- Daniel: Should we create a simpler / sync API for each primitive or create a new sync API for everything
- James: Just have a sync-suffix on the operation would be enough
- Anne: I agree on the suffix approach, but ...
- Anna: Should we restrict the size of the input?
- Daniel: Restrict to workers
- Luca: Needs to not only be workers but any environment that can block
- Anne: Would need IDL changes
- Daniel: There is a PR that uses the latest syntax for Async iterables for the digest operation
- James: We would be willing to implement it for digets, not so positive at the other operations (specially sing)
- Luca: Not sure whether the WebIDL changes have been replicated in all the engines
- Andreu: Not sure about Chrome
- Luca: Is Webkit interested?
- Anne: I don´t think there is a lot of interest
- Anne: What's the interest on this feature?
- Luca: to avoid having to store the whole buffer
- Luca: and streaming hashing is like a basic feature for a cryptography API
- Anne: there is no a standard position request yet, that would help.
- Anna: we are not going to implement it inmediately
- Javi: If it's just a lack of resources, would the engines be willing to review and merge patches from external contributors?
- Anna: Yes, probably
- Anne: Yes, probably
- Anne: Is this just for digest?
- Daniel: yes, I decided to start with this because it's the simplest and most useful, but would like to evaluate signing and verifying later; encrypt and decrypt are highly controversial so they are omitted for now
- Anna: We won´t implement encrypt and decrypt
- Javi: Chrome neither
- Daniel: I'm going to create the standard position request for Safari and Firefox; I will ask Chrome as well
- Daniel: Highly controversial topic, but quite much support from the devs, and interest from Brave
- Anna: lack of interest
- Anne: interest unclear
- Javi: as far as I know Chrome is strong against
- Daniel: main concerns are related to tracking issues; I have provided some alternatives but didn´t get any feedback
- Javi: We need to be sure if Chrome is a strong blocker, given the lack of interest from Mozilla an Safari
- Daniel: I will try to gather more feedback from chrome
- Daniel: I will create a standard position request
- Daniel: Streaming API would be probably a good candidate, especially if the Async Iterators is widely supported by the egnines.
- Daniel: The spec doesn´t strictly specify that the hashing is done incrementally.
- Luca: Should measure how the implementation behaves with large files (eg, memory limits)
- Daniel: Should we require incremental hasghing?
- James: as long as it's is not observable, we don't care
- Daniel: For hashing it could be better to do it in the main thread