Finally, a Standard for Hybrid Public-Key Encryption

The Crypto Forum Research Group (CFRG) of the Internet Research Task Force (IRTF) has published RFC 9180, specifying Hybrid Public Key Encryption (HPKE). The result of a three-year effort, this new standard aims to be simple, reusable, and future-proof, addressing the long-standing lack of a single, modern standard for public-key encryption. It is already being adopted in emerging Internet standards like TLS Encrypted Client Hello and Oblivious DNS-over-HTTPS.

The Core Idea: Non-Interactive Key Exchange

While public-key cryptography dates back to the 1970s and the Diffie-Hellman key exchange, most protocols that need to encrypt a message to a specific public key rely on a more specific mechanism. This can be done non-interactively—the sender never needs to talk to the receiver before sending an encrypted message. The process is as follows:

  1. The sender generates a fresh ephemeral key pair.
  2. The sender computes a shared secret by combining their ephemeral private key with the receiver's public key.
  3. An encryption key is derived from this shared secret, which is then used to encrypt the message.
  4. The sender packages the ephemeral public key and the ciphertext, and sends both to the receiver.

This "hybrid" approach—using asymmetric cryptography for key establishment and symmetric cryptography for message encryption—is known as the Diffie-Hellman Integrated Encryption System (DHIES), with ElGamal encryption being a foundational design. The receiver performs the same key agreement and key derivation steps with their private key and the sender's ephemeral public key, enabling them to decrypt the message.

Why Not Use Existing Standards?

Despite the apparent simplicity of this model, a number of subtle design decisions—ranging from key exchange algorithm choice to wire format encoding—must be made to ensure interoperability. Previous standardization efforts such as ANSI X9.63 (ECIES), IEEE 1363a, and ISO/IEC 18033-2 have typically failed to provide satisfactory answers to these questions.

  • Many rely on outdated or uncommon primitives like RIPEMD or CMAC-AES.
  • They often lack support for modern AEAD algorithms.
  • Several lack rigorous IND-CCA2 security proofs.
  • They frequently fail to provide test vectors, leading to inconsistent and non-interoperable implementations across libraries.

This fractured landscape has led to a split in practice, with some libraries like NaCl and libsodium implementing modern, simplified variants, while others like BouncyCastle stick to more "classical" algorithm combinations. Importantly, this lack of a uniform standard has not prevented critical applications from relying on ECIES—for instance, the Apple/Google Exposure Notification Privacy-preserving Analytics (ENPA) platform uses it mid-pandemic.

Design Goals and Construction

HPKE is composed of three building blocks, any combination of which must yield a valid instantiation:

  • A Key Encapsulation Mechanism (KEM): Handles public-key operations. Its "Encap" algorithm creates a shared secret and encapsulates it for a receiver's public key; the counterpart "Decap" algorithm recovers the original shared secret using the corresponding private key.
  • A Key Derivation Function (KDF): Processes the shared secret to generate the symmetric keys used for encryption.
  • An Authenticated Encryption with Associated Data (AEAD) algorithm: Performs the actual encryption and decryption of application data.

This modular design provides the flexibility different applications need. However, HPKE itself is not a full protocol—it does not negotiate algorithms or handle other protocol-level concerns. It is up to the implementing application to select a suitable ciphersuite.

Authentication Modes and Reusability

Beyond the implicit authentication of the receiver (only they can decrypt), HPKE supports several modes of sender authentication. Using a pre-shared key or a sender's private key, these modes allow recipients to verify the message's origin. The inclusion of a pre-shared key and the sender's private key, if any, is mixed into a "key schedule" to derive the final encryption secrets. A limitation exists here: not every KEM (such as most post-quantum algorithms) can support the sender private key authentication variant.

The design of the key schedule is central to HPKE's reusability. It can mix secrets from both the KEM and any pre-shared keys. Crucially, applications are not forced to use the built-in AEAD. An "export-only" mode allows them to derive a shared, application-specific secret, enabling them to use custom AEADs or non-standard KEMs while still relying on HPKE's foundational key schedule.

A Minimalist Interface

A primary goal is simplicity for the developer. The interface hides away the most subtle aspects of the cryptography. Encrypting a message is intended to be as direct as a couple of function calls, with many libraries offering a single-shot convenience API:

The API never exposes raw cryptographic primitives like nonces ("number used once") or sequence numbers. Managing these is an internal task of the HPKE context. This is a deliberate safety decision, as nonce reuse can have catastrophic consequences for the security of the AEAD. A caller that managed nonces externally would also have to handle sequencing; exposing that state was seen as a security and usability risk for application developers.

Wire format is similarly strict. All non-application data messages are entirely fixed-length, eliminating any ambiguity or unnecessary choices for implementers, such as deciding on elliptic curve point compression, which is instead handled within the KEM abstraction.

A Rigorous Process

Following in the footsteps of TLS 1.3 and QUIC, HPKE was developed in an iterative loop of specification and implementation. From the very first draft, interoperability testing across multiple independent codebases was a priority, helping to catch mistakes and clarify the specification early on. This effort was paired with extensive formal analysis. This scrutiny surfaced novel insights about the multi-user security limits of ChaChaPoly1305 and contributed new CFRG guidance on AEAD usage limits.

A Foundation for the Future

While fresh off the standard track, HPKE bridges the gap between theory and practical deployment—a valuable contribution to a world in need of better encryption standards. Its modular and generic construction, alongside its already broad adoption in drafts for Oblivious HTTP and Message Layer Security, positions it to be a foundational building block in protocols like TLS, where flexibility and agility are key. An expanding set of interoperable implementations from major libraries like OpenSSL, BoringSSL, and Cloudflare's CIRCL, as well as formally verified versions in hacspec, points to a wide-spread industry endorsement.

With the publication of RFC 9180, developers finally have a versatile, modern standard for public-key encryption ready for wide-scale deployment.