Cryptanalysis Methodology — classify the family before you reach for an attack

The root triage routine for any CTF crypto challenge: identify the cipher family from the challenge's own artifacts, then match each given parameter to the specific weakness it enables, before touching any heavy machinery. Start here whenever you have ciphertext, a challenge script (chall.py/server.py), or odd-looking numbers and no idea which page in this wiki to open next.

The signal that gives it away

There usually isn't one single signal — the routing is done by matching the *shape of the given artifacts* to a family, not by a single number the way a specific attack has a threshold. What you're looking for at this stage:

- What variables does the script/output actually hand you? n, e, c or a PEM block → RSA territory. p, g, g^x or "multiplicative group" language → discrete log. Curve parameters (a, b, p) plus points → elliptic curve. A matrix, a basis, or the phrase "short vector" → lattice. - **What does the ciphertext/plaintext *look* like before you've touched it? A short alphabet with a skewed letter histogram (mostly still readable structure, just shuffled) is the classical-cipher signal, not a modern-cipher one — don't spend time on frequency-analysis math against something that turns out to be base64. - What access do you have to the system, not just the output? A static blob of ciphertext is a very different problem from a live service that will encrypt/decrypt on demand (AES with chosen-ciphertext access) — the latter opens block-cipher-mode-specific oracles that a static ciphertext dump never will. - Is what you're looking at even encryption?** crc, checksum, or other polynomial bit-operations are not cryptography — treat them as a distinct, easier linear-algebra problem, not as a weak cipher.

The single biggest false signal: judging the plaintext space (letter frequency, printable-ASCII ratio, "does this look like English") *before* stripping encoding layers. Base64/hex/URL-encoded ciphertext looks statistically nothing like the plaintext underneath it and will send you down the wrong family entirely if you classify off it directly.

How it's exploited

Run this in order, every time, before opening any attack-specific page:

1. Decode layers first. Strip base64/hex/URL wrappers (and check for double-encoding) before judging what family you're looking at — see Encoding and Decoding Layers — peel base64/hex/URL/compression first or you attack the wrong plaintext. This step is cheap and skipping it is the single most common way to misclassify a challenge. 2. Classify the family by artifacts. This is a lookup, not a guess: - n, e, c or PEM keys → RSA Fundamentals — the routing hub: which artifact points to which attack; specific weakness hints (small e, close primes, tiny d, a leaked bit range) route further via Integer Factorization Methodology — which factoring attack to try, in what order or straight to the matching named attack. - p, g, g^x or an explicit multiplicative group → Discrete Logarithm — the factorization of the group order picks your algorithm. - Curve parameters (a, b, p) plus one or more points → Elliptic Curve Fundamentals — the audit that routes to the right ECC attack. - Short alphabet, letter-histogram skew, structure that survives the "shuffle" → Substitution & Shift Cipher — recovered by letter-frequency, not by algebra and the rest of the classical family. - AES (or another block cipher) with live chosen-ciphertext or chosen-plaintext access to an oracle → Block Cipher Modes of Operation — the mode carries the CTF vulnerability, not the primitive — the *mode*, not the primitive, is almost always where the CTF bug lives. - Matrices, bases, or an explicit "find the short vector" framing → Lattice Fundamentals — encoding a bounded unknown as a short vector. - crc or other polynomial bit-ops → CRC and Polynomial Recovery — forging or reversing a checksum built from GF(2) division (linear over GF(2), not a cipher at all). 3. Match each weakness to the attack it enables. Once the family is fixed, map every parameter the challenge *chose to give you* to what it unlocks: a repeated nonce, a shared/reused modulus, a partial key leak, an oracle that answers a yes/no question. A challenge author who hands you an unusual parameter almost always did it on purpose — treat every given value as a clue, not as flavor text. 4. Reduce, then solve. Convert the specific challenge into a known hard-or-easy problem — factoring, DLP, a linear system, a lattice short-vector problem — and reach for the standard tool for *that* reduced problem, not a bespoke one. Practically: write down the equations that relate the unknowns you want to the values you were given, then count constraints against unknowns. If you have as many independent equations as unknowns (or more), it's a solvable linear/algebraic system before it's anything else — try CRT, straight linear algebra (including over GF(2), see Linear Algebra over GF(2) — solving bit-level unknowns as a linear system mod 2), or lattice reduction (Lattice Fundamentals — encoding a bounded unknown as a short vector, LLL Reduction — the polynomial-time workhorse behind almost every lattice attack) depending on the shape of the constraint, rather than reaching for a named attack you half-remember by pattern-matching the challenge title.

What does NOT work

- Guessing the primitive from vibes. Picking an attack because the challenge *category* says "crypto" or because the ciphertext "looks like" something you've broken before, without first checking which concrete artifacts you were actually given. The structure and the given parameters should drive the choice every time — if you can't point to the specific n, e, c (or curve params, or group order) that justifies the family you picked, you haven't classified it yet, you've guessed. - Classifying plaintext space before decoding. Running frequency analysis, printable-ratio checks, or "does this look like flag format" heuristics against ciphertext that's still wrapped in base64/hex. It will not resemble English (or any plaintext) at that layer, and the false negative sends people hunting for exotic ciphers when the actual cipher is trivial once decoded. - Reaching for a named heavy-machinery attack before the reduction step. Jumping straight to lattice reduction, Coppersmith, or index calculus because the numbers are "big" without first writing out what's actually unknown and what's actually given. Most challenges that look intimidating collapse to a small, well-known reduced problem once you count equations vs. unknowns — the heavy tool is usually applied to that reduced problem, not to the raw challenge statement. - Treating this page as an attack in itself. It routes; it doesn't exploit anything on its own. If you find yourself trying to apply "the methodology" directly to a challenge instead of landing on one of the family/attack pages it points to, you've stalled at triage — the goal is always to leave this page for a more specific one.

Related

Encoding and Decoding Layers — peel base64/hex/URL/compression first or you attack the wrong plaintext RSA Fundamentals — the routing hub: which artifact points to which attack Integer Factorization Methodology — which factoring attack to try, in what order Discrete Logarithm — the factorization of the group order picks your algorithm Elliptic Curve Fundamentals — the audit that routes to the right ECC attack Substitution & Shift Cipher — recovered by letter-frequency, not by algebra Block Cipher Modes of Operation — the mode carries the CTF vulnerability, not the primitive Lattice Fundamentals — encoding a bounded unknown as a short vector LLL Reduction — the polynomial-time workhorse behind almost every lattice attack CRC and Polynomial Recovery — forging or reversing a checksum built from GF(2) division Linear Algebra over GF(2) — solving bit-level unknowns as a linear system mod 2 Custom Cipher Reverse — read the source, invert every primitive, run the pipeline backwards Multi-Step Crypto Chain — recognizing and decomposing a pipeline challenge