Establishing a key differs from protecting content
Traditional designs can generate a content key, protect it with the recipient’s public key and encrypt the body symmetrically. KEM-based designs instead generate a shared secret together with its encapsulation and derive content-protection material. The first pattern is not every modern scheme’s sole workflow.
The division combines public-key management with symmetric content protection rather than applying public-key operations to each message byte. Encapsulation, parameters and ciphertext need a specified format and context; the label hybrid alone does not define reconstruction.
References: [1]
HPKE specifies a KEM, KDF and AEAD composition
RFC 9180 defines an HPKE suite through its KEM, KDF and AEAD choices. KEM establishes a secret, KDF binds context into key and nonce material, and AEAD protects content and associated data, each under distinct interfaces.
HPKE distinguishes Base, PSK, Auth and AuthPSK modes. Encrypting to a recipient in Base mode does not authenticate which sender created the message. Applications must establish the recipient-key binding and select the relevant mode.
References: [1]
The composed guarantees retain boundaries
RFC 9180 does not guarantee forward secrecy against compromise of long-term recipient secrets or recover lost or reordered messages. Ordered processing within one context supplies some replay protection, but not general protection across contexts. Applications still define sequencing, retries, key identifiers and errors rather than extending secrecy into every session guarantee.
The word hybrid can also describe combinations of classical and post-quantum key-establishment mechanisms. That differs from the public-key/symmetric composition discussed here; the label alone does not identify algorithms, assumptions or guarantees after a component fails.