DEV Community

Cover image for Week 2: Multiplicative Inverses in Finite Fields: When Division Still Works in a Closed World
Olusola Caleb
Olusola Caleb

Posted on

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

#blockchain #cryptography #bitcoin #go

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 kk 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 pp . So how do you “divide”?

That’s where the multiplicative inverse comes in.

In a finite field with a prime size pp , for every non-zero element aa , there has to be some other element bb such that:

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

We call bb the inverse of aa , written a−1a^{-1} .

So to “divide” by aa , you just multiply by a−1a^{-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 pp and any aa not divisible by pp :

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

Do a little algebraic rearranging:

a×ap−2≡1 (mod p) a \times a^{p-2} \equiv 1 \ (\text{mod} \ p)

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

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

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

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

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

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

Calculating 717mod  197^{17} \mod 19 gives us 1111 , and sure enough, 7×11=777 \times 11 = 77 , and 77mod  19=177 \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)
}
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)