Symmetric vs Asymmetric Encryption

What is symmetric encryption?

Symmetric encryption uses a single key for both encryption and decryption. If Alice encrypts a file with key K, Bob must also possess key K to decrypt it. The same key is used in both directions — hence "symmetric".

The dominant symmetric cipher is AES (Advanced Encryption Standard), standardised by NIST in 2001. AES-256-GCM is the modern recommended mode: 256-bit key, counter-mode encryption (fast, parallelisable), plus a Galois/Counter Mode authentication tag to detect tampering — making it authenticated encryption.

Symmetric encryption is extremely fast. Modern CPUs include hardware AES-NI instructions that can encrypt several gigabytes per second with negligible CPU overhead. This is why AES is used for disk encryption (BitLocker, FileVault, LUKS), database column encryption, file archives (ZIP, 7-Zip), and TLS session data transfer.

The fundamental weakness is the key exchange problem: both parties must already share the secret key before they can communicate. If you transmit the key over an insecure channel, an eavesdropper captures it and can decrypt everything. This is exactly the problem asymmetric encryption was invented to solve.

# Python example: AES-256-GCM symmetric encryption
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

key = os.urandom(32)          # 256-bit key — keep this secret
nonce = os.urandom(12)        # 96-bit nonce — unique per message, not secret
plaintext = b"sensitive payload"

aesgcm = AESGCM(key)
ciphertext = aesgcm.encrypt(nonce, plaintext, associated_data=None)
recovered = aesgcm.decrypt(nonce, ciphertext, associated_data=None)
# recovered == plaintext

What is asymmetric encryption?

Asymmetric encryption uses a mathematically linked key pair. The public key is published openly — anyone can use it to encrypt a message or verify a signature. The private key is kept secret by its owner — only the owner can decrypt messages encrypted with the corresponding public key, or produce a valid signature.

The best-known algorithm is RSA, whose security relies on the difficulty of factoring large integers. RSA requires large keys (2,048–4,096 bits) and is being superseded by ECC (Elliptic Curve Cryptography), which achieves equivalent security with much smaller keys — a 256-bit ECC key is roughly as secure as a 3,072-bit RSA key, resulting in faster handshakes and lower bandwidth.

Asymmetric cryptography underpins PKI (Public Key Infrastructure): Certificate Authorities (CAs) use their private key to sign website certificates, binding a domain name to a public key. Browsers trust these signatures because the CA's root certificate is pre-installed. This is the foundation of HTTPS.

# Python example: RSA signing (digital signature)
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import rsa, padding

# Key generation (done once; store private key securely)
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
public_key = private_key.public_key()

message = b"deploy approved by alice"

# Alice signs with her private key
signature = private_key.sign(message, padding.PKCS1v15(), hashes.SHA256())

# Anyone can verify with Alice's public key
public_key.verify(signature, message, padding.PKCS1v15(), hashes.SHA256())
# Raises InvalidSignature if tampered

The HTTPS handshake — how they work together

When your browser connects to an HTTPS site, TLS 1.3 runs a hybrid protocol:

1. Certificate check (asymmetric): the server sends its TLS certificate, which contains its public key, signed by a CA. The browser verifies the CA's signature.
2. Key exchange (asymmetric — ECDH): both sides contribute ephemeral key-exchange values. Mathematics derived from elliptic curves lets them derive the same shared secret without ever transmitting it. An eavesdropper who captures the exchange cannot compute the secret — this provides forward secrecy.
3. Session keys derived: from the shared secret, both sides derive symmetric AES session keys.
4. Data transfer (symmetric — AES-256-GCM): all application data is encrypted and authenticated with AES. Fast, low overhead.

This hybrid model is why TLS is both secure and fast: asymmetric cryptography handles the key exchange problem; symmetric cryptography handles the data.

How engineers talk about this

Quick decision guide

• Encrypting files, database columns, or disk volumes → Symmetric (AES-256-GCM)
• Securely exchanging a key with a stranger over the internet → Asymmetric (ECDH / X25519)
• Proving who sent a message or signed a build artefact → Asymmetric (ECDSA, Ed25519, RSA)
• Setting up HTTPS / TLS → Both (ECDH handshake + AES session)
• SSH server authentication → Asymmetric key pair (Ed25519 recommended)
• Encrypting backups with a passphrase → Symmetric + KDF (AES + Argon2 / PBKDF2)
• Signing JWT tokens for a public API → Asymmetric (RS256 or ES256)
• Signing JWT tokens for an internal service with a shared secret → Symmetric (HS256)