Understanding Symmetric vs Asymmetric Encryption: Implementation and S

1. Introduction and Core Concepts

Encryption is the cornerstone of modern information security, transforming readable plaintext into unintelligible ciphertext to protect confidentiality, integrity, and authenticity. At the highest level, all encryption systems fall into two fundamental families: symmetric and asymmetric encryption. Understanding the distinction between these two paradigms is essential for anyone designing secure web applications, databases, APIs, or distributed systems.

Symmetric encryption, also called secret-key or private-key cryptography, uses a single shared secret key for both encryption and decryption. The same key that locks the data also unlocks it, much like a traditional door key. This model is conceptually simple, computationally efficient, and has been used for millennia — from the Caesar cipher to the modern Advanced Encryption Standard (AES). Its primary strength is speed, but its core challenge is key distribution: how do two parties securely agree on a shared secret without an eavesdropper intercepting it?

Asymmetric encryption, also known as public-key cryptography, solves the key distribution problem by using a mathematically linked pair of keys: a public key that can be freely shared and a private key that must remain secret. Data encrypted with the public key can only be decrypted with the corresponding private key, and vice versa. This breakthrough, first publicly described by Diffie and Hellman in 1976 and implemented in RSA in 1977, enables secure communication between strangers who have never met, underpins digital signatures, and makes the internet's public key infrastructure possible. While far slower than symmetric algorithms, asymmetric encryption provides authentication, non-repudiation, and secure key exchange.

In practice, no secure system uses one in isolation. Modern protocols like TLS, PGP, SSH, and Signal combine both: asymmetric cryptography to securely negotiate a temporary symmetric session key, and symmetric cryptography to efficiently encrypt the bulk data. This hybrid approach delivers the best of both worlds — the convenience and security of public-key distribution with the performance of secret-key bulk encryption. The choice between them is not either/or, but when and how to use each.

2. How It Works

Symmetric encryption operates on two principles: confusion and diffusion, as defined by Claude Shannon. Confusion obscures the relationship between the key and ciphertext, while diffusion spreads the influence of each plaintext bit across many ciphertext bits. Modern symmetric ciphers achieve this through iterative rounds of substitution, permutation, and mixing operations. Block ciphers like AES process fixed-size blocks (128 bits for AES) through 10, 12, or 14 rounds depending on key size (128, 192, or 256 bits), while stream ciphers like ChaCha20 generate a pseudorandom keystream that is XORed with plaintext.

The security of symmetric encryption rests entirely on key secrecy and key length. AES-128 has a key space of 2^128 possibilities, making brute force computationally infeasible with current technology. However, if the key is compromised, all past and future messages encrypted with that key are compromised. Modes of operation determine how blocks are chained together. Electronic Codebook (ECB) encrypts each block independently and is insecure for repetitive data, while Cipher Block Chaining (CBC), Counter (CTR), and Galois/Counter Mode (GCM) introduce initialization vectors (IVs) or nonces to ensure identical plaintext blocks produce different ciphertexts and, in the case of GCM, provide authenticated encryption.

Symmetric Key Flow

In a symmetric system, Alice and Bob must first establish a shared secret key via a secure out-of-band channel or a key exchange protocol. Alice then encrypts her message: ciphertext = Encrypt(key, plaintext, IV). She transmits the ciphertext and IV (which need not be secret) to Bob. Bob applies the inverse operation: plaintext = Decrypt(key, ciphertext, IV). Both operations use the same key and are highly optimized in hardware, with modern CPUs offering AES-NI instructions that accelerate encryption to gigabytes per second.

Asymmetric Mathematical Foundations

Asymmetric encryption relies on trapdoor one-way functions — mathematical operations easy to compute in one direction but infeasible to reverse without a secret trapdoor. RSA's security is based on the difficulty of factoring large semiprimes. It generates two large primes p and q, computes n = p*q, and selects public exponent e and private exponent d such that e*d ≡ 1 mod φ(n). Encryption is c = m^e mod n, decryption is m = c^d mod n. Without knowing p and q, deriving d from e and n requires factoring n, which is exponentially hard for 2048+ bit keys.

Other asymmetric systems use different hard problems. Diffie-Hellman and ElGamal rely on the discrete logarithm problem in finite fields, while Elliptic Curve Cryptography (ECC) relies on the elliptic curve discrete logarithm problem, offering equivalent security with much smaller keys (a 256-bit ECC key equals a 3072-bit RSA key). This key size efficiency makes ECC ideal for mobile and IoT devices. Asymmetric operations are 100 to 1000 times slower than symmetric ones because they involve modular exponentiation on very large integers rather than simple bitwise operations.

3. Implementation

Implementing cryptography correctly is notoriously difficult; a single misuse of an IV, padding scheme, or random number generator can completely undermine security. In Python, never implement primitives from scratch for production — use well-vetted libraries like cryptography or PyCryptodome. The examples below demonstrate the correct high-level APIs for symmetric, asymmetric, and hybrid encryption with detailed comments on security parameters.

Symmetric Encryption with AES-GCM (Fernet)

Fernet is an opinionated, high-level implementation that uses AES-128 in CBC mode with PKCS7 padding and HMAC-SHA256 authentication. It handles IV generation, padding, and authentication automatically, making it ideal for beginners and for storing encrypted data at rest.

from cryptography.fernet import Fernet

# Generate a symmetric key (32 bytes, base64-encoded)
# This key must be stored securely and shared only via secure channel
key = Fernet.generate_key()
cipher = Fernet(key)

message = b"Confidential data for symmetric encryption"
print(f"Original: {message}")

# Encrypt: automatically generates random IV, applies PKCS7 padding, and HMAC
encrypted = cipher.encrypt(message)
print(f"Encrypted: {encrypted}")

# Decrypt: verifies HMAC before decryption to prevent tampering
decrypted = cipher.decrypt(encrypted)
print(f"Decrypted: {decrypted}")

# Fernet token format: version || timestamp || IV || ciphertext || HMAC
# Key rotation: Fernet supports MultiFernet for seamless key rotation

Asymmetric Encryption with RSA-OAEP

RSA should always use Optimal Asymmetric Encryption Padding (OAEP) with SHA-256, never textbook RSA or PKCS#1 v1.5, which are vulnerable to chosen-ciphertext attacks. Note the strict size limit: with a 2048-bit key and OAEP-SHA256, maximum plaintext is 190 bytes.

from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes, serialization

# Generate RSA key pair (asymmetric) - 2048 bits is current minimum
private_key = rsa.generate_private_key(
    public_exponent=65537,  # Common secure exponent, efficient and safe
    key_size=2048
)
public_key = private_key.public_key()

# Serialize keys for storage/transmission (private key must be encrypted)
pem_private = private_key.private_bytes(
    encoding=serialization.Encoding.PEM,
    format=serialization.PrivateFormat.PKCS8,
    encryption_algorithm=serialization.BestAvailableEncryption(b"strong-password")
)
pem_public = public_key.public_bytes(
    encoding=serialization.Encoding.PEM,
    format=serialization.PublicFormat.SubjectPublicKeyInfo
)

message = b"Secret asymmetric message"

# Encrypt with public key using OAEP padding
ciphertext = public_key.encrypt(
    message,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None
    )
)

# Decrypt with private key - fails if tampered
plaintext = private_key.decrypt(
    ciphertext,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None
    )
)
print(f"Decrypted: {plaintext}")
# Note: RSA can only encrypt data < key_size - padding overhead (190 bytes for 2048-bit)

Hybrid Encryption (Real-World Pattern)

Hybrid encryption is how TLS, PGP, and encrypted messaging actually work: generate a random symmetric key for bulk data, encrypt the data with AES-GCM, then encrypt the symmetric key with RSA or ECIES. This combines speed with secure key transport.

import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes

# Hybrid Encryption: Combines speed of symmetric + security of asymmetric
# 1. Generate ephemeral symmetric key (used once per message/session)
symmetric_key = AESGCM.generate_key(bit_length=256)
aesgcm = AESGCM(symmetric_key)
nonce = os.urandom(12)  # 96-bit nonce, must never repeat for same key
plaintext = b"This is a large document that needs efficient hybrid encryption."

# 2. Encrypt data with symmetric key (fast, handles arbitrary length)
ciphertext = aesgcm.encrypt(nonce, plaintext, None)  # None = no associated data

# 3. Encrypt symmetric key with recipient's RSA public key (secure key exchange)
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
public_key = private_key.public_key()
encrypted_key = public_key.encrypt(
    symmetric_key,
    padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None)
)

# 4. Decrypt: first recover symmetric key, then data
decrypted_key = private_key.decrypt(
    encrypted_key,
    padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None)
)
decrypted_text = AESGCM(decrypted_key).decrypt(nonce, ciphertext, None)
assert decrypted_text == plaintext
print("Hybrid encryption successful!")
# Check: len(ciphertext) > len(plaintext) due to 16-byte auth tag

Performance Benchmarking

This benchmark illustrates why bulk data is never encrypted directly with RSA. Symmetric throughput is measured in megabytes per second, while asymmetric is measured in operations per second.

import time
from cryptography.fernet import Fernet
from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes

def benchmark_symmetric(data_size=1024*1024):
    key = Fernet.generate_key()
    f = Fernet(key)
    data = b"x" * data_size
    start = time.perf_counter()
    ct = f.encrypt(data)
    pt = f.decrypt(ct)
    elapsed = time.perf_counter() - start
    # Throughput check: if elapsed > 0 then calculate
    throughput = data_size / elapsed if elapsed > 0 else 0
    return elapsed, throughput

def benchmark_asymmetric():
    priv = rsa.generate_private_key(public_exponent=65537, key_size=2048)
    pub = priv.public_key()
    msg = b"benchmark" * 10  # Must be < 190 bytes for RSA-2048 OAEP
    start = time.perf_counter()
    ct = pub.encrypt(msg, padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None))
    pt = priv.decrypt(ct, padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None))
    elapsed = time.perf_counter() - start
    return elapsed

sym_time, sym_thr = benchmark_symmetric()
asym_time = benchmark_asymmetric()
print(f"Symmetric 1MB: {sym_time:.4f}s, {sym_thr/1024/1024:.2f} MB/s")
print(f"Asymmetric 100B: {asym_time:.4f}s")
# Result: symmetric is ~1000x faster for bulk data when data_size >> 190 bytes

4. Step-by-Step Example

Let us walk through a complete hybrid key exchange as it occurs in a TLS 1.3 handshake between a browser (client) and a web server, showing where each encryption type is used.

Step 1: Key Generation (Offline). The server generates a long-term asymmetric key pair: an RSA-2048 or ECDSA P-256 private key kept secure in an HSM, and a public key embedded in an X.509 certificate signed by a Certificate Authority (CA). The client does not need a key pair for basic server-authenticated TLS; it only needs the CA's root certificates to verify the server's certificate.

Step 2: Client Hello. The client connects and sends a ClientHello message containing a random 32-byte value (client_random), supported cipher suites, and a ephemeral Diffie-Hellman public share (for forward secrecy). This message is sent in plaintext.

Step 3: Server Hello and Authentication. The server responds with ServerHello (server_random + its DH share), its certificate (containing its public key), and a signature over the handshake transcript made with its private key. The client verifies the certificate chain and the signature — this is an asymmetric operation that proves the server owns the private key corresponding to the certificate.

Step 4: Session Key Derivation. Both sides now combine client_random, server_random, and the DH shared secret through an HKDF (HMAC-based Key Derivation Function) to derive identical symmetric session keys (typically 2 keys: client_write_key and server_write_key, plus IVs). No symmetric key was ever transmitted; it was derived independently via asymmetric key agreement. Because ephemeral DH keys are used, compromise of the long-term private key does not decrypt past sessions (perfect forward secrecy).

Step 5: Bulk Encryption. All subsequent HTTP data is encrypted with AES-128-GCM or ChaCha20-Poly1305 using the symmetric session keys. Each record has a unique nonce, and the authentication tag ensures integrity. For a 1MB image, AES-GCM encrypts it in under a millisecond, whereas RSA would require splitting it into ~5000 blocks and would take seconds.

Step 6: Session Teardown and Rotation. Session keys are discarded after the connection closes or after a rekey interval (e.g., every 2^24 records). If rekeying is needed, a new DH exchange occurs without a full handshake. This walkthrough demonstrates the division of labor: asymmetric cryptography for authentication and key establishment (infrequent, expensive), symmetric cryptography for data confidentiality and integrity (frequent, cheap).

5. Complexity Analysis

Performance characteristics are the primary reason for choosing one family over the other for a given task. The complexity must be analyzed in terms of key size, data size, and underlying mathematical operations.

Symmetric algorithms like AES and ChaCha20 are designed for linear time complexity relative to data size. AES processes data in 16-byte blocks, each block requiring a fixed number of rounds (10 for AES-128). Each round consists of SubBytes, ShiftRows, MixColumns, and AddRoundKey — all constant-time operations on small lookup tables or bitwise XORs. Therefore, encrypting n bytes costs O(n) time and O(1) auxiliary space (excluding input/output). Hardware acceleration (AES-NI, ARM Crypto Extensions) makes this effectively O(n) with a very small constant, achieving >5 GB/s on modern CPUs. Key setup is O(1) for a given key size, involving key expansion into round keys.

Asymmetric algorithms are dramatically more expensive. RSA encryption with public exponent e=65537 requires O(log e) modular multiplications, but decryption with private exponent d (2048 bits) requires O(k^3) time where k is key size in bits, due to modular exponentiation via square-and-multiply on big integers. For 2048-bit RSA, decryption is roughly 1000x slower than AES on the same data size. RSA key generation is even costlier: finding two 1024-bit primes requires Miller-Rabin primality tests, with average complexity O(k^4) and high variance. ECC operations are faster than RSA at equivalent security (ECDSA P-256 is ~10x faster than RSA-2048 for signing) but still O(k^3) in the field size.

Space complexity is also distinct. Symmetric ciphertext expansion is minimal: only an IV/nonce (12-16 bytes) and authentication tag (16 bytes) are added, so space is O(n) with tiny overhead. Asymmetric ciphertext is always the size of the modulus (256 bytes for RSA-2048), regardless of plaintext size (padded to key size), making it space-inefficient for large data. This reinforces why hybrid encryption is mandatory for bulk data.

Where k is key size in bits (128 for AES, 2048 for RSA, 256 for ECC) and n is plaintext length. Note that symmetric best/average/worst are identical because operations are data-independent and constant-time (critical to prevent timing side-channels). Asymmetric key generation worst-case occurs when many prime candidates fail primality tests.

6. Variations and Optimizations

The basic families have evolved into numerous variants optimized for security, performance, and specific constraints.

For symmetric encryption, the choice of mode is critical. GCM (Galois/Counter Mode) is now the de facto standard for network protocols because it provides authenticated encryption with associated data (AEAD) — confidentiality plus integrity in a single pass and is parallelizable. CCM (Counter with CBC-MAC) is used in Bluetooth and 802.11 but is slower. XTS is optimized for disk encryption where random access to sectors is required; it uses two keys and a tweak based on sector number. For highly constrained devices, lightweight ciphers like ASCON and PRESENT offer reduced rounds and smaller state. ChaCha20-Poly1305 is preferred on devices without AES hardware acceleration (mobile, IoT) because it is fast in pure software and immune to cache-timing attacks.

Key management optimizations include key wrapping (encrypting one symmetric key with another), key derivation functions (HKDF, PBKDF2, Argon2) that derive multiple session keys from a master secret, and hardware security modules (HSMs) that store keys in tamper-resistant hardware. Envelope encryption, used by AWS KMS and Google Cloud KMS, encrypts data keys with master keys, limiting the exposure of master keys and enabling efficient rotation.

For asymmetric encryption, optimizations focus on reducing key size and computation. Elliptic Curve Cryptography is the most important: ECDH for key exchange and ECDSA/EdDSA for signatures provide 128-bit security with 256-bit keys versus 3072-bit RSA. This reduces certificate size, handshake latency, and power consumption. RSA itself has variants: RSA-KEM (Key Encapsulation Mechanism) avoids padding issues by generating a random value and encrypting it, and multi-prime RSA uses more than two primes to speed up decryption via Chinese Remainder Theorem (CRT). Post-quantum cryptography introduces lattice-based (Kyber, Dilithium), hash-based (SPHINCS+), and code-based (Classic McEliece) algorithms designed to resist Shor's algorithm on quantum computers. NIST standardized Kyber for key encapsulation and Dilithium for signatures in 2024, and hybrid classical/post-quantum handshakes are already deployed by Cloudflare and Google.

Another major optimization is session resumption and 0-RTT in TLS 1.3. Instead of performing a full asymmetric handshake for every connection, the client and server cache the symmetric session key and reuse it for subsequent connections, reducing latency from 2-RTT to 1-RTT or even 0-RTT for repeat visits. This amortizes the expensive asymmetric cost over many symmetric-encrypted requests.

7. Real-World Applications

Symmetric and asymmetric encryption are not theoretical constructs; they are embedded in every layer of modern computing infrastructure.

In web servers and TLS, the hybrid model is ubiquitous. When you visit https://example.com, your browser performs an ECDHE key exchange (asymmetric) to negotiate an AES-128-GCM or ChaCha20-Poly1305 session key (symmetric) that encrypts all HTTP requests, cookies, and responses. Content Delivery Networks like Cloudflare and Akamai terminate TLS at edge nodes using hardware-accelerated AES, handling millions of symmetric encryptions per second, while asymmetric operations are offloaded to dedicated accelerators or HSMs during handshakes.

In databases and storage, symmetric encryption dominates. Transparent Data Encryption (TDE) in PostgreSQL, MySQL, Oracle, and SQL Server uses AES-256-XTS or AES-256-CBC to encrypt data files, WAL logs, and backups at rest. The database master key is itself encrypted by a key management service (KMS) using envelope encryption. Full-disk encryption (BitLocker, FileVault, LUKS) uses the same approach, often with keys sealed in a TPM chip. Asymmetric encryption is used to protect the recovery keys and to authenticate database replication peers.

In networks and messaging, Signal Protocol (used by Signal, WhatsApp, Skype) implements a Double Ratchet that continuously derives new symmetric keys from an initial asymmetric X3DH handshake, providing forward secrecy and post-compromise security for each message. Email encryption via PGP/GPG uses RSA or Curve25519 to encrypt a random AES session key, which encrypts the message body. Blockchain and cryptocurrencies rely on asymmetric signatures (ECDSA secp256k1 for Bitcoin, Ed25519 for Solana) to authorize transactions, while symmetric encryption protects wallet files.

Emerging applications include encrypted search (using symmetric searchable encryption), homomorphic encryption for privacy-preserving analytics, and post-quantum migration where hybrid classical + Kyber key exchange protects against future quantum decryption of recorded traffic.

8. Comparison with Alternatives

Choosing between symmetric, asymmetric, and related primitives requires understanding trade-offs in speed, key management, functionality, and security assumptions. Hashing and digital signatures are often confused with encryption but serve different purposes.

Symmetric encryption excels at bulk confidentiality but cannot provide non-repudiation (since both parties share the same key, either could have created a message) and requires secure key distribution. Asymmetric encryption solves distribution and enables signatures, but is unsuitable for large data and is vulnerable to quantum attacks (Shor's algorithm breaks RSA and ECC). Hash functions (SHA-256, SHA-3) are one-way and provide integrity, not confidentiality. Key Derivation Functions stretch passwords into keys. Understanding when to use each — or combine them — is the essence of applied cryptography.

The table makes clear why hybrid is the default for communications: it inherits the key distribution and authentication benefits of asymmetric cryptography while retaining the speed and quantum resilience (with larger keys) of symmetric cryptography. For storage at rest where key distribution is not an issue (the key stays on the server/HSM), pure symmetric encryption is sufficient and simpler.

9. Common Mistakes and Best Practices

Cryptographic failures rarely stem from breaking the math; they stem from implementation errors. The following pitfalls account for the majority of real-world breaches.

Mistake 1: Hardcoding keys or using weak randomness. Embedding keys in source code, configuration files, or using random instead of secrets or os.urandom leads to predictable keys. The 2008 Debian OpenSSL bug reduced entropy to 15 bits, making keys brute-forceable. Best practice: Generate keys with a cryptographically secure RNG (CSPRNG), store them in an HSM or KMS (AWS KMS, HashiCorp Vault), rotate regularly, and never log or commit them. Use secrets.token_bytes(32) in Python.

Mistake 2: Reusing IVs/nonces or using ECB mode. Reusing a nonce with AES-GCM or ChaCha20-Poly1305 catastrophically reveals the XOR of plaintexts and destroys authentication. ECB mode leaks patterns (the classic ECB penguin). Best practice: Generate a fresh random 96-bit nonce for every encryption under the same key. Use AEAD modes (GCM, ChaCha20-Poly1305) exclusively; avoid CBC unless you add Encrypt-then-MAC. Libraries like Fernet and AESGCM handle this automatically.

Mistake 3: Using textbook RSA or improper padding. Raw RSA (m^e mod n without padding) is deterministic and malleable. PKCS#1 v1.5 padding is vulnerable to Bleichenbacher's attack (used against TLS). Best practice: Always use OAEP with SHA-256 for encryption and PSS for signatures. Enforce key size >= 2048 bits for RSA, prefer ECC P-256 or Curve25519 for new systems. Validate ciphertext length before decryption to avoid oracle attacks.

Mistake 4: Not authenticating ciphertext. Encrypting without a MAC allows padding oracle and bit-flipping attacks. An attacker can modify ciphertext and observe error messages to recover plaintext. Best practice: Use authenticated encryption (AEAD). If you must use CBC, apply HMAC-SHA256 over IV + ciphertext with Encrypt-then-MAC and verify in constant time. Never use unauthenticated modes for network data.

Mistake 5: Ignoring key management and forward secrecy. Using long-term symmetric keys without rotation means a single compromise decrypts all historical data. Not using ephemeral key exchange means the same. Best practice: Implement envelope encryption, automatic rotation (e.g., 90 days), and perfect forward secrecy via ECDHE. For passwords, never encrypt — hash with Argon2id or bcrypt with a unique salt. Audit key usage and enforce least privilege.

• Always use high-level, audited libraries; do not roll your own crypto.
• Enable constant-time comparisons for MACs and signatures to prevent timing attacks.
• Keep libraries updated; vulnerabilities like Heartbleed and Lucky13 were patched quickly but exploited for years on unpatched systems.
• Test with known-answer vectors (NIST CAVP) and fuzz your decryption paths.

10. Interview Questions

Interviewers use symmetric vs. asymmetric encryption to test both theoretical understanding and practical judgment. Expect questions that probe trade-offs, failure modes, and system design.

Q1: Why is symmetric encryption faster than asymmetric, and why can't we just use asymmetric for everything?
Answer: Symmetric ciphers use simple bitwise operations (XOR, S-box lookups, permutations) on small blocks and are parallelizable and hardware-accelerated, giving O(n) linear time with tiny constants. Asymmetric ciphers rely on modular exponentiation on 2048+ bit integers, which is O(k^3) and requires big-integer arithmetic. Encrypting 1MB with RSA-2048 would require ~5000 separate RSA operations (since each can only handle ~190 bytes), taking seconds versus <1ms for AES. Additionally, RSA ciphertext expansion (256 bytes per block) would bloat data. Hence we use hybrid: asymmetric to exchange a 32-byte AES key, symmetric for bulk data.

Q2: How does TLS 1.3 establish a secure connection? Walk through the key exchange.
Answer: TLS 1.3 uses ephemeral ECDHE for forward secrecy. Client sends ClientHello with a key_share (ephemeral ECDH public key) and supported groups. Server responds with ServerHello containing its key_share, certificate (with long-term public key), and CertificateVerify (signature over handshake transcript with its private key). Both compute the shared secret via ECDH, derive handshake and application traffic keys via HKDF, and then switch to symmetric AEAD (AES-GCM/ChaCha20) for all further records. The handshake is 1-RTT, and 0-RTT resumption is possible with PSK. Emphasize that the long-term private key is only used for authentication, not encryption, so compromise does not decrypt past traffic.

Q3: What is the difference between AES-CBC and AES-GCM, and why is GCM preferred?
Answer: CBC (Cipher Block Chaining) provides only confidentiality, requires padding, is sequential (not parallelizable), and needs a separate HMAC for integrity; it is vulnerable to padding oracle attacks if not implemented as Encrypt-then-MAC. GCM (Galois/Counter Mode) is an AEAD mode that provides confidentiality and integrity in one pass, is parallelizable, requires no padding, and produces an authentication tag that detects tampering. GCM uses CTR mode for encryption and GHASH for authentication, is faster with hardware support, and is nonce-misuse resistant to a degree (though nonce reuse is still catastrophic). For new systems, always prefer GCM or ChaCha20-Poly1305.

Q4: If an attacker gets your AES key, what is the impact versus getting your RSA private key? How do you mitigate each?
Answer: AES key compromise decrypts all data encrypted with that key — past and future — until the key is rotated, but does not affect other keys. Mitigation: use envelope encryption, short-lived data keys, frequent rotation, and HSM storage. RSA private key compromise is more severe: the attacker can impersonate the server, decrypt any session keys encrypted with that public key (if not using forward secrecy), and forge signatures. Mitigation: use ECDHE for forward secrecy so session keys are not encrypted with the long-term key, store private keys in HSMs, use short-lived certificates (e.g., 90 days via Let's Encrypt), and have a revocation plan (CRL/OCSP, Certificate Transparency).

Q5: How would you securely store user passwords? Would you use symmetric or asymmetric encryption?
Answer: Neither. Passwords should not be encrypted (reversible) but hashed with a slow, salted, memory-hard KDF. Use Argon2id (preferred), bcrypt, or PBKDF2-HMAC-SHA256 with a unique 16+ byte salt per user and appropriate cost parameters (e.g., Argon2id with 64MB memory, 3 iterations). Hashing is one-way, so a database breach does not reveal passwords, and salting prevents rainbow tables. Encryption would require a key that, if stolen, reveals all passwords. Additionally, enforce pepper (application-wide secret added to hash) stored in HSM/KMS for defense in depth.