Maths for cryptography, the honest version

Cryptography has a reputation as the most maths-heavy corner of computing. It deserves about a quarter of that reputation. The deep stuff — formal proofs, lattice theory, advanced number theory — sits at the research frontier, and most working developers never need to touch it. The maths you genuinely need to use cryptography correctly in real systems is far smaller and far more boring than the reputation suggests.

This post is the honest version. What you actually need, what you can skip, and the four places the maths shows up in practice.

What you actually need

Modular arithmetic, fluently

If you can compute 17 mod 5 (it's 2), and you can solve 3x ≡ 1 (mod 7) with a bit of thought (x = 5, because 15 mod 7 = 1), you're nine-tenths of the way there. The modular arithmetic that matters is:

• Addition, subtraction, multiplication mod n behave the way you expect.
• Division mod n means multiplying by the modular inverse, which exists iff gcd is 1.
• Exponentiation mod n is computable in O(log e) operations via square-and-multiply.

Practise this until it stops feeling exotic. RSA, Diffie-Hellman, and large parts of elliptic-curve crypto are modular arithmetic at a scale your laptop handles in microseconds. The intimidation factor disappears once you've worked through ten exercises by hand.

Group theory at intuition level

A group is a set with an operation that is associative, has an identity, and gives every element an inverse. That's it. You don't need to prove theorems about cosets. You need to internalise three facts:

1. The integers mod n under addition form a group.
2. The non-zero integers mod p (for prime p) under multiplication form a group.
3. The points on an elliptic curve form a group under a geometric "addition" rule.

Once you see groups as the structure that makes "raise to a power" and "find a discrete log" meaningful, half the cryptographic literature reads like ordinary engineering.

The order of a group element — how many times you apply the operation before getting back to the identity — is the single concept that powers Lagrange's theorem, Fermat's little theorem, and most of asymmetric crypto's security argument. Spend an afternoon on it.

Finite fields, definitionally

You don't need to construct GF(2^8) from scratch. You need to know that a finite field is a set on which you can add, subtract, multiply, and divide (except by zero) and stay within the set. The two flavours that show up are GF(p) for a prime p (which is just integers mod p) and GF(p^k) for a prime power (which is built differently — polynomials mod an irreducible polynomial).

AES uses GF(2^8). Elliptic curves are defined over GF(p) or GF(2^k). Pairing-based crypto piles up extension fields. For most purposes the right level of understanding is "I know what field this curve is over, I know that field elements have a fixed bit-width, and I know multiplication is constant-time on good implementations."

What you can skip

The list of things people assume you need but don't, unless you're going into research:

• Number-theoretic proofs. You can use RSA without proving the security reduction to integer factorisation.
• Lattice mathematics. Important if you work on post-quantum crypto, totally skippable otherwise.
• Algebraic geometry. The deep theory behind elliptic curves and pairings is a research field. Using a curve safely needs a fraction of a percent of it.
• Formal proofs in a proof assistant. Beautiful work, irrelevant to writing or reviewing application crypto.
• Information theory beyond the definition of entropy. You need to know that a 128-bit key has 128 bits of entropy when generated correctly. You do not need to read Shannon's 1948 paper.

If you do go into research, all of these become essential. Most people don't, and the literature pretending otherwise is the source of a lot of unnecessary intimidation.

Where the maths shows up in practice

Concrete cases where the maths I described actually matters in a security or systems context.

Reading a TLS handshake

When you trace a TLS 1.3 handshake, you'll see the client and server exchanging X25519 public keys (each is a 256-bit number) and computing a shared secret via scalar multiplication on Curve25519. The maths you need to understand what's happening: enough finite-field intuition to know that the points live in GF(2^255 - 19), enough group theory to know that "scalar multiplication" means adding a point to itself k times, and enough modular arithmetic to know why the result is constant-size. That's it. You don't need to be able to derive the curve equation.

Choosing key sizes

When someone tells you "AES-128 is fine, RSA-2048 is borderline, ECC-256 is comparable to RSA-3072", that comparison comes from the asymptotic complexity of the best known attacks: brute force for AES, the general number field sieve for RSA, Pollard's rho for ECC. You don't need to be able to derive those complexities. You need to know they exist, what their inputs are, and where to look up the current recommended sizes.

Hashing and birthday bounds

If a 256-bit hash function gives 128 bits of collision resistance (because of the birthday paradox), and 256 bits of preimage resistance, you need just enough probability to understand why. Specifically: with N possible outputs, you expect a collision after about √N samples. That's the entire derivation. It tells you why SHA-256 is a sensible default for content-addressed storage but why you'd want SHA-512 or BLAKE3 if you need the larger collision-resistance budget.

Reading a paper claiming a break

Cryptographic breaks get announced regularly. The vast majority don't matter for production systems — they're improvements in attack complexity from "infeasible" to "slightly less infeasible". Reading the abstract and skimming for the new attack complexity is enough to know whether to act. You need to recognise terms like "advantage", "negligible function", "indistinguishability" well enough to spot when a paper is claiming a real-world break versus a theoretical advance. That's a vocabulary gap, not a mathematical one.

A slightly contrarian take

The honest answer is that the maths reputation of cryptography is mostly defended by people who already have the maths and find it satisfying. The actual barrier to using cryptography correctly in production is engineering, not mathematics — choosing the right primitive, parameterising it correctly, avoiding side channels, getting key management right. None of that is mathematical.

You can be a competent applied cryptographer with about three weekends of maths and a healthy fear of rolling your own primitives. If someone tells you otherwise, ask them to point at the specific theorem they think you need.

Where this fits in

The Networking & Cryptography track covers the engineering side at the depth where it actually matters — protocol design, key exchange, authenticated encryption, what goes wrong in real deployments — with just enough maths to keep the explanations honest.