Week 2: Multiplicative Inverses in Finite Fields: When Division Still Works in a Closed World

Olusola Caleb — Fri, 09 Jan 2026 02:58:37 +0000

A few weeks back, I kicked off a public build challenge: constructing a blockchain from absolute zero, in Go, one layer at a time.

We started at the very bottom, with finite fields. It’s the fundamental math that every modern cryptographic system is built upon.

If you missed that first part, you can catch up here:
Week 1: Finite Field Elements, the math quietly powering blockchains

Today, we are digging into what makes finite fields actually work for cryptography: multiplicative inverses. This is where things get interesting.

Wait, Division in a World Without Fractions?

If we think about normal math for a second, the multiplicative inverse of $k$ is just $1k\frac{1}{k}$ . Easy.

But in a finite field, there are no fractions. Everything is a whole number, and all the math wraps around a fixed number called the modulus $p$ . So how do you “divide”?

That’s where the multiplicative inverse comes in.

In a finite field with a prime size $p$ , for every non-zero element $a$ , there has to be some other element $b$ such that:

\times b \equiv 1 \ (\text{mod} \ p)

We call $b$ the inverse of $a$ , written $a^{-1}$ .

So to “divide” by $a$ , you just multiply by $a^{-1}$ . It’s a clever workaround that keeps everything nice, neat, and within the field.

Finding the Inverse: Fermat’s Little Theorem to the Rescue

I remember getting stuck here at first. How do you find this inverse without fractions?

Then I discovered: Fermat’s Little Theorem.

It says that for a prime $p$ and any $a$ not divisible by $p$ :

a^{p-1} \equiv 1 \ (\text{mod} \ p)

Do a little algebraic rearranging:

\times a^{p-2} \equiv 1 \ (\text{mod} \ p)

And there it is! Comparing this to our definition, we see:

a^{-1} \equiv a^{p-2} \ (\text{mod} \ p)

The inverse is just the element raised to the power $p - 2$ . No fractions needed- just exponentiation!

Here’s the example I worked through in my notes:

In the finite field $GF (19)$ (so $p = 19$ ), what’s the inverse of $7$ ?

7^{-1} \equiv 7^{17} \ (\text{mod} \ 19)

Calculating $7^{17} \mod 19$ gives us $11$ , and sure enough, $\times 11 = 77$ , and $\mod 19 = 1$ . Perfect.

Why Primes Are Non-Negotiable

Here’s a crucial point: this guarantee holds when the modulus defines a field, prime moduli are the simplest case.

If you use a composite number (like 10), some elements won’t have an inverse. For example, in mod 10 arithmetic, what number multiplied by 5 gives you 1? There isn’t one. The whole system breaks.

That’s why in cryptography, we almost always work with prime fields. Guaranteed inverses aren’t a nice to have, they’re mandatory. Signature algorithms rely on fields where inverses are well defined, even if implementations try to avoid computing them directly.

Translating the Math Into Go

So, how does this look in our actual Golang code? Pretty clean actually.

The Inverse() method for our FieldElement type boils down to:

func (a FieldElement) Inverse() FieldElement {
    // Hello, Fermat's Little Theorem
    exponent := a.prime - 2
    return a.Pow(exponent)
}

This ensures a fundamental truth always holds:

// If this isn't true, something is terribly wrong.
a.Mul(a.Inverse()).Equals(One) // This will always be true.

Baking this math directly into our types is how we make crypto code that’s hard to misuse.

for those crious what that looks like in action?

// Let's test it in GF(19)
a := NewFieldElement(7, 19)
inverse := a.Inverse()  // This computes 7^(17) mod 19
fmt.Printf("The inverse of 7 is: %d\n", inverse.Value) // Output: 11

// Let's verify
result := a.Mul(inverse)
fmt.Println(result.Value == 1) // Output: true

This Isn't Just Academic: Actual Blockchains Run On It

Multiplicative inverses aren't some math trivia. They are essential for:

Elliptic curve cryptography: Adding and doubling points on a curve requires "division," which is just multiplication by an inverse.
Digital signatures (ECDSA/Schnorr): The signing process involves solving equations within the field. No inverses, no signatures.
Zero-knowledge proofs: These systems perform complex polynomial math, all of which depends on the ability to invert elements cleanly.

In short, if finite fields are the foundation, multiplicative inverses are the load bearing beams. No inverses, no zero trust guarantees, no blockchain.

So, What's Coming Next?

With a solid grasp of field arithmetic and inverses under our belt, we’re ready to climb the next layer: elliptic curves. This is where our field elements become (x, y) coordinates, and cool math becomes beautiful, usable cryptography.

You can follow along with the full Go implementation here:
GitHub: Building a Blockchain in Go

What should we dive into next?

Elliptic curve point addition in Go?
How scalar multiplication powers key generation?
The step from curves to actual digital signatures?

Let me know in the comments.

The takeaway?

Finite fields feel abstract until you need to actually use them. Then, concepts like the multiplicative inverse become your most important tools. They transform a theoretical "closed number system" into the practical bedrock of digital trust.

Finite Fields: The Hidden Math Powering Blockchains

Olusola Caleb — Thu, 01 Jan 2026 23:24:04 +0000

Week 1: Finite Field Elements: the math quietly powering blockchains

A few weeks ago, I promised a public build challenge: we’d explore blockchain from the ground up in Go, week by week, sharing insights, code, and the intuition behind it all.

Here’s the first installment.

Before elliptic curves, digital signatures, or zero-knowledge proofs, blockchains rely on something much more fundamental: finite fields.

If this concept isn’t clear, cryptography feels like magic.
If it is clear, everything else starts to click.

What is a Finite Field?

Think of a clock.

On a 12 hour clock:

The numbers only go from 0 to 11
9 + 5 doesn’t give 14, it wraps around and gives 2

This is an example of modular arithmetic, a simple way to understand finite fields.

A finite field works similarly, but with some important differences:

The “clock size” (the number of elements) is usually a prime number or a power of a prime
Every non-zero number has a multiplicative inverse
This makes division always possible within the field

That last property is why primes are critical in cryptography: without inverses, many algorithms break.

Why Blockchains Care

Finite fields provide:

Deterministic arithmetic: every operation is predictable
Exact computation: no floating-point errors or rounding ambiguity
Guaranteed inverses: critical for cryptographic signatures and key operations

Elliptic curves, ECDSA, Schnorr, all of it is built on top of this.
If arithmetic isn’t perfectly predictable, cryptography collapses.

What’s a Field Element?

A field element is simply:

a number that lives inside a finite field

Its value is always interpreted modulo the field size.
For example, in GF(19), 7 and 26 are actually the same field element because 26 ≡ 7 mod 19.

Field elements are the building blocks of cryptography: they’re the “numbers” that elliptic curves, signatures, and blockchains operate on.

That’s exactly what my FieldElement type models: a value plus the field it belongs to.

Values always stay within the field
Operations only happen between elements of the same field

This design ensures invalid math is impossible to ignore. Errors show up early, instead of silently breaking cryptographic logic later. That’s intentional.

What’s next

With finite fields in place, we’re ready to move up the stack:

Elliptic curve points
Point addition and scalar multiplication
Digital signatures

Check out the full Go implementation here: https://github.com/Caleb40/elliptic-curves-go

This post is about understanding why the code exists, not just making it compile.

If you want the next post to dive into inverses or elliptic curves themselves, drop a comment below.

DEV Community: Olusola Caleb