Chapter 1: Symmetric Cryptography - Fast, Shared, and Modal#

Symmetric crypto uses one shared key for both encryption and decryption. It is fast (hardware-accelerated AES runs at gigabytes per second) but has one hard problem: how do both parties get the same key without an eavesdropper seeing it? (Part II answers that.)

The subtlety that sinks beginners is modes of operation. A block cipher like AES encrypts one fixed 16-byte block. To encrypt anything real, you chain blocks, and the chaining mode is where security lives or dies.

The ECB penguin - why mode matters

The naive mode, ECB (Electronic Codebook), encrypts each block independently. Identical plaintext blocks produce identical ciphertext blocks. Encrypt a bitmap of the Linux penguin in ECB and you can still see the penguin in the ciphertext, the outline leaks straight through. ECB destroys confidentiality on any data with structure. If you ever see AES/ECB in code, treat it as a bug. ²

The modern answer is AEAD (Authenticated Encryption with Associated Data), which fuses confidentiality and integrity into one primitive so you cannot get one without the other:

graph LR
    PT[Plaintext] --> ENC
    K[Key] --> ENC
    N[Nonce - unique!] --> ENC
    AD[Associated Data<br/>headers, not encrypted] --> ENC
    ENC["AEAD Encrypt<br/>(AES-GCM / ChaCha20-Poly1305)"] --> CT[Ciphertext]
    ENC --> TAG["Auth Tag<br/>(detects tampering)"]
    style ENC fill:#065f46,color:#fff
    style N fill:#7c2d12,color:#fff

The two AEAD ciphers you should reach for:

The nonce is not a secret, but it must be unique

A nonce (number-used-once) does not need to be secret, it ships in the clear. But under a given key it must never repeat. With GCM’s 96-bit random nonce, birthday-bound collisions become a real risk after roughly $2^{32}$ messages under one key. The safe patterns: use a counter nonce (guaranteed unique), rotate keys well before the limit, or use a nonce-misuse-resistant mode like AES-GCM-SIV. ³

Chapter 2: Hashing - The One-Way Street#

A cryptographic hash maps arbitrary input to a fixed-size digest such that it is infeasible to (a) reverse it, (b) find two inputs with the same digest (collision resistance), or (c) find an input matching a given digest (preimage resistance).

Three uses that people constantly conflate, and they need different functions:

flowchart TD
    Q{What are you hashing for?}
    Q -->|Integrity / fingerprint| Fast["SHA-256, SHA-3, BLAKE3<br/><b>FAST is good</b>"]
    Q -->|Passwords| Slow["Argon2id, scrypt, bcrypt<br/><b>SLOW is the point</b>"]
    Q -->|Message authentication| MAC["HMAC-SHA256<br/><b>keyed hash</b>"]
    style Fast fill:#1e3a8a,color:#fff
    style Slow fill:#7c2d12,color:#fff
    style MAC fill:#065f46,color:#fff

This is the crux: for file integrity you want the fastest secure hash; for passwords you want the slowest. Using SHA-256 for passwords is a vulnerability (a GPU cracks billions/sec); using Argon2id for a file checksum is just pointlessly slow. Same word, “hash”, opposite requirements.

MACs add a key so that only someone holding the secret can produce or verify the tag, this is integrity and authenticity. Use HMAC and always compare tags with a constant-time comparison, an early-exit == leaks timing information an attacker can use to forge tags byte by byte.

The double-hashing structure is not decoration, it defends against length-extension attacks that would otherwise let an attacker append data to a naïvely-keyed H(K \| m) construction.

Chapter 3: Asymmetric Cryptography - Solving the Key-Exchange Problem#

Asymmetric (public-key) crypto uses a keypair: a public key you share freely and a private key you guard with your life. Anyone can encrypt to your public key; only your private key decrypts. Or: you sign with your private key; anyone verifies with your public key.

• RSA - the classic. Security rests on the hardness of factoring large integers. Now considered large and slow, 3072-bit keys for 128-bit security. Fine, but heavy.
• Elliptic Curve Cryptography (ECC) - the same security with dramatically smaller keys, because it rests on the elliptic-curve discrete-log problem, which is harder per bit. A 256-bit ECC key ≈ a 3072-bit RSA key.

xychart-beta
    title "Key Size for Equivalent Security (bits) - RSA vs ECC"
    x-axis ["80-bit", "112-bit", "128-bit", "192-bit", "256-bit"]
    y-axis "Key Size (bits)" 0 --> 16000
    bar [1024, 2048, 3072, 7680, 15360]
    line [160, 224, 256, 384, 512]

The chasm between the bars (RSA) and the line (ECC) at high security levels is why modern protocols default to elliptic curves: Ed25519 for signatures, X25519 for key exchange, both fast, small, and designed to be hard to misuse ⁴.

Asymmetric crypto rarely encrypts your data directly

Public-key operations are slow and size-limited. In practice you almost never RSA-encrypt a file. You use asymmetric crypto to exchange or wrap a symmetric key, then encrypt the bulk data with fast AEAD. This is hybrid encryption, and it is what TLS, PGP, age, and every sane system actually do.

Chapter 4: Diffie-Hellman and Forward Secrecy#

Diffie-Hellman (DH) is the beautiful trick at the heart of it. Both parties mix their private secret with the other’s public value and, thanks to the algebra, arrive at the same shared secret, while an eavesdropper who saw both public values cannot compute it.

The killer property is (Perfect) Forward Secrecy. If each session uses an ephemeral DH keypair (ECDHE, the “E” is ephemeral) that is thrown away afterward, then even if an attacker records all your encrypted traffic today and steals your long-term private key next year, they still cannot decrypt the recorded sessions. The session keys died with the sessions.

Why forward secrecy is non-negotiable now

“Record now, decrypt later” is a real, funded adversary strategy, especially with quantum computers on the horizon (Chapter 7). Forward secrecy means today’s captured ciphertext does not become a liability the day your server key leaks. TLS 1.3 makes forward-secret ECDHE mandatory, the old static-RSA key exchange (no forward secrecy) was removed entirely. ⁵

Chapter 5: The TLS 1.3 Handshake, For Real#

Here is the handshake we kept saying “use TLS” about, the actual thing. TLS 1.3 cut the round trips from two to one and stripped out every insecure option ⁵:

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: 1-RTT Handshake
    C->>S: ClientHello<br/>+ supported ciphers<br/>+ key_share (ephemeral ECDHE pubkey)
    Note over S: pick cipher, generate<br/>own ephemeral key
    S->>C: ServerHello + key_share
    Note over C,S: Both derive shared secret via ECDHE<br/>→ derive handshake keys (HKDF)
    S->>C: {EncryptedExtensions}
    S->>C: {Certificate} (server's X.509 chain)
    S->>C: {CertificateVerify} (signature proving key ownership)
    S->>C: {Finished} (MAC over transcript)
    Note over C: verify cert chain + hostname<br/>verify signature + Finished
    C->>S: {Finished}
    Note over C,S: Application data flows, encrypted with AES-GCM / ChaCha20-Poly1305

Every step earns its place:

• key_share in the very first message - the client guesses the group and sends its ephemeral key immediately, which is how TLS 1.3 saves a round trip.
• Certificate + CertificateVerify - the certificate binds the server’s identity to a public key (via the PKI chain from Volume II); the signature proves the server actually holds the matching private key. A stolen certificate without the private key is useless.
• Finished - a MAC over the entire handshake transcript. If a man-in-the-middle tampered with any earlier message (e.g., a downgrade attack stripping strong ciphers), the transcripts won’t match and the handshake aborts.

What TLS 1.3 deleted is as important as what it kept

TLS 1.3 removed RSA key exchange, static DH, CBC-mode ciphers, RC4, MD5, SHA-1, compression (goodbye CRIME/BREACH), and renegotiation. The design philosophy: fewer knobs means fewer ways to misconfigure yourself into a breach. A protocol with no insecure options can’t be talked into one. Disable TLS 1.0/1.1 everywhere; prefer 1.3, allow 1.2 only for legacy clients.

Chapter 7: Harvest Now, Decrypt Later#

timeline
    title The Post-Quantum Transition Timeline
    Today : Adversaries record encrypted traffic ("harvest now")
          : Data with long secrecy lifetime is already at risk
    2024 : NIST finalizes PQC standards (ML-KEM, ML-DSA, SLH-DSA)
    2025-2030 : Hybrid deployment (classical + PQC together)
    2030s : Cryptographically-relevant quantum computer plausible
          : Classical asymmetric crypto considered broken
    Beyond : PQC-only for anything requiring long-term confidentiality

The asymmetric split in the quantum threat:

• Asymmetric crypto (RSA, ECC, DH) - broken by Shor’s algorithm. This is the emergency.
• Symmetric crypto (AES) and hashes (SHA-2/3) - only weakened by Grover’s algorithm, which effectively halves the security level. The fix is trivial: use AES-256 (which retains 128-bit security post-quantum) and 384-bit+ hashes. Symmetric crypto is basically fine.

In 2024 NIST standardized the first post-quantum algorithms ⁷:

• ML-KEM (Kyber) - key encapsulation, the replacement for ECDH key exchange.
• ML-DSA (Dilithium) and SLH-DSA (SPHINCS+) - digital signatures.

The pragmatic move today: hybrid

No one flips to PQC-only overnight, the new algorithms are younger and less battle-tested. The industry answer is hybrid key exchange: run classical X25519 and ML-KEM together, combining both shared secrets, so the session is secure unless both are broken. Chrome, Cloudflare, and others already deploy X25519+ML-KEM by default. If you procure crypto with a decade-plus secrecy requirement, ask your vendors about their PQC roadmap now. ⁸