Substitution & Shift Cipher — recovered by letter-frequency, not by algebra

Every plaintext symbol is replaced by a fixed substitute (a permutation of the alphabet, or the special case of a constant/incrementing shift) — and because the mapping never changes mid-message, the ciphertext's letter-frequency histogram is just a relabeled copy of the plaintext language's, which is what breaks it every time.

The signal that betrays it

- Ciphertext is still letters (or a fixed small alphabet), same length as plaintext, one-to-one with the input — no block structure, no obvious modular-exponentiation or XOR math anywhere in the challenge. That "it's still recognizably alphabetic" look is itself the tell: nothing but a relabeling happened. - Doing a straight letter-count histogram on the ciphertext produces a distribution shaped like the target language's (a tall spike, a small cluster of mid-frequency letters, a long tail of rare ones) just shuffled to different labels — that's the confirmation, not just the suspicion. - Two sub-cases share this signal but are told apart by the size of the key: - Shift cipher (Caesar-style): the whole alphabet is rotated by one constant — every ciphertext letter is plain + k mod 26 for the *same* k. Signal: the *shape* of the frequency histogram, not just its peak, matches English almost exactly, only rotated — i.e. the gaps between the frequent letters and the rare ones line up if you slide the alphabet. - General substitution: an arbitrary permutation of the 26 letters, no algebraic relationship between plaintext and ciphertext letter position. Signal: the histogram shape matches English in aggregate (same peak/valley pattern of frequencies) but the *specific* letters occupying each frequency rank are unrelated to a simple offset — sliding the alphabet doesn't align it. - Watch for a positional/incrementing shift variant: the offset itself changes by a fixed increment as you move through the message (letter 1 shifted by k, letter 2 by k+1, letter 3 by k+2, ...) instead of staying constant. This is sometimes called a progressive or "rolling" Caesar cipher. The signal is that plain frequency analysis on the *whole* ciphertext looks flatter/noisier than a real single-shift Caesar would (each position effectively uses a different alphabet), but the structure is still just two small integers (start offset, increment) — not a full permutation — so it stays in scope for brute force, not full substitution cryptanalysis.

How it's exploited

Shift cipher — brute force is always viable first. There are only 25 meaningful keys (offsets 1–25; shift 0 is excluded — it leaves the plaintext unchanged, so it's never the encryption key in practice). Decrypt under each of the 25 non-zero offsets and score the result; the correct one is the only one that reads as language (or contains the expected crib/flag shape). This is cheap enough that it's worth trying *before* frequency analysis even for a constant-shift cipher — frequency analysis is a fallback/confirmation, not a prerequisite, when the keyspace is this small.

Shift cipher — frequency analysis as a shortcut or cross-check. Take the single most frequent letter in the ciphertext, assume it maps to 'E' (or 'T' as the runner-up check if 'E' doesn't produce sense), and the offset falls out directly: k = ciphertext_peak_letter - 'E' mod 26. Useful when you want to skip trying all 25 by hand, but on a computer the brute force above is simpler to implement and just as fast, so treat this as the manual/no-tool technique.

General substitution — recover the mapping via frequency analysis + structure, not brute force. The keyspace (26! arrangements) is far too large for exhaustive search, so the real recovery process is: 1. Rank ciphertext letters by frequency and provisionally align them to the expected English rank order (E, T, A, O, I, N, S, H, R, D, L, U, ...). This gets several letters right immediately but rarely all of them — the middle-frequency letters are genuinely ambiguous from counts alone. 2. Use structural cues to disambiguate and correct the provisional mapping: single-letter words are almost always 'a' or 'I'; the most common bigrams/trigrams (TH, HE, AN, ER / THE, AND, ING); doubled letters in ciphertext (likely 'LL', 'SS', 'EE', 'OO' in plaintext); a ciphertext letter that never appears next to itself or in common digraphs is a signal it's a rare plaintext letter (Q, X, Z, J). 3. Iterate: substitute the confident letters into the full ciphertext, read the partially-decrypted text, and let emerging word fragments suggest the next few letters (classic crib-and-refine loop) until the whole permutation is recovered. 4. If doing this by hand doesn't converge fast enough, an automated hill-climbing/simulated-annealing search that swaps pairs of key letters and scores each candidate key by a quadgram (4-letter sequence) log-probability fitness function converges reliably on the full 26-letter key from ciphertext alone, without needing any known-plaintext crib — this is what tools like quipqiup-style solvers do under the hood, and it's the right tool to reach for once manual crib-and-refine stalls.

Positional/incrementing shift — brute force the two integers. Search over plausible (start offset, increment) pairs — typically small integers, so this is a tiny nested loop, not a real search problem — decrypting and scoring each candidate the same way as the constant-shift case. Don't try to run plain single-shift frequency analysis on this variant; see below.

What does NOT work

- Running standard single-peak frequency analysis (assume ciphertext-peak = 'E') on a general substitution cipher. It only reliably recovers the shift *constant* when there's one global constant to find. Against an arbitrary permutation it will misidentify letters whose true frequency rank doesn't match their intuitive guess (frequency ties and near-ties between mid-table letters are common) — frequency ranking is a *starting point* to seed the permutation, not a closed-form solution the way it is for a shift cipher. - Running plain single-shift frequency analysis (or the 25-key brute force) against the incrementing/positional-offset variant. Because the effective shift changes every letter, the aggregate ciphertext histogram doesn't cleanly reproduce a rotated English distribution the way constant-shift ciphertext does — the "find the peak, subtract 'E'" trick and the flat 25-way brute force both fail (or produce a text that's only locally readable near the correct starting offset before drifting into garbage). Recognize the incrementing structure first and brute-force the (start, increment) pair instead. - Treating a small-alphabet or non-English-looking ciphertext as "must be something more exotic." If it's still one-to-one, fixed-length, letter-for-letter, it's still in scope for frequency analysis regardless of surface appearance (numbers-as-letters, non-Latin alphabet, etc.) — swap in that language/alphabet's known frequency table rather than assuming the classical approach doesn't apply. - Skipping straight to full permutation search/brute force for general substitution. 26! keys is computationally hopeless by exhaustive search; the technique that works is the frequency-plus-structure-plus-iteration approach (or automated hill-climbing) above, never brute force.

Related: frequency-analysis Affine Cipher — a tiny 312-key space that known-plaintext or brute force both break instantly Vigenere Cipher — Kasiski / Index-of-Coincidence Key-Length Recovery Permutation Cipher — frequencies survive intact, only position is scrambled Cryptanalysis Methodology — classify the family before you reach for an attack