Pure post-quantum mode

What this is

By default, Chromium-based browsers (Chrome, Edge, Brave, Opera) advertise the X25519MLKEM768 hybrid in their TLS ClientHello. They support pure ML-KEM-1024 in the underlying TLS code, but they don’t offer it unless you explicitly add it to the offer set via a launch flag. Firefox and Safari currently follow the same posture.

When you launch Chromium with --ssl-key-log-additional-keyshare-groups=MLKEM1024, the browser adds MLKEM1024 (codepoint 0x0202) to its supported_groups AND sends a key_share for it. Any server that accepts that group will then negotiate a fully post-quantum key exchange with you, with no classical fallback in the ECDH leg.

As of May 2026, the only public-internet servers that pick MLKEM1024 when offered are Google’s own properties (gmail, youtube, google.com) and a handful of experimental endpoints. RPCScan tracks the rest of the ecosystem so you can see who else ever flips it on.

Enable it (macOS)

Quit Chrome, then launch it from the terminal:

For Brave:

For Edge:

Enable it (Linux)

Enable it (Windows)

From PowerShell:

Verify it works

With your flag-launched browser, visit any page on RPCScan and look at the footer pill. If the edge sees MLKEM1024 in your ClientHello it lights green: ● Pure post-quantum (MLKEM1024). If it sees the hybrid it shows ● PQ hybrid (X25519MLKEM768).

You can also verify directly with openssl s_client built against OpenSSL 3.5+ (which speaks pure ML-KEM):

Once we deploy pq.rpcscan.info as a hand-rolled origin (planned; see /security for the migration roadmap), the same command will return Negotiated TLS group: MLKEM1024 for any client that asks.

Caveats

• The flag is undocumented and may break unrelated sites if their TLS termination has strict ClientHello fingerprinting.
• Chrome can rename or remove the flag at any release without notice. Today’s exact value is --ssl-key-log-additional-keyshare-groups=MLKEM1024 (Chrome 131+).
• Adding pure ML-KEM-1024 to your ClientHello adds ~1.5 KB to every TLS handshake. Negligible on broadband; visible on a phone over a slow link.
• If a server rejects fingerprints it doesn’t recognize, you may see TLS handshake failures. Drop the flag and the site works again.

Better than a flag: install our extension

We’re shipping a small browser extension that flips this on for any tab pinned to RPCScan, surfaces a per-tab posture badge, and (eventually) speaks pure ML-KEM-1024 directly via WebAssembly so it works regardless of whether Chrome ships the flag. See /security/extension for status.