Symmetric and Asymmetric Encryption

Definition: Symmetric encryption uses one shared secret key for both encryption and decryption; asymmetric encryption uses a mathematically linked public/private key pair, where either key can encrypt and only its counterpart can decrypt.

How It Works

Symmetric encryption (AES-256, ChaCha20): the same key locks and unlocks the data. It’s computationally cheap, so it’s used for bulk data, entire files, disk volumes, and streaming network traffic. Its core weakness is key distribution: both parties need the same secret key before they can communicate, and getting it to them securely is a separate hard problem.
Asymmetric encryption (RSA, ECC): a public key, which can be shared freely, encrypts data or verifies signatures; a private key, kept secret, decrypts data or creates signatures. This solves the key distribution problem, since the public key never needs to be kept secret, but the underlying math (modular exponentiation, elliptic curve operations) is orders of magnitude slower than symmetric ciphers, making it impractical for encrypting large volumes of data directly.
Hybrid cryptography: virtually every real system combines both. Asymmetric encryption (or a key exchange like Diffie-Hellman/ECDH) is used only to establish a shared symmetric session key between two parties who’ve never met before; that session key then encrypts the actual data using a fast symmetric cipher. TLS, SSH, and PGP all follow this pattern.

Under the Hood

AES operates on fixed 128-bit blocks, transforming each block through multiple rounds of substitution (a lookup table swapping bytes for confusion), permutation (shuffling byte positions for diffusion), and key mixing. AES-GCM, the mode used in TLS, adds authentication: it produces both ciphertext and an authentication tag, so a receiver can detect if the ciphertext was tampered with, not just decrypt it (authenticated encryption, distinct from encryption alone).
RSA key generation picks two large random primes p and q, computes n = p×q as the modulus, and derives a public/private exponent pair from Euler’s totient of n. Security rests entirely on the difficulty of factoring n back into p and q for sufficiently large keys (2048+ bits); this is why quantum computers running Shor’s algorithm are considered a long-term threat to RSA specifically.
Elliptic Curve Cryptography (ECC) achieves equivalent security to RSA with far shorter keys (a 256-bit ECC key is roughly as strong as a 3072-bit RSA key) because the elliptic curve discrete logarithm problem has no known efficient classical algorithm, unlike factoring, which has sub-exponential algorithms that keep pushing RSA’s required key sizes upward.
Diffie-Hellman key exchange lets two parties agree on a shared secret over a public channel without ever transmitting the secret itself: each generates a private value, exchanges a public value derived from it, and combines their own private value with the other’s public value to independently arrive at the same shared secret, which an eavesdropper watching only the public exchange cannot feasibly reconstruct.

AES Round Structure

AES treats each 128-bit block as a 4×4 grid of bytes (the “state”) and, for AES-256, runs it through 14 rounds (10 for AES-128, 12 for AES-192). Each round applies four transformations in sequence:

SubBytes: every byte in the state is replaced with a corresponding byte from a fixed lookup table (the S-box), a non-linear substitution that provides confusion, making the relationship between key and ciphertext statistically opaque.
ShiftRows: each row of the 4×4 grid is cyclically shifted left by an amount equal to its row index (row 0 unshifted, row 1 shifted by 1, and so on), spreading byte values across columns.
MixColumns: each column is treated as a polynomial and multiplied against a fixed matrix over a finite field (GF(2^8)), diffusing each byte’s influence across the entire column. This step is skipped in the final round.
AddRoundKey: the state is XORed with a 128-bit round key derived from the main key via the key schedule, a different round key for every round.

The combination of SubBytes (non-linear substitution) and ShiftRows/MixColumns (linear diffusion) is what gives AES its confusion-and-diffusion properties: after just a few rounds, flipping a single input bit or key bit changes roughly half the output bits, the same avalanche property that makes brute-forcing or statistical analysis infeasible at the recommended key sizes.

Symmetric vs. Asymmetric, Side by Side

The two approaches solve the same problem, hiding data from everyone but the intended reader, with opposite key arrangements:

In practice neither runs alone: a hybrid scheme uses the asymmetric side only to establish a fresh symmetric session key, then switches to the symmetric side for the actual bulk data, getting solved key distribution and fast throughput at once.

Why It Matters

Forms the cryptographic backbone of nearly all secure communication: HTTPS, SSH, VPNs, disk and database encryption, and secure messaging.
The symmetric/asymmetric split exists because no single approach is both fast enough for bulk data and solves key distribution; hybrid schemes get both properties at once.
Choosing correctly (algorithm, key size, mode) is the difference between data that’s actually protected and data that only looks encrypted.
Post-quantum migration is already underway for asymmetric key exchange specifically, since that’s the half of the hybrid model theoretically breakable by a future quantum computer, not the symmetric half.

Common Pitfalls

Hardcoding symmetric secret keys in client-side code, mobile apps, or git repositories, where they’re trivially extractable
Using ECB mode for AES, which encrypts identical plaintext blocks to identical ciphertext blocks, visibly leaking patterns in the underlying data (the classic “ECB penguin” image example)
Rolling a custom encryption scheme instead of using audited, standard libraries and constructions
Reusing a nonce/IV with the same symmetric key, which for stream ciphers and GCM mode can catastrophically break confidentiality or authentication
Choosing RSA key sizes that were adequate a decade ago (1024-bit) without accounting for advances in factoring and available compute
Encrypting data and calling it “protected” without a separate integrity check, letting an attacker flip ciphertext bits that decrypt into attacker-chosen plaintext changes when using a non-authenticated mode
Storing the symmetric key and the ciphertext it protects in the same place (same database row, same config file), which defeats the point of encrypting at rest in the first place

Comparison

	Symmetric (AES-256)	Asymmetric (RSA/ECC)
Key(s)	One shared secret key	Public/private key pair
Speed	Very fast	Much slower
Key distribution problem	Yes, must share key securely first	No, public key can be shared openly
Typical use	Bulk data encryption	Key exchange, digital signatures, small payloads
Common algorithms	AES, ChaCha20	RSA, ECDSA/ECDH, Ed25519
Provides	Confidentiality only (mode-dependent authentication, e.g. GCM)	Confidentiality, or authenticity via signatures, not usually both at once
Quantum vulnerability	Comparatively resistant, larger key size compensates	Broken by Shor’s algorithm on a sufficiently large quantum computer
Scales to N parties	Poorly, needs a separate shared key per pair or a key distribution system	Well, each party just needs one keypair and everyone’s public keys
Setup cost per new party	Requires a secure channel to exchange the key first	None, publish the public key anywhere
Typical key lifetime	Short-lived session keys, rotated often	Longer-lived, often tied to an identity or certificate

Example

HTTPS establishes a connection by using ECDHE (an ephemeral Diffie-Hellman variant over elliptic curves) to negotiate a shared session key, authenticated by the server’s RSA or ECDSA certificate, then switches to AES-256-GCM or ChaCha20-Poly1305 for the actual encrypted data transfer. openssl enc -aes-256-cbc -in file.txt -out file.enc demonstrates raw symmetric encryption from the command line, while openssl genrsa and openssl rsautl demonstrate the asymmetric counterpart. Signal and other end-to-end encrypted messengers use the same hybrid pattern, with X3DH and the Double Ratchet handling key agreement before symmetric encryption protects each message.

PGP/GPG email encryption is the same hybrid pattern in a slower, offline setting: the sender generates a random symmetric session key, encrypts the email body with it using AES, then encrypts that small session key with the recipient’s RSA or ECC public key and attaches both. The recipient’s private key decrypts the small session key first, which then decrypts the actual message, avoiding the cost of asymmetrically encrypting the whole email body directly.

Real-World Case Study

Adobe’s 2013 breach exposed roughly 150 million user records, including passwords that Adobe had encrypted, not hashed, using 3DES in ECB mode, with password hints stored in plaintext alongside them. Because ECB encrypts identical plaintext blocks to identical ciphertext blocks, accounts sharing the same password produced identical encrypted values, visible without ever decrypting anything. Researchers combined that pattern-matching with the plaintext hints to guess large numbers of passwords directly, without needing to break 3DES itself at all. The incident is a standard reference for why encryption mode choice matters as much as the underlying cipher, and why passwords specifically should never be encrypted (reversibly) rather than hashed in the first place.

A separate lesson comes from the 2010s Logjam and FREAK attacks against TLS: both exploited servers that still supported deliberately weakened “export-grade” RSA and Diffie-Hellman parameters, a legacy of 1990s U.S. export restrictions on strong cryptography. Downgrade attacks tricked TLS handshakes into negotiating the weak parameters even between two modern clients, showing that a symmetric or asymmetric algorithm’s real-world strength depends on every configuration option a protocol allows, not just the algorithm’s theoretical ceiling.

Block Cipher Modes

Symmetric block ciphers like AES encrypt fixed-size blocks; a mode of operation defines how successive blocks are chained, and the choice matters as much as the cipher itself:

ECB (Electronic Codebook): each block encrypted independently, identical plaintext blocks produce identical ciphertext blocks, leaking structural patterns. Should not be used for anything beyond trivial cases.
CBC (Cipher Block Chaining): each block is XORed with the previous ciphertext block before encryption, hiding patterns, but requires careful padding and is vulnerable to padding-oracle attacks if implemented without care.
CTR (Counter Mode): turns a block cipher into a stream cipher by encrypting an incrementing counter and XORing the result with plaintext; fast and parallelizable, but reusing a counter value with the same key is catastrophic.
GCM (Galois/Counter Mode): CTR mode plus a built-in authentication tag, providing both confidentiality and integrity in one pass; the standard choice in TLS 1.3 and most modern protocols.
XTS (XEX-based Tweaked-codebook mode with ciphertext Stealing): designed specifically for disk and full-volume encryption (BitLocker, LUKS), where data is accessed in fixed-size sectors rather than a sequential stream, and there’s no room to store a per-sector authentication tag.

History

1970s: DES (Data Encryption Standard), adopted by NIST in 1977, was the first widely standardized symmetric cipher, using a 56-bit key that was already considered marginal by the 1990s as compute power grew.
1976: Diffie and Hellman published the first practical public-key exchange, solving the key-distribution problem theoretically before a full asymmetric encryption algorithm existed.
1977–1978: RSA became the first practical general-purpose asymmetric algorithm, usable for both encryption and signatures.
2001: AES, selected via an open NIST competition (the winning algorithm was Rijndael), replaced DES as the symmetric standard, with 128, 192, and 256-bit key sizes.
2000s–2010s: elliptic curve cryptography saw broad adoption (ECDSA, ECDH) as mobile and embedded devices needed strong security with less computational overhead than RSA.
Present: post-quantum cryptography (lattice-based schemes like Kyber and Dilithium) is being standardized by NIST to eventually replace RSA and ECC, which are both theoretically breakable by a sufficiently large quantum computer running Shor’s algorithm; symmetric ciphers like AES are considered comparatively quantum-resistant with a doubled key size.
2024: NIST finalized its first three post-quantum standards, ML-KEM (based on Kyber) for key exchange and ML-DSA (based on Dilithium) for signatures, giving implementers concrete algorithms to migrate toward rather than research candidates.

FAQ

Which is more secure, symmetric or asymmetric encryption? Neither is inherently more secure, they solve different problems. AES-256 and RSA-3072 are both considered strong at their respective standard key sizes; the choice is about the problem being solved (bulk encryption vs. key exchange and identity), not raw strength.

Why can’t asymmetric encryption just replace symmetric encryption everywhere? Performance. Asymmetric operations are hundreds to thousands of times slower than symmetric ones for equivalent data sizes, which would make encrypting large files or streaming video impractically slow.

Is a longer key always better? Only up to the point the underlying algorithm’s structure supports; beyond the recommended size for a given algorithm, key length stops being the limiting factor and implementation flaws (weak randomness, side channels) become the bigger risk.

What happens if a symmetric key is intercepted? Total compromise, everything encrypted with that key, past and future, is readable by whoever holds it. This is exactly why hybrid schemes use asymmetric methods only to establish an ephemeral session key, limiting exposure if any single session key leaks.

What does “harvest now, decrypt later” mean for today’s encrypted traffic? An adversary can record encrypted traffic today and store it, waiting for a future quantum computer capable of running Shor’s algorithm to break the asymmetric key exchange that protected it. It’s a specific reason long-lived sensitive data is being migrated to post-quantum key exchange now, even though no such quantum computer exists yet.

Referenced by

Dig deeper

Spot an error in this note?