Post-Quantum HPKE

The IETF is working on post-quantum security for HPKE , the scheme used in protocols like TLS ECH, MLS, and Oblivious HTTP. We’ve implemented the draft: it runs today in hpke-rs, part of libcrux , and you can try it live in the demo further down this post. This post covers what changes on the way to post-quantum HPKE, and why the transition may not be a drop-in.

HPKE , standardized in RFC 9180 with an update coming up soon , is a CFRG scheme for hybrid public key encryption. The encryption is “hybrid” because it combines both worlds: the payload is encrypted with a symmetric scheme, and the symmetric key is established against the receiver’s public key with a KEM.

The core of HPKE is a two-function single-shot API. The sender encrypts a message msg, with Seal, to the receiver’s public key pkR. Additional information that is bound to the ciphertext is added in the context strings info and additional data aad. The resulting encapsulation enc and a ciphertext ct are sent to the receiver.

enc, ct <- Seal(pkR, info, aad, msg)
msg     <- Open(enc, skR, info, aad, ct)

The receiver recovers the plaintext message msg from enc and ct with their decapsulation key skR. HPKE also defines multi-message contexts, an exporter interface, and authenticated modes. HPKE is widely deployed: it is a building block of ECH , MLS , and ODOH .

What changes in PQ HPKE

HPKE is parameterized over a KEM, a KDF, and an AEAD. The KEM is the part that needs to get updated (draft-ietf-hpke-pq ). The Seal/Open API are unchanged.

New KEMs. The draft registers pure post-quantum KEMs based on ML-KEM at all three security levels, and hybrid KEMs that run ML-KEM alongside a classical ECDH group so that the combined KEM stays secure as long as either component does.

For the migration, the hybrid KEMs are the conservative choice: a flaw in ML-KEM or in the classical scheme alone does not lead to a compromise. For new deployments we recommend MLKEM1024-P384, or MLKEM768-P256 when compliance and higher security is not a concern, but size and speed.

New KDFs. Alongside HKDF, the draft adds the Keccak-based extendable-output functions SHAKE128, SHAKE256, TurboSHAKE128, and TurboSHAKE256. These line up with ML-KEM’s own internal hashing, so an implementation does not need to pull in a second hash family (typically SHA-2).

No sender authentication from the KEM. There is a practical caveat to using the new KEMs. HPKE’s Auth and AuthPSK modes authenticate the sender through AuthEncap/AuthDecap, which are built on a static-static Diffie-Hellman between the sender’s and the receiver’s keys. A KEM has no such operation: it only encapsulates to a public key, it cannot demonstrate possession of a key. So those two modes are unavailable with the post-quantum KEMs. Another HPKE draft looks at authentication modes for HPKE specifically.

Larger message sizes. The post-quantum ciphersuites are significantly larger on the wire than the classical ECDH ones. The encapsulation travels with every message, so this is a per-message cost:

All sizes in bytes. That is roughly a 35× increase in encapsulation size. It is usually acceptable on the web, but it matters for constrained links and small devices, which is exactly the setting of our IoT PQC work .

Demo

The demo below runs HPKE Seal/Open end to end in the browser using hpke-rs, our HPKE implementation, now part of libcrux and compiled to WASM . The post-quantum ciphersuites in the dropdown are the draft’s, running hpke-rs and libcrux right in your browser. Everything happens locally: the key pair is generated in your browser, and no key material or plaintext is sent anywhere. To try it:

1. Select a ciphersuite and generate a key pair on the receiver side.
2. Fill in the info, additional data, and payload on the sender side.
3. Click Seal. The sender encrypts the payload to the receiver’s public key; the encapsulated key and ciphertext appear on the receiver side.
4. Click Open. The receiver recovers the plaintext with their private key, using the same info and additional data.

Summary

The HPKE API does not change for the post-quantum transition — the changes are in the KEM and KDF algorithms, plus two differences that are visible to applications: sender authentication no longer comes for free from the KEM, and every message carries about a kilobyte more. Hybrid KEMs are the sensible default while the ecosystem migrates.