Post-quantum key exchange adds a new group to the TLS ClientHello. Here's how ML-KEM and ML-DSA reshape JA3/JA4 fingerprints and what it means for detection.
Post-quantum cryptography stopped being a research topic and started showing up in production TLS handshakes in 2026. Cloudflare recently argued that classical signature algorithms can't simply wait for better post-quantum replacements, and APNIC has been tracking what PQC rollout actually looks like operationally across networks. Both pieces are about deployment, not fingerprinting — but the mechanism they describe changes the same ClientHello that JA3/JA4 fingerprinting has always read. This post is about that side effect: what post-quantum key exchange and signatures actually do to your TLS fingerprint.
Key Takeaways
- Post-quantum key exchange adds a new supported group to the ClientHello, not a new protocol. Hybrid mechanisms like
X25519MLKEM768sit in the samesupported_groupsandkey_shareextensions JA3/JA4 already hash. - The key shares are much bigger. A classical X25519 key share is 32 bytes; a hybrid ML-KEM-768 key share runs well over 1,000 bytes — sometimes enough to push a ClientHello across a UDP or fragmented-TCP boundary.
- ML-DSA affects
signature_algorithms, a different extension, for handshake signatures rather than key exchange — a separate, complementary shift in the same message. - Support is uneven across browsers and versions, so whether a client offers a PQC group at all — and in what position — adds a new, currently high-entropy fingerprinting signal.
- JA4 already handles this correctly. Because it sorts extensions and cipher suites by numeric value before hashing, a client turning PQC support on or off just changes which sorted values go into the hash — it doesn't break the format the way ordering-sensitive JA3 would.
What's Actually New in the ClientHello
TLS fingerprinting works because the ClientHello — cipher suites, extensions, supported groups, key shares — is dictated by the TLS library, not the user. Post-quantum key exchange doesn't add a new message type or a new round trip; it changes the contents of two fields already inside that same ClientHello:
supported_groupsgains one or more new named groups for hybrid key exchange, most notablyX25519MLKEM768— a combination of classical X25519 elliptic-curve Diffie-Hellman and ML-KEM-768, the lattice-based key-encapsulation mechanism NIST standardized as FIPS 203. The IETF's TLS hybrid ML-KEM key-exchange draft specifies exactly how this is negotiated inside TLS 1.3.key_sharecarries the actual key material for whichever groups the client is willing to send eagerly. This is where PQC leaves the biggest fingerprint: ML-KEM-768's public key alone is 1,184 bytes, dwarfing X25519's 32 bytes, so a hybrid key share is over an order of magnitude larger than a classical one.
Signatures are a separate story. ML-DSA (Module-Lattice Digital Signature Algorithm, FIPS 204) shows up in the signature_algorithms extension, which governs how the handshake itself is authenticated — not how the shared secret is derived. A client or server can support post-quantum key exchange, post-quantum signatures, both, or neither, and each combination is a distinct, observable pattern in the ClientHello.
Why Hybrid, Not Pure Post-Quantum
Every deployed post-quantum group in TLS today is hybrid: it combines a classical algorithm (X25519) with a post-quantum one (ML-KEM) rather than replacing X25519 outright. The shared secret is derived from both, so an attacker has to break both the elliptic-curve problem and the lattice problem to recover it — a hedge against the possibility that ML-KEM, still a comparatively young standard, turns out to have an undiscovered weakness. That hedging strategy is also why Cloudflare's post frames ML-DSA the way it does: post-quantum signature schemes are newer and less battle-tested than key exchange, so waiting for a hypothetically better one is a real cost, not just caution.
Why This Is a Fingerprinting Signal
A fingerprinting server doesn't need any new infrastructure to notice PQC — JA3 and JA4 already hash the full supported_groups and extension list. What changes is what those hashes now encode:
Version and build dating. PQC support rolled out gradually — Chrome enabled X25519MLKEM768 by default in specific release ranges, other browsers followed on their own timelines. A ClientHello that does or doesn't offer the hybrid group, combined with everything else JA4 already reads, narrows down not just "this is Chrome" but roughly which Chrome.
A consistency check for spoofed clients. The same logic TLS fingerprinting already applies to bot detection — does the handshake match what the claimed User-Agent should produce — gets a new, currently very discriminating field. A scraping library or an older TLS-impersonation tool that hasn't been updated to add the PQC group will mismatch a User-Agent claiming a current browser version, the same way a Python requests handshake mismatches a Chrome User-Agent today.
Size, not just content, is now informative. Because ML-KEM key shares are so much larger than classical ones, the raw size of the ClientHello itself becomes a coarse signal — a PQC-capable ClientHello is visibly bigger before anyone even parses individual fields.
The Network-Layer Wrinkle: Bigger ClientHellos
A larger key_share extension means a larger ClientHello, and that has consequences below the TLS layer. Over TCP, TLS handshake messages are already allowed to span multiple TCP segments, so a bigger ClientHello mostly just means slightly more data before the handshake completes. Over QUIC, where the TLS ClientHello rides inside the Initial packet, a much larger ClientHello is more likely to require the client to coalesce multiple UDP datagrams or rely on the connection's amplification-limit handling — an edge case some middleboxes and older QUIC stacks historically handled inconsistently. None of this breaks the handshake in a compliant implementation, but it's one more place where PQC support surfaces as an observable, implementation-dependent behavior rather than an invisible internal change.
What It Means for Detection Systems
None of this is a new detection category — it's a new set of values inside the categories that already exist. A bot-detection or anti-fraud system that checks TLS fingerprints for consistency gains one more axis to reason about: does this client's PQC posture match what its claimed browser and version should produce, and does that posture stay consistent across requests from the same session? A VPN or interception proxy that terminates and re-establishes its own TLS connection will carry its own TLS library's PQC support (or lack of it), independent of the original client — the same tell that already exposes TLS-terminating proxies today, just with one more field to compare.
For the browser fingerprinting picture more broadly, this is a network-layer signal, not a JavaScript-observable one — you can't read a page's TLS ClientHello from navigator properties. It sits alongside TLS and HTTP/3/QUIC fingerprinting as one more piece of what a server sees before your browser renders anything.
Frequently Asked Questions
Does post-quantum TLS make my connection slower?
Marginally, and mostly in the handshake, not ongoing throughput. The larger key shares add a small amount of one-time handshake bandwidth and computation; for most connections over modern networks this is not perceptible. Where it matters more is highly constrained networks or paths sensitive to ClientHello fragmentation, as noted above.
Can I disable post-quantum key exchange to reduce my fingerprint's entropy?
You could, if your browser exposes the option, but it would likely make you more identifiable, not less. As PQC-capable groups become standard in current browser releases, a ClientHello that conspicuously lacks them looks like an outdated build or a deliberately modified client — trading one fingerprinting signal for a more suspicious one.
Is ML-KEM the same as ML-DSA?
No. ML-KEM (FIPS 203) is a key-encapsulation mechanism used for key exchange — it's what shows up in supported_groups/key_share as part of a hybrid group like X25519MLKEM768. ML-DSA (FIPS 204) is a signature algorithm used to authenticate the handshake, appearing in signature_algorithms instead. Both are post-quantum, lattice-based, and NIST-standardized, but they solve different problems and appear in different ClientHello fields.
Does this affect JA3 fingerprints differently than JA4?
Yes, more than most protocol changes do. JA3 hashes ciphers and extensions in the order the client sent them, so it's sensitive to exactly how a library orders its new PQC group among existing ones. JA4 sorts both before hashing, so it's robust to ordering differences and only reflects the actual set of values — including whether PQC groups are present — making it the more stable choice for tracking this transition. See TLS fingerprinting explained for how JA3 and JA4 differ more generally.
