Why do we need two groups that "look the same"? Why specifically cubic curves? And how many points does an elliptic curve actually have? This week connected the algebra to the cryptography.
João opened this session by stepping back from the formulas to motivate why we're studying elliptic curves at all. The answer comes down to a single idea: we need two groups that behave identically, but where going from one to the other is easy in one direction and hard in reverse.
On the left, we have a familiar group: numbers. ℤp — integers {0, 1, 2, ..., p−1} with addition mod p. We know how to add numbers. Simple.
On the right, we want a group of objects — something that isn't numbers — where every operation in the number group has an exact counterpart. If 5 + 4 ≡ 2 (mod 7) on the left, then the objects labeled 5G and 4G must combine to give the object labeled 2G on the right. Same structure, different elements.
The goal: Find a group of non-number objects that mirrors the number group perfectly — same operation table, same structure — but where the mapping from numbers to objects is easy and the reverse mapping is hard. That's the foundation of all public-key cryptography.
João introduced this with a beautiful example. Take ℤ6 — the numbers {0, 1, 2, 3, 4, 5} with addition mod 6. Now consider a completely different group: rotations of a circle in 60° increments.
Let's test it. In the number group: 4 + 3 = 7 ≡ 1 (mod 6). In the rotation group: 240° composed with 180° = 420° ≡ 60°. And 60° corresponds to 1. It works.
João built the full operation tables for both groups to make this undeniable. Here's a smaller example with ℤ3 and rotations by 120°:
| + | 0 | 1 | 2 |
|---|---|---|---|
| 0 | 0 | 1 | 2 |
| 1 | 1 | 2 | 0 |
| 2 | 2 | 0 | 1 |
| ∘ | 0° | 120° | 240° |
|---|---|---|---|
| 0° | 0° | 120° | 240° |
| 120° | 120° | 240° | 0° |
| 240° | 240° | 0° | 120° |
The two tables are structurally identical. Replace 0 with 0°, 1 with 120°, 2 with 240°, and the left table becomes the right table. Same structure, different labels. This is called an isomorphism — a bijective mapping between two groups that preserves the operation.
João's definition, distilled: Two groups are isomorphic when they have the same operation table — just with different labels for the elements. Every operation you can do in one group has an exact mirror in the other.
So we have two isomorphic groups — numbers and rotations. Can we use rotations to hide numbers?
Suppose I want to prove I know two numbers that add to 3 (mod 6), without revealing which numbers. Instead of sending the numbers (say, 1 and 2), I send their rotation equivalents: 60° and 120°. The verifier composes them: 60° + 120° = 180°. They check: does 180° correspond to 3? Yes. Proof accepted.
But there's a fatal problem.
The verifier can reverse the mapping trivially. If I give you 60°, you immediately know it's 1 (just divide by 60). The mapping number → rotation is easy, but rotation → number is equally easy. There's no trapdoor. The "hiding" is an illusion — the verifier sees right through it.
For cryptography, we need a mapping where going from number to object is easy, but going from object back to number is computationally infeasible. Rotations fail this requirement. Elliptic curve points satisfy it — that's why we use them.
João stepped back to frame the bigger picture. Modern cryptography uses two fundamental types:
In practice, both are used together. You use public-key crypto (the slow one) to securely exchange a shared key, then switch to symmetric crypto (the fast one) to encrypt the actual data. This is how TLS/SSL works — every HTTPS connection you make does this handshake.
Public-key crypto is based on hard problems. João outlined three of them, in increasing order of hardness:
Elliptic curves give us the hardest problem with the smallest keys. That's the practical reason they dominate modern cryptography. Not because they're proven unbreakable — because nobody has found an efficient way to break them.
In Week 4, João stated that elliptic curves (cubic) have a special property: a line through two points on the curve always hits a third point. This week, he proved why this only works for cubics.
The proof is elegant. Take the curve y² = x³ + ax + b and any non-vertical line y = mx + k. To find where they intersect, substitute the line equation into the curve equation:
A cubic equation always has exactly 3 roots (in the complex numbers). But roots come in two flavors: real and imaginary. The key insight is that imaginary roots always come in conjugate pairs — you can't have just one imaginary root. So the possibilities are:
When we draw a line through two known points on the curve, we already know two of the three roots (x₁ and x₂). Since those are real, the third root must also be real (can't have 1 imaginary root alone). So the line must hit a third point. Guaranteed.
What about tangent lines? When a line is tangent at a point, that point counts as a "double root" (multiplicity 2) — it's like two roots that happen to coincide. So tangent at point A gives roots {x₁, x₁, x₃} — still three roots, still guaranteed to hit one more point.
Why quadratic curves (circles, ellipses) don't work: Substituting a line into a degree-2 curve gives a quadratic equation — only 2 roots. A line through two points on a circle gives two intersections, period. No third point. No natural binary operation. No group.
Why quartic or higher don't work: A degree-4 curve would give 4 roots from a line intersection. You could get 2 or 4 real intersections — and a line through 2 known points might hit 0 or 2 more, with no guarantee of exactly 1 more. The "input two points, get exactly one output" structure is lost.
Cubic is the sweet spot: Exactly 3 roots means a line through 2 known points gives exactly 1 new point. That's a binary operation. That's a group.
Brandon connected this beautifully: "So it's these properties that allow us to satisfy all the properties of a group." Exactly. Cubics are special not because someone decided they should be — but because the root structure of degree-3 polynomials is the only one that naturally produces a well-defined binary operation on curve points.
João addressed one detail from the proof. The analysis above assumes a non-vertical line (y = mx + k). Vertical lines (x = constant) don't fit this form — their slope is infinite.
For a vertical line, you substitute a constant x into y² = x³ + ax + b, giving y² = C for some constant. This is a quadratic equation in y, not cubic. So the possibilities are:
Vertical lines give 0 or 2 intersections, not 3. That's why we handle them separately in the group definition — Rule 3 from Week 4 says "if the line is vertical, the result is the point at infinity." The point at infinity patches the one case where the cubic property doesn't apply.
Once you know why a third intersection exists, how do you actually find it? João showed the technique using Vieta's formulas — a classic result that relates the roots of a polynomial to its coefficients.
For a cubic equation x³ + cx² + ... = 0 with roots x₁, x₂, x₃, Vieta's formulas say:
This is exactly the point addition formula from Week 4. Vieta's formulas give a shortcut: instead of solving a full cubic equation, you use the relationship between roots and coefficients to jump straight to x₃. Since you already know two of the three roots, you only need one subtraction.
Brandon's observation: "Vieta's formulas work for nth-degree polynomials generally. But does it still work when the original equation is y² = x³... not y = x³...?" Yes — because you substitute the line equation to eliminate y, reducing everything to a single polynomial in x. The substitution is what converts the system into a standard polynomial that Vieta's applies to.
Over the reals, an elliptic curve has infinitely many points. Over a finite field 𝔽p, the curve has a finite number of points — but how many?
João walked through the counting argument. For each x value in {0, 1, ..., p−1}, you compute the right side of y² = x³ + ax + b. Call it C. Then you ask: is C a quadratic residue mod p? (i.e., does some y exist where y² ≡ C?)
This isn't exact — the actual count fluctuates around p + 1. But the order of magnitude is always close to p. A curve over 𝔽13 has roughly 13–14 points. A curve over 𝔽101 has roughly 100 points. A curve over a 256-bit prime has roughly 2256 points.
This gives us two important numbers for any elliptic curve over a finite field:
Why both numbers matter: The characteristic p determines what field the coordinates live in (all arithmetic is mod p). The order n determines the size of the cyclic group — which is the number of possible private keys, the number of distinct points the generator can reach, and the security parameter of the system. They're approximately equal but not identical, and both are critical for the math to work.
João previewed the next major topic: cyclic groups. An elliptic curve group is always cyclic (or contains a large cyclic subgroup), which means there exists a generator G where repeated addition hits every point:
A student asked: "What happens when you hit the point at infinity? Can you not generate anymore?" João clarified: the point at infinity is where the cycle completes. After nG = 𝒪, the next addition (n+1)G = 𝒪 + G = G — you're back at the start. You can keep going forever; you just loop. And the sequence 1G, 2G, ..., nG covers every point exactly once before cycling.
Not all groups are cyclic. But for elliptic curve cryptography, we specifically choose curves that produce cyclic groups (or we work within a cyclic subgroup). Cyclic is important because it gives us the clean number-to-point mapping we need for the discrete log problem.
Brandon asked about curve selection: "Are there standard elliptic curves? Is it hard to pick a good one?"
Yes, there are standards. The most well-known:
The mention of pairings was a preview. Not all curves support pairings — a special bilinear map between groups that enables SNARKs. secp256k1 doesn't support pairings, which is why it works for signatures but not for ZK proofs. BN254 and BLS12-381 are specifically constructed to be pairing-friendly. We'll learn about pairings in a few weeks.
Everything vulnerable to quantum: João reiterated that all these curves — secp256k1, BN254, BLS12-381 — are vulnerable to Shor's algorithm on quantum computers. The discrete log problem (both integer and elliptic curve versions) and prime factorization are all theoretically broken by quantum. What survives: hash functions (no mathematical structure to exploit) and lattice-based cryptography (different hard problem). His personal take on quantum computing: "Science is crazy, but I don't believe they will be able to do it. They're not even close."
Next week: cyclic groups formalized. We'll learn what makes a group cyclic, what a generator is, what the order of an element means, and why Lagrange's theorem constrains everything. João also hinted at subgroups — even if a full group isn't cyclic, we can always find cyclic subgroups within it. This is the last piece of algebra before pairings, which are the final mathematical ingredient for Groth16.
Week 5 done. We know why cubics are the only curves that give us groups, why rotations fail at cryptography, and why two nearly-equal large numbers — the field characteristic and the group order — define the security of every elliptic curve system. Next week: cyclic groups and generators. 🔄
📝 ZK and cryptography evolve fast — if any tip here is outdated, incorrect, or no longer applies, please reach out on X so I can update this article accordingly.