v150 · Web Cryptography

Algorithm Updates in WebCrypto

Post-quantum and modern algorithms come to crypto.subtle: ML-KEM (key encapsulation, FIPS 203), ML-DSA (digital signatures, FIPS 204), and ChaCha20-Poly1305 (AEAD, RFC 8439) — plus new encapsulateBits/encapsulateKey, decapsulateBits/decapsulateKey, and getPublicKey instance methods, with a static SubtleCrypto.supports() capability check on the interface object. Every demo here runs the real browser implementation.

concepts

  1. ML-KEM key exchange

    The post-quantum handshake. Generate an ML-KEM-768 / ML-KEM-1024 keypair, encapsulateBits() to the public key to produce a ciphertext + shared secret, then decapsulateBits() to recover the identical secret. Watch the two parties derive the same 32-byte key without ever transmitting it.

  2. ML-DSA signatures

    Quantum-resistant signing. Generate an ML-DSA-44/65/87 keypair, sign() a message, and verify() it. Tamper with a byte and watch verification fail. Compare the (large) signature sizes across the three parameter sets, and derive the public key from the private one with getPublicKey().

  3. ChaCha20-Poly1305 AEAD

    A fast software-friendly authenticated cipher. encrypt() / decrypt() with a 12-byte nonce and optional additional-authenticated-data. See the Poly1305 tag reject a tampered ciphertext or wrong AAD, and watch the real OperationError when the nonce isn't exactly 12 bytes.

  4. Hybrid session key

    The end-to-end pattern: encapsulateKey() derives an AES-GCM CryptoKey straight from an ML-KEM public key — no manual key-derivation step — and that session key immediately encrypts a message. One post-quantum KEM feeding a symmetric channel.

  5. Capability matrix

    An honest feature-detection grid. It tries the new static SubtleCrypto.supports() first — it ships on the interface object under the same WebCryptoPQC gate — and falls back to calling crypto.subtle.generateKey() for every algorithm name (ML-KEM-768/1024, ML-DSA-44/65/87, ChaCha20-Poly1305, X-Wing) when it's absent, reporting the real result — including X-Wing, which the ChromeStatus entry lists but Chromium does not yet implement.

why it shipped

A large-scale quantum computer would break RSA and elliptic-curve cryptography, so NIST standardised replacements: ML-KEM for key establishment and ML-DSA for signatures. Until now the web platform had no browser-provided implementation, forcing developers to ship large WASM crypto libraries. Adding these algorithms — plus ChaCha20-Poly1305, a widely-deployed AEAD that outperforms AES-GCM on hardware without AES acceleration — to the Web Cryptography API gives web apps audited, native, constant-time primitives for the post-quantum transition. New KEM-shaped methods (encapsulateBits/encapsulateKey/decapsulateBits) were needed because a KEM's "encrypt to a public key, get a shared secret" shape doesn't fit the existing encrypt/deriveKey model.

enabling it

Behind a flag in Chrome 150 (developer trial). Launch Chrome with --enable-blink-features=WebCryptoPQC, or turn on chrome://flags/#enable-experimental-web-platform-features. An origin trial follows on desktop in Chrome 151–154 with public registration (chromestatus API, updated 2026-06-17; origin-trial feature name WebCryptoAdditionalAlgorithms202606) — no default-on milestone is recorded yet (status text “Proposed”). Every demo feature-detects first and shows a banner with these exact steps when the algorithms aren't available — it never fakes a result.

references

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗