Key points
- The sender encapsulates a shared secret to the recipient public key.
- A key schedule derives an encryption context from that secret.
- AEAD efficiently encrypts and authenticates the actual message.
- HPKE base mode does not authenticate a sender identity and does not provide recipient-compromise forward secrecy.
Why hybrid encryption combines algorithms
Public-key cryptography solves the key-distribution problem: a sender can target a recipient without first sharing a secret. Symmetric authenticated encryption handles message data efficiently. HPKE specifies how to compose those pieces interoperably rather than inventing a custom envelope. [1]
The HPKE flow in three steps
First, the sender uses the recipient public key to create an encapsulated value and shared secret. Second, the HPKE key schedule combines that secret with context to derive keys and nonces. Third, the sender uses the resulting AEAD context to encrypt; the recipient decapsulates with the private key and reconstructs the same context. [1]
The transmitted package includes an encapsulated KEM value and ciphertext. Only the recipient private key holder should be able to reconstruct the decryption context in the base case.
Authentication and non-goals
RFC 9180 defines base, pre-shared-key, authenticated, and authenticated-plus-PSK modes. Applications must choose the required mode and bind identities correctly. Base mode alone proves neither a human identity nor sender possession of a long-term private key. [1]
The specification also calls out non-goals including replay prevention, plaintext-length hiding, and forward secrecy after recipient-private-key compromise. The application protocol must address those properties where required. [1]
Common questions.
Is HPKE the same as HTTPS?
No. HPKE is a message-encryption framework. HTTPS is a transport protocol using TLS. An application can carry HPKE ciphertext over HTTPS.
Does HPKE authenticate the sender?
Not in base mode. RFC 9180 defines authenticated modes, but applications must choose and bind identities correctly. [1]
Does HPKE provide forward secrecy?
Not against later compromise of the recipient private key in base and authenticated modes. RFC 9180 states this limitation explicitly. [1]
Primary sources
Definitions prefer standards bodies, government guidance, and the first-party SealTask architecture. Links open the complete source.
- 01 RFC 9180: Hybrid Public Key Encryption The HPKE construction, modes, security goals, and non-goals.
- 02 RFC 5869: HMAC-based Extract-and-Expand Key Derivation Function The HKDF specification and extract-then-expand design.
- 03 SealTask security architecture Product-specific encryption boundary, server visibility, protocols, and current limitations.