Hybrid Public Key Encryption (HPKE) is an attempt to standardize the widely-used practice of using asymmetric and symmetric primitives together, to benefit from both the key management advantages of public-key algorithms, and from the performance boost of symmetric primitives.

HPKE ciphersuites are a triple consisting of (KEM, KDF, AEAD). Traditionally, the KEM would’ve simply been a symmetric key encrypted using a public key, however HPKE goes on a more generic route: “generate the symmetric key and its encapsulation with the public key”.

DH-Based KEM

As mentioned above, the approach for key encapsulation supports more than just direct encryption of a symmetric key. An example based on DH key exchange (that also relies on an “internal” KDF) goes (roughly) as follows:

  1. You get the DH public key of the party you’re trying to communicate with.
  2. You generate an ephemeral DH keypair and perform a DH computation with the key from step (1), obtaining a “shared secret”. The public part of your new ephemeral keypair is actually the “encapsulated” key.
  3. Using that shared secret, you derive a symmetric key that you’ll actually use for encrypting the plaintext.

Voila, you have yourself a KEM. Obviously, the draft goes into a lot more detail than this.

Authentication

Apart from plain encryption using a public key, HPKE supports 3 modes: authentication using a PSK, authentication through possession of a KEM private key, and a combination of PSK and KEM private key.

For PSK authentication, the value and ID of the PSK is mixed in when producing the encryption context. For KEM private key authentication, the public part of the sender’s keypair during encryption context generation. This latter mode depends on a KEM that supports AuthEncap and AuthDecap instead of Encap and Decap.

Encryption

HPKE defines a key schedule common to all the modes mentioned above, which processes the protocol inputs to produce an encryption context. The key schedule produces a secret key (used with the AEAD), a base-nonce (also for use with the AEAD), and an exporter secret. Key commitment is baked into the scheme.

Encryption is unidirectional - the receiver’s context must not be used for encrypting; the sender’s context must not be used for decrypting. The encryption context can, however, be used to derive other secrets for use by the application for other purposes, including the case where a receiver wants to send back replies.

Secret export

HPKE allows both parties to derive extra secrets from the exporter secret using the KDF Expand functionality.

Security considerations

The desired security goals are:

  • Message secrecy
  • Export key secrecy: indistinguishability of exported secrets from random bitstrings of equal length
  • Sender authentication (for the PSK, Auth and PSK/Auth modes)

The DHKEM described above is vulnerable to a key-compromise impersonation attack, i.e. if an attacker gets their hands on the recipient’s private key they can impersonate any sender by decapsulating the shared secret, performing the key schedule and then replacing the ciphertext(s) with whatever they desire.

key-compromise impersonation attacks are generally possible on HPKE because KEM ciphertexts are not bound to HPKE messages.

Applications that need/want resistance against such attacks need to handle their own mitigations, e.g. by appending a signature from the sender for (enc, ciphertext). PSKs also strengthen the authentication and secrecy properties as the attacker now has to obtain two secrets.

HPKE is fairly low-level and thus expects some security properties to be provided through some higher-level mechanisms in the application. Possibly the most important of these relates to the ordering of messages - receivers must present ciphertexts in the same order in which they were produced/sent.

HPKE does not attempt to provide a number of features:

  • algorithm downgrade prevention
  • replay protection - some replay protection is provided within the same context (since ciphertexts must be decrypted in sequence), but nothing beyond that
  • forward secrecy - ciphertexts can be decrypted if the receiver’s public key is compromised
  • hiding plaintext length