The Cipher Bureau: An Interactive Field Guide to Cryptography

Exhibit 01 // Rome, c. 58 BC // Classical

The Caesar Cipher: Shift the Alphabet

Julius Caesar protected military orders by replacing each letter with the letter a fixed number of positions further along the alphabet. A shift of 3 turns A into D, B into E, and so on. To read the message, the recipient simply shifts back.

The "key" here is just the shift amount: a single number between 1 and 25. Keep that in mind, because it is exactly what breaks this cipher.

Field Equipment: Cipher Wheel

Outer ring: plaintext letters. Inner ring: what each becomes. Drag the slider and watch the inner ring rotate.

Shift (the key)

3

Your message Encrypted output

Analyst note Formally: C = (P + k) mod 26 for each letter P with key k. The keyspace has only 25 usable keys, so an attacker can exhaustively test every one in less time than it took to read this sentence. This is the core lesson of key length: security should rest on the size of the keyspace, not the secrecy of the method. That principle, attributed to Auguste Kerckhoffs in 1883, still governs modern cipher design.

Exhibit 02 // Baghdad, 9th century // Classical

Substitution Ciphers and the First Codebreakers

An obvious upgrade: instead of shifting the alphabet, scramble it completely. Map each letter to any other letter. Now there are about 403,000,000,000,000,000,000,000,000 possible keys (26 factorial). Surely unbreakable?

The Arab scholar Al-Kindi showed otherwise. Languages have fingerprints: in English, E appears far more often than any other letter, followed by T, A, O. Count the letters in the ciphertext, and the disguise slips. This is frequency analysis, and it is why a huge keyspace alone is not enough.

Field Equipment: Scrambled Alphabet + Frequency Counter

Your message (longer text shows the fingerprint better)

Encrypted output

Letter frequencies: ciphertext (red) vs typical English (blue)

Your ciphertextTypical English

Notice the tallest red bar. Whatever letter it is, it is almost certainly playing the role of E. Pull that thread and the whole cipher unravels, one letter at a time.

Analyst note Frequency analysis works because simple substitution preserves the statistical structure of the plaintext: it is a bijection on the alphabet applied uniformly. Later designs fought back with polyalphabetic ciphers (Vigenere, and eventually the Enigma machine), which change the mapping as the message progresses, flattening the frequency profile. Those fell too, to deeper statistics and to machines. The lasting lesson: good encryption must make ciphertext statistically indistinguishable from random noise.

Exhibit 03 // Present day // Modern symmetric

Symmetric Encryption: One Shared Key

Modern symmetric ciphers like AES are the industrial descendants of everything above. Same core idea: one secret key both locks and unlocks the message. The difference is that AES operates on bits rather than letters, mixes them through many rounds, and its output is statistically indistinguishable from random noise. No frequency fingerprint survives.

Symmetric encryption is fast, which is why it protects data at rest (full-disk encryption, encrypted databases) and data in bulk. Its weakness is not the math. It is logistics: both parties must already share the key. How do you deliver a secret key over an insecure channel? Hold that thought for Exhibit 04.

Field Equipment: Real AES-256-GCM (runs in your browser)

Shared passphrase (the key is derived from this) Message

Ciphertext (Base64)

Press Encrypt. Then try changing one character of the passphrase and decrypting: it will fail completely, not partially.

Analyst note This demo derives a 256-bit key from your passphrase using PBKDF2 (SHA-256, 100,000 iterations, random salt), then encrypts with AES in GCM mode using a fresh random 96-bit IV per message. The salt and IV are prepended to the ciphertext, which is fine: they are not secrets, they exist to guarantee the same message never encrypts the same way twice. GCM is an authenticated mode, so tampering with even one bit of the ciphertext makes decryption fail outright rather than producing garbled plaintext. In practice: never invent your own construction; use a vetted authenticated mode like AES-GCM or ChaCha20-Poly1305.

Exhibit 04 // 1976 onward // Modern asymmetric

Asymmetric Encryption: The Key Distribution Problem, Solved

The breakthrough of the 1970s: use two mathematically linked keys instead of one. The public key can be shouted from the rooftops; anyone can use it to encrypt a message to you. Only the matching private key, which never leaves your possession, can decrypt it. Flip the direction and you get digital signatures: sign with your private key, and anyone can verify with your public one.

Symmetric

One shared key locks and unlocks. Fast. Great for bulk data. Problem: securely sharing the key in the first place.

Asymmetric

Public key encrypts, private key decrypts. Slow, but nothing secret ever needs to travel. Great for key exchange and signatures.

In the real world the two are combined: your browser uses asymmetric cryptography for a few milliseconds to agree on a fresh symmetric key, then AES does the heavy lifting for the rest of the session. That handshake is the "S" in HTTPS.

Field Equipment: Toy RSA (deliberately tiny numbers)

Real RSA uses primes hundreds of digits long. This toy version uses tiny ones so you can watch the machinery. It encrypts each character separately, which real RSA never does, but the math is genuine.

p = 61 q = 53 n = p×q = 3233 (public) e = 17 (public) d = 2753 (private)

Message

Character-by-character trace

Press Encrypt to watch each character become a number, get raised to the 17th power mod 3233, and come back out again.

Analyst note Encryption: c = m^e mod n. Decryption: m = c^d mod n, where d is chosen so that e×d ≡ 1 mod φ(n), and φ(n) = (p-1)(q-1) = 3120. The security rests on one asymmetry of effort: multiplying p and q is instant, but recovering them from n (factoring) is computationally infeasible at real key sizes (2048+ bits). Anyone who factors n can compute d and read everything. This is also why quantum computing matters to cryptographers: Shor's algorithm factors efficiently, which is driving the current migration to post-quantum algorithms such as ML-KEM.

Exhibit 05 // Present day // Integrity

Hashing: A Fingerprint, Not a Lockbox

Here is the most common confusion in the field, so read this twice: hashing is not encryption. Encryption is reversible by design; whoever holds the key gets the message back. A hash function is a one-way meat grinder. It takes input of any size and produces a fixed-length fingerprint, and there is no key and no way back.

That one-way property is exactly what you want for storing passwords (the site checks your fingerprint without ever storing the password itself), verifying downloads have not been tampered with, and detecting whether any file has changed.

Field Equipment: SHA-256 + The Avalanche Effect

Input A

Input B (change just one character) SHA-256 of B, differences from A marked in orange

Fixed length: always 256 bits One-way: no key, no reversal Deterministic: same in, same out Avalanche: tiny change, total change

Analyst note: password storage done properly Plain SHA-256 is too fast for passwords: an attacker with a stolen database can test billions of guesses per second against it. Real systems add a unique random salt per user (so identical passwords hash differently and precomputed rainbow tables are useless) and use a deliberately slow, memory-hard function such as Argon2, bcrypt, or scrypt. Try it below: the same password with two different salts.

Password

Exhibit 06 // Field manual // Choosing the tool

Which Tool for the Job?

The question is never "which is strongest?" but "what property do I need?" Do you need the data back later? Then you need encryption, and a key. Do you only need to verify or compare? Then you need a hash, and storing a key would be a liability.

Situation	Tool	Why
Storing user passwords	Hash (salted, slow: Argon2/bcrypt)	You never need the password back, only to check a match. If breached, no key exists to leak.
Encrypting a laptop drive	Symmetric (AES)	Bulk data, one owner, speed matters. The key stays with the owner.
Sending your credit card to a website	Asymmetric handshake, then symmetric session	No pre-shared key exists between you and the site. TLS uses public-key crypto to agree on an AES key, then AES takes over.
Verifying a downloaded file is intact	Hash (SHA-256)	Compare fingerprints. Any tampering changes the hash completely.
Proving an email really came from you	Digital signature (asymmetric)	Sign with your private key; anyone verifies with your public key. Confidentiality is not the goal, authenticity is.
Encrypting a database of customer records	Symmetric (AES), keys in a key management system	Large volumes, frequent access: symmetric speed, with careful key handling.

Field Qualification: Six Scenarios