🔏 Encryption & Cryptography
The mathematical foundation of information security — symmetric & asymmetric encryption, hash functions, digital signatures, PKI, key management, TLS, and preparing for the post-quantum era.
Overview
Cryptography is the bedrock of cybersecurity — it protects data confidentiality, ensures integrity, verifies authenticity, and provides non-repudiation. Every secure connection (TLS), every signed binary (code signing), every hashed password (bcrypt), and every encrypted database (AES-256) relies on cryptographic primitives. Understanding how these primitives work — and when they fail — is essential for any security professional. With quantum computing on the horizon, cryptographic agility is becoming a critical organizational capability.
Key Concepts
Asymmetric Encryption
Uses a key pair — public key (shareable) encrypts, private key (secret) decrypts. Solves the key distribution problem. RSA: Most widely deployed — 2048-bit minimum (4096-bit recommended). Based on integer factorization hardness. Used for key exchange, digital signatures, and certificate signing. Slower than symmetric — never used for bulk encryption. ECC (Elliptic Curve Cryptography): Same security as RSA with much smaller keys — ECC-256 ≈ RSA-3072. Faster, less CPU/bandwidth. Ed25519: Modern EdDSA signature scheme — deterministic, fast, and resistant to side-channel attacks. Used by SSH, GPG, and cryptocurrency. Diffie-Hellman (DH/ECDHE): Key agreement protocol — two parties derive a shared secret over an insecure channel without ever transmitting the key. ECDHE provides Perfect Forward Secrecy in TLS.
Digital Signatures
Proves authenticity (who signed it), integrity (data hasn't been modified), and non-repudiation (signer can't deny signing). Process: hash the message → encrypt hash with private key → recipient decrypts with public key → compares hashes. RSA-PSS: RSA Probabilistic Signature Scheme — recommended over PKCS#1 v1.5 (deterministic, vulnerable to attacks). ECDSA: Elliptic Curve Digital Signature Algorithm — used in TLS certificates, Bitcoin, and code signing. Smaller signatures than RSA. Ed25519: Modern, fast, deterministic signature scheme — no need for secure random number generation during signing (unlike ECDSA which fails catastrophically with bad RNG — see PlayStation 3 hack). Use cases: Code signing (verify software authenticity), document signing (legal contracts), certificate signing (CAs sign server certificates), JWT signing (API authentication), commit signing (Git GPG/SSH signatures).
Hash Functions & MACs
Cryptographic hash functions produce a fixed-size fingerprint from arbitrary input. Properties: deterministic, fast, avalanche effect (small input change → completely different hash), pre-image resistant, collision resistant. SHA-256: Industry standard — used in TLS certificates, blockchain, file integrity, code signing. Part of SHA-2 family. SHA-3 (Keccak): NIST-standardized alternative — different internal design (sponge construction), provides defense-in-depth if SHA-2 is ever broken. BLAKE3: Extremely fast modern hash — 4x faster than SHA-256, used in integrity checking and deduplication. Password hashing: NEVER use SHA-256 for passwords — it's too fast (enables brute force). Use bcrypt (battle-tested, cost factor), Argon2id (OWASP recommended, memory-hard, resists GPU attacks), or scrypt. HMAC: Hash-based Message Authentication Code — proves both integrity AND authenticity. HMAC-SHA256 is used in JWT signatures, API authentication, and webhook verification.
Key Management
The most critical aspect of cryptography — algorithms don't fail, key management does. Envelope encryption: Data encrypted with a Data Encryption Key (DEK), DEK encrypted with a Key Encryption Key (KEK). Only KEK needs HSM protection. Used by AWS KMS, Azure Key Vault, GCP Cloud KMS. Key hierarchy: Master Key (HSM-protected, never exported) → KEK (encrypts DEKs) → DEK (encrypts data). Separation limits blast radius. HSM (Hardware Security Module): Tamper-resistant hardware that generates, stores, and uses keys without ever exposing them. FIPS 140-2/3 Level 3 certified. Cloud offerings: AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM. Key rotation: Automatic rotation every 90-365 days. Immediate rotation on compromise. Old keys retained for decryption only. BYOK/HYOK: Bring Your Own Key — customer generates key and imports to cloud KMS. Hold Your Own Key — key never leaves customer premises. For regulated industries requiring full key custody.
PKI & Certificates
Public Key Infrastructure enables trust on the internet. X.509 certificates bind a public key to an identity, signed by a Certificate Authority (CA). Certificate chain: Root CA (self-signed, stored in OS/browser trust store) → Intermediate CA (signs server certs) → Leaf certificate (your domain). Browsers validate the entire chain. Certificate Authorities: Let's Encrypt (free, automated via ACME protocol, 90-day certs), DigiCert, Sectigo for paid/EV certificates. Certificate Transparency (CT): Public append-only logs of all issued certificates — allows domain owners to detect rogue certificates. OCSP & CRL: Certificate revocation checking — OCSP Stapling is preferred (server fetches and caches revocation status, reducing client latency). Certificate pinning: Mobile apps pin expected certificates/public keys to prevent MITM even with compromised CAs — but increases operational complexity (rotation requires app update).
Post-Quantum Cryptography
Quantum computers threaten current cryptography. Shor's algorithm breaks RSA, ECC, and Diffie-Hellman by efficiently factoring large numbers and solving discrete logarithm. Grover's algorithm halves the effective security of symmetric encryption (AES-256 → 128-bit security — still safe, but AES-128 drops to 64-bit). NIST PQC Standards (2024): ML-KEM (CRYSTALS-Kyber) for key encapsulation, ML-DSA (CRYSTALS-Dilithium) for digital signatures, SLH-DSA (SPHINCS+) for hash-based signatures. Harvest Now, Decrypt Later: Adversaries are capturing encrypted data today to decrypt when quantum computers arrive — critical for long-lived secrets (government, healthcare, financial). Crypto-agility: Design systems to swap cryptographic algorithms without rewriting applications. Use abstraction layers, algorithm-agnostic APIs, and maintain a cryptographic inventory. Migration timeline: NIST recommends starting PQC migration now, with full transition by 2035.
Symmetric Encryption
Uses a single shared key for both encryption and decryption. Fast and efficient for bulk data. AES (Advanced Encryption Standard): The gold standard — AES-128 (fast, sufficient for most use cases), AES-256 (required for classified/regulated data). Block cipher modes: ECB (insecure — never use), CBC (legacy, vulnerable to padding oracle), GCM (recommended — provides both encryption AND authentication), CTR (parallelizable, used in disk encryption). ChaCha20-Poly1305: Stream cipher alternative to AES-GCM — used by Google, WireGuard, and TLS 1.3. Faster in software on devices without AES hardware acceleration (ARM mobile). Key challenge: How do you securely share the key? This is solved by asymmetric encryption or key exchange protocols.
Symmetric vs Asymmetric Comparison
| Property | 🔵 Symmetric | 🟣 Asymmetric |
|---|---|---|
| Keys | Single shared key | Public + Private key pair |
| Speed | 🟢 Very fast (100x–1000x) | 🔴 Slow (computationally expensive) |
| Key Size | 128–256 bits | 2048–4096 bits (RSA) / 256 bits (ECC) |
| Key Distribution | 🔴 Hard — must share key securely | 🟢 Easy — public key is shareable |
| Use Cases | Bulk data encryption, disk encryption, database encryption, VPN tunnels | Key exchange, digital signatures, certificate signing, email encryption |
| Algorithms | AES-256-GCM, ChaCha20-Poly1305 | RSA-4096, ECC P-256, Ed25519, X25519 |
| Quantum Threat | 🟡 Grover halves security (AES-256 → 128-bit) | 🔴 Shor breaks RSA & ECC completely |
| In Practice | ✅ Hybrid approach — use asymmetric to exchange symmetric keys, then symmetric for bulk data (TLS, PGP, S/MIME) | |
TLS 1.3 Handshake
TLS 1.3 completes the handshake in just 1 round-trip (1-RTT) — down from 2 in TLS 1.2. It removed insecure algorithms (RSA key exchange, CBC, RC4, SHA-1) and mandates Perfect Forward Secrecy via ECDHE.
TLS 1.3 — 1-RTT Handshake
Key improvements: mandatory ECDHE (Perfect Forward Secrecy), 1-RTT handshake, 0-RTT resumption, removed RSA key exchange, no CBC mode, only AEAD ciphers (AES-GCM, ChaCha20-Poly1305)
Envelope Encryption Architecture
Envelope encryption is the industry-standard pattern used by AWS KMS, Azure Key Vault, and GCP Cloud KMS. It separates the data encryption key from the key that protects it — limiting blast radius and enabling efficient key rotation.
Envelope Encryption Pattern
Used by AWS KMS (CMK → Data Key), Azure Key Vault, and GCP Cloud KMS. Master key never leaves the HSM. DEKs are generated per operation and wrapped by the KEK for storage.
Interview Preparation
What is the difference between AES-CBC and AES-GCM, and why is GCM preferred?
Both are AES block cipher modes, but they differ fundamentally: AES-CBC (Cipher Block Chaining) provides confidentiality only — it encrypts data but does not verify integrity. It's vulnerable to padding oracle attacks (e.g., POODLE, Lucky
1
3where an attacker manipulates ciphertext and observes error responses to decrypt data. CBC also requires padding and is sequential (cannot be parallelized). AES-GCM (Galois/Counter Mode) is an AEAD cipher — it provides both confidentiality AND authentication in a single operation. The GCM tag (128-bit) guarantees that ciphertext hasn't been tampered with. GCM is parallelizable (faster), doesn't require padding, and is resistant to padding oracle attacks. GCM is mandated by TLS 1.3 and is the recommended mode for virtually all modern encryption. The only caveat: GCM requires unique nonces — reusing a nonce with the same key completely breaks security.
How does the TLS 1.3 handshake work and what improved over TLS 1.2?
TLS 1.3 handshake:
1Client Hello — client sends supported cipher suites, ECDHE key share, and random nonce. Key difference: the key share is sent immediately (not after negotiation).
2Server Hello — server selects cipher suite, sends its ECDHE key share, certificate, and signature. Encrypted Extensions follow.
3Key Derivation — both sides compute the shared secret from ECDHE key exchange. All subsequent messages are encrypted.
4Client Finished — confirms handshake integrity. Total: 1-RTT (1 round trip). Improvements over TLS 1.2: Reduced from 2-RTT to 1-RTT (faster connection setup). Removed insecure algorithms: RSA key exchange (no PFS), CBC mode, RC4, SHA-1, static DH. Mandatory Perfect Forward Secrecy via ECDHE — every session uses ephemeral keys, so compromising the server's private key cannot decrypt past sessions. 0-RTT resumption for repeat connections (with replay protection). Only AEAD ciphers allowed (AES-GCM, ChaCha20-Poly1305). Encrypted server certificate (hides identity from network observers).
