From Caesar Cipher to AES-256-GCM: A History of Encryption in One Tool

Guide · Last verified Aug 27, 2026

The text encryptor lets you try out four methods on the same screen: Caesar cipher, ROT13, Vigenere cipher, and AES-256-GCM. They aren't just four ciphers thrown together at random — that order is literally the 2,000-year path cryptography has walked, from simple shifts in ancient Rome to the modern web encryption standard. This guide uses the tool's actual code to trace why each stage exists to patch a weakness in the one before it.

1. Caesar cipher: the limits of a single shift

The Caesar cipher substitutes each letter by shifting the alphabet a fixed number of positions. It's named after Julius Caesar, who reportedly used a shift of 3 for military communications in ancient Rome. In the tool's code, the caesar(s,n) function adds the shift value to each letter's character code and takes the remainder mod 26 — a mod26 operation. The problem is that the shift can only be one of 1 through 25. With just 25 possibilities, an attacker who brute-forces all 25 shifts is guaranteed to find the plaintext. It can be cracked by hand, without a computer, in a few minutes.

2. ROT13: a special case of Caesar, and therefore weaker still

ROT13 is a Caesar cipher with the shift fixed at exactly 13. Since the alphabet has 26 letters, 13 is exactly half, giving it a symmetric property: applying the same transform twice returns the original text. Because of this, it isn't actually used for security — it's used for "deliberately easy to reverse" purposes like hiding spoilers or masking answers on internet forums. The tool's own help text says as much, describing ROT13 as "a simple text transform, not real encryption."

3. Vigenere cipher: introducing a key to defeat frequency analysis

The fundamental weakness of Caesar and ROT13 is that the shift is fixed, so frequency analysis of individual letters (for example, "E" is the most common letter in English) can reverse-engineer the shift. The Vigenere cipher, which emerged in the 16th century, patches this by repeating a keyword so a different shift applies to each letter. The tool's vigenere(s,key) function strips the key down to lowercase letters only, then cycles through the key one character at a time to pull a shift value for each input character. The longer and more random the key, the more secure it is — but classical attacks like the Kasiski examination, which finds the period at which the key repeats, already existed by the 19th century, which is why the tool itself warns that Vigenere "isn't suitable for real security."

4. AES-256-GCM: the current standard for symmetric encryption

From here on, we leave hand-solvable substitution ciphers behind for a modern block cipher where brute force is mathematically infeasible. This tool implements AES-256-GCM using the browser's built-in Web Crypto API, and the actual parameters, confirmed directly in the code, are as follows.

In the actual code, the key is derived with crypto.subtle.deriveKey({name:'PBKDF2',salt,iterations:100000,hash:'SHA-256'}, ...), a fresh salt (16 bytes) and IV (12 bytes) are pulled via crypto.getRandomValues() on every run, and the final output is assembled as base64(salt + iv + ciphertext). During decryption, that string is sliced back apart to extract the salt and IV, and the same key-derivation process runs in reverse.

5. Why does PBKDF2 iterate 100,000 times?

You can't use a password directly as an encryption key because human-chosen passwords are far more predictable than a truly random 256-bit key — an attacker can simply try a list of common passwords. PBKDF2 (Password-Based Key Derivation Function 2) deliberately repeats a hash operation tens or hundreds of thousands of times, artificially raising the computational cost of turning one password into a key. A legitimate user only pays that cost once, but an attacker has to pay it again for every one of the millions of candidate passwords they try, so the total brute-force time scales directly with the iteration count. The 100,000 iterations this tool uses is a common baseline in web encryption — a middle ground that adds no perceptible delay in the browser while meaningfully raising the cost of an offline brute-force attack.

6. Why generate a fresh salt and IV every time?

Without a salt, every user with the same password — or every message encrypted with the same password — would end up with the identical key. That lets an attacker precompute results for common passwords (a rainbow table) and attack many targets at once with a single table. Drawing the salt fresh and random on every encryption means the same password derives a different key each time, defeating that kind of precomputed attack. The IV (initialization vector) is regenerated for the same reason — reusing the same key and IV twice breaks the security guarantees of GCM mode — so this tool generates a fresh 12-byte IV on every encryption, ensuring the same plaintext and password never produce the same ciphertext twice.

FAQ