← Back to Blog Research

IETF RFC 9180: HPKE (Hybrid Public Key Encryption)

12 min read

The name HPKE is confusing. "Hybrid" in HPKE does not mean "post-quantum hybrid." It is older terminology meaning "asymmetric plus symmetric": use a public-key operation to derive a key, then use a symmetric cipher to encrypt the data. RSA-OAEP works this way. ECIES works this way. Most modern public-key encryption works this way. The term predates the post-quantum era.

IETF RFC 9180, published in February 2022, standardizes a clean, modern HPKE scheme. It is what protocols like TLS Encrypted Client Hello (ECH), Messaging Layer Security (MLS), and Oblivious DNS over HTTPS (ODoH) use to encrypt arbitrary payloads under a recipient's public key. It is not post-quantum hybrid in the sense ETSI TS 103 744 means, but it is increasingly being extended to support post-quantum KEMs as part of broader PQC migration.

This post explains what HPKE does, the four modes it offers, how it differs from ETSI TS 103 744's hybrid KEX, and where post-quantum KEMs fit. For developers building protocols on top of HPKE or migrating existing applications to PQC, understanding RFC 9180 is essential.

What HPKE Provides

HPKE is a single primitive that combines:

A KEM (Key Encapsulation Mechanism)
A KDF (Key Derivation Function)
An AEAD cipher (Authenticated Encryption with Associated Data)

Given a recipient's public key, HPKE can:

Encrypt one or more messages to that recipient
Optionally authenticate the sender (if the sender has their own key pair)
Optionally mix in a pre-shared key for additional security

The result is a single API that handles asymmetric encryption end-to-end.

The basic flow:

Sender calls Setup with the recipient's public key, gets back an encapsulated key and a context
Sender uses the context to seal one or more messages (with associated data)
Sender sends the encapsulated key and the ciphertexts to the recipient
Recipient calls Setup with their secret key and the encapsulated key, gets back a context
Recipient uses the context to open the messages

The encapsulated key carries the per-session randomness. The context binds all subsequent operations to that session.

Why HPKE Was Needed

Before HPKE, every protocol that wanted to encrypt under a public key invented its own scheme. RSA-OAEP for old systems, ECIES with various curves and AEAD choices for newer ones. Each protocol had subtle differences in how it derived the AEAD key, what it bound into the AAD, how it handled multi-message contexts.

HPKE is a clean, standardized version that gives protocols a single building block. Use HPKE, follow the spec, and you get a known-secure construction. Many of the subtle pitfalls in custom designs are avoided.

The IETF Crypto Forum Research Group (CFRG) developed HPKE and shepherded it through standardization. RFC 9180 documents the result.

The Four Modes

HPKE supports four modes:

Mode 0: Base

Just the recipient's public key. Anyone can send a message; the recipient decrypts.

`` Setup(skR, enc) -> context context.Seal(aad, plaintext) -> ciphertext ``

This is the most common case: anonymous public-key encryption.

Mode 1: PSK

Pre-shared key in addition to the recipient's public key. Both sender and recipient know the PSK; the sender provides a PSK identifier to the recipient.

Use case: bind encryption to a specific channel context, like a session token both parties already have.

Mode 2: Auth

Sender has a key pair too. The encapsulation incorporates both keys, providing authentication of the sender.

Use case: mutual authentication where the recipient wants to verify which sender created the ciphertext.

Mode 3: AuthPSK

Combination of Auth and PSK. Sender has a key pair, both parties have a PSK.

Use case: highest assurance multi-factor authentication of a session.

Algorithm Choices

HPKE separates KEM, KDF, and AEAD. RFC 9180 standardizes specific combinations. Common choices:

KEM: DHKEM(P-256, HKDF-SHA-256), DHKEM(X25519, HKDF-SHA-256), DHKEM(P-384, HKDF-SHA-384), DHKEM(P-521, HKDF-SHA-512), DHKEM(X448, HKDF-SHA-512)
KDF: HKDF-SHA-256, HKDF-SHA-384, HKDF-SHA-512
AEAD: AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305, Export-Only

DHKEM is a Diffie-Hellman-based KEM. The sender and recipient run ECDH; the result is processed through HKDF to produce the shared secret. This is the classical (non-PQC) KEM family in HPKE.

Export-Only AEAD means HPKE produces an export key but does not encrypt directly. Higher-level protocols use the exported key for their own encryption.

How HPKE Differs from TS 103 744

TS 103 744 is about hybrid KEX (key exchange). HPKE is about hybrid public key encryption (the "hybrid" here meaning asymmetric plus symmetric). These are different operations.

Specifically:

TS 103 744 hybrid: combine classical and PQC KEMs to derive a shared secret. Used in TLS handshakes, IPsec key exchange.
RFC 9180 HPKE: encrypt data under a recipient's public key using a KEM plus AEAD. Used in MLS group operations, ECH, ODoH.

HPKE itself can use a hybrid KEM (TS 103 744-style) by selecting a hybrid KEM in the KEM slot. This is being standardized: post-quantum HPKE drafts add ML-KEM and HQC to the KEM choices.

So HPKE is the protocol building block; hybrid KEX is the algorithm property. PQC HPKE adds hybrid KEX algorithms to the HPKE primitive.

PQC HPKE

The CFRG is standardizing HPKE with post-quantum KEMs. Drafts in progress:

draft-westerbaan-cfrg-hpke-xyber768d00: HPKE with X25519+ML-KEM-768 hybrid KEM
draft-cfrg-hpke-mlkem: HPKE with pure ML-KEM (no hybrid)
Other drafts exploring HPKE with HQC, classic McEliece

Once standardized, applications using HPKE today (MLS, ECH, ODoH) can migrate to PQC by negotiating PQC HPKE algorithms instead of classical ones. The HPKE API stays the same; the underlying KEM changes.

For QNSQY, HPKE is not directly used because QNSQY's file format is custom (QSPG v2). But the design patterns are similar: KEM for encapsulation, HKDF for derivation, AEAD for bulk encryption. See hybrid encryption.

HPKE in TLS Encrypted Client Hello

TLS 1.3 Encrypted Client Hello (ECH) is one of the most prominent uses of HPKE. The problem ECH solves: the ClientHello message in TLS reveals which server the client is connecting to (via the SNI field). This leaks browsing patterns to network observers.

ECH solves this by encrypting the inner ClientHello under the server's public key, using HPKE. The outer ClientHello points to a fronting server (often a CDN); the inner ClientHello reveals the actual SNI only after decryption.

HPKE is the natural fit because:

The server publishes its HPKE public key in DNS HTTPS records
The client uses that key to seal the inner ClientHello
Single message, single recipient, no session negotiation needed

ECH is rolling out across browsers and CDNs in 2025 to 2026.

HPKE in MLS

Messaging Layer Security (MLS, RFC 9420) uses HPKE for member-to-member encryption within a group. MLS supports group sizes up to thousands; each member pair uses HPKE to encrypt key updates and welcome messages.

MLS combined with PQC HPKE will eventually provide post-quantum group messaging. The path is open; libraries are integrating. See IETF RFC 9420 MLS.

HPKE in Oblivious DNS

Oblivious DNS over HTTPS (ODoH) lets clients query DNS without revealing their IP to the resolver. The client encrypts the DNS query with HPKE under the resolver's public key; an intermediate proxy forwards the ciphertext.

The proxy sees the IP but not the query. The resolver sees the query but not the IP. Privacy through separation. HPKE makes the encryption layer simple and secure.

Implementation Considerations

For implementers, RFC 9180 has clear test vectors and reference implementations. Pitfalls to watch:

Context reuse: a context is for one direction (sender to recipient). Two-way communication uses two contexts.
PSK quality: in PSK mode, the PSK should have sufficient entropy; otherwise it provides no security.
AAD binding: associated data binds the ciphertext to context. Inconsistencies between sender and recipient AAD cause decryption failures.
Multi-recipient handling: HPKE in base form is single-recipient. Multi-recipient requires either separate HPKE calls or a higher-level protocol (like MLS).

QNSQY supports multi-recipient encryption through a custom file format (QSPG v2 with FLAG_MULTI_RECIPIENT) that uses ML-KEM for each recipient slot. This is similar in spirit to running HPKE per recipient but with a unified file format optimized for storage and sharing.

HPKE Performance

HPKE is fast. The setup adds one ECDH operation (or KEM encap/decap) plus HKDF. Each Seal/Open is a single AEAD call. For large messages or many small messages to the same recipient, HPKE amortizes well: the setup happens once, the AEAD operations are cheap.

PQC HPKE inherits the underlying KEM performance:

DHKEM(X25519): ~150 microseconds setup
ML-KEM-768 KEM: ~50 microseconds setup
Hybrid (X25519+ML-KEM-768): ~200 microseconds setup
HPKE Seal: AEAD speed (gigabytes per second)

The setup cost is negligible for most use cases. AEAD performance dominates total throughput.

HPKE Test Vectors and Validation

RFC 9180 ships with test vectors covering all four modes and every standardized algorithm combination. The vectors live in Appendix A of the RFC and are mirrored in the CFRG hpke-spec repository on GitHub. Each test vector includes the inputs (sender ephemeral key, recipient public key, info, AAD), the intermediate values (shared secret, secret, key, base nonce), and the resulting ciphertext.

Implementations are expected to match these vectors byte for byte. The Cloudflare HPKE library, the Mozilla NSS HPKE module, and the BoringSSL HPKE port all pass the full test vector set. For new implementations, running RFC 9180 vectors during CI is the table-stakes validation step before claiming HPKE compliance.

For PQC HPKE drafts, test vectors are appearing in the corresponding draft documents. As of early 2026, the xyber768d00 draft includes a small set of vectors covering hybrid encapsulation, decapsulation, and Seal/Open. These are subject to change until the draft progresses.

QNSQY does not implement HPKE directly, but the underlying primitives (HKDF-SHA-256, AES-256-GCM, ChaCha20-Poly1305) all pass their own RFC and ACVP test vectors. The QSPG v2 format documents its key derivation context labels in a public specification, which lets independent implementations verify compatibility.

Migration Patterns from Classical to PQC HPKE

Existing HPKE deployments (ECH, MLS, ODoH) face a coordinated migration to PQC over the 2025 to 2030 window. Three patterns are emerging.

Pattern A: per-server hybrid switch. The server publishes a new HPKE public key using a hybrid KEM (X25519 plus ML-KEM-768). Clients that support hybrid use the new key; clients that do not fall back to the classical key. This is how Cloudflare and Google have rolled out hybrid TLS, and the same pattern applies to ECH.

Pattern B: dual-issuance. During the transition the server holds both a classical and a hybrid public key, advertised in different DNS records or different metadata fields. Clients pick whichever they understand. Once classical clients drop below a threshold (1 percent of traffic, say) the classical key is retired.

Pattern C: opportunistic upgrade. The first handshake uses classical HPKE, then negotiates PQC for subsequent messages. This is faster on the initial connection but provides no PQC protection for the first message. MLS group operations can use this pattern when adding a new member who does not yet have PQC keys.

Pattern A is the consensus recommendation for new deployments because it preserves the harvest-now-decrypt-later guarantee from the first message.

FAQ

Is HPKE post-quantum?

Not by default. HPKE specifies the protocol structure. The KEM slot can be filled with classical (DHKEM) or post-quantum (ML-KEM hybrid) algorithms. PQC HPKE drafts are in progress at CFRG; expect standardization through 2026.

Should I use HPKE or build my own asymmetric encryption?

Use HPKE. Custom designs have a long history of subtle flaws. HPKE is a clean, well-analyzed construction with formal security proofs. Implementations exist in major cryptographic libraries (libsodium, BoringSSL, Cloudflare's HPKE library, etc.).

Does QNSQY use HPKE?

QNSQY uses a custom file format (QSPG v2) rather than HPKE because the file format predates HPKE standardization and supports features (multi-recipient, polyglot, deniable encryption) not in HPKE. The cryptographic design follows similar principles: KEM for key encapsulation, HKDF for derivation, AEAD for bulk encryption. See pricing.

What is DHKEM?

DHKEM is a Diffie-Hellman-based KEM, defined in RFC 9180. It is the standard KEM for HPKE in the classical setting. It runs ECDH between sender's ephemeral key and recipient's static key, then derives the shared secret via HKDF. Its formal security as a KEM is proven in the random oracle model.

How does HPKE handle replay?

Base HPKE does not include replay protection. The sender produces a ciphertext; if the same ciphertext is sent twice, the recipient can decrypt both. Replay protection is added at higher layers (sequence numbers, nonces, session IDs). MLS and other HPKE consumers add their own replay handling.

Does HPKE support forward secrecy?

Single-message HPKE (Mode 0) provides forward secrecy on the sender side because the sender uses an ephemeral key. The recipient's static key is held longer, so compromise of the recipient's key compromises all past messages encrypted to that key. For full forward secrecy on both sides, higher-level protocols (MLS, Signal-style ratchets) layer additional ephemeral key exchanges on top of HPKE.

How big is an HPKE-encapsulated key?

Depends on the KEM. DHKEM(X25519) produces 32-byte encapsulated keys. ML-KEM-768 produces 1088-byte ciphertexts. Hybrid X25519 plus ML-KEM-768 produces 1120 bytes total. For protocols sending many small messages, the encapsulated key dominates the wire size. For larger payloads (file encryption, archive sealing) the relative overhead disappears.

Sources

IETF RFC 9180, "Hybrid Public Key Encryption," February 2022. https://datatracker.ietf.org/doc/html/rfc9180
IETF CFRG Working Group. https://datatracker.ietf.org/group/cfrg/about/
IETF draft-westerbaan-cfrg-hpke-xyber768d00. https://datatracker.ietf.org/doc/draft-westerbaan-cfrg-hpke-xyber768d00/
IETF RFC 5869, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)." https://datatracker.ietf.org/doc/html/rfc5869
NIST SP 800-56A Rev 3, "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography." https://csrc.nist.gov/pubs/sp/800/56/a/r3/final
Cloudflare HPKE Library. https://github.com/cloudflare/circl
CFRG hpke-spec repository (test vectors). https://github.com/cfrg/draft-irtf-cfrg-hpke

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY