Engineering · 2026-04-11

Key Encapsulation for Identity Tokens: KEM in a Post-Quantum Auth Stack

By J. W. Bouckaert

The key exchange assumption that quantum breaks

Every modern authentication system that encrypts bearer tokens in transit relies on the same foundational assumption: that two parties can establish a shared secret over an untrusted network without an eavesdropper being able to derive that secret. For Diffie-Hellman and its elliptic-curve variant, the assumption rests on the hardness of the discrete logarithm problem, and it has held since Diffie and Hellman published the method in 1976.

It will not hold against a quantum computer running Shor's algorithm.

The distinction matters because identity tokens (JWTs, access tokens, refresh tokens, verifiable credential presentations) are bearer instruments. Whoever holds the token holds the identity. And every one of those tokens, at some point in its lifecycle, traverses a channel that was encrypted using a key derived from Diffie-Hellman or its elliptic-curve variant (ECDH).

This is the harvest now, decrypt later (HNDL) threat model, and it applies to any identity system that sends tokens over TLS connections whose key exchange is classical ECDH or finite-field Diffie-Hellman.

Key exchange vs. key encapsulation: The structural difference

The terms "key exchange" and "key encapsulation" are often used interchangeably. They describe different interfaces, and the difference affects how a protocol is built.

Key exchange (interactive)

In Diffie-Hellman key exchange, both parties contribute a share:

1. Alice generates a keypair and sends her public key to Bob
2. Bob generates a keypair and sends his public key to Alice
3. Both parties independently compute the same shared secret from their private key and the other's public key

Used this way, with both parties generating fresh keys, it is interactive and takes a round trip. Diffie-Hellman can also be used in one pass: the sender combines a fresh key pair with the recipient's published static key, as JWE does with ECDH-ES and HPKE does with its DH-based KEM.

Key encapsulation (one-directional)

In a KEM, the flow is asymmetric:

1. Bob publishes his encapsulation (public) key
2. Alice generates a random shared secret, encapsulates it under Bob's public key, and sends the ciphertext
3. Bob decapsulates using his private (decapsulation) key to recover the shared secret

This is one-pass: Alice needs Bob's public key, but Bob does not need to be online during encapsulation. The KEM interface is what post-quantum schemes such as ML-KEM provide, so one-pass designs that use ephemeral-static Diffie-Hellman today can move to ML-KEM without changing their message flow.

Consequences for auth

Identity token issuance is inherently one-directional. An identity provider (IdP) generates a token and delivers it to a relying party (RP) or user agent. The IdP knows the payload. The consumer needs to decrypt or verify it. This maps directly to the KEM model:

• The RP publishes its encapsulation key
• The IdP encapsulates a symmetric key, encrypts the token payload, and sends both
• The RP decapsulates and decrypts

There is no interactive handshake and no session state. Token encryption formats that use one-pass ephemeral-static ECDH today, such as JWE with ECDH-ES, follow the same flow, which is why a KEM can replace the classical step in them directly.

ML-KEM (FIPS 203)

In August 2024, NIST published FIPS 203, the Module-Lattice-Based Key-Encapsulation Mechanism Standard, derived from the CRYSTALS-Kyber algorithm. ML-KEM was the first post-quantum KEM NIST standardized. In March 2025 NIST selected HQC, which is based on different mathematics, as a second KEM, with a final standard expected in 2027.

ML-KEM's security is based on the Module Learning With Errors (MLWE) problem, a lattice problem for which no efficient quantum algorithm is known. Unlike discrete logarithm problems (which Shor's algorithm solves efficiently), lattice problems remain computationally hard even for quantum computers, and have been the focus of the NIST Post-Quantum Cryptography project since 2016.

Parameter sets

ML-KEM defines three parameter sets, each targeting a different NIST security level:

For comparison, the classical key exchange primitives used in TLS 1.3 today:

The size difference is real: ML-KEM-768 ciphertexts are 34× larger than X25519 public keys. But the shared secret remains 32 bytes in all cases, meaning the symmetric encryption layer (AES-256-GCM) is unchanged. The overhead is exclusively in the key establishment phase.

The hybrid transition: ML-KEM + ECDH

NIST and the broader cryptographic community recommend a hybrid approach during the transition period: combining ML-KEM with a classical key exchange (typically X25519) so that security is maintained even if one of the two algorithms is later found to be flawed.

TLS 1.3 already supports this. RFC 9954 (July 2026) describes hybrid key exchange in TLS 1.3, and RFC 10024 (August 2026) defines the ML-KEM hybrid groups, including X25519MLKEM768 (codepoint 0x11EC). Browsers enabled it by default before the RFCs were final: Chrome in version 131 in November 2024 (Google announcement) and Firefox in version 132 in October 2024. Cloudflare's deployment notes cover the server side. (Note: RFC 9180 defines HPKE (Hybrid Public Key Encryption), which uses "hybrid" in the KEM+AEAD sense, distinct from the classical+PQ "hybrid" used here.)

For identity token encryption specifically, the hybrid approach works as follows:

1. Encapsulate a shared secret using ML-KEM-768 under the RP's lattice public key
2. Derive a second shared secret using X25519 with the RP's curve public key
3. Combine both secrets via HKDF-SHA-256 to produce the final symmetric key
4. Encrypt the token payload with AES-256-GCM using the combined key

This ensures that an attacker must break both ML-KEM and X25519 to recover the token, whether with a quantum or a classical computer.

Relation to hybrid signatures

PasskeyBridge already implements hybrid signatures (ML-DSA-65 + ES256) for identity assertions. A KEM transition follows the same dual-algorithm philosophy: each asymmetric operation carries both a classical and a post-quantum guarantee. On the platform today, only the signature layer has its post-quantum half:

The bottom two rows are already quantum-resistant: Grover's algorithm provides only a quadratic speedup against symmetric ciphers and hash functions, which is mitigated by using 256-bit key lengths. The transition work is exclusively in the asymmetric layers: signatures and key establishment.

KEM in the identity token lifecycle

To make this concrete, here's how ML-KEM integrates into the lifecycle of an encrypted identity token:

Token issuance (IdP side)

1. IdP retrieves RP's encapsulation key (ML-KEM-768 public key)
2. IdP calls ML-KEM.Encaps(ek) → (shared_secret, ciphertext)
3. IdP derives token_key = HKDF-SHA-256(shared_secret, "identity-token-v1")
4. IdP encrypts token payload: ct = AES-256-GCM(token_key, nonce, token_payload)
5. IdP signs (ciphertext || ct || nonce) with ML-DSA-65 private key
6. IdP transmits: { kem_ct: ciphertext, token_ct: ct, nonce, signature }

Token consumption (RP side)

1. RP verifies ML-DSA-65 signature over (kem_ct || token_ct || nonce)
2. RP calls ML-KEM.Decaps(dk, kem_ct) → shared_secret
3. RP derives token_key = HKDF-SHA-256(shared_secret, "identity-token-v1")
4. RP decrypts token_payload = AES-256-GCM.Open(token_key, nonce, token_ct)
5. RP validates token claims (exp, iss, aud, sub_hash)

There is no handshake or session state. The RP's encapsulation key can be published in a DID document, cached at the edge, or distributed via a well-known endpoint, like a traditional JWK, but quantum-resistant.

BLAST and encrypted tunnels

PasskeyBridge's BLAST encrypted tunnel protocol still starts every session with ephemeral X25519. A client that also sends a 1,184-byte ML-KEM-768 encapsulation key gets a hybrid session: the server encapsulates, concatenates the ML-KEM shared secret in front of the X25519 shared secret, and derives the tunnel key with HKDF-SHA-256 under the info string blast-tunnel-v2: plus the session id. A client that omits the key stays on blast-tunnel-v1: and X25519 alone. A hybrid init that the runtime cannot serve answers 503 and does not fall back.

• Key negotiation keeps X25519 and adds ML-KEM-768 encapsulation when the client sends a key
• Tunnel key derivation is still HKDF-SHA-256; the hybrid input is 64 bytes
• Per-message encryption remains AES-256-GCM (already quantum-safe)
• Session teardown is unchanged: the tunnel key is destroyed on both sides

The extra handshake payload is the 1,088-byte ciphertext, about one kilobyte on an edge verification path. Identity tokens are not encrypted this way.

For delay-tolerant identity over geostationary satellite links, where a round trip takes about half a second or more, one-pass encryption matters more. A device can encrypt to the server's cached public key with ML-KEM, or with ephemeral-static ECDH, without a handshake, and the server decrypts when the message arrives.

The HNDL deadline

The harvest now, decrypt later threat is the reason NSA and CISA give for starting the migration before a quantum computer exists: traffic recorded today can be decrypted later. NSA's CNSA 2.0 suite specifies ML-KEM-1024 for national security systems. Its timeline has traditional networking equipment use CNSA 2.0 algorithms exclusively by 2030, and web browsers, servers, cloud services and operating systems by 2033, toward a goal of quantum-resistant national security systems by 2035.

For identity systems specifically, the HNDL risk is acute because:

1. Bearer tokens encode identity claims: a decrypted token reveals who authenticated, when, and with what permissions
2. Token lifetimes are bounded but audit trails are permanent: even expired tokens reveal the identity graph
3. Credential metadata is high-value intelligence: scope grants, delegation chains, and trust scores reveal organizational structure

Implementation considerations

Key rotation

ML-KEM encapsulation keys can follow the rotation policy already used for classical keys. For key exchange, use a fresh key pair per session, as BLAST does with its ephemeral X25519 key.

Ciphertext expansion and MTU

An ML-KEM-768 encapsulation key (1,184 bytes) or ciphertext (1,088 bytes) fits in a single TCP segment of 1,460 bytes on its own. A TLS ClientHello that carries an X25519MLKEM768 key share (1,216 bytes) plus its other extensions can exceed one segment, which exposed servers and middleboxes that assumed the ClientHello arrives in one packet. ML-KEM-1024 keys and ciphertexts (1,568 bytes) exceed one segment on their own. TCP splits these messages into segments, so they do not cause IP fragmentation, but paths with a smaller MTU, such as some non-terrestrial network links, need more packets per handshake.

Runtime

The handshake uses the runtime's WebCrypto ML-KEM-768. There is no published timing figure for Encaps or Decaps on production traffic, because a figure from this path would be a public claim this article does not make. Measure KeyGen, Encaps and Decaps on your own runtime, cold and warm, before budgeting for them.

Summary

Key encapsulation fits protocols in which one party creates a secret for another, which is the model of identity token issuance. ML-KEM is designed to be secure against chosen-ciphertext attacks (IND-CCA2) and is believed to resist quantum attacks. Its keys and ciphertexts are larger than X25519's, and the extra kilobyte or so per handshake or token is the main cost.

For identity systems, the migration path is clear:

1. Use X25519MLKEM768 for TLS where your clients and servers support it.
2. Add ML-KEM-768 in hybrid mode alongside X25519 for any token encryption you control.
3. For national security systems, follow the CNSA 2.0 timeline and ML-KEM-1024.

Explore PasskeyBridge's post-quantum identity stack →

Start free · Test the API