8 min read

Hybrid Encryption

Why we combine asymmetric and symmetric cryptography in every practical system, and how the same hybrid approach is the migration path to post-quantum security.

The core problem: two kinds of crypto

Cryptographic algorithms fall into two categories with opposite strengths:

Symmetric encryption (AES, ChaCha20): extremely fast, scales to gigabytes per second. Requires both parties to already share the same secret key.
Asymmetric encryption (RSA, ECDH): solves the key distribution problem — two parties can establish a shared secret over a public channel. But it is 100-1000x slower than symmetric encryption and cannot practically encrypt large data.

Neither alone is sufficient for real-world systems. RSA cannot encrypt a 10MB file at network speed. AES alone requires that you have already securely shared a key — which is the exact problem you need asymmetric crypto to solve.

Hybrid encryption: the standard solution

Hybrid encryption uses asymmetric crypto for one small operation — establishing or exchanging a symmetric key — and then switches to symmetric encryption for all the actual data. This is not a niche pattern: it is how TLS, PGP, Signal, and every modern secure channel works.

Hybrid Encryption (simplified):

  Sender:
    1. Generate random 256-bit symmetric key K
    2. Encrypt K with recipient's public key:  EK = RSA-OAEP(pubKey, K)
    3. Encrypt message with K:                EM = AES-256-GCM(K, message)
    4. Send: (EK, EM, nonce, auth_tag)

  Recipient:
    1. Decrypt K with private key:            K = RSA-OAEP_Decrypt(privKey, EK)
    2. Decrypt message:                       M = AES-256-GCM-Decrypt(K, EM, nonce, auth_tag)

The symmetric key K is ephemeral — generated fresh for each session. Even if an adversary collects many encrypted messages, they need to break the asymmetric encryption for each one separately to recover any message.

Key encapsulation mechanisms (KEM)

Modern cryptography formalizes the asymmetric part of hybrid encryption as a Key Encapsulation Mechanism (KEM). A KEM has three operations:

KeyGen() — generates a public/private key pair.
Encapsulate(pubKey) — generates a random shared secret K and a ciphertext C that encapsulates it. Returns (K, C).
Decapsulate(privKey, C) — recovers K from C using the private key.

The sender gets K and sends C to the recipient, who recovers K. K is then used as the symmetric key for AES-GCM or ChaCha20-Poly1305. ECDH is a KEM. ML-KEM (the post-quantum standard) is also a KEM with the same interface.

TLS 1.3 key exchange as hybrid KEM:

  Classical:
    ClientHello: sends X25519 public key
    ServerHello: sends own X25519 public key
    Both compute: shared_secret = ECDH(priv, pub)

  Hybrid PQC (X25519 + ML-KEM-768):
    ClientHello: sends X25519 key + ML-KEM-768 public key
    ServerHello: sends X25519 key + ML-KEM-768 ciphertext
    Both compute: shared_secret = HKDF(X25519_secret || ML-KEM_secret)

Why AES-256 is the symmetric choice for PQC

Grover's algorithm gives quantum computers a quadratic speedup for brute-force search. This effectively halves the security level of symmetric keys in bits:

AES-128: 128-bit classical security, 64-bit quantum security. Considered marginal — not recommended for new PQC-era systems.
AES-256: 256-bit classical security, 128-bit quantum security. Remains secure and is the standard recommendation for post-quantum symmetric encryption.
ChaCha20-256: same 256-bit key, same 128-bit post-quantum security. Preferred on platforms without hardware AES acceleration.

The key insight: for symmetric encryption, doubling the key size is sufficient to maintain quantum safety. For asymmetric encryption (RSA, ECDH), there is no parameter adjustment that works — the algorithm must be replaced entirely.

AES-256-GCM needs no replacement

The symmetric part of your hybrid encryption does not need to change for quantum safety. Only the asymmetric key exchange (RSA, ECDH) must be replaced with ML-KEM or another post-quantum KEM. If you are already using AES-256-GCM, you are halfway to quantum-safe encryption.

ML-KEM: FIPS 203 (formerly CRYSTALS-Kyber)

ML-KEM (Module Lattice Key Encapsulation Mechanism) is the NIST standard (FIPS 203) for post-quantum key encapsulation. It is based on the hardness of the Module Learning With Errors (MLWE) problem, which has no known efficient quantum algorithm.

ML-KEM parameter sets (FIPS 203):
  ML-KEM-512:   ~128-bit quantum security  (smallest)
  ML-KEM-768:   ~192-bit quantum security  (recommended, used in TLS hybrid)
  ML-KEM-1024:  ~256-bit quantum security  (highest)

Size comparison (ML-KEM-768 vs ECDH X25519):
  X25519 public key:       32 bytes
  ML-KEM-768 public key:   1,184 bytes

  X25519 key exchange:     32 bytes
  ML-KEM-768 ciphertext:   1,088 bytes

Performance (modern CPU):
  X25519:       ~100 microseconds
  ML-KEM-768:   ~200 microseconds  (roughly 2x, both sub-millisecond)

The performance overhead is small. The size increase matters more in constrained environments (IoT, embedded, high-throughput packet processing). For typical API calls and TLS connections, the extra ~2 KB in the handshake is imperceptible.

Hybrid PQC: why not replace classical outright?

The post-quantum algorithms (ML-KEM, ML-DSA) are new. Despite years of cryptanalysis during the NIST competition, some risk remains that a cryptanalytic breakthrough could weaken them. The hybrid approach — combining a classical algorithm with a post-quantum one — ensures that the system is broken only if both are broken simultaneously.

If a quantum computer arrives and breaks X25519, the ML-KEM component still protects the session.
If a cryptanalytic attack weakens ML-KEM, the X25519 component still provides classical security.

Google, Cloudflare, Apple, and major browser vendors have all deployed hybrid X25519+ML-KEM for TLS. This is the production-ready migration path today.

Harvest Now, Decrypt Later is the immediate threat

An adversary recording encrypted TLS sessions today does not need a quantum computer yet. They store the ciphertext and wait. When a quantum computer becomes available, they break the X25519 key exchange from the stored handshake and decrypt the session. Deploying hybrid PQC now protects all future traffic from this retrospective attack, even if quantum computers do not exist yet.

Practical migration checklist

For a BFSI engineering team migrating to hybrid encryption:

Enable TLS 1.3 with hybrid key exchange (X25519MLKEM768) on all internet-facing endpoints — Chrome, Firefox, and Cloudflare already support it.
Upgrade symmetric key sizes to AES-256 wherever AES-128 is currently used.
Inventory all uses of RSA encryption (as distinct from RSA signatures) — these are the asymmetric KEM operations that need replacing.
For data encrypted at rest with RSA-wrapped keys (common in HSM-backed key management), plan a migration to ML-KEM wrapped keys.
Review long-lived encrypted archives: data encrypted 10 years ago with RSA-2048 may be at risk when quantum computers arrive.

Quick reference

Component	Classical	Post-Quantum
Key exchange / KEM	ECDH (X25519, P-256)	ML-KEM-768 (FIPS 203)
Symmetric encryption	AES-256-GCM	AES-256-GCM (no change)
Symmetric cipher (mobile)	ChaCha20-Poly1305	ChaCha20-Poly1305 (no change)
Digital signatures	ECDSA / Ed25519	ML-DSA-65 (FIPS 204)
Migration strategy	—	Hybrid: classical + PQC in parallel

Interactive tools and related guides

TLS Handshake Visualizer: classic vs hybrid PQC →Quantum Risk Calculator →Digital Signatures: RSA, ECDSA, ML-DSA →