{
 "id": "eph56605b5",
 "slug": "hybrid-encryption",
 "title": "Hybrid encryption",
 "updated": "2026-10-15",
 "topic_path": [
  {
   "id": "technology",
   "label": "Technology and the built world",
   "api_url": "https://www.edgepedia.org/api/v1/topics/technology"
  },
  {
   "id": "technology.computing",
   "label": "Computing and digital systems",
   "api_url": "https://www.edgepedia.org/api/v1/topics/technology.computing"
  },
  {
   "id": "technology.computing.networks",
   "label": "Networks and security",
   "api_url": "https://www.edgepedia.org/api/v1/topics/technology.computing.networks"
  },
  {
   "id": "technology.computing.networks.alpha-2-to-ma",
   "label": "Titles 2 to Ma",
   "api_url": "https://www.edgepedia.org/api/v1/topics/technology.computing.networks.alpha-2-to-ma"
  }
 ],
 "geo": [
  {
   "id": "geo.nongeo.t1946.technology.computing.networks.alpha-2-to-ma",
   "label": "Non-geographic · 1946 to 2000: Titles 2 to Ma",
   "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946.technology.computing.networks.alpha-2-to-ma",
   "path": [
    {
     "id": "geo.nongeo",
     "label": "Non-geographic",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo"
    },
    {
     "id": "geo.nongeo.t1946",
     "label": "Non-geographic · 1946 to 2000",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946"
    },
    {
     "id": "geo.nongeo.t1946.technology",
     "label": "Technology and the built world",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946.technology"
    },
    {
     "id": "geo.nongeo.t1946.technology.computing",
     "label": "Computing and digital systems",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946.technology.computing"
    },
    {
     "id": "geo.nongeo.t1946.technology.computing.networks",
     "label": "Networks and security",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946.technology.computing.networks"
    },
    {
     "id": "geo.nongeo.t1946.technology.computing.networks.alpha-2-to-ma",
     "label": "Titles 2 to Ma",
     "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946.technology.computing.networks.alpha-2-to-ma"
    }
   ]
  }
 ],
 "excerpt": "Hybrid encryption encrypts a message with a fast symmetric cipher under a fresh random key, protecting that key with the recipient's public key, as in HPKE.",
 "snippet": "Hybrid encryption encrypts a message with a fast symmetric cipher under a fresh random key, protecting that key with the recipient's public key, as in HPKE.",
 "node": "technology.computing.networks.alpha-2-to-ma",
 "markdown": "# Hybrid encryption\n\nHybrid encryption encrypts a message with a fast symmetric cipher under a fresh random key, and protects that key with the recipient's public key. Neither half alone suffices: public-key schemes have restricted message spaces, so each ciphertext can hide only a limited number of plaintext bits, and they are too slow for bulk data.<sup>[7]</sup> The output is a pair: an encapsulated or encrypted session key plus one or more arbitrary-sized ciphertexts encrypted under that key.<sup>[2]</sup>\n\n| Key fact | Detail |\n|---|---|\n| Output | An encapsulated session key plus ciphertext(s) of the message encrypted symmetrically under that key<sup>[2]</sup> |\n| Standard decomposition | KEM (key encapsulation mechanism) + DEM (data encapsulation mechanism), formalized by Cramer and Shoup<sup>[1]</sup> |\n| Modern standard | HPKE, RFC 9180: any KEM + KDF + AEAD combination<sup>[3]</sup> |\n| Security goal | IND-CCA2 security of the whole scheme under classical assumptions on the primitives<sup>[2]</sup> |\n| Recommended instantiation | DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_256_GCM (Tink), 128-bit elliptic-curve security<sup>[4]</sup> |\n| Post-quantum KEM | ML-KEM (FIPS 203), 256-bit shared secrets, parameter sets ML-KEM-512/768/1024<sup>[5]</sup> |\n| Main caveat | Provides privacy, not authenticity; sender must be authenticated by other means<sup>[4]</sup> |\n\n## How it works\n\nThe scheme decomposes into a key encapsulation mechanism (KEM) and a data encapsulation mechanism (DEM). The KEM takes a public key and outputs a ciphertext c and a key k, with correctness (k recoverable from c given the secret key) and security (k indistinguishable from uniform given the public key and c). The DEM encrypts the actual plaintext under k with a symmetric scheme such as AES.<sup>[6]</sup> This KEM/DEM paradigm is how anything longer than very short messages is encrypted with public-key cryptography in practice.<sup>[1]</sup>\n\nFormal guarantees come from composition theorems. If the public-key scheme is CCA-secure and the private-key scheme is CCA-secure, the hybrid construction is a CCA-secure public-key scheme; for CPA security it suffices that the public-key scheme is CPA-secure and the private-key scheme is one-time (EAV) secure.<sup>[6]</sup> A hybrid scheme was proved secure against chosen-ciphertext attack when both KEM and DEM are CCA-secure.<sup>[7]</sup> There is a construction, secure under the Decisional Diffie-Hellman assumption, whose KEM alone is not CCA2-secure yet whose whole hybrid scheme is, relaxing the earlier requirement.<sup>[8]</sup> Later work introduced IND-CCCA (constrained chosen-ciphertext) security for KEMs, stronger than IND-CPA but strictly weaker than IND-CCA, and proved that any IND-CCCA-secure KEM combined with any authenticated symmetric encryption scheme yields IND-CCA-secure hybrid encryption.<sup>[9]</sup> The main security property demanded of KEMs today is IND-CCA2, though Diffie-Hellman viewed as a KEM does not formally satisfy it and is still considered safe for ephemeral key exchange in [TLS 1.3](https://www.edgepedia.org/tls-1-3).<sup>[10]</sup>\n\n## How it is done\n\nA practitioner follows these steps, shown here in the Diffie-Hellman form used by HPKE:<sup>[3]</sup>\n\n1. **Key generation.** The receiver holds a long-term key pair; in HPKE's DHKEM this is a Diffie-Hellman pair \\( (y, g^{y}) \\).\n2. **Encapsulation.** The sender generates a fresh key pair \\( (x, g^{x}) \\), computes the non-interactive shared secret, and derives an encryption key from it. The KEM's Encap creates the symmetric secret and wraps it for the public key; the receiver's Decap(skR, enc) recovers it.<sup>[3]</sup>\n3. **Symmetric encryption.** The sender encrypts the message with an AEAD scheme under the derived key and sends the encapsulation plus the ciphertext.<sup>[3]</sup>\n4. **Decryption.** The receiver decapsulates, derives the same key, and decrypts.<sup>[3]</sup>\n\nHPKE is designed as a composition of a KEM, a key derivation function (KDF), and an AEAD algorithm; any combination of the three yields a valid instantiation subject to security constraints.<sup>[3]</sup> Google's Tink library recommends the DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_256_GCM key type for most use cases, implementing RFC 9180 with 128-bit security for elliptic-curve schemes, security against adaptive chosen-ciphertext attacks, and randomized encryption; plaintext and context info can have arbitrary length within 0..\\( 2^{32} \\) bytes.<sup>[4]</sup>\n\n## Origin\n\nThe combined use of public-key and conventional cryptosystems is called \"hybrid encryption.\"<sup>[7]</sup> The underlying public-key idea goes back to Diffie and Hellman's 1976 paper \"New Directions in Cryptography,\" published in the IEEE Transactions on Information Theory, whose key exchange is today called Diffie-Hellman key exchange.<sup>[3]</sup><sup> • </sup><sup>[13]</sup> After the demise of public-key knapsack systems (Brickell and Odlyzko, 1988), public-key encryption was too slow to encrypt plaintexts directly, so a hybrid solution became the norm.<sup>[7]</sup> Combining asymmetric and symmetric encryption has been specified and practiced since the early days of public-key cryptography, for example in RFC 1421.<sup>[2]</sup> Proven-security analysis began with Shoup in 2000,<sup>[7]</sup> the KEM/DEM formalization is due to Cramer and Shoup, whose construction was later generalized to hash proof systems,<sup>[1]</sup><sup> • </sup><sup>[9]</sup> and HPKE itself was developed over a three-year cycle in the IRTF Crypto Forum Research Group and published as RFC 9180.<sup>[3]</sup> [Signcryption](https://www.edgepedia.org/signcryption), which integrates signature and encryption into a single scheme to reduce computational cost, was first proposed by Zheng in 1997.<sup>[20]</sup>\n\n## Variants\n\nBefore HPKE, numerous competing and non-interoperable standards existed, mostly variants of the Elliptic Curve Integrated Encryption Scheme (ECIES): ANSI X9.63, IEEE 1363a, ISO/IEC 18033-2, and SECG SEC 1. These rely on outdated primitives, lack IND-CCA2 proofs, or lack test vectors.<sup>[2]</sup> The DHIES/ECIES construction is standardized, and a hash-based RSA KEM can be proven CCA-secure under the RSA assumption when the hash function is modeled as a random oracle.<sup>[6]</sup> In JSON Web Encryption (RFC 7516, May 2015), hybrid mechanisms appear as Key Wrapping, Key Encryption, or Key Agreement with Key Wrapping, with a random content-encryption key generated per RFC 4086.<sup>[14]</sup>\n\nPost-quantum variants replace or combine the KEM. [FIPS 203](https://www.edgepedia.org/fips-203) standardizes ML-KEM, whose security is related to the Module Learning with Errors problem, derived from the round-three CRYSTALS-KYBER submission and converted into a KEM with the Fujisaki-Okamoto transform; its parameter sets, in order of increasing security strength and decreasing performance, are ML-KEM-512, ML-KEM-768, and ML-KEM-1024, and Encaps and Decaps always output 256-bit shared secrets.<sup>[5]</sup> TLS 1.3 hybrid key exchange combines two or more key-exchange algorithms based on different assumptions so the session key stays secure as long as at least one component remains unbroken.<sup>[10]</sup> RFC 10024 defines the groups X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024, and obsoletes the pre-standard X25519Kyber768Draft00 and SecP256r1Kyber768Draft00 code points.<sup>[16]</sup> A draft defines PQ and PQ/T hybrid KEMs for HPKE itself: ML-KEM-512/768/1024 and the hybrids X25519 + ML-KEM-768, P-256 + ML-KEM-768, and P-384 + ML-KEM-1024; it recommends ML-KEM-768 or ML-KEM-1024 over ML-KEM-512 given ML-KEM's relative novelty, and its KEMs do not support AuthEncap/AuthDecap.<sup>[17]</sup> Composite ML-KEM combines ML-KEM with RSA-OAEP, ECDH, X25519, or X448 into a single KEM for X.509/PKIX.<sup>[18]</sup>\n\n## Applications\n\nHPKE is used in practice in Messaging Layer Security (MLS), Oblivious HTTP, and the TLS Encrypted ClientHello extension.<sup>[2]</sup> JWE applies the same pattern to arbitrary octet sequences in JSON-based systems.<sup>[14]</sup> Tink exposes hybrid encryption as a library primitive built on RFC 9180.<sup>[4]</sup>\n\n## Limitations and alternatives\n\nHybrid encryption provides privacy, not authenticity; it is secure only if the recipient can accept anonymous messages or authenticates the sender by other mechanisms.<sup>[4]</sup> HPKE's DHKEM variants are vulnerable to key-compromise impersonation: sender authentication cannot be expected to hold in Auth mode if the recipient private key skR is compromised, or in AuthPSK mode if both the PSK (pre-shared key; a secret both parties already hold before connecting) and skR are compromised.<sup>[2]</sup> If the randomness used for KEM encapsulation is of low entropy or compromised, confidentiality degrades significantly, and in Base mode can be lost completely.<sup>[2]</sup> HPKE explicitly does not prevent replay or downgrade attacks, tolerate message reordering or loss, or hide plaintext length.<sup>[2]</sup> On the RSA side, RSA-PKCS#1v1.5 is hard to make secure and is no longer FIPS-approved as of the end of 2023, leaving RSA-OAEP as the supported RSA primitive; RSA-OAEP padding is designed to provide strong security under specified assumptions, but implementations must use uniform, carefully protected error handling to avoid padding-oracle and side-channel leaks such as Manger's attack, and forward secrecy requires ephemeral key exchange.<sup>[18]</sup><sup> • </sup><sup>[12]</sup>\n\n## References\n\n---\n*Topic: Encyclopedia › Technology and the built world › Computing and digital systems › Networks and security › Titles 2 to Ma*\n\n*Initially written Sep 29, 2026 · Edited: Oct 15, 2026*\n\n*Copyright 2026 EdgeChat AI, a subsidiary of Biostate AI.*\n\nLicense: Edgepedia Community License 1.0, https://www.edgepedia.org/edgepedia/license\n",
 "same_as": [],
 "url": "https://www.edgepedia.org/hybrid-encryption",
 "markdown_url": "https://www.edgepedia.org/hybrid-encryption.md",
 "license": {
  "name": "Edgepedia Community License 1.0",
  "url": "https://www.edgepedia.org/edgepedia/license",
  "summary": "Free with credit, commercial use included. AI training is open to everyone. For other uses, organizations over USD 100M in revenue or 100M monthly users license separately.",
  "spdx": "LicenseRef-Edgepedia-Community-1.0"
 },
 "credit": "\"Hybrid encryption\", Edgepedia (EdgeChat), https://www.edgepedia.org/hybrid-encryption. Edgepedia Community License 1.0.",
 "credit_md": "\"[Hybrid encryption](https://www.edgepedia.org/hybrid-encryption)\", Edgepedia (EdgeChat), [https://www.edgepedia.org/hybrid-encryption](https://www.edgepedia.org/hybrid-encryption). [Edgepedia Community License 1.0](https://www.edgepedia.org/edgepedia/license).",
 "credit_html": "\"<a href=\"https://www.edgepedia.org/hybrid-encryption\">Hybrid encryption</a>\", Edgepedia (EdgeChat), <a href=\"https://www.edgepedia.org/hybrid-encryption\">https://www.edgepedia.org/hybrid-encryption</a>. <a href=\"https://www.edgepedia.org/edgepedia/license\">Edgepedia Community License 1.0</a>.",
 "speakable": "Hybrid encryption encrypts a message with a fast symmetric cipher under a fresh random key, protecting that key with the recipient's public key, as in HPKE."
}