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. This assumption is called the computational Diffie-Hellman (CDH) assumption, and for fifty years, it has held.

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).

Whether the channel that carried your tokens will remain confidential in ten years matters more than whether they were signed correctly.

This is the harvest now, decrypt later (HNDL) threat model—and it applies to every identity system transmitting tokens over TLS 1.3 today, because TLS 1.3 key exchange is ECDH.

Key exchange vs. key encapsulation: The structural difference

The terms "key exchange" and "key encapsulation" are often used interchangeably. They are not the same thing, and the distinction has architectural consequences for auth systems.

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

This is interactive—it requires a round-trip. Both parties must be online simultaneously. The shared secret is derived, not transmitted.

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 non-interactive—Alice needs Bob's public key, but Bob does not need to be online during encapsulation. The shared secret is generated by Alice and transmitted in encrypted form rather than jointly derived.

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, no session state and no round-trip latency penalty. This is why KEM is structurally superior to key exchange for bearer token protection in identity systems.

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 is the only NIST-approved post-quantum KEM.

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.

Latency impact of larger ciphertexts

The ciphertext size increase from ECDH to ML-KEM is the most commonly cited objection. Let's quantify it.

Per-token overhead

For a typical identity token exchange (IdP → RP), ML-KEM-768 adds:

On a modern network with 10ms RTT, the additional 1 KB adds approximately 0.08ms of transmission time. The computational overhead of 0.25ms is dominated by the lattice arithmetic in decapsulation. Total per-token cost: under 0.35ms.

For auth systems working inside a login-path latency budget, this represents less than 1% of it.

At scale

Even at enterprise scale, the bandwidth overhead is negligible relative to typical API traffic. The compute overhead is distributable across edge nodes—precisely the architecture that edge-first identity verification is designed for.

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. The classical+PQ hybrid is specified by draft-ietf-tls-hybrid-design and registered in the TLS Supported Groups registry as X25519MLKEM768 (codepoint 0x11EC). Major browsers have shipped it by default since late 2024 (Chromium announcement, Cloudflare deployment notes): Chrome 131 in November 2024, and Firefox 132 in October 2024 after Firefox 124 shipped the earlier Kyber768Draft00 variant experimentally. (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—quantum or classical.

Relation to hybrid signatures

PasskeyBridge already implements hybrid signatures (ML-DSA-65 + ES256) for identity assertions. The KEM transition follows the same dual-algorithm philosophy: every cryptographic operation in the identity stack carries both a classical and a post-quantum guarantee.

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)

No round-trip. No session state. No interactive negotiation. The RP's encapsulation key can be published in a DID document, cached at the edge, or distributed via a well-known endpoint—exactly like a traditional JWK, but quantum-resistant.

BLAST and encrypted tunnels

PasskeyBridge's BLAST encrypted tunnel protocol already uses ephemeral key exchange for session establishment. The migration from ECDH to ML-KEM-768 for BLAST tunnel key establishment is architecturally straightforward:

• Key negotiation shifts from X25519 ECDH to ML-KEM-768 encapsulation
• Tunnel key derivation continues to use HKDF-SHA-256 from the shared secret
• Per-message encryption remains AES-256-GCM (already quantum-safe)
• Session teardown is unchanged—the tunnel key is destroyed on both sides

The primary difference is in the initial handshake payload size. A BLAST tunnel establishment with X25519 transmits 32 bytes of key material. With ML-KEM-768, it transmits 1,088 bytes. On an edge verification path, this adds less than 0.1ms.

For delay-tolerant identity over non-terrestrial networks, where round-trip latencies exceed 600ms, the non-interactive nature of KEM is even more valuable. A GEO satellite link that adds 600ms per round-trip makes interactive key exchange prohibitively expensive. KEM eliminates the round-trip entirely—the device encapsulates locally using the server's cached public key, and the server decapsulates when the message arrives.

The HNDL deadline

The harvest now, decrypt later threat is not theoretical. Nation-state adversaries are actively recording encrypted traffic for future decryption. The NSA's CNSA 2.0 suite mandates ML-KEM-1024 for national security systems by 2030, and CISA's Post-Quantum Cryptography Initiative recommends transition planning to begin immediately.

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

Every identity token encrypted with ECDH today is a future plaintext for a quantum adversary. The migration to ML-KEM is a deadline.

Implementation considerations

Key rotation

ML-KEM encapsulation keys should be rotated on the same schedule as classical keys—typically every 90 days for long-lived keys, or per-session for ephemeral use. PasskeyBridge's tenant key management system already supports atomic key rotation with configurable policies.

Ciphertext expansion and MTU

ML-KEM-768 ciphertexts (1,088 bytes) fit comfortably within a single TCP segment (MSS typically 1,460 bytes). ML-KEM-1024 ciphertexts (1,568 bytes) approach the MSS limit but do not exceed it. Neither parameter set triggers IP fragmentation on standard networks.

For non-terrestrial network paths with reduced MTU (e.g., Starlink's ~1,400-byte path MTU), ML-KEM-768 remains within bounds while ML-KEM-1024 may require PMTUD adjustments.

WASM performance

PasskeyBridge implements ML-KEM via PQClean compiled to WebAssembly (ML-KEM-768). Benchmark data from production:

These are measured on edge function cold starts (worst case). Warm invocations are approximately 40% faster.

Summary

Key encapsulation does not slot in where key exchange was. For any protocol where one party generates the secret and the other consumes it—which is precisely the model of identity token issuance—it is a structural improvement.

ML-KEM eliminates the interactive round-trip that DH requires. It provides IND-CCA2 security (chosen-ciphertext attack resistance) by construction—something DH-based schemes achieve only through careful protocol engineering. And it is quantum-resistant under current cryptanalytic understanding.

For identity systems, the migration path is clear:

1. Today—Deploy ML-KEM-768 in hybrid mode alongside X25519 for all token encryption
2. 2027—Begin deprecating standalone ECDH key exchange for token protection
3. 2030—Align with CNSA 2.0 requirements (ML-KEM-1024 for national security systems)

The ciphertext is larger. The math is different. But the outcome is the same: a shared secret that protects a bearer token in transit. The only difference is that this one will still be secret in 2040.

Explore PasskeyBridge's post-quantum identity stack →

Start free · Test the API