up:: In the Protocols MOC

HPKE (Hybrid Public Key Encryption)

HPKE, Hybrid Public Key Encryption, is the standardized way to encrypt a message to someone’s public key using modern building blocks, defined in RFC 9180. It assembles three primitives into one scheme: a key-encapsulation mechanism that agrees on a fresh symmetric key, a key-derivation function that shapes that key into working material, and an AEAD cipher that actually seals the payload. The word “hybrid” here means public-key math wrapped around symmetric encryption, which is a different sense of the word from the classical-plus-post-quantum hybrids that dominate the migration. HPKE is the encryption engine underneath TLS Encrypted Client Hello, MLS group messaging, and Oblivious HTTP, and because its KEM slot is a swappable component, it has a clean path to post-quantum security through an ML-KEM KEM.

Source: R. Barnes, K. Bhargavan, B. Lipp, C. Wood, “Hybrid Public Key Encryption,” RFC 9180, February 2022, rfc-editor.org/rfc/rfc9180.

The short version:

• HPKE is a ciphersuite of three parts: a KEM, a KDF, and an AEAD. RFC 9180 defines a ciphersuite as exactly that triple, so every HPKE deployment names one algorithm for each slot.
• The “hybrid” in the name is the classic public-key-plus-symmetric split. HPKE generates a symmetric key with a KEM and encapsulates it under the recipient’s public key, then encrypts the actual data with a fast AEAD cipher.
• It is a general-purpose sealing primitive, and three major protocols already lean on it: TLS Encrypted Client Hello encrypts the sensitive ClientHello fields with HPKE, MLS uses it for every group public-key operation, and Oblivious HTTP uses it to seal requests from a relay.
• HPKE has four modes: base (no sender authentication), PSK, auth (sender proves a static key), and auth-PSK (both). The mode decides whether the recipient learns who sent the message.
• The post-quantum path runs through the KEM slot. Drop an ML-KEM KEM into the KEM position and the confidentiality of an HPKE message becomes quantum-resistant, which is why HPKE is the natural carrier for PQC in the protocols built on top of it.

Think of HPKE as a standardized shipping process for a sealed package. The KEM is the tamper-proof lockbox that only the recipient’s key can open, and inside it rides a single-use combination. The KDF stamps that combination into the exact shape the lock on the outer crate needs, and the AEAD is that outer crate, fast to pack and impossible to open or alter without the combination. You address the whole thing to a public key, and only the holder of the matching private key can work backward through the lockbox to the combination and then into the crate. HPKE writes down that process once so every protocol that needs to seal a message to a public key uses the same audited machinery instead of improvising its own.

What is HPKE?

HPKE is a scheme for encrypting an arbitrary-length message so that only the holder of a specific private key can read it, standardized by the IRTF’s Crypto Forum Research Group as RFC 9180 in February 2022. It is an Informational RFC, which is the CFRG’s publication track, and it has become the reference construction that IETF standards reach for when they need public-key encryption of a payload. The scheme is defined entirely in terms of three swappable primitives, and RFC 9180 §4 states the shape directly: “A ciphersuite is a triple (KEM, KDF, AEAD) containing a choice of algorithm for each primitive.”

The three roles map cleanly onto the three jobs of sealing a message:

1. The KEM agrees on a key. A key-encapsulation mechanism takes the recipient’s public key and produces two things at once: a fresh shared secret, and an encapsulation of that secret that only the recipient’s private key can open. The sender never has to invent the key and encrypt it separately.
2. The KDF shapes it. A key-derivation function stretches and formats the KEM’s shared secret into the exact keying material the AEAD needs, binding in context so keys derived for different purposes never collide.
3. The AEAD seals the data. An authenticated-encryption cipher encrypts the actual payload under the derived key and produces a tag that detects any tampering, so the recipient gets both confidentiality and integrity from one operation.

Source: R. Barnes, K. Bhargavan, B. Lipp, C. Wood, RFC 9180, §4, February 2022, rfc-editor.org/rfc/rfc9180.

What does “hybrid” mean in HPKE?

The “hybrid” in HPKE is the oldest idea in applied public-key cryptography: use slow public-key math only to agree on a key, then do the heavy lifting with fast symmetric encryption. It has nothing to do with the classical-plus-post-quantum hybrid combiners that carry TLS hybrid key exchange, and conflating the two words is a common trap. RFC 9180 §1 draws the line precisely against the older textbook approach, describing HPKE as conveying “an encryption key encapsulated with a public key scheme, along with one or more arbitrary-sized ciphertexts encrypted using that key.”

There is a subtle improvement over the textbook version worth naming. The old pattern generated a random symmetric key and then encrypted that key under the recipient’s public key. HPKE instead has the KEM generate the symmetric key and its encapsulation together, which RFC 9180 §1 frames as the shift from “encrypt the symmetric key with the public key” to “generate the symmetric key and its encapsulation with the public key.” That is exactly the KEM abstraction, and it is why HPKE composes so cleanly with lattice KEMs like ML-KEM, which are built as key encapsulation from the ground up.

Source: R. Barnes, K. Bhargavan, B. Lipp, C. Wood, RFC 9180, §1, February 2022, rfc-editor.org/rfc/rfc9180.

What are HPKE’s modes?

HPKE ships in four modes, and the mode a protocol picks decides whether the recipient gets any assurance about who sent the message. Confidentiality to the recipient is constant across all four; sender authentication is the variable. RFC 9180 §5 lays them out in a table:

Mode	Code	What it adds
mode_base	0x00	Encryption to the recipient with no sender authentication
mode_psk	0x01	Sender proves knowledge of a pre-shared key
mode_auth	0x02	Sender proves possession of a static asymmetric key
mode_auth_psk	0x03	Sender proves both a pre-shared key and a static asymmetric key

The base mode is the workhorse, sealing a message to a public key when the recipient does not need to know the origin. The auth modes matter when the payload itself has to carry a claim of who sent it, which is why sender-authenticated HPKE is where the post-quantum authentication question shows up. RFC 9180 §7.1.5 anticipates future KEMs and requires that any new KEM “MUST indicate whether or not Auth and AuthPSK modes are supported,” so a post-quantum KEM slotting into HPKE has to declare whether it can carry the authenticated modes or only the base one.

Source: R. Barnes, K. Bhargavan, B. Lipp, C. Wood, RFC 9180, §5 and §7.1.5, February 2022, rfc-editor.org/rfc/rfc9180.

Where is HPKE used?

HPKE is a foundational primitive that several high-profile IETF standards adopted rather than rolling their own public-key encryption, which is what makes it load-bearing for the transition. RFC 9180 §1 itself names two of its applications, Messaging Layer Security and TLS Encrypted ClientHello, and the ecosystem has added more since.

1. TLS Encrypted Client Hello (ECH). The plaintext ClientHello leaks the destination server name and other fields that identify a connection. ECH encrypts those sensitive fields with HPKE to a public key the client fetches in advance, so a network observer cannot read which site is being requested. HPKE is the sealing engine for that encrypted inner message.
2. MLS group messaging. RFC 9420 builds its entire ratchet tree on HPKE. Every public-key encryption in the group key agreement is an HPKE operation, and the group’s ciphersuite names the KEM, KDF, and AEAD that HPKE uses.
3. Oblivious HTTP. An OHTTP client seals its HTTP request to a gateway’s public key with HPKE and routes it through a relay that cannot read the contents, so the gateway sees the request without seeing the client’s address and the relay sees the address without seeing the request.

The pattern across all three is that HPKE is the reusable sealing layer, and each protocol supplies the surrounding logic. That reuse is exactly why HPKE’s post-quantum story matters so much: an ML-KEM KEM added to HPKE upgrades the confidentiality of every one of these protocols through a single well-audited component rather than three separate migrations.

Source: R. Barnes, K. Bhargavan, B. Lipp, C. Wood, RFC 9180, §1, February 2022, rfc-editor.org/rfc/rfc9180; R. Barnes, B. Beurdouche, R. Robert, J. Millican, E. Omara, K. Cohn-Gordon, “The Messaging Layer Security (MLS) Protocol,” RFC 9420, §5.1, July 2023, rfc-editor.org/rfc/rfc9420.

Is HPKE post-quantum?

HPKE as standardized in RFC 9180 is not post-quantum, because its named KEMs are the classical elliptic-curve DHKEMs built on ECDH over curves like Curve25519 and P-256, and Shor’s algorithm breaks those. The design, though, was built to be re-parameterized, and the fix lives entirely in the KEM slot. Substitute a post-quantum KEM, most naturally ML-KEM, and the confidentiality of an HPKE message becomes quantum-resistant while the KDF and AEAD slots stay exactly as they are.

RFC 9180 §9.1.3 addresses the quantum question at the composition level, stating that its theorems “in combination with a post-quantum-secure authenticated KEM, guarantee the post-quantum security of HPKE’s Auth mode.” The practical read is that HPKE inherits the quantum resistance of whatever KEM you put in it, so the migration for every HPKE-based protocol reduces to standardizing a post-quantum KEM identifier and having both sides support it. This is the same combiner logic as TLS hybrid key exchange applied one layer down, at the reusable encryption primitive rather than at each protocol’s handshake, which is why HPKE is a strategic piece of the applied-PQC map.

Source: R. Barnes, K. Bhargavan, B. Lipp, C. Wood, RFC 9180, §9.1.3, February 2022, rfc-editor.org/rfc/rfc9180.

Common misconceptions

• “HPKE’s ‘hybrid’ means it mixes classical and post-quantum algorithms.” It means public-key math wrapped around symmetric encryption, the older sense of hybrid. A classical-plus-post-quantum combiner is a separate idea, and RFC 9180’s baseline KEMs are all classical elliptic-curve DHKEMs.
• “HPKE is a replacement for TLS.” HPKE is a message-sealing primitive that protocols embed. TLS Encrypted Client Hello uses HPKE to protect part of its handshake, and MLS and Oblivious HTTP use it for their public-key operations, but HPKE does not set up a session on its own.
• “HPKE is already quantum-safe because it is modern.” The RFC 9180 ciphersuites use elliptic-curve KEMs that Shor’s algorithm breaks. HPKE becomes quantum-safe only when its KEM slot is filled with a post-quantum KEM like ML-KEM.
• “Any HPKE message proves who sent it.” Only the auth and auth-PSK modes give sender authentication. The base mode, which is the most common, encrypts to the recipient with no proof of origin.
• “Migrating HPKE means rewriting the KDF and AEAD too.” The post-quantum change is confined to the KEM slot. The KDF and AEAD, which are symmetric and only weakened by Grover, stay in place at their existing sizes.

Questions people ask

What is HPKE in one sentence? It is the RFC 9180 standard for encrypting a message to a public key by combining a KEM, a KDF, and an AEAD into a single sealing scheme.

What does the “hybrid” in Hybrid Public Key Encryption mean? Public-key math combined with symmetric encryption, the classic construction where a KEM agrees on a key and a fast symmetric cipher encrypts the payload. It is not the classical-plus-post-quantum combiner sense of hybrid.

Where is HPKE actually used? In TLS Encrypted Client Hello to encrypt sensitive handshake fields, in MLS for every group public-key operation, and in Oblivious HTTP to seal requests routed through a relay.

Is HPKE quantum-safe? Not as standardized, because RFC 9180’s KEMs are classical elliptic-curve schemes that Shor’s algorithm breaks. It becomes quantum-safe when an ML-KEM KEM is dropped into its KEM slot, which upgrades the confidentiality of every protocol built on it.

How is HPKE different from a KEM by itself? A KEM only agrees on a symmetric key. HPKE takes that key, derives working material with a KDF, and uses an AEAD to actually encrypt and authenticate a payload, so it delivers a complete sealed message rather than just a shared secret.

What are HPKE’s four modes for? They control sender authentication: base gives none, PSK proves a shared key, auth proves a static asymmetric key, and auth-PSK proves both. Confidentiality to the recipient is present in all four.

---

Everything here is the map, given freely. When your team needs its own encryption surfaces sorted into what already resists a harvesting quantum adversary and what still has to move, that’s what an alignment briefing is for.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.