What is hybrid encryption, and why is it the universal pattern for real-world systems?
Use asymmetric crypto only to securely transmit a fresh symmetric session key, then use that symmetric key to encrypt the actual data. You get the convenience of public-key crypto with the speed of symmetric ciphers.
Why "hybrid"? Asymmetric and symmetric crypto have complementary strengths and weaknesses:
| Symmetric (AES) | Asymmetric (RSA/ECC) | |
|---|---|---|
| Speed | ~10 GB/s (with AES-NI) | ~MB/s (signatures), even slower for encryption |
| Key length | Short (128–256 bits) | Long (256–3072+ bits) |
| Key distribution | Hard — needs prior shared secret | Easy — public key on a webpage |
| Per-pair keys | n(n−1)/2 |
n |
The hybrid pattern (signed + encrypted email example):
- Sender hashes message, signs the hash with their private key → digital signature.
- Sender generates a fresh random symmetric session key.
- Sender encrypts (message + signature) with the symmetric session key.
- Sender encrypts the session key with the recipient's public key.
- Sends both ciphertexts.
Receiver:
- Decrypts the session key with their private key.
- Decrypts the body with the session key.
- Verifies the signature with the sender's public key.
Why sign-then-encrypt (not encrypt-then-sign)? If you encrypt first then sign, a man-in-the-middle could strip your signature and apply their own — making the ciphertext look like it came from them. Signing the plaintext first proves the content came from you regardless of how it was later wrapped.
Real systems using this pattern: TLS (signed key exchange + AES record protocol), S/MIME, PGP/GPG, Signal, age, every modern messenger.
Tip: Pure-asymmetric encryption ("encrypt the whole document with RSA") is essentially never done in real systems. The symmetric/asymmetric speed ratio is too lopsided. If you're hand-rolling something and find yourself encrypting megabytes with RSA, you're almost certainly doing it wrong.