The HTTPS/TLS Fundamentals course introduced enough cryptography to explain how a browser padlock actually works — symmetric/asymmetric crypto, hashing, and key exchange, covered just deeply enough to get through a TLS handshake (https1-2, https1-3). This course goes underneath that: the primitives themselves, why they're built the way they are, and — because it's genuinely a great story with real technical substance — a proper look at classical cryptography's most famous machine, the Enigma, and how it was broken.

The Four Goals of Cryptography

"Cryptography" is often shorthand for just one thing — keeping messages secret. That's only a quarter of the picture. Every cryptographic system exists to provide some combination of four distinct guarantees:

The Vocabulary You'll Need

• Plaintext — the original, readable message before any transformation.
• Ciphertext — the transformed, unreadable-without-the-key output.
• Cipher — the algorithm that transforms plaintext into ciphertext and back.
• Key — the secret input that controls exactly how a cipher transforms the data; the same cipher with a different key produces completely different ciphertext.
• Encrypt / decrypt — apply the cipher forward (plaintext → ciphertext) or in reverse (ciphertext → plaintext).
• Cryptography — the practice of designing these systems; cryptanalysis — the practice of breaking them; cryptology — the umbrella term covering both.

That last distinction matters more than it looks — Chapter 4's entire subject is cryptanalysis, not cryptography: how a well-designed cipher's real-world implementation and operation, not its underlying mathematics, ended up being its weakness.

Kerckhoffs's Principle — The Algorithm Isn't the Secret

Formulated by Auguste Kerckhoffs in 1883, the principle states: a cryptographic system should remain secure even if everything about it — except the key — is public knowledge. Only the key is secret; the algorithm itself can be published, studied, and attacked by the entire world without that alone breaking the system.

This runs directly against instinct. Surely keeping the algorithm itself secret adds a layer of protection? In practice, the opposite holds:

• A secret algorithm has never been reviewed by anyone outside the small group that built it — flaws go unnoticed until an attacker finds them first.
• A public algorithm like AES (Ch.5) has been attacked for decades by the world's best cryptanalysts and has held up — that scrutiny is the evidence of its strength.
• Relying on secrecy of design rather than secrecy of key is called security through obscurity, and it's considered a red flag rather than a defence in modern cryptographic engineering.

Symmetric vs. Asymmetric — A First Look

Two fundamentally different approaches to using a key, both covered in real depth later in this course:

Every classical cipher this course covers next — including Enigma — is symmetric: the same setting that encrypts a message also decrypts it. Asymmetric cryptography is a 20th-century invention (Chapter 9), and understanding why it took so long to invent is itself a genuinely interesting question, revisited once Chapter 9 lays out the "hard problem" symmetric crypto never solved.

Where This Course Is Headed

Hands-On Exercises

Chapter 1 introduced the vocabulary — plaintext, ciphertext, cipher, key — in the abstract. This chapter puts real, historical ciphers behind those words, and builds toward a genuinely important point: every classical cipher, no matter how clever, eventually falls to the same weapon — statistics. Understanding exactly why sets up Chapter 3's Enigma machine as something more than a historical curiosity — it was a serious, partially successful attempt to defeat this exact weakness mechanically.

The Caesar Cipher — Simplest Substitution

Named for Julius Caesar, who reportedly used it for military messages: shift every letter of the alphabet forward by a fixed amount. A shift of 3 turns A into D, B into E, and so on, wrapping around at the end.

The key here is just the shift amount — a single number between 1 and 25. ROT13 (shift 13) is the same idea, still occasionally used today for puzzle spoilers, precisely because it offers no real security — its own reversal is trivial to spot.

Substitution Ciphers, Generalized

A monoalphabetic substitution cipher generalizes Caesar's idea: instead of a fixed shift, use any arbitrary one-to-one mapping from plaintext letters to ciphertext letters. There are 26! (about 4×10²⁶) possible mappings — brute force is completely infeasible here, unlike Caesar's 25 keys.

And yet monoalphabetic substitution is still comprehensively broken — not through brute force, but through a completely different kind of attack.

Frequency Analysis — Breaking Substitution Ciphers

Every natural language has a distinctive statistical fingerprint. In English text, E is by far the most common letter (roughly 12.7% of all letters), followed by T, A, O, I, N — often remembered by the mnemonic ETAOIN SHRDLU. A monoalphabetic substitution cipher maps each plaintext letter to always the same ciphertext letter — which means it preserves this frequency fingerprint perfectly, just relabeled.

Given enough ciphertext, an analyst counts how often each ciphertext symbol appears, matches the most frequent symbol to E, the next most frequent to T, and so on — then refines using common short words ("THE", "AND"), double letters, and known digraphs/trigraphs. No matter how large the keyspace, the underlying language's statistics leak straight through the substitution.

Transposition Ciphers

A completely different family: instead of replacing letters, rearrange their order. The rail fence cipher writes the message in a zigzag across several "rails" and reads them off row by row; columnar transposition writes the message into a grid and reads the columns out in a key-defined order.

Because a transposition cipher never changes which letters appear — only their order — the letter frequencies of the ciphertext are identical to the plaintext's, which defeats a naive frequency-count attack outright. But it introduces a different weakness: the ciphertext is a pure anagram of the plaintext, and short, structured messages are often recoverable by testing plausible word fragments and grid dimensions — a real weakness, just a different one than substitution's.

The Vigenère Cipher — "Le Chiffre Indéchiffrable"

For roughly 300 years, the Vigenère cipher (popularized in the 16th century) was considered unbreakable — French for "the indecipherable cipher." It's a polyalphabetic substitution cipher: instead of one fixed shift (Caesar) or one fixed mapping (monoalphabetic substitution), it cycles through multiple different shifts, determined by a repeating keyword.

Each letter of the keyword selects a different Caesar shift for the letter beneath it — "ATTACK" gets encrypted with a different effective cipher at nearly every position, so the same plaintext letter (the two T's in ATTACK) can produce two completely different ciphertext letters. That single property is exactly what defeats a direct frequency count: the ciphertext's letter frequencies are smeared across multiple shifted alphabets rather than reflecting English's fingerprint directly.

Breaking Vigenère — the Kasiski Examination

Vigenère's real weakness is that the keyword repeats. If a keyword is 5 letters long, then every 5th letter of ciphertext was shifted by the same keyword letter — meaning the ciphertext is actually 5 separate, interleaved Caesar ciphers, each individually breakable by ordinary frequency analysis once you know that 5 is the key length.

Friedrich Kasiski published the practical break in 1863: look for repeated sequences of 3+ letters in the ciphertext. If the same plaintext fragment happens to align with the same part of the repeating keyword twice, it produces the same ciphertext fragment twice — and the distance between those two repeats must be a multiple of the key length. Find several such repeated fragments, take the greatest common divisor of their distances, and the key length falls out.

Why All Classical Ciphers Eventually Fall

Every cipher in this chapter shares one structural weakness: each is a fixed, repeating transformation — a single shift, a single substitution alphabet, or a substitution alphabet that repeats every few letters. Fixed and repeating transformations always leave some statistical fingerprint of the underlying language intact, and given enough ciphertext, that fingerprint is always recoverable.

Hands-On Exercises

Chapter 2 closed on a bridge: Enigma is, structurally, a polyalphabetic substitution cipher — the same family as Vigenère — but instead of cycling through a short repeating keyword, it mechanically generates a new substitution alphabet on every single keystroke. This chapter is about exactly how it did that: the physical components, the electrical path a signal actually takes, and the daily settings that — per Kerckhoffs's Principle (Chapter 1) — were the only real secret in the whole system.

The Physical Machine, Component by Component

A military Enigma (the German Wehrmacht/Luftwaffe 3-rotor variant this chapter focuses on) is built from five functional parts, wired together in series:

The Electrical Pathway — Tracing a Keypress

Pressing a single key completes a circuit that travels through the entire machine in one direction, then back through most of it in the other direction, before finally lighting a lamp. In order:

Every keypress passes through the rotor stack twice — once outward toward the reflector, once back — which is exactly what makes Enigma reciprocal: with identical settings, encrypting a letter and decrypting a letter are literally the same operation run through the same circuit. That's why the same machine, same daily settings, both encrypted and decrypted — a genuinely elegant piece of engineering, and (as Chapter 4 shows) also the source of its most damaging flaw.

The Rotors — Wiring & Stepping

Each rotor is a disc with 26 electrical contacts on each face, internally wired so that entering on contact A might exit on contact F, entering on B might exit on U, and so on — a fixed, physical monoalphabetic substitution baked into the metal (echoing Chapter 2's substitution ciphers, just implemented as wiring rather than a lookup table).

What makes it more than a fixed substitution is that the rightmost rotor physically advances one position after every keypress, like the units wheel on an odometer — so the substitution it performs on the very next letter is different again. When the rightmost rotor completes a full revolution, it "kicks" the middle rotor forward one position too (with a quirky, historically fiddly detail called double-stepping, where the middle rotor can occasionally step twice in a row); the leftmost rotor advances only rarely. The practical effect: the combined substitution performed by all three rotors together doesn't meaningfully repeat until many thousands of letters have been typed — nothing like Vigenère's short, repeating keyword from Chapter 2.

The Reflector (Umkehrwalze) — Symmetric But Flawed

The reflector is wired as 13 fixed pairs covering all 26 letters (A always reflects to, say, Y and vice versa), and critically, it has one structural property: no letter can ever reflect back to itself. That single design choice — which is what makes the machine reciprocal at all — turns out to be Enigma's single most exploitable weakness, covered in full in Chapter 4.

The Plugboard (Steckerbrett) — Extra Scrambling

Before the German military added it, Enigma's civilian/commercial version relied on the rotors and reflector alone. The plugboard sits at both the very start and very end of the electrical path (steps 2 and 10 above) and swaps pairs of letters via physical cables — typically 10 pairs swapped, out of 26 letters, on a standard military setup. It doesn't change the fundamental structure of the cipher at all — it's still the same rotor-and-reflector substitution underneath — but it multiplies the number of possible daily configurations enormously, which mattered a great deal for the keyspace calculation below.

The Daily Key Settings — What Was Actually Secret

Per Chapter 1's Kerckhoffs's Principle, the machine's design was not secret — the Allies had working Enigma machines. What was secret, distributed via monthly codebooks to every operator, was the daily key:

• Rotor choice & order (Walzenlage) — which 3 of the available rotors were installed, and in what left-to-right order.
• Ring settings (Ringstellung) — an offset between each rotor's internal wiring and its outer letter ring.
• Initial rotor positions (Grundstellung) — the starting letter each rotor was turned to before the message was typed.
• Plugboard pairs (Steckerverbindungen) — which ~10 letter pairs were physically cabled together that day.

Every operator sending or receiving a message that day used the identical settings — get any one piece wrong, and the decrypted output is unreadable garbage from the very first letter.

Enigma's Keyspace — Astronomically Large...

Combining rotor choice and order, ring settings, starting positions, and plugboard pairings, the total number of possible daily configurations for a 3-rotor military Enigma has been estimated at roughly 10¹¹⁴ — a number so large that brute-forcing every possible setting, even with modern computing power, remains completely infeasible. On paper, this looks like an unbreakable system.

Hands-On Exercises

Chapter 3 ended with a warning: the ~10¹¹⁴ keyspace calculation assumed an attacker searching blindly, with no shortcuts and no help from the machine's own structure or the humans operating it. Neither assumption held. This chapter covers how Enigma was actually broken — first by Polish mathematicians before the Second World War even started, then at a much larger, sustained scale at Britain's Bletchley Park — and why the real story is less "a genius found one clever trick" and more "a systematic, industrial-scale process exploited several genuine weaknesses at once."

The Reflector's Fatal Flaw, Formalized

Chapter 3 introduced the reflector's guarantee that no letter can ever encrypt to itself, and asked you to reason about why that might help a codebreaker even without knowing the daily key. Here's the formal technique built on exactly that property, known as crib-dragging.

A crib is a guessed or known fragment of plaintext believed to appear somewhere in a message — more on where these guesses actually came from in the next section. To test a crib against a stretch of ciphertext:

1. Slide the crib along the ciphertext, testing one starting position (offset) at a time.
2. At each offset, compare the crib letter-by-letter against the ciphertext letters directly beneath it.
3. If any letter of the crib matches the ciphertext letter in the same position, that offset is impossible — Enigma could never have produced a letter mapping to itself — and can be discarded immediately, with zero knowledge of the actual daily key required.

This alone doesn't reveal the key — but it dramatically narrows down which positions in the ciphertext a guessed crib could actually start at, which is the essential first step every other technique in this chapter builds on.

Cribs — Where the Guesses Came From

Crib-dragging is only useful if you have a good guess for what plaintext to test. In practice, German military communication was remarkably predictable:

• Routine weather reports opened with the same standard phrase, Wettervorhersage ("weather forecast"), nearly every single day.
• Uneventful daily status reports commonly used the stock phrase Keine besonderen Ereignisse ("nothing to report").
• Formal messages followed rigid formatting and titles — dates, ranks, and unit names appearing in predictable positions.
• Some phrases were considered so security-sensitive their use was actually restricted — Hitler's name, for instance, was avoided in encrypted traffic specifically because its predictable spelling made it a dangerously strong crib.

The Polish Contribution — Rejewski & the Bomba

The first real break came years before the war, from the Polish Cipher Bureau. Mathematician Marian Rejewski exploited a specific procedural weakness in how Germany used Enigma in the early-to-mid 1930s: each operator's message began with the day's starting position, enciphered twice in a row as a check against transmission errors. That doubled repetition, combined with rigorous permutation-group mathematics, let Rejewski deduce the internal rotor wiring and build the Bomba kryptologiczna — an electromechanical device that automated testing candidate rotor settings against this specific weakness.

In July 1939, with war looming, Poland shared its Enigma-breaking methods and even reconstructed machines with British and French intelligence — a critical head start that the much larger Bletchley Park effort built directly on top of.

Turing, Welchman & the British Bombe

Once Germany fixed the doubled-key weakness the Poles had exploited, the Polish method stopped working. At Bletchley Park, Alan Turing designed a new electromechanical device — also called the Bombe, distinct from and considerably more powerful than the Polish Bomba — built around crib-dragging rather than the doubled-key flaw. Gordon Welchman then added a critical improvement, the diagonal board, which dramatically increased the number of plugboard-related contradictions the machine could detect, cutting the effective search time enormously.

How the Bombe Actually Worked, Conceptually

Starting from a crib believed to align with a stretch of ciphertext, codebreakers built a menu — a diagram linking each ciphertext letter to its corresponding crib letter at that position, forming a chain (and sometimes closed loops, which were especially valuable). The Bombe then electrically simulated many linked Enigma rotor-sets simultaneously, each wired according to the menu, and tested candidate rotor starting positions one at a time — extremely fast, since it was doing this electromechanically rather than by hand.

For each candidate position, the machine checked whether the wiring was self-consistent. A contradiction — most directly, a chain implying some letter would have to map to itself, violating the reflector's own guarantee from Chapter 3 — meant that starting position was impossible and could be discarded instantly, without ever needing to determine the plugboard or ring settings for it at all. Only candidate positions surviving this contradiction check were passed on for further, more detailed testing. The overwhelming majority of the ~10¹¹⁴-sized keyspace was never touched directly; entire families of settings were ruled out the moment a single contradiction appeared.

Human & Operational Mistakes That Helped

Beyond the machine's own structural properties, operators themselves handed codebreakers real, repeated advantages:

• Lazy or predictable settings — some operators chose starting positions or plugboard pairs following obvious patterns (keyboard sequences, initials, or repeatedly reusing a personal favorite), rather than genuinely random choices, nicknamed "cillies" by Bletchley staff.
• Message-key reuse — sending the same or a very similar message twice under different daily keys (for instance, retransmitting a message that failed to arrive) gave codebreakers two independently encrypted versions of the same plaintext, dramatically easier to attack together than either alone.
• "Kisses" — cases where the same message content was transmitted both via Enigma and via a separately-broken, lower-grade cipher, letting codebreakers use the already-known plaintext as a perfect crib against the Enigma version.
• Rigid message formatting — the same predictability the cribs section above already covered, but worth restating here as a genuinely operational (not mathematical) failure: discipline about varying message structure was simply never enforced.

What This Teaches About Cryptography Generally

Enigma's underlying cipher mathematics were genuinely sound for their era — the ~10¹¹⁴ keyspace from Chapter 3 was real. Every practical avenue of attack covered in this chapter — the reflector's structural guarantee, predictable message content, procedural shortcuts, and operator carelessness — came from how the system was used, not from the core cipher design being fundamentally broken.

Hands-On Exercises

Chapters 2 through 4 covered ciphers no one would trust with real data today — but the underlying ideas (substitution, permutation, and the danger of a repeating key) turn out to be exactly the ideas modern symmetric cryptography is built from, just executed with vastly more rigor and mathematical scrutiny. This chapter leaves history behind and covers the ciphers actually protecting real systems right now — including the ones briefly introduced in https1-2, covered here in real depth.

Block Ciphers vs. Stream Ciphers — Two Different Approaches

Modern symmetric cryptography splits into two families, based on how they handle data:

Block ciphers also need a mode of operation to handle messages longer than one block — that's genuinely its own topic, covered fully in Chapter 6.

The Data Encryption Standard (DES) — A Brief History

Developed by IBM and adopted as the US federal encryption standard in 1977, DES was the first widely-used, publicly-specified block cipher — a real-world application of Chapter 1's Kerckhoffs's Principle, published openly rather than kept secret. It operates on 64-bit blocks using a 56-bit key and a structure called a Feistel network, which splits each block in half and repeatedly mixes the halves together across 16 rounds.

56 bits gives roughly 7.2 × 10¹⁶ possible keys — enormous by 1970s standards, but computing power caught up. By 1998, the Electronic Frontier Foundation's purpose-built "Deep Crack" machine brute-forced a DES key in under a day, publicly and decisively demonstrating that 56 bits was no longer remotely adequate.

Triple DES (3DES) — The Stopgap

Rather than design a wholly new cipher immediately, the industry's first response was to apply DES three times in a row, typically with two or three different keys, extending the effective key length without changing the underlying algorithm at all.

The AES Competition & Rijndael

Rather than have a single government agency design DES's replacement behind closed doors, the US National Institute of Standards and Technology (NIST) ran a genuinely open, public competition from 1997 to 2000 — every candidate algorithm was published in full and attacked publicly by cryptographers worldwide, the largest real-world demonstration of Kerckhoffs's Principle this course covers.

The winner, submitted by Belgian cryptographers Joan Daemen and Vincent Rijmen under the name Rijndael, became the Advanced Encryption Standard (AES) in 2001 — and remains, over two decades later, the world's dominant symmetric cipher, with no practical attack against the full algorithm ever found.

AES Internals — A Conceptual Overview

AES operates on 128-bit blocks, with a choice of 128-, 192-, or 256-bit keys (correspondingly using 10, 12, or 14 rounds). Each round applies four distinct transformations in sequence:

• SubBytes — a byte-for-byte substitution through a fixed, cryptographically-designed lookup table (the S-box) — conceptually Chapter 2's substitution ciphers, but nonlinear and specifically engineered to resist frequency-style analysis.
• ShiftRows — cyclically shifts bytes within each row of the block's internal grid — conceptually Chapter 2's transposition ciphers, rearranging position without changing values.
• MixColumns — a matrix operation that spreads each byte's influence across an entire column, ensuring a single-bit change in the input cascades into a large, unpredictable change in the output (the "avalanche effect," revisited properly in Chapter 7).
• AddRoundKey — XORs the block with a subkey, freshly derived from the main key for that specific round via a key schedule.

AES Security Today

AES-128's keyspace is roughly 3.4 × 10³⁸ — utterly infeasible to brute-force with any foreseeable computing power, classical or otherwise. AES-256 is sometimes preferred for long-term data or particularly high-value secrets, partly as a margin against future cryptanalytic advances, and partly because of quantum computing: Grover's algorithm can theoretically halve a symmetric cipher's effective key strength, meaning AES-256 still offers roughly AES-128-equivalent (128-bit) security even against a quantum attacker — a topic Chapter 12's post-quantum preview returns to.

Stream Ciphers

A stream cipher takes a key (plus, critically, a nonce — a number used once) and generates a long pseudorandom keystream, then simply XORs that keystream with the plaintext, one bit or byte at a time. Decryption is identical: XOR the same keystream against the ciphertext.

RC4, designed in 1987, was for years the most widely deployed stream cipher — used in early WEP Wi-Fi security and early TLS. Statistical biases discovered in its keystream output, combined with real misuse in WEP's key-scheduling, eventually made it thoroughly broken and deprecated. ChaCha20 is its modern successor — fast, carefully designed, and one of the two cipher families (alongside AES) used throughout TLS 1.3 today.

Hands-On Exercises

Chapter 5 covered AES as a cipher that transforms exactly one 128-bit block at a time. Real messages are almost never exactly 128 bits — so every real use of a block cipher needs a mode of operation: a defined way of chaining repeated block-cipher operations together to handle messages of any length. This turns out to matter as much as the underlying cipher itself — a message encrypted with rock-solid AES, in the wrong mode, can still be catastrophically insecure.

ECB — Electronic Codebook

The most obvious approach: split the message into blocks, and encrypt each block independently with the same key.

This has one devastating property: identical plaintext blocks always produce identical ciphertext blocks. Any structure or repetition in the original data — rows of a spreadsheet, repeated fields in a record, or the flat colored regions of an image — survives directly into the ciphertext, just relabeled.

This is structurally the exact same weakness Chapter 2 spent an entire chapter exploiting in monoalphabetic substitution: a fixed mapping — there, letter-to-letter; here, block-to-block — always leaks the structure of whatever it's applied to, no matter how strong the underlying transformation is.

CBC — Cipher Block Chaining

CBC breaks ECB's fixed-mapping problem directly: before encrypting each block, XOR it with the previous block's ciphertext first. This makes every block's encryption depend on everything that came before it, so identical plaintext blocks no longer produce identical ciphertext.

The very first block has no "previous ciphertext" to XOR against, so CBC needs an initialization vector (IV) — a random, unpredictable value used only once, playing a role reminiscent of Chapter 5's stream-cipher nonce. CBC encryption is inherently sequential (each block depends on the last), though decryption can actually be parallelized, since every ciphertext block is already available up front.

CTR — Counter Mode

Counter mode takes a completely different approach: rather than encrypting the plaintext directly, it encrypts a counter (a nonce combined with an incrementing number) to generate a keystream, then XORs that keystream with the plaintext — turning a block cipher into a stream cipher, in the same spirit as Chapter 5's ChaCha20.

Because each block's keystream depends only on the nonce and counter — not on any other block — CTR mode is fully parallelizable in both directions, unlike CBC, and needs no padding at all, since it's really a stream cipher underneath.

The Missing Piece — None of These Provide Integrity

ECB, CBC, and CTR all provide confidentiality only — none of them protect integrity or authenticity, Chapter 1's other two goals. An attacker who intercepts CBC or CTR ciphertext can flip specific bits without ever needing the key, causing controlled, predictable changes in the decrypted plaintext — with no built-in mechanism to detect that tampering occurred at all. This is the exact scenario Chapter 1's very first exercise asked you to reason about in the abstract; here it is made concrete.

GCM — Galois/Counter Mode (Authenticated Encryption)

GCM solves the missing piece directly. It's built on CTR mode's own encryption approach, but adds a built-in authentication tag, computed over the ciphertext using a technique called GMAC — bundling confidentiality, integrity, and authenticity into a single primitive, a category called AEAD (Authenticated Encryption with Associated Data). "Associated data" lets an application authenticate extra context — like a message header — without needing to encrypt it at all.

Chapter 8 covers message authentication and AEAD ciphers in full depth; this chapter's job is just to establish GCM as the mode-of-operation-level answer to the gap the previous section identified. GCM (or an equivalent AEAD mode) is the default in TLS 1.3 today, precisely because it closes the confidentiality-only gap that ECB, plain CBC, and plain CTR all share.

Choosing a Mode Today

This is the mode-choice version of Chapter 5's "never roll your own cipher" warning: the cipher can be perfectly strong AES, and the system can still be broken by choosing the wrong mode around it. Reach for a vetted AEAD mode by default rather than assembling confidentiality and integrity by hand.

Hands-On Exercises

Chapter 6 mentioned GCM's authentication tag without explaining how anything like it is actually built. Hash functions are the primitive that makes it possible — and they're a genuinely different tool from everything covered so far: no key in their basic form, and deliberately, permanently not reversible.

What Is a Hash Function?

A cryptographic hash function takes an input of any length — a single character or an entire multi-gigabyte file — and deterministically produces a fixed-length output, called a digest or hash. The same input always produces the same output, but there's no way to run the process backward: given only the digest, there's no operation that recovers the original input.

Hash ≠ Encryption

This is one of the most common mix-ups in casual security conversation — "we encrypted your password" almost always actually means "we hashed it," and the two are fundamentally different operations:

"Decrypting a hash" isn't a meaningful operation at all — there's no key to decrypt it with, and the transformation was never designed to be reversed.

The Three Security Properties

A cryptographically secure hash function needs to resist three distinct kinds of attack:

• Preimage resistance — given only a hash output H, it should be computationally infeasible to find any input that produces H.
• Second-preimage resistance — given a specific input M1, it should be infeasible to find a different input M2 that produces the same hash as M1.
• Collision resistance — it should be infeasible to find any two different inputs M1 and M2 (neither one given in advance) that happen to produce the same hash.

Collision resistance is strictly the hardest of the three to achieve — and, thanks to a genuinely counterintuitive piece of probability, it needs considerably more output bits than the other two properties to hold up.

The Birthday Paradox & Why Collision Resistance Needs More Bits

The "birthday paradox" observes that in a room of just 23 people, there's already a better-than-even chance two of them share a birthday — far fewer people than the 366 you might naively expect, because you're comparing every pair of people against each other, not just one person against everyone else.

The same math applies to hash collisions. Finding a specific preimage for an n-bit hash takes roughly 2ⁿ attempts on average. But finding any collision at all — any two inputs that happen to match — takes only about 2ⁿ/² attempts, because every new attempt is being checked against every previous attempt, not just one fixed target.

The Avalanche Effect

A well-designed hash function exhibits the avalanche effect: changing even a single bit of the input should completely and unpredictably change the output digest, with roughly half of the output bits flipping on average. Two near-identical inputs should never produce even remotely similar-looking hashes — this is the same underlying idea Chapter 5 introduced for AES's MixColumns step, now the defining property of an entire class of primitive.

MD5 — Broken

Designed in 1992 with a 128-bit output, MD5 was for years the internet's default hash function. Its 128-bit output already gives only ~2⁶⁴ collision resistance per the birthday paradox above — a real weak point even before anything else went wrong. In 2004, researchers (Wang et al.) demonstrated practical collision attacks, dramatically faster than the theoretical 2⁶⁴ figure, exploiting real structural weaknesses in MD5's design. The consequences were not theoretical: the 2012 Flame malware used a forged MD5 collision to fake a legitimate Microsoft code-signing certificate. MD5 is still sometimes used for non-security checksums (verifying a file wasn't corrupted in transit) but must never be used anywhere security depends on it.

SHA-1 — Also Broken

Designed in 1995 with a 160-bit output, SHA-1 became the internet's next default — used for years in TLS certificates, and still used today inside Git for commit hashing (a non-security use, more on that distinction shortly). In 2017, Google and CWI Amsterdam publicly demonstrated SHAttered, a practical SHA-1 collision, using an approach echoing MD5's own 2004 break. Browsers and certificate authorities deprecated SHA-1 for TLS certificates around the same time.

SHA-2 — The Current Workhorse

Published in 2001, SHA-2 is actually a family of functions — SHA-256, SHA-384, SHA-512, named for their output size in bits. Despite being designed by the NSA (a detail that draws periodic suspicion), SHA-2 has been public and openly scrutinized for over two decades, per Chapter 1's Kerckhoffs's Principle, with no practical attack ever found. It remains the dominant hash function in TLS, Bitcoin, and countless other systems today.

SHA-3 — A Structurally Different Backup

MD5, SHA-1, and SHA-2 all share the same underlying internal design, called the Merkle-Damgård construction. SHA-3, standardized by NIST in 2015 after another open public competition (again mirroring the AES competition from Chapter 5), uses a completely different internal design called the sponge construction, based on an algorithm called Keccak. SHA-3 isn't a replacement for SHA-2 — SHA-2 remains fully secure — it exists specifically as a structural hedge: if some future breakthrough attack targets a weakness shared by the Merkle-Damgård construction itself, SHA-3's genuinely different internals wouldn't be affected the same way.

What Hash Functions Are Actually Used For

• Integrity verification — confirming a downloaded file or received message wasn't altered, by comparing hashes.
• Digital signatures — signing algorithms (Chapter 10) actually sign a message's hash, not the raw message itself, since hashes are small and fixed-size regardless of the original message's length.
• Content addressing — Git identifies every commit by its hash; blockchain systems chain blocks together the same way.
• Password storage — with an important, easily-missed caveat below.

Hands-On Exercises

Chapter 7 introduced hash functions as tools for integrity checking — but a plain hash, sent alongside a message with no other protection, turns out to guarantee almost nothing on its own. This chapter covers the missing ingredient: binding an integrity check to a secret, so only someone who holds it can produce a valid one — and finally explains, properly, what GCM's authentication tag from Chapter 6 was actually doing the whole time.

Why a Plain Hash Isn't Enough

Imagine a sender transmits a message along with its SHA-256 hash, so the receiver can verify nothing was altered in transit. An attacker intercepting this in transit can simply:

1. Tamper with the message however they like.
2. Recompute the SHA-256 hash of their tampered message — this requires no secret at all, anyone can run SHA-256.
3. Forward the tampered message along with this newly-recomputed, perfectly valid hash.

The receiver checks the hash, finds it matches, and accepts the tampered message as genuine. The hash was never wrong — it correctly hashed the (tampered) message it was given. A plain hash verifies "this message wasn't altered after I computed this specific hash," which is completely useless against an attacker who can just recompute a fresh one.

MACs — Message Authentication Codes

A MAC is a hash-like function that also takes a secret key: MAC(key, message). Only someone who holds the key can produce a valid MAC for a given message. The sender computes the MAC and sends it alongside the message; the receiver, who also holds the key, recomputes the MAC independently and checks it matches.

This directly closes the gap from the previous section: an attacker who tampers with the message can no longer just recompute a matching value, because doing so requires the secret key they don't have. A mismatched MAC means either the message was altered, or it wasn't produced by someone holding the real key — either way, it's rejected.

HMAC — Hash-based MAC

Rather than design an entirely new primitive for MACs, HMAC is the standard way of building a MAC out of an existing hash function you already trust (Chapter 7's SHA-256, for instance). Conceptually:

The nested, double-hashing structure isn't decoration — it exists specifically to defend against a real weakness in naive approaches like simply computing Hash(key || message) directly. Some hash constructions (including the Merkle-Damgård structure behind SHA-1 and SHA-2, from Chapter 7) allow an attacker who knows a hash's output — without knowing the original input — to compute a valid hash for that input with extra data appended to it. This is called a length-extension attack, and it's a real, demonstrated weakness in the naive construction. HMAC's specific nested design was engineered to resist it.

Verifying a MAC — Constant-Time Comparison

Encrypt-then-MAC vs. MAC-then-Encrypt vs. Encrypt-and-MAC

Combining a cipher (Chapters 5-6) with a MAC can be done in three different orders, and the choice genuinely matters:

Encrypt-then-MAC's advantage is concrete, not theoretical: because the MAC covers the ciphertext, the receiver can verify it and reject a tampered message before ever decrypting attacker-controlled data. This is exactly the standard defense against Chapter 6's padding oracle attacks — if a tampered ciphertext is rejected by the MAC check first, the vulnerable padding-error behavior that a padding oracle attack depends on is never even reached.

AEAD — What GCM Was Actually Doing All Along

Chapter 6 introduced GCM as bundling confidentiality, integrity, and authenticity into one primitive, without fully explaining how. Now it can be stated precisely: GCM's authentication tag is built from GMAC, a MAC construction specialized for GCM's own CTR-mode-based encryption — and the overall structure of GCM is, in essence, encrypt-then-MAC baked directly into a single, efficient primitive, rather than two separate operations bolted together by hand. That's the real technical answer behind Chapter 6's "mode-of-operation-level" preview.

Associated Data — Authenticating Without Encrypting

Sometimes part of a message genuinely needs to stay readable — a network packet's routing header, say, needs to be visible before decryption can even happen — while still being protected from tampering. AEAD ciphers support this directly via associated data: extra data that's included in the authentication tag's computation (so tampering with it is detected) but is never encrypted at all. A network packet with an unencrypted header (needed for routing) and an encrypted payload, both covered by one authentication tag, is the textbook example.

Hands-On Exercises

Every cipher covered since Chapter 2 — including AES and every mode in Chapters 5-6 — is symmetric: the same secret has to reach both parties before anything can happen. Chapter 1 named this "the hard problem symmetric crypto never solved," and previewed asymmetric cryptography as the eventual answer. This chapter is that answer, in full.

The Problem Symmetric Crypto Never Solved

How do two parties who have never met establish a shared secret, over a channel an eavesdropper might be listening to the entire time? Historically, the only real answer was physical: couriers, sealed codebooks, or — as Chapter 3 covered directly — Enigma's own daily key settings, physically distributed on paper to every operator in advance. That approach doesn't scale to two strangers connecting over the open internet for the first time, which is exactly the situation every HTTPS connection (https1) faces constantly.

Trapdoor Functions — The Core Idea

Asymmetric cryptography is built on trapdoor functions: a function that's easy to compute in one direction, but computationally infeasible to reverse — unless you possess a specific secret piece of information (the "trapdoor") that makes reversal easy. The public key effectively is the function itself, fully public; the private key is the trapdoor.

RSA — Trapdoors from Prime Factorization

RSA's trapdoor is built from a genuinely simple asymmetry in difficulty: multiplying two large prime numbers together is fast and easy, but factoring that product back into its two original primes is computationally infeasible once the primes are large enough (2048+ bits in practice).

• Public key — the product of the two primes (the "modulus"), plus a public exponent.
• Private key — derived using the two original prime factors, which only the key's owner knows.

Encryption and decryption both use modular exponentiation against the modulus. Knowing the two original prime factors lets you efficiently compute the specific exponent needed to reverse the operation; without them, an attacker is left facing the same hard problem — factor an enormous number — that made RSA usable in the first place.

RSA in Practice — Key Sizes & Speed

2048-bit RSA keys are the accepted minimum today, with 3072 or 4096 bits used for higher security margins. RSA is computationally expensive compared to Chapter 5's symmetric ciphers — exactly why Chapter 1 flagged asymmetric crypto as "much slower, used sparingly." In practice, RSA is typically used only to encrypt or exchange a much shorter symmetric key, after which the actual bulk data is handled by fast AES or ChaCha20 (Chapters 5-6) — precisely what https1's TLS handshake does.

Diffie-Hellman Key Exchange — A Different Approach

Diffie-Hellman (DH), published in 1976, doesn't encrypt or decrypt anything at all. It lets two parties who have never met derive an identical shared secret over a public channel, even if an eavesdropper sees every single message exchanged between them.

The real mathematics uses modular exponentiation over a large prime, and the hard problem underneath is the discrete logarithm problem: given the public values exchanged, finding either party's private exponent is computationally infeasible for large enough numbers.

RSA vs. Diffie-Hellman — Different Jobs

RSA can both encrypt data directly and produce digital signatures (Chapter 10). Diffie-Hellman solves key exchange specifically — it never encrypts a message itself, only derives a shared secret both parties can then use with a symmetric cipher.

DH's major practical advantage is forward secrecy, when used with fresh, temporary ("ephemeral") values for every session — commonly written DHE. Even if a party's long-term private key is compromised at some later date, past session keys derived via ephemeral DH cannot be recovered from that long-term key alone, since the ephemeral values used to derive them were never transmitted anywhere and are discarded immediately after use.

Elliptic Curve Cryptography (ECC) — Smaller Keys, Same Security

ECC is built on a different hard problem entirely — the elliptic curve discrete logarithm problem — believed to be considerably harder, per key bit, than either RSA's factoring problem or plain Diffie-Hellman's discrete logarithm problem. The practical payoff is dramatic: a 256-bit ECC key offers roughly the same real-world security as a 3072-bit RSA key.

Why the gap is so large: no algorithm anywhere near as effective as the best known factoring or discrete-log algorithms has ever been found against elliptic curve math, so ECC needs far fewer bits to reach an equivalent difficulty level — smaller keys, faster computation, and less bandwidth and storage, all for the same practical security. ECDH is the elliptic-curve version of Diffie-Hellman; ECDSA, the elliptic-curve signing equivalent, is covered fully in Chapter 10.

Putting It Together — What TLS Actually Does

Now fully informed, https1's handshake can be stated precisely: modern TLS 1.3 uses ECDHE (ephemeral elliptic-curve Diffie-Hellman) for key exchange, giving every session forward secrecy by default, then immediately switches to a fast symmetric AEAD cipher — AES-GCM or ChaCha20-Poly1305 (Chapters 5, 6, and 8) — for all the actual bulk data. RSA's role in modern TLS has shifted almost entirely to signing the server's certificate (Chapter 10) rather than performing the key exchange itself.

Hands-On Exercises

Chapter 9 built RSA and ECC entirely around encryption — confidentiality. This chapter covers the reverse-direction use of the exact same key pairs: proving who produced a message and that it wasn't altered. By the end of this chapter, every one of Chapter 1's four goals will finally have a concrete mechanism behind it — and https1's certificate chapters can be revisited with full understanding of what's actually happening underneath.

Signing vs. Encrypting — Not the Same Operation

These two operations use the same key pair, but in opposite roles:

Notice the pattern flips entirely: encrypting is "anyone can lock it, only the owner can unlock it"; signing is "only the owner can produce it, anyone can check it." Same key pair, opposite direction of use.

How Signing Actually Works — Hash-Then-Sign

Chapter 7 mentioned that signing algorithms actually sign a message's hash, not the raw message — here's why, and exactly how it works:

1. The signer computes a cryptographic hash of the message (Chapter 7) — messages can be any length, but signing algorithms operate on fixed-size numeric inputs, so hashing first makes the input size uniform and small.
2. The signer applies their private key to that hash, producing the signature.
3. The signer sends the message plus the signature.
4. The recipient independently hashes the received message themselves.
5. The recipient uses the signer's public key to check whether the signature corresponds to that hash. If it matches, the signature is valid; if not, either the message was altered or the signature wasn't produced by the claimed signer's private key.

RSA Signatures vs. ECDSA vs. EdDSA

RSA can sign directly, using the same trapdoor idea from Chapter 9 run in the signing direction. ECDSA is the elliptic-curve signature algorithm — offering the same dramatically smaller key and signature sizes for equivalent security that Chapter 9 covered for ECDH, and it's now the dominant choice for new certificate issuance. EdDSA (commonly seen as Ed25519) is a newer, related alternative — faster, and critically, deterministic: it doesn't need a fresh random value for every signature the way ECDSA does.

What a Signature Actually Proves

Tying directly back to Chapter 1's four goals:

• Integrity — Chapter 7's avalanche effect means even a single altered bit of the message produces a completely different hash, which will no longer match the signature. Any tampering is detected.
• Authenticity — only someone holding the corresponding private key could have produced a signature that verifies successfully against a given public key.
• Non-repudiation — because only the private key holder could have produced it, they cannot credibly deny having signed it later, assuming their private key was never compromised.

The Trust Chain — From Signatures to Certificates

A signature alone only proves "produced by whoever holds this specific private key" — it says nothing about who that key actually belongs to in the real world. That's exactly the gap https1's certificate chapters (https1-4, https1-5) exist to close, and it can now be explained fully.

A Certificate Authority (CA) signs a certificate that binds a specific public key to a specific identity — a domain name, for instance — using exactly the hash-then-sign process described above, with the CA's own private key. Browsers and operating systems ship with a small, curated set of trusted root CA public keys built in. The full chain of trust is literally a chain of signatures: a root CA signs an intermediate CA's public key, and that intermediate CA signs the actual website's certificate — each link individually verifiable via the exact signature-verification process described earlier in this chapter, all the way back to a root key the browser already trusts.

Signatures Beyond TLS

Certificates are only one application. Code signing lets software be verified as genuinely coming from its claimed publisher, unaltered — which is exactly what Chapter 7's 2012 Flame malware defeated, by forging an MD5 collision specifically to produce a fraudulent, still-valid-looking Microsoft code signature. Software update mechanisms and package managers both rely on signature verification to ensure a downloaded update or package genuinely came from its claimed source. Git commit signing applies the same idea to source code history itself.

Hands-On Exercises

Every primitive this course has covered — AES (Ch.5), hashing (Ch.7), MACs (Ch.8), RSA/DH/ECC (Ch.9), signatures (Ch.10) — is only as strong as the keys behind it. This chapter is the full payoff of the throughline first named in Chapter 1 and demonstrated concretely in Chapter 4's Enigma breakdown: real cryptographic failures are almost always about key management, not the underlying mathematics.

Entropy — Where Keys Actually Come From

A cryptographic key needs to come from a source of genuine entropy — true unpredictability, not merely output that "looks random." A cryptographically secure pseudorandom number generator (CSPRNG), properly seeded from an operating system's real entropy sources (hardware noise, timing jitter, and similar unpredictable physical inputs), is the correct tool. A pseudorandom number generator built for simulations, games, or statistical sampling — even one that passes ordinary randomness tests — is a completely different, unsuitable tool: such generators are typically deterministic and predictable once their internal state or seed is known, which is exactly what a cryptographic attacker needs.

Key Storage — Where Keys Live Once Generated

Keys should never be committed directly into source code or version control — a rule this site's own pipelines1-5 states plainly: a committed credential is compromised forever, since version history retains it indefinitely even after deletion. Environment variables are a step up but still leave keys sitting in plaintext in process memory and configuration. The modern standard is a dedicated secrets manager (a cloud provider's KMS, or a tool like Vault) — purpose-built for storing, retrieving, and auditing access to sensitive key material, with the keys themselves encrypted at rest, echoing dbsec1-5's encryption-at-rest coverage applied specifically to key material rather than application data.

Hardware Security Modules (HSMs)

An HSM is a dedicated, tamper-resistant hardware device that generates and stores private keys such that they never leave the device in plaintext form at all. Rather than retrieving a key to use it elsewhere, cryptographic operations — signing, decryption — are performed inside the HSM itself; only the input and the result cross the boundary, never the raw key material. This is a categorically different security model from software-only storage: even a fully compromised host system, with complete access to its own memory and disk, still cannot extract the private key — it can only request operations using it, and only for as long as it retains legitimate access to do so. HSMs are standard for root CA private keys (Chapter 10), banking infrastructure, and as the backend for most cloud KMS offerings.

Key Rotation

Keys shouldn't live forever. Regular rotation limits the blast radius of an undetected compromise (an old, retired key is useless to an attacker even if it was silently stolen), reduces how much data any single key ever protects, and forces regular verification that key-management processes actually work end to end, rather than being untested until an emergency. Rotation is easy to state and genuinely hard to execute well — replacing a key used by many dependent systems or services requires careful coordination, echoing the real complexity behind TLS certificate revocation.

Key Derivation — One Master Key, Many Purposes

Rather than independently generating and managing a large number of separate keys, real systems often derive several purpose-specific keys from one master secret, using a key derivation function (KDF). HKDF, a standard example, is built internally using HMAC (Chapter 8) — a direct callback to the exact primitive that chapter established. This reduces how much raw entropy needs to be generated and carefully managed directly, while still keeping keys used for different purposes (encryption, authentication, and so on) cryptographically separated from one another.

The Human Side — Access Control & the Principle of Least Privilege

dbsec1-3's least-privilege account design applies directly to keys themselves — not every service or person needs access to every key a system uses. For especially high-value keys (a root CA key, for instance), real systems sometimes use dual control or split-knowledge schemes, requiring several independent custodians to jointly participate before a key can be used or reconstructed at all — the same principle underlying real root CA key ceremonies and much cryptocurrency custody today.

What Actually Breaks Key Management in Practice

Looking back across this entire course, nearly every "real-world" failure this course has covered was a key-management failure, not a mathematical one:

• Chapter 4 — Enigma's "cillies" (predictable settings) and message-key reuse.
• Chapter 5 — a reused stream-cipher key/nonce, reintroducing the two-time-pad vulnerability.
• Chapter 6 — a reused CBC initialization vector, leaking whether two messages start identically.
• Chapter 9 — a compromised static (non-ephemeral) private key retroactively exposing every past session that used it.
• Chapter 10 — Sony's 2010 ECDSA nonce reuse, directly leaking a signing private key.
• This chapter — the 2008 Debian OpenSSL entropy disaster, making entire classes of keys exhaustively guessable from the moment of generation.

Hands-On Exercises

The final chapter, in two parts: the post-quantum preview flagged back in Chapters 5 and 9, and a single worked scenario that combines every primitive this course has built, in the order a real system would actually use them.

Post-Quantum Cryptography — Preparing for Shor's Algorithm

Chapter 9 explained the asymmetry precisely: Shor's algorithm, on a sufficiently powerful quantum computer, breaks RSA, Diffie-Hellman, and ECC outright — not a manageable degradation like Grover's algorithm's effect on AES (Chapter 5), which can simply be countered with a larger key. Machines capable of running Shor's algorithm at the scale needed to threaten real-world key sizes don't exist yet — but "post-quantum cryptography" is the active, ongoing work of replacing this course's Chapter 9 algorithms with new ones built on entirely different hard math problems, believed resistant to both classical and quantum attack alike.

The leading approach is lattice-based cryptography. Mirroring Chapter 5's AES competition and Chapter 7's SHA-3 competition, NIST ran another open, public, multi-year competition (2016-2024) — a third demonstration of Chapter 1's Kerckhoffs's Principle at genuinely massive scale. The results, standardized in 2024: ML-KEM (formerly CRYSTALS-Kyber) for key exchange, and ML-DSA (formerly CRYSTALS-Dilithium) for signatures — direct post-quantum replacements for Chapter 9's Diffie-Hellman/ECDH and Chapter 10's RSA/ECDSA signatures respectively.

A Full Worked System — Securing a Message End to End

Alice needs to send Bob a message, securely and verifiably, over an untrusted network. Here's every chapter of this course, contributing one piece each, in order:

This is, in essence, exactly what a modern TLS 1.3 connection with client certificate authentication does — every step traceable to a specific chapter of this course, none of it magic.

What This Course Doesn't Cover

In the interest of an honest accounting, matching the precedent this site's ts5 course set for its own closing chapter: full protocol design (how TLS assembles these primitives into an actual wire protocol — that's https1's subject specifically), cryptocurrency-specific cryptography, zero-knowledge proofs, homomorphic encryption, and formal, mathematically rigorous security proofs are all real, substantial topics this course intentionally left out of scope. This course is the foundation those subjects build on, not a replacement for studying them directly.

This Course's Throughline, Restated One Last Time

Chapter 1 predicted it; Chapter 4 demonstrated it with Enigma. By this final chapter, the pattern has repeated six times across nearly a century of real cryptographic history:

Six case studies, from a 1930s rotor machine to 2010s consumer electronics to open-source infrastructure — every one a key-management or operational failure, never a mathematical one.

Where to Go From Here

This course is the foundation underneath several others already on this site: https1's entire handshake is now fully explainable, chapter by chapter, using nothing but this course's own primitives. bc1-2's password hashing is Chapter 7 and Chapter 11 applied specifically to authentication. dbsec1-5/dbsec1-6's encryption at rest and in transit are Chapter 5 and Chapter 6 applied specifically to databases. owasp1-2's entire "Cryptographic Failures" category can now be read with real technical grounding behind every item on the list, rather than as an abstract warning.

Hands-On Exercises