Sal's Blog

Switching from Next.js to Astro

Sun, 13 Sep 2026 23:38:00 GMT

When I first decided to go back to blogging, I wanted to write posts in Markdown and have that be delivered to the web.

HTML written by hand was out of the question purely because it's tedious. I like Markdown, and by 2024, there really wasn't any shortage of platforms (both static local build tools as well as hosted solutions) that allowed one to write in paragraphs without having to deal with syntax. The market settled: it's either WYSIWYG, or the typical format in the "textarea" box in most chat software; relying on nothing but UTF-8, punctuations and paragraphs to format plain text, yet successfully convey a message without formatting typography per text components.

I could have gone with WordPress, but I didn't want to deal with hosting. I'm not particularly against the idea of using it, but I have the particular skills to turn text files stored locally then deployed to materialize into a static website. So, I may as well put that to good use.

So, a static site generator is what I settled on.

For my current incarnation of the blog, I don't really remember what made me settle with a Node.js+React combo, but I really wanted to use that. I think the Node.js draw stemmed from my early enthusiasm for JavaScript way back in 2010, and the fact that I was excited that a Turing-complete language like JavaScript escaped from being merely a scripting language for a web page, to something to sit alongside Python and Ruby.

That said, my preference for DIY static site gen is not superior to having hosted solutions do everything for you. I simply like the idea of static site generation, and I don't expect anyone to do it.

Over the years, I used several tools. Many of them were merely an aggressive attempt at replacing Makefiles, or to bring some CMake-like tooling to the JavaScript world.

I started with Cake. Then moved to Grunt.js. I tried Yeoman, but I didn't quite like it. Then my absolute favourite was released in 2013: Gulp.js. I used that for a while.

But the overall theme was that none of these tools were dedicated to static site generation, but an overarching theme even above that was that I liked flexibility. Grunt.js provided guardrails yet had some flexibility, but Gulp.js took the flexibility step even further, while also operating within its frameworks.

But then, I eventually stopped blogging altogether. It was a whole host of reasons. You reading the above thought process of mine probably felt exhausted reading it, and that's probably what contributed to it. That, and also, just the unwillingness to look stupid. (Part of what brought me back to blogging was realizing that looking stupid is probably a lot less harmful than having nothing to show at all.)

Fast-forward to 2024, I decided, enough with the tooling. In the end of the day, it's not about tooling at all; tech exists to get things done, no matther how much so many programmers see otherwise. Some of us seem to forget that our hobbies are funded entirely by the ability to serve the world. It's what rewards us, literally, in cash.

Similar idea to blogging. It's not the tooling. Whether it is WordPress, Hugo static site generator, or anything else. It's about getting the word across in written form, using a medium what many call "the World Wide Web", accessed through a web browser.

I just bit the bullet and settled with Next.js. I chose it because it was the tool that I was deeply familiar with, and it was capable of merely serving as a static site generator.

And that's where I casually began to blog.

Onto Astro

Next.js served me well for a while, and I'm sure many who use it will continue to benefit from it.

To get this out of the way, I genuinely did not care about the vendor lock-in for Next.js. I always thought that I'll switch when the vendor lock-in becomes too invasive.

That said, here are some things about Next.js itself that became too obnoxious for me to tolerate:

lag from save to screen for HMR
it's a full-stack framework with the ability to run stuff on the backend. I don't need that part; my blog is a static site with each page being an HTML page
there was a noticeable lag in page-to-page transition
too much magic and abstractions

So that settled it.

I had to look for something else.

I have considered Hugo. In fact, it may have been more than 6 months ago that I was looking at migrating away from Next.js. Why didn't I choose Hugo? It's because taking a quick glance at the docs made it look like Hugo was strictly a template-only tool, and that would make things tricky for if I ever wanted to have features for more elaborate than mere static texts that don't have any JavaScript enhancements. And not to mention, I also had a lot of faith in Next.js to make sure that only the JavaScript that I needed is what was smartly loaded up for the page in question. I did not get that confidence with Hugo.

So I said "no thanks" to Hugo.

Fast forward to a few days, I really was considering moving to something else. I've been hearing about Astro for a while. It boasted support for React support.

I could have merely tried it out myself. But I took the word of Allen Pike, who moved his site from Jekyll to Astro. That was more than enough evidence for me to make the switch.

So, I just went ahead and asked AI to translate my old site to Astro.

And it worked.

And here we are.

What people forgot about React

Wed, 26 Aug 2026 00:00:00 GMT

It was Monday, November 11th, 2013. Allen Pike of Steamclock Software was the host of a talk series, called VanJS; it's a technology group for Vancouver Canada-based JavaScript, Node.js, and web enthusiasts. Attending it costed $5. The company that I was interning at, StrongLoop, covered my cost of admission. The first talk was by Steven Luscher, and he introduced to the audience a new open source project for frontends by Facebook: React.

Even as far back as 2013, anything new is a tough sell.

The days leading up to React's release, people have been proudly wrangling with jQuery and various plugins. People wrote frameworks on top of jQuery. Backbone.js was released in October 13th of 2010, and a whole cottage industry was built around that. Shortly afterwards, AngularJS came out (not to be confused with the new Angular 2.0, which is an evolution ahead of the older AngularJS). Backbone.js won the hearts of those familiar with jQuery, but AngularJS quickly caught up as it boasted patterns that encouraged separation of concern, and inversion of control, ultimately, testability.

Those frameworks were almost established standards by the time React came out, so it shouldn't be any surprise why anyone would be skeptical of React. And people are still skeptical of it, as of 2026.

But Steven Luscher wasn't presenting a framework. He was presenting a library that primarily lived on the view layer in application source code, and data was merely "fed in" via the this.setState method.

But what made React so intriguing was that updating content on screen meant not only updating the individual components that had their contents change, but it empowered writing code that looked like it redrew the entire screen! This was enabled thanks to React's virtual DOM — an in-memory version of what could be actually on the DOM — and materializes it into the web page, but only what's changed, via a DOM diffing algorithm.

Performance-oriented veterans at that time would frown at screen redraws, favouring more fine-grained, manually hand-coded UI updates. But this came at a real cost to quality assurance for more complex UI updates. So performance-minded teams needed to plan around product updates.

So prior to React, you either had three choices:

minimize UI updates, favouring minimal features for simpler, more easier to reason about code. Performance remained in-tact, however.
allow for more ambitious UI updates via fine-grained coding choices, but giving up code simplicity, risking bugs. Performance still remained in-tact.
redraw the entire screen, allowing for more complex UI, keeping simpler code, but sacrificing performance.

With React, we were no longer beholden to only choosing two of either interactivity, code simplicity, or performance; React gave us all three.

Steven Luscher demonstrated performance, by drawing a grid of DIVs, each representing a pixel of a live-updating phase-shifting sine curve.

The plain DOM+JavaScript "redraw everything" demo showed poor performance.

The React one showed real-time rendering, with smooth animation!

People were excited.

And I was especially excited. So much so, I ended up createing the /r/reactjs subreddit.

What this means

Some rather astute observer would have looked at the problem of writing web UI during web's mid-2000s boom pre-React, and would have concluded that UI application state is merely a change over time.

That would not have been a novel idea. This insight has been documented repeatedly. The "observer pattern" by the "Gang of Four" in 1994 is a good example. Out of the Tarpit in 2006 made mention of "state merely being derived".

Even in 1943, we had the idea of global state merely being an update in response to an input, and we've invented the "finite state automaton", or "finite state machine".

Combining that, we see that UI can be modeled easily as an FSA/FSM.

And that's the idea of those that opted to "just redraw everything"; upon an input, internal state updates, UI looks different. Rinse-and-repeat.

For more product-oriented stakeholders, state transition provides a bird's-eye-view. Designers merely model applications as state, state transitions, and UI state, allowing the act of detailing out a rather high-level overview of application behaviour, before writing a single line of code.

And thus, UI is merely a finite state automaton.

Prior to React, the FSA/FSM approach came with a sacrifice of quality, delivery cadence, performance, or any combination of the 3.

React derisked an FSA/FSM-like architecture entirely, empowering product people to merely provide screens and screen transitions, giving frontend engineers a blueprint to build a product relatively quickly.

My own experience

Although React does allow for turning high-level designs to working software, while also allowing for quick turnarounds for iterations and pivots to meet business' needs, React's core DOM diffing algorithm allows for more interactivity, beyond just transitioning from view to view, all without sacrificing performance.

This fact alone isn't merely a demo — such as that of Steven Luscher sine wave mapped to large blocky pixels made from DIVs demo.

I've actually implemented something like this over at StageKeep. It presented an interaction similar to Figma. Fast, buttery smooth panning and zooming. Interactions once believed to be limited to WebGL and shaders is instead done entirely in SVG by synthesizing coordinates and and zoom value into a 2D grid.

It was insanely elegant.

In Conclusion

React merely isn't just a fad. It's not merely a preference. It became a critical tool for translating business requirements into feature rich, accessible user experiences, with a faster delivery cadence.

It not only made it faster to transition from screen to screen, but deeply interactive applications with screen content updates happening at animation speeds.

Caveat

I may be praising React for its performance in-spite of the simplicity that it introduced to the market, but I am by no means married to this library. What I do champion however is this mathematical notion of UI:

\text{View} = f(\text{State})

Where $f$ is the transformation function that translate states to a view.

Anything that gives us such an elegance, I will always be a champion of.

If you hate React, your comment will have me harbour no grudges towards. I even have my own set of greivances for React, too.

That said, if you value tightly coupling controls with models, then this is a mindset I frankly can't stand behind on.

Helpful topic to teach yourself lattice-based crypto: cosets

Sun, 21 Sep 2025 02:25:00 GMT

I've talked about subgroups. The thing about studying subgroups, is that it may feel like we're dismissing all other subsets. The next logical question would be, why not study the rest of the sets?

And this is where cosets comes along. Although cosets don't cover every subsets of a group, but, nevertheless, it still broadens the scope further than what subgroups ever did, and they can be used to build powerful primitives. Primitives that are used in many cryptographic studies.

So what is a coset?

A coset is what you get when you take a subgroup $H$ of a group $G$ and "shift" it by some element of $G$ .

Formally, if $G$ is a group and $H \leq G$ is a subgroup, as well as some operator $\cdot$ , then cosets take on any of the following forms

left coset of $H$ by $g \in G$ : $g\cdot H = \{g\cdot h | h \in H\}$
right coset of $H$ by $g \in G$ : $H \cdot g = \{h \cdot g | h \in H\}$

The key properties of cosets are:

The set of all left cosets of $H \leq G$ forms a partition of $G$ , and right cosets of $H \leq G$ forms a partition of $G$ . Meaning that every element of $G$ belong to exactly one left coset and one right coset of $H$
Every element of $G$ belongs to exactly one left coset and right coset of any subgroup $H$ .
All cosets of $H$ have the same number of elements as $H$ itself.
Cosets are either equal or disjoint

Example with Integers

Additions in integers $\mathbb{Z}$ forms a group. We can define a subgroup of $\mathbb{Z}$ as being nothing but multiples of a particular integer, using $n\mathbb{Z}$ (where $n \in \mathbb{Z}$ ), e.g. $5\mathbb{Z} = \{\ldots, -15, -10, -5, 0, 5, 10, 15, \ldots\}$ .

Using additions as the "shift" operator, then the possible left cosets of $H = 5\mathbb{Z}$ gives:

$0 + H = \{\ldots, -15, -10, -5, 0, 5, 10, 15, \ldots\}$
$1 + H = \{\ldots, -14, -9, -4, 1, 6, 11, 16, \ldots\}$
$2 + H = \{\ldots, -13, -8, -3, 2, 7, 12, 17, \ldots\}$
$3 + H = \{\ldots, -12, -7, -2, 3, 8, 13, 18, \ldots\}$
$4 + H = \{\ldots, -11, -6, -1, 4, 9, 14, 19, \ldots\}$

These cosets partition $\mathbb{Z}$ into 5 distinct sets, each containing all integers that give the same remainder when divided by 5. This is a fundamental concept that leads to modular arithmetic.

This is a powerful idea to be leveraged when discussing quotient groups.

Helpful topic to teach yourself lattice-based crypto: subgroups and Lagrange's theorem

Sat, 20 Sep 2025 23:38:00 GMT

In another post, we have been introduced to groups.

The next question to ask is, can groups be subdivided? Yes, they most certainly can. Now, is that subdivision guaranteed to be a group themselves? Only under certain circumstances, and it is entirely on a case-by-case basis on certain sets. Not all groups can cleanly be subdivided into other groups.

But if they are, they most certainly serve as an interesting focus of study, which we will explore further in another post.

Now, when a group is subdivided, and if it happens to respect group laws, then such a subdivision is called a subgroup, and as a notation, we say that if $G$ is a group, let $H$ be a subgroup of $G$ , we denote it as $H \leq G$ .

Also, as a shorthand, when we're talking about the total number of elements in a group $G$ , we call it the order of the group $G$ , and the order of group $G$ is denoted as $|G|$ . This is especially meaningful for groups with a finite number of elements in $G$ .

Because mathematicians went with the $\leq$ symbol, they also gave themselve the liberty of having $G$ be a subgroup of itself, and so $G \leq G$ .

In fact, every group fundamentally has at the bare minimum the following two subgroups:

$G$
Trivial group, $\{e\}$

Where $e$ is the identity element (and recall that every group must have an identity element in order to even be considered a group).

When studying groups of finite order, when $H \leq G$ , by Langrange's theorem $|G|$ is divisible by $|H|$ .

Helpful topic to teach yourself lattice-based crypto: groups

Mon, 15 Sep 2025 23:20:00 GMT

In another article about rings and fields, I briefly touched on the topic of an abelian group.

As a quick refresher, in order for a set that happens to be equipped with a binary operation to even be considered an abelian group, it must satisfy the following properties:

Closure: $a + b$ is a part of the field. (For example, adding two numbers together will always get another number.)
Associativity: $(a + b) + c = a + (b + c)$
Identity: there exists an element $O$ such that $a + O = a$
Inverses: for every $a$ , there exists some $d$ , such that $a + d = O$
Commutativity: $a + b = b + a$

But a generalization of an abelian group is just a group, and it merely involves removing the requirement that a set equipped with a binary operation to not guarantee to be commutative.

So in other words, get rid of the commutativity requirement, and we're left with a group.

Groups are an important topic to explore, because later on, we are going to be exploring the idea of a subgroup.

Important topic to teach yourself lattice-based crypto: rings and fields

Sun, 14 Sep 2025 04:38:00 GMT

I briefly mentioned in an another post that lattice-based crypto builds on the idea of grid of points (a lattice), and selecting a secret point, and hiding it by adding a small, controlled amounts of "noise".

The imagery that may come to mind is something that can easily be derived by plotting real numbers on a grid (or something that may look like a grid). Indeed, that's precisely what so many videos online often use as analogies (such as this one by chalk talk). Math with real numbers is often used as the basis, and integers are used to identify all exact spots on the grid.

But in lattice-based cryptography, integers aren't quite used as how you were taught in elementary school, and real numbers aren't used at all.

What's used, instead are rings (more specifically, polynomial quotient rings, but more on that in another blog post), and to work with those rings, we must work with fields (more spefically, finite fields, but also will be a subject of a future blog post, or, feel free to read my post on "elliptic curve cryptography" which does touch on the topic of finite field math).

So what are rings?

A ring is a set that must satisfy the following properties:

must be equipped with an addition ( $+$ $+$ ) operation, thus forming an abelian group, which satisfies the following properties:
- Closure: $a + b$ is a part of the field. (For example, adding two numbers together will always get another number.)
- Associativity: $(a + b) + c = a + (b + c)$
- Identity: there exists an element $O$ such that $a + O = a$
- Inverses: for every $a$ , there exists some $d$ , such that $a + d = O$
- Commutativity: $a + b = b + a$
must be equipped with a multiplication ( $\cdot$ ) operation, thus forming a semigroup, which only has as a requirement that the operation be associative, similar to the associativity property of abelian groups
must have a distributive property $a\cdot (b + c) = a\cdot b + a\cdot c$

When we add more properties to a semigroup, we start giving them different names. For example, a semigroup with commutative properties (similar to commutative properties of abelian groups), we call them a commutative semigroup.

When we have the multiplication operations of a ring form a commutative semigroup, we refer to it a "commutative ring".

Then when we give a semigroup the added property of an identity element, we call that semigroup a "monoid".

When a ring not only has a commutative semigroup, but that commutative semigroup is actually a monoid, we call that ring a "field".

And the defintition of a field will be an important concept in order to effectively reason about the math behind lattic-based crypto.

Helpful topic to teach yourself lattice-based crypto: abstract algebra

Sun, 14 Sep 2025 01:16:00 GMT

I'll be honest: when talking about lattice-based crypto, I don't know who my audience is. But I do have aspirations that someone with just a high school background can pick up this topic, even if it only means that they'll be able to implement in a rote fashion, rather than having a more nuanced discussion about it. But for people who are actually interested in pursuing certain topics in mathematics, or theoretical cryptography, I'm hoping these articles act as a gateway for them.

There are so many topics to dive into in order to actually have a finer understanding of how things work, but for my first article to my blog about this topic to teach absolute beginners, I'm going to point to a brilliant series that introduces abstract algebra.

At the highest level, lattice-based cryptography builds on the idea of a grid of points (a lattice). We choose a secret point, and then hide it by adding a small, controlled amount of “noise.” But unlike the lattices you might picture from geometry class, these aren’t built from real numbers on graph paper. Instead, the points live in a polynomial ring space, where arithmetic is done with addition, subtraction, and multiplication (but not ordinary division). The rules look familiar, but they play out in a different, more abstract setting.

Unlike university lecture recordings, these series of videos feel a lot more approachable. The tone almost feels like it is welcoming to those who don't even have any experience beyond basic algebra.

Definitely check them out: https://www.youtube.com/playlist?list=PLi01XoE8jYoi3SgnnGorR_XOW3IcK-TP6

A simple proof of the Cayley-Bacharach theorem

Thu, 19 Dec 2024 08:00:00 GMT

The Cayley-Bacharach theorem states:

If two cubics $C_1$ and $C_2$ intersect at 9 points, and a third cubic $C_3$ passes through 8 of the 9th point, then it will also pass through the 9th intersection point, as well.

Proof

We have three cubics, $C_1$ , $C_2$ , and $C_3$ .

Because $C_1$ and $C_2$ are degree $3$ curves, by Bézout's theorem, $C_1$ and $C_2$ will intersect on at most $3 \cdot 3 = 9$ points. Another way to say this is that $C_1$ and $C_2$ will share $9$ common vanishing points. Also worded alternatively, the zero set of both $C_1$ and $C_2$ will be those 9 points. Also note that the linear combination of $C_1$ and $C_2$ forms a pencil that will span the space of all cubics that pass through those 9 points.

Let's have it so that the third cubic $C_3$ passes through 8 of the 9 points of the intersections of $C_1$ and $C_2$ .

This means that the space of cubics that pass through those 8 points—for which $C_1$ , $C_2$ , and $C_3$ will be a part of—imposes 8 linear condition. Because of this, the space of cubics that pass through these 8 points is expressible as a system of 8 cubic equations. Solving for it will thus leave us with a linear combination of two cubics, giving us again a pencil of cubics that pass through those 8 points. And again, the span of which includes $C_1$ , $C_2$ , and $C_3$ .

This means that $C_3$ can be expressible as a linear combination of $C_1$ and $C_2$ .

By Bézout's theorem, not only the span will share those 8 vanishing points, but will also all 9 vanishing points.

This proof has been inspired by one written by Matthias Volk, over at his blog post "Cayley-Bacharach theorem".

Monads in TypeScript

Sat, 23 Nov 2024 08:00:00 GMT

I've been writing code that aims to be as axiomatic as possible. The goal is to focus on some basic functionality for one problem domain, and generalizing it across domains.

And this ultimately leads to paradigms, that allows for seamless transition from domain model to domain models. No façades needed. It's all just idioms that work practically everywhere.

And this is where monads come in.

What are monads

Monads are a way to encapsulate a result of a computation. To extract it, a special "bind" operator is given a function to further transform that result and return another instance of a monad.

It may seem like I'm generically referring to closures, and I could, but monads also have "laws" that they naturally adhere to. Not saying these laws can't be preserved using closures, but I am saying that the concept is not exclusive to them.

But before I even talk about monad laws, let's define a type that we can use to represent a monad.

A type for monad

A type signature that I'm going to go with:

type Monad<T> = {
	then: <V>(f: (value: T) => Monad<V>) => Monad<V>;
};

In the above case, the then method in an instance of a Monad<T> is our "bind" operator that we talked about earlier.

A lot of JavaScript programmers prefer to structure that bind operator as a method to an object, and that method is often either named flatMap or then.

And if you're wondering: is the then the same then in promises, then yes, that most certainly is. We'll see later why JavaScript promises are monads.

Moving on, perhaps to initialize a Monad, we'd define a function called unit to do so:

const unit = <T>(value: T): Monad<T> => ({
	then: (f) => f(value);
})

To use it, it's simply a matter of invoking it like so:

declare const m: Monad<number>;

const newMonad = m.then((value) => {
	// Do stuff with `value` here

	return unit(null);
});

// The value of `newMonad` should represent `Monad<null>`

Monad laws

Now that we have defined a type for a monad, we can now use it to explore how it can adhere to the monad laws.

Monads have three laws that they must adhere to.

Law 1: Left Identity

The expression:

unit(x).then(f);

Is equivalent to just:

f(x);

Law 2: Right Identity

The expression:

m.then(unit);

Is equivalent to just:

m;

Law 3: Associativity

The expression:

m.then(f).then(g);

Is equivalent to

m.then((x) => f(x).then(g));

This last rule is the most salient of them all.

Consequence of law 3.

Because of law 3, we can nest monads as much as we want.

For example, we can expand the above to add yet another step:

m.then((x) => f(x).then((x) => g(x).then((x) => h(x))));

And that above expression can also be written as:

m.then(f).then(g).then(h);

You may think, the above looks ugly, and I agree it does, but there are cases where this can come in handy.

But first, let's look at Promises.

Promises as monads

Promises are monads.

So the above expressions of then is very similar to how promises work.

But one of the earliest motivations for promises were created to mitigate "callback hell", that is result of a computation that will eventually be available asynchronously, will be made available through callbacks.

And, by the nature of a lot of problems, one asynchronous call will lead to another.

Here's an example:

// This is ugly…

doSomething((err, s) => {
	if (err) {
		return;
	}
	doSomething((err, s) => {
		if (err) {
			return;
		}
	});
});

For a long time, people hated that.

That said, it can be useful to have some amount of tasteful nesting.

Recall that async/await is just an abstraction for chained nesting of promises.

For example, this code:

async function fn() {
	await doSomething();
	await doSomething();
	await doSomething();
}

Is equivalent to:

function fn() {
	return doSomething()
		.then(() => doSomething())
		.then(() => doSomething())
		.then(() => Promise.resolve(undefined));
}

Because of that, we can actually combine both async/await with promises.

This is what the code would look like:

async function fn() {
	await doSomething().then(() => doSomething());
	await doSomething();
}

How is this useful?

It's useful if you want the elegance of issuing a GET request without storing any intermediate variables

function fn() {
	return fetch("https://example.com")
		.then((response) => response.json())
		.then((value) => parse(value));
}

This is compared to this:

async function fn() {
	const response = await fetch("https://example.com");
	return parse(await response.json());
}

Neither is more or less legible than the other (IMO), but at the very least, in certain situation, if it is felt that it is best to avoid declaring any additional variables, then the promise approach (as opposed to the async/await approach) can be favourable for some people.

More monad patterns

What's nice about monads (and interface segregation in general) is that monads don't care about implementation.

A programming pattern employed is to fail fast.

But, failing fast with runtime exceptions cause undesirable crashes.

A middle ground is to fail fast, preventing further execution, but just not crash.

This idea is not new.

Division by zero, for example is not allowed. With IEEE754 floating point numbers, division by zero yields (at least mathematically under most operations) an invalid quantity. But this will not cause a crash; simply that subsequent derivation of new values from such an inconsistent state will yield more inconsistent state.

We can achieve an effect quite similar to that with monads.

This is done by defining a "nothing monad".

It would work something like this.

function nothing<T>(): Monad<T> {
	return {
		then: () => nothing(),
	};
}

And subsequent invocations of then will do nothing at all.

For example:

function divide(a: number, b: number): Monad<number> {
	return {
		then: () => {
			if (b === 0) {
				return nothing<number>();
			}
			return unit(a / b);
		},
	};
}

divide(10, 0)
	.then((x) => {
		console.log("Should not be here");
		return x;
	})
	.then((x) => {
		console.log("Not here either");
		return x;
	});

Conclusion

Monads have some powerful axioms that you can leverage to compose smaller blocks of computation. This effectively yields an inversion of control, away from the domain models that could have required full control over other domain objects, and instead allow other domain objects to pass the computation along to something else through chaining.

I hope this article provides something to think about.

What I value more than clean code

Sat, 02 Nov 2024 00:00:00 GMT

Previously, I wrote about code being ephemeral.

I have so much more thoughts about code cleanliness.

Especially considering that TypeScript is now ever growing in popularity, and it may one day outpace JavaScript in adoption.

As its popularity grows, the signals of it being a highly liked programming language also comes with the noise from those who dislike it.

I've heard many dissenting opinion from TypeScript haters, but one complaint that I hear alot (but not necessarily the biggest complaint) is that TypeScript makes code harder to read.

After all, JavaScript never introduced type annotations. For this reason, I have to admit, the language looks perhaps a lot less "cluttered" than typed languages such as Java, C#, and C++.

And among those who argue that JavaScript looks cleaner, in their eyes, TypeScript looks a lot messier.

If clean code is to be striving for, then surely TypeScript is a step backward.

And it's for that reason why clean code is not to be strived for, at least, by the metric of how "cluttered" things look. The concept of "appearance" is arbitrary. How do you define "appearance"?

What's the ideal metric instead of clean code, then?

The ideal metric to look for is how easy is it to reason about the code.

Axioms for easy to reason about code

Logic isn't enough.

After all, I've said this before, and I will say it again: bugs are not software that misbehave; it's something that someone wrote, and they are responsible to have deployed that faulty code. The execution environment just runs it. The execution environment doesn't have free will. It's logical. It's black and white.

This is where we need an axiom to determine what's considered "easy to reason about code".

So here's what I think will be a good set of guidelines:

determinism
number of state mutations; the lower the easier
number of heterogeneous parallel tasks; the lower the easier
API surface; the lower the easier
atomicity

On ephemerality and code readability

Fri, 01 Nov 2024 07:00:00 GMT

I'd often hear about the virtues of writing readable code ever since I first started learning to program back in 2006.

Compared to today, blogging was both at its infancy, but still really taking off, with no plateau in sight. There were many ways I'd read about programming, and it's through link aggregation services that I'd stumble upon various programming blog posts, and one of the oft-repeated advice that I'd encounter is the advice that one should write code that is easy to read.

Hence why every once in a while, I'd encounter the quote "programs must be written for people to read, and only incidentally for machines to execute" by Harold Abelson.

As I progressed into my programming career, it was the same drill: take requirements, and turn it into functioning software, with as minimal bugs as possible. Supposedly code that is easy to read is minimal of bugs, at least in the event that the code is handed off to someone.

Back in 2012, one framework that was lauded as the panacea for frontend development was Backbone.js, a framework that brought the MVC paradigm to thick client development. Dropping-in the library into the very start of a project paved the way on how to best structure code to not only deliver software, but one that is minimal of bugs.

To me, it felt revolutionary at that time, but there really wasn't much innovation in this library. It was just a handful of classes that provided an event handler to data changes, propagating data changes from collections to views. Nothing that couldn't be implemented on our own. However, having a common framework that many use is much easier to hire for, so that's a bonus.

2013 is what sparked the beginning of a new era. The developers of Facebook had open sourced React, the front-end framework that was internally worked on and deployed at Instagram.

Although, it's unclear if it took ideas from Backbone.js, but it did revolutionize how to think about the state update and re-render cycle. There were many paradigms to be drawn from Backbone.js, but React was also different in many ways.

While Backbone.js relied heavily on singleton instances of models and collections, React had no such hard requirements. You decided when React should trigger a view refresh. Better yet, you decided on what sub-tree to focus on. But if you wanted to redraw the entire tree, you could do so, with minimal performance penalty! This is a luxury not immediately available with Backbone.js.

While Backbone.js held your hand at how to structure your code, it provided no mechanism for changes to the view. React flipped the script; you are free to maintain your own state management paradigm, but the view rendering is something that React took over for the most part.

Backbone.js required you to build the actual DOM tree on your own (albeit, it did have templating facilities so that you didn't entirely have to). React forced you to work almost entirely with its virtual DOM system, somewhat. Actually, React borrowed ideas from functional programming and functional reactive programming (probably where the name "React" came from). Sure, you don't build the browser DOM tree yourself. Instead, you build a virtual DOM tree, that is then mapped one-to-one to the actual DOM layout. But once it has been laid out, you can grab the reference element, and do what you want to your heart's content. So you initialized an HTML5 canvas element, and want to draw to it? Once it has been laid out onto the DOM tree from the virtual DOM, React will allow you to gain access to it afterwards via references.

With this in mind, it felt as though React empowered you to focus more on the business logic, while it took over rendering for you. Although some applications would benefit greatly from the ability to manipulate the DOM directly, most applications will benefit more from delegating rendering, while allowing one to focus on the business logic (bear in mind, as mentioned earlier, React doesn't necessarily stop you from manipulating the DOM. It even has features that allow you to gain access to the DOM. However, DOM manipulation still feels like it's been buried away somewhere, and you have to go look for it, unlike Backbone.js).

And this brings me to my thesis on "ephemerality of code".

Readable Code

I talked about the time span from 2006 to mid 2010s. It wasn't until 2016 when React really took off. The entire time when I was writing React, I'd feel writing readable code was perhaps a thing of the past.

It's 2024, and I still hear the virtues of writing readable code.

I am not going to deny that readable code makes a lot of sense.

Depending on the problem domain, writing readable code is probably a critical part of a software developer's job. It's almost as if they need to be going a step above Harold Abelson's quote, and actually treat the human brain that reads code as a CPU architecture to target, and incidentally be compiled to run on ARM64 sometimes.

But there are other problem domains that I simply find this strategy is not a valuable use of one's time.

And the case being is writing code in React.

Code ephemerality

Let's really not forget one thing about software development: we're building something for people.

Many salaried people may cynically point out that they are being paid to turn a profit.

That is true. But one can't just take money from people in exchange for nothing, lest you want to be accused of stealing or committing fraud. People need to see value, in order to be convinced that they should forfeit their money for the privilege of using the product.

The thing is, people's needs change, and to reflect their needs, what the front-end presents to users also needs to change.

This is why code needs to be ephemeral.

This is why being proud of React code is a pointless endeavour.

As more and more people move away from writing raw CSS, and onto writing CSS directly into the JavaScript/TypeScript, the whole concept of writing "beautiful code" has been turned on its head.

Now, things are going even crazier with Tailwind. Previously, each style attribute was placed on individual lines; now they can span several page worth of horizontal scrolling to see the full styling rule.

It's awful. It's great developer experience when developing, but terrible when maintaining.

And that's OK.

Because in the end of the day, ephemerality of code makes all of this moot.

The life of the code should be the life of the specific iteration of your software.

Free yourself

Previously, I remember there being a strong emphasis on readable code, while balancing functionality.

But considering the competitive nature of SaaS, it probably doesn't make sense to be stuck splitting hairs.

It's also that I'm beginning to see a shift in attitudes of software development as a profession. Many have grown to value work-life balance.

For a long time, sacrificing one's health for long hours was a virtue worth cherishing. But now, people cherish work-life balance. They focus on work for 40 hours, and live their life for the remaining 128 hours.

Hence why nicely structured code doesn't really matter much. It will all get thrown away anyways.

So what should one focus on during their 8 hours of work? Just build and ship things.

Surely there is a time for clean code…

Of course you shouldn't be writing half-thought out code all the time.

So when is it the appropriate time to write clean code?

Definitely not the front-end.

Business logic should probably be very clean. It should also be unit tested. Then integration tested for further sanity checks.

Some protocol-level stuff should really be well-documented and put into neatly-packed functions and classes.

Why those should be "dirty code", too

The headline bit misleading. Of course have them be clean.

But for many, clean code is trying to model things as prototypes for future objects, and opaquely model their behaviour, all wrapped up in a black box.

People love this approach since these opaque implementation encapsulate behaviour, with a focus more on the interfaces instead of the implementation. Furthermore, if objects lack behaviour, they're often regarded as "anemic types". The presence of "anemic type" is a code smell, for many.

But why the fear and disdain for anemic types? If we're writing for embedded devices, sure, minimzing stack space and heap allocations is probably a wise approach to coding. But on web browsers, it's fine to generate a type who's sole purpose is to transfer data from entity to entity. It's all going to get garbage-collected anyways.

Code as configuration

Software solves business problems.

One of the biggest benefit of software is that it does exactly what it is told to do (yes even bugs. The software is not at fault for being buggy; it's who wrote it). It doesn't take breaks, and can potentially work 24/7. Sure, it is subject to the weakest part of the system it runs under, and hence why a lot of SaaS products have an uptime measured in "nines". These numbers are so high (but not exactly 100%), they may as well be 100% as far as UX is concerned.

And yet, for a lot of business cases, the same piece of code may not live forever. It could have, but business requirements will push out the old, and bring in the new.

And hence comes the idea of code as configuration.

Business has new requirements?

If you bought off-the-shelf software that does pretty much what it needs to do (such as file servers), you simply had to update the .htaccess file. It's code that isn't Turing-complete like Python or JavaScript. It's configuration.

But those are so limited in what they offer.

This is where turing-completeness comes in.

Instead of working in a DSL, you work with an actual Turing-complete programming language.

Want the power of Nginx, but control the computing environment? Just import Caddy into a Go project and module that.

Likewise for React frontends.

Some changes may require some CSS updates. But others could require rethinking the UX flow.

This is where the rewrite happens. Not because someone wanted to refactor to a brand new "good practice" they read about on the Internet, but because the old component no longer served customers optimally, and it's time for an overhaul.

Situations like these are fairly common.

Ephemerality and AI

This brings me to AI.

Google's CEO, Sundar Pichai, boasted about how more than a quarter of the company's new code is created by AI.

Many found this concerning.

"Is AI taking my job?", some wondered.

Many didn't ask, and instead went straight to questioning these metrics.

Could the CEO be lying? Or maybe he's telling the truth. But what's the quality like of the code that is written?

A lot of commenters highlighted how there used to be living people maintaining guardianship of the code that they write. What will the situation be like going forward? Couldn't this lead to more bugs?

I've never worked at Google, so I honestly can't comment on what's going on there.

But I can comment on something that I am much more familiar with: AI-generated code that I deliver in my work.

Sure, a lot of the code that I need to deliver is entirely inappropriate to be written by an AI. Examples of this would be a lot of backend code. I need to maintain a close watchful eye of what I am writing, favouring immutability. Go is not an immutable language by default. And AI-generated code that I ask to produce often introduces lots of mutations that are far too excessive for my liking.

Mutability is fine, but this comes at the cost of being able to reason about the code.

So if AI sucks for backend, then what is it good for?

Definitely React frontends!

Conclusion

So SaaS as a business has become competitive. Not only in terms of the sheer number of offerings on the market, but surprisingly, there's just not enough labour going around. The market has shifted towards favouring high code velocity, and with it comes the sacrifice of code cleanliness. Employers are pushing developers to ship quickly, while doing all they can to retain talent. Someone writes code, they leave, someone takes over.

What should that person do? Just rewrite.

A cute Golang pattern

Sun, 13 Oct 2024 07:00:00 GMT

Go has types. And types have methods.

Go has type aliasing. Aliased types lose the original methods, but introduces new ones.

Go may not support inheritance, but casting gets you pretty close to it.

Only problem is, unless the type aliases are in the same modules, unexposed fields remain unexposed.

Is that last point a problem? Not really.

Regardless, type aliasing can introduce some really cool semantics.

For example, if you wanted to implement a stack using slices, rather than wrap a slice inside a struct, just alias the slice!

type Stack[T any] []T

func (s *Stack[T]) Push(value T) {
	*s = append(value)
}

func (s *Stack[T]) Pop() T {
	lastItem := s[len(s) - 1]
	*s = s[:-1]
	return lastItem
}

Then, if you wanted to map over all of the elements in the stack, well, a mapper can can come in handy.

type Mapper[T any, V any] []T

func (s Mapper[T, V]) Map(cb func (value V) T) []T {
	arr := make([]T, len(s))
	for i, el := s {
		arr[i] = cb(i)
	}
	return arr
}

Then, putting it all together, you get:

stack := Stack[int]{}

stack.Push(10)
stack.Push(20)
stack.Push(3)
stack.Pop()
stack.Push(30)

fmt.Printf("%#v\n", Mapper[int, int](stack).Map(func (v int) int {
	return v * 2
}))

What's the benefit of this? The one main benefit is that method calls require only a single parameter.

if you value the ability to pass in only a single parameter, then the pattern outlined should be helpful to you.

Primer on Elliptic Curve Cryptography

Mon, 23 Sep 2024 07:00:00 GMT

I'm going to be giving a talk that gives a quick primer on elliptic curve cryptography. But I thought I'd do a writeup on it before the presentation so that people who want to read up on it before-hand can do so. That, and also writing things down actually fleshes out what I'm about to talk about.

When building information systems, you're either storing information, or sending it somewhere else. But for every interaction you have with information, malicious actors will always be attempting to either steal or sabbotage information, impersonate someone, or fraudulently deny that they have ever committed a transaction.

Our goal is to thwart these malicious actors, and the predominant strategy for this has been to have intended actors be very easily able to disseminate and store information, while making it difficult for malicious actors to cause harm.

The Discrete Log Problem (or rather the Elliptic Curve Discrete Log Problem)

There are many strategies for difficulty, but with elliptic curves (in finite fields of prime order, which is a space we will discuss a bit later), the difficulty has been brought on by the difficulty in solving the discrete log problem.

That is, we have some function that takes two parameters of a particular group (for example, two points on an elliptic curve), which returns another element of that group. We repeatedly apply that function to a single element of that group, for a very large number of times. The result of that function invocation could be public information which is potentially used to identify an actor, along with the element that the function was applied on. Meanwhile, the very large number of times where the function was applied is private information that an actor will have derived before generating that public information. Everyone knows the public information—the result of the function invocations, and the element in which the invocation was applied to—but only the actor knows how many times they've called that function to derive that public information.

To put it in math terms, let's define some function $\text{operate}$ , which takes two parameters $P$ and $Q$ of a group. What we're doing is given some publicly-known information. Where element $G$ , we're invoking it with some $d$ number of times:

\underbrace{\text{operate}(G, \text{operate}(G, \text{operate}(G, \ldots)))}_{d} = R

The element $G$ along with the result $R$ is public information, but $d$ is private information that should never be shared.

The basis of the elliptic curve discrete log problem is that even if we are publicly given the element $G$ , the result $R$ , and the underlying algorithm behind the hypothetical $\text{operate}$ function, it should still be absolutely impossible to recover $d$ .

The $\text{operate}$ function

Previously, we were introduced to the $\text{operate}$ function, which takes two elements from a group, and returns another element from that same group.

But what does it mean to operate on two elements from a group to return an element of a group, and how does it relate to elliptic curves?

In the context of elliptic curves, we have a curve that looks like the one below:

We pick two points $P$ and $Q$ on that curve, and we draw a straight line that crosses the two points, that line will actually end up crossing a third point $R'$ on the curve.

We call it $R'$ and not just $R$ is because $R'$ is not our result of our $operate$ function. Fortunately, finding $R$ from $R'$ is very easy: it's merely the result of vertically reflecting $R'$ to find $R$ .

And if $P$ and $Q$ are equal to eachother (e.g. $P = Q$ ), then finding the result involves imagining that you are drawing a line that crosses two points that are negligibly different from each other, thus forming what is known by mathematicians a "tangent" line. And that tangent line will also cross another point, which is our $R'$ , which we then flip veritcally to find $R$ .

In projective geometry, the idea of counting a tangent of a line as two distinct points is called "counting multiplicities".

Just a quick spoiler: regardless of whether you decide to draw line that crosses first with $Q$ or with $P$ , we will always get the same $R'$ . This effectively renders the $\text{operate}$ function to have a "commutative property", that is $\text{operate}(P, Q) = \text{operate}(Q, P)$ .

Later, we'll show that the the above elliptic curve rendered from the Weierstrass form $y^2 = x^3 + ax + b$ (where $a, b \in \mathbb{F}$ ), also shares associative properties.

Some math notations, and an introduction to Abelian groups

Earlier, I introduced the $\text{operate}$ function. But writing it out gets a little wordy.

Mathematicians have instead opted for—rather confusingly—the infix $+$ operator to express a 2-parameter operation on group elements.

That is, given two elements $P$ and $Q$ of a group, the expressed $\text{operate}(P, Q)$ operation is instead expressed as:

P + Q = R

Yes, the $+$ symbol is used for something that may not be intuitively an addition.

It could be argued that there is a good reason for this.

For one, even with the abbreviation, repeating the expression of several "additions", $d$ -number of times gets repetitive:

\underbrace{G + G + G + \ldots + G}_{d} = R

So, we can just express the above as a scalar multiplication of G by the quantity $d$ :

\underbrace{G + G + G + \ldots + G}_{d} = d\cdot G = dG = R

The $dG$ expression is certainly a lot more compact than $\underbrace{G + G + G + \ldots + G}_{d}$ .

So in short, we settled with:

dG = R

Other arguments behind why is that a lot of cryptographic primitives form an Abelian group.

That is, they have the following properties:

Commutativity: the expression $A + B$ can equally be expressed as $B + A$
Associativity: regardless of if you compute $(A + B) + C$ or $A + (B + C)$ , the results will be the same
Existence of an identity element: given some element $I$ , we can compute $A + I = A$
Existence of an inverse: that is, not only do we have some $A$ , but also some $A'$ , such that $A + A' = I$ . And in the case of Abelian groups that attempt to allude to the concept of an "addition", rather than expressing $A + A'$ , we'd express $A - A = I$ , analogous to a subtraction.

In the context of elliptic curve group operations (called "addition" going forward), the identity element isn't left to some variable name of $I$ , of course. That will be discussed later.

Abelian group scalar multiplications

Earlier I mentioned that we are computing some $dG$ such that we are repeatedly applying $G + G + G \ldots G$ , all the way until $G$ has been added $d$ number of times.

The problem is that $d$ can be a ridiculously large number. Sometimes a number so large, by some estimates, it exceeds the total number of atoms in the known universe!

If computers are really bad at iterating over the number of atoms in a glass of water, there is no way we're going to be able to compute a number as large as the total number of atoms in the unverse, or anything near it!

Good thing is, Abelian groups have an associative property.

Thanks to this, we can group operations together.

For example, in the expression $G + G + G + G$ , rather than computing $((G + G) + G) + G$ , instead, let's compute $(G + G) + (G + G) = 2G + 2G = 4G$ .

When we first compute the left set of additions $2G$ , we already know the value of the second $2G$ , thus saving us a computation.

And we can boadly apply this to eight additions.

G + G + G + G + G + G + G + G = 2G + 2G + 2G + 2G = 4G + 4G = 8G

This should yield just 3 computations rather than 8.

The double and add algorithm

We see that there is potential to cutting down computations from $O(d)$ to just $O(log_2d)$ .

But the algorithm above implies that we're using something similar to dynamic programming. That is, to memoize individual results.

This requires $O(log_2d)$ of auxiliary space.

We can do better. We can reduce that down to just $O(1)$ auxiliary space.

This is where the double and add algorithm comes in.

The basic gist of the algorithm is this:

start with some identity element as the result $R$
convert the number $d$ $d$ into binary digits, and iterate through each digits from most-significant bit, down to the last significant bit
- if the digit $1$ is encountered, set $R$ to $2R + G$
- otherwise set $R$ to $2R$

Now you've saved time from $O(d)$ down to $O(log_2d)$ , with no auxiliary space required.

Possible Side-Channel attack

So with the double and add algorithm, we see that one branch of the if-statement runs two operations, where as the other only computes one.

Problem is, someone can be snooping in on CPU cycles and use it to recover the secret number!

A mitigation to the side-channel attack is to resort to the Montgomery ladder.

Why is it easy to go one way but hard the other

It's easy to go one way because we're able to look at the binary structure of an integer, but going the other way is effectively a really difficult search problem, and there are just no (known) shortcuts.

Math of drawing lines across elliptic curves

I introduced the curve, that we call the "elliptic curve". But of course, it's difficult to draw such a curve perfectly. Not to mention, computers can't work with drawings very well.

Instead, they can work with math.

They have support for additions, subtractions, exponentiation, etc.

So let's use good old math for this.

Elliptic curves can be expressed as the equation:

y^2 = x^3 + ax + b

That equation describes what is known as a "Weierstrass form", which knowing this name may be useful when discussing ECC.

Of course $x$ and $y$ are variables that relate to eachother, but $a$ and $b$ are constants that we pick right before we interact with others.

Regardless, now our problem is, if we happened to have picked two points $P$ and $Q$ on a curve, how would we find the $x$ -coordinate of the third point, and the corresponding $y$ -coordinate?

Here is where we will do some derivations for the math to recover those values.

Projective Geometry

In high school, when drawing two parallel lines, both will remain parallel forever.

This is called affine geometry.

However, with elliptic curves as used in cryptography, we're going to be taking advantage of another branch of geometry called projective geometry.

Projective geomoetry shares all the same properties of affine geometry, but one important facet of projective geometry that we're going to take advantage of is that parallel lines are not parallel in projective geometry.

Instead, they intersect at a point, and that point is the point at infinity.

We'll see later that this is a powerful concept that we can take full advantage of.

Finding the x-coordinate of the third point

Let's define $P = (x_1, y_1)$ as a point on the curve and $Q = (x_2, y_2)$ on that same curve.

We'll first need to define the equation of the line that is secant to $P$ and $Q$ , and it will be this:

y = mx+\beta

Where we can think of $m$ as the slope of the line, and $d$ is where the line intercepts at the y-coordinate, when $x = 0$ , or simply known as the " $y$ -intercept".

Our $m$ isn't just any value; it's dependent on the positions of $P$ and $Q$ , for $P \neq Q$ , and $Q \neq -P$ . To compute the slope, it's merely the "rise over the run", or rather the rate of change of $y$ , with respect to $x$ . In other words, it's a ratio, and the ratio is computed by calculating the differences in the y coordinates with respect to the x-coordinates.

So:

m = \frac{y_2 - y_1}{x_2 - x1}

To find the $y$ -intercept $\beta$ , we'd simply sample a point on the equation of the line, and solve for $d$ . We'll just take the coordinates from $P$ .

\beta = y_1 - mx_1

OK, this is nice to know and all, but what can we do with this?

Well, we need to find the third point on the curve.

Can we use algebra for this?

We can see that both the equation of the line, and the equation of the curve have a $y$ -coordinate.

How about we do a substitution? After all, the points on the line intersect with the points of the curve. Does this mean that both the line and the curve will intersect at all three points? Let's try:

y^2 = x^3 + ax + b \Rightarrow (mx+\beta)^2 = x^3 + ax + b

We can see that the left-hand side is quadratic with respect to x, and the right-hand side is cubic. Subtracting a quadratic from a cubic will still yield a cubic equation.

Let's do that.

\begin{align} (mx+\beta)^2 = x^3 + ax + b \Rightarrow 0 & = x^3 + ax + b - (mx+\beta)^2 \\ & = x^3 + ax + b - m^2x^2 - 2mx\beta - \beta^2 \\ & = x^3 - m^2x^2 + (a - 2m\beta)x + (b - \beta^2) \end{align}

Now, here is a property that you have to remember: for cubic polynomials—such as the one that we derived on the right-hand side of the equation above—there are three possible values of $x$ that we can plug in for the equation to hold (e.g. the cubic polynomial to equal zero).

Let's call them $x_1$ , $x_2$ , and $x_3$ .

We're getting close. We already know $x_1$ and $x_2$ . Now all we need to do is find $x_3$ .

Let's reinterpret the polynomial from above into some other polynomial where we re-express the constant coefficients of the polynomial as some other set of constants:

x^3 - m^2x^2 + (a - 2m\beta)x + (b - \beta^2) = a_3x^3 + a_2x^2 + a_1x + a_0

Where $a_3 = 1$ , $a_2 = m^2$ , $a_1 = (a - 2m\beta)$ , $a_0 = (b - \beta^2)$ .

We can infer this from factorizing the cubic expression like so:

\begin{equation} \begin{split} a_3x^3 + a_2x^2 + a_1x + a_0 & = a_3(x^3 + \frac{a_2}{a_3}x^2 + \frac{a_1}{a_3}x + \frac{a_0}{a_3}) \\ & = a_3(x-x_1)(x-x_2)(x-x_3) \end{split} \end{equation}

Expanding the right-hand side of the above equation should yield:

a_3x^3 - a_3(x_1 + x_2 + x_3)x^2 + a_3(x_1x_2 + x_1x_3 + x_2x_3)x - a_3x_1x_2x_3

Now, from the earlier derivation of our polynomial, we saw that the coefficient associatd with $a_3$ is just $1$ , so we can simply get rid of the $a_3$

That is:

x^3 - (x_1 + x_2 + x_3)x^2 + (x_1x_2 + x_1x_3 + x_2x_3)x - x_1x_2x_3

And also, remember, that above polynomial should equal to the one we derived earlier.

x^3 - (x_1 + x_2 + x_3)x^2 + (x_1x_2 + x_1x_3 + x_2x_3)x - x_1x_2x_3 = x^3 - m^2x^2 + (a - 2m\beta)x + (b - \beta^2)

Now let's focus on the second term of both of the polynomials. We see that the second term are equal to each other.

-(x_1 + x_2 + x_3)x^2 = -m^2x^2

Just get rid of the $x^2$ and the negative, and we get:

x_1 + x_2 + x_3 = m^2

And we can finally solve for $x_3$ :

x_3 = m^2 - x_1 - x_2

Finding the y-coordinate of the third point

Finally, to solve for $y_3$ , we just plug everything into the equation of the line:

y_3 = mx_3 + \beta

What if the two points on the curve are equal to each other?

So, what if two points on the curve are equal to each other.

This would mean that if we naively plug in $m = \frac{y_2 - y_1}{x_2 - x_1} = \frac{0}{0}$ , which is indeterminate.

This means that we will need to think outside the box.

A primer on differential calculus

The trick to do is to pretend that we have a point that slightly differs on the curve, where the difference is so small, it may as well be 0, but we still get the slope of it.

I'm not going to go over the entire math behind it. But the gist of it goes like this.

Given some function $f$ , we want to find the instantaneous rate of change with respect to its input.

That is, as some value $a$ approaches the input $x$ of $f(x)$ , we will get the differentation at point $x$ , written as $\frac{d}{dx}f(x)$ , defined as the limit of $\frac{f(x) - f(a)}{x - a}$ , as $a$ approaches $x$ .

As a short-hand, the above can be written like so:

\frac{d}{dx}f(x) = \lim_{a\rightarrow x}\frac{f(x) - f(a)}{x - a}

Alternative as some value $h$ approaches $0$ , we will get the differentation at point $x$ , written as $\frac{d}{dx}f(x)$ , defined as the limit of $\frac{f(x + h) - f(x)}{x + h - x}$ , as $h$ approaches $0$ .

It can be abbreviated to:

\frac{d}{dx}f(x) = \lim_{h\rightarrow 0}\frac{f(x + h) - f(x)}{x + h - x} = \lim_{h\rightarrow 0}\frac{f(x + h) - f(x)}{h}

Effectively, $\frac{d}{dx}f(x)$ is giving you the slope of some line at point $(x, f(x))$ .

We're just going to go over one example, and afterwards, I'm just going to include some common patterns that have been discovered.

The beauty of the "limit" operator as denoted by $\lim_{x\rightarrow a}f(x)$ is saying that we want to know what does the expression $f(x)$ tend to as $x$ approaches $a$ . We might not know much about the value at $a$ , but we can give something that is pretty much the answer that we have been looking for.

This is great for functions where a function is not defined at $a$ .

Let's take the function $\frac{x^2}{x}$ . The function $\frac{x^2}{x}$ is indeterminate at $x = 0$ , even though $\frac{x^2}{x} = x$ . So, the limit expression $\lim_{x\rightarrow 0}\frac{x^2}{x}$ is saying that we are going to find some expression that $\frac{x^2}{x}$ approaches as $a$ approaches $0$ . And the limit operator will help us reveal that the limit of $\frac{x^2}{x}$ as $x$ approaches $0$ is simply 0.

\lim_{x\rightarrow 0}\frac{x^2}{x} = \lim_{x \rightarrow 0}x = 0

Now onto computing an ifinitesimally small change in x to find the slope at $x$ .

Let's take the example of $f(x) = x^2$ . The slope at $x$ is derived as follows:

\begin{equation} \begin{split} \frac{d}{dx}x^2 &= \lim_{h\rightarrow 0}\frac{(x + h)^2 - x^2}{h} \\ &= \lim_{h\rightarrow 0}\frac{x^2 + 2xh + h^2 - x^2}{h} \\ &= \lim_{h\rightarrow 0}\frac{2xh + h^2}{h} \\ &= \lim_{h\rightarrow 0}(2x + h) \\ &= \lim_{h\rightarrow 0}2x + \lim_{h\rightarrow 0}h \\ &= 2x + 0 \\ &= 2x \end{split} \end{equation}

Therefore $\frac{d}{dx}x^2 = 2x$ .

There are many more rules like this.

Here's a handful of rules:

Constant rule: $\frac{d}{dx}c = 0$
Identity rule: $\frac{d}{dx}x = 1$
Sum rule: $\frac{d}{dx}\sum_f^{F}f(x)=\sum_f^F\frac{d}{dx}f(x)$
Product rule: $\frac{d}{dx}(f(x)g(x)) = f(x)\frac{d}{dx}g(x)+(\frac{d}{dx}f(x))g(x)$
Chain rule: $\frac{d}{dx}f(g(x)) = \frac{d}{dg(x)}f(g(x))\frac{d}{dx}g(x)$

Then we can compose those above rules to create more rules.

For example, the coefficient rule is a combination of the constant rule and product rule:

\frac{d}{dx}cf(x) = c\frac{d}{dx}f(x) + (\frac{d}{dx}c) f(x) = c\frac{d}{dx}f(x) + 0f(x) = c\frac{d}{dx}f(x)

And then, there is the positive integer power rule, which is just the product rule recursively applied, all the way until we reach the identity and constant rule.

I'll leave it as a exercise to prove that the positive integer power rule is pretty much $\frac{d}{dx}x^n = nx^{n-1}$ , e.g. $\frac{x}{dx}x^3 = 3x^2$ .

Deriving the slope of the line at a point on the elliptic curve

OK, now that we have summarized some differentiation rules above, let's go ahead and derive the equation of the curve that will help us find the slope of the line tangent to a point curve.

Recall that the equation of the curve is defined as:

y^2 = x^3 + ax + b

Also recall that $\frac{d}{dx}f(x)$ is the slope of the point at $(x, f(x))$ , pretending that we're trying to find a slope of the points $(x, f(x))$ and $(x + h, f(x + h))$ , as $h$ approaches 0.

In math terms, we're looking for some $m$ such that:

m = \lim_{h \rightarrow 0} \frac{f(x) - f(x + h)}{x + h - x}

In the equation of the curve, we're actually trying to find the change in $y$ with respect to $x$ .

This means we're trying to find $m = \frac{dy}{dx}$ .

We're going to apply the $\frac{d}{dx}$ operator on both sides of the equation.

\frac{dy^2}{dx} = \frac{d}{dx}(x^3 + ax + b).

Trying to find $\frac{dy^2}{dx}$ , and then ultimately derive $\frac{dy}{dx}$ will require some clever hacks. We'll get back to it later.

Let's start with the right-hand side.

\begin{equation} \begin{split} \frac{dy^2}{dx} &= \frac{d}{dx}(x^3 + ax + b) \\ &= \frac{d}{dx}x^3 + \frac{d}{dx}ax + \frac{db}{dx} \\ &= 3x^2 + a\frac{d}{dx}x + 0 \\ &= 3x^2 + a \\ \end{split} \end{equation}

Therefore $\frac{dy^2}{dx} = 3x^2 + a$ .

Now, onto the left-hand side of the equation.

What we're interested in is what happens to $y$ for some $x$ . You can think of $y$ being a function of $x$ .

So, we can go with chain rule.

The chain rule will give the derivative as the product of the differentation $\frac{dy^2}{dy}$ and $\frac{dy}{dx}$

\begin{equation} \begin{split} \frac{dy^2}{dx} &= 3x^2 + a \\ \frac{dy^2}{dy}\frac{dy}{dx} &= \\ 2y\frac{dy}{dx} &= \end{split} \end{equation}

So, we get $2y\frac{dy}{dx} = 3x^2 + a$ .

And remember, we're trying to find $m = \frac{dy}{dx}$ .

So, isolating $\frac{dy}{dx}$ from the resulting equation and we get:

\frac{dy}{dx} = m = \frac{3x^2 + a}{2y}

What if the two points are vertical reflections of each other?

At this point, we stop.

We just assume the result is a point at infinity.

And recall that "adding" a point $P$ to a point $Q$ that is a mirror reflection of $P$ is as if $Q = -P$ , and $P + Q = P + (-P) = P - P = \infty$ .

Summary of elliptic curve "addition"

When two points are different, for $P = (x_1, y_1)$ and $Q = (x_2, y_2)$ the slope is simply defined as:

m = \frac{y_2 - y_1}{x_2 - x1}

And for $P = Q$ , then we use the derivative:

m = \frac{3x^2 + a}{y2}

The $y$ -intercept of the line is defined as:

d = y_1 - mx_1

Finally, to find the third point:

y_3 = mx_3 + \beta

And if $Q = -P$ , then we do nothing, and just have the "addition" yield the point at infinity.

Relating back to Abelian groups

Commutativity

As we can see, drawing a straight line that crosses between two points $P$ and $Q$ also crosses a third point on the curve. This is true regardless of from which direction you decided to draw that line. Did you decide to have that line cross $P$ first, or $Q$ first? The result is the same! The order doesn't matter.

Associativity

What's cool about this is that we can also apply this operation with three points $P$ , $Q$ , and $S$ .

Regardless of if you start by attempting to find some $R_1$ by first drawing a line through $P$ and $Q$ , or through $Q$ and $S$ , after you've drawn a line through $R_1$ and the remaining point where you didn't "add" yet, you'll still get the same $R_2$ .

Not convinced?

Stay tuned for the proof.

Identity element

This is where Mathematicians used their imagination.

It may sometimes be emphasized that $P$ and $Q$ shouldn't be vertical reflections of each other?

What happens if they are?

The resulting line will never intersect anywhere on the curve in affine geometry, but instead will intersect at a point at infinity in projective geometry, which we will denote as $\infty$ .

It may sound blasphemous, but there is an important opportunity for us here.

For one, we can treat this as the "identity element".

Imagine if $P$ and $Q$ were indeed vertical reflections of each other.

Then computing $P + Q$ will give us $\infty$ .

How can we use the fact that there exists some $\infty$ that we can play around with?

Well, imagine if we have $P$ , and draw a perfectly vertical line that crosses $P$ .

It will of course go on for $\infty$ . We can think of this as $P + \infty$ . Now, the thing about crossing $P$ and $\infty$ , it will also cross some point that is a reflection of $P$ .

And remember the operation: the idea is, once we've crossed a third point, we reflect vertically!

This means that crossing $P$ and $\infty$ will cross the vertical reflection of $P$ , which we will call $P'$ , and doing so will require flipping vertically, thus giving us $P$ again.

This means that $P + \infty$ yield $P$ , or $P + \infty = P$ .

Existence of an inverse

I've already mentioned earlier that if $P$ and $Q$ were vertical reflections of each other, then we get some point at infinity denoted as $\infty$ . In other words $P + Q = \infty$ , only if $P$ and $Q$ are vertical reflections of each other.

But if $P + \infty = P$ , is there a $P - P = \infty$ ?

Yes!

If $P$ is a vertical reflection of $Q$ , then this merely means that $Q$ could simply be denoted as $-P$ .

In other words, "negation" is merely the act of vertically reflecting $P$ .

Bonus: Proof of Associativity

Commutativity is obvious: regardless of which direction you start to draw the line between $P$ and $Q$ , you will always land on the same point $-(P + Q)$ .

But associativity is a bit more tricky.

For many, it's not enough to look at a drawing and be satisfied by the associative properties. Is there a case for some $P$ , $Q$ , and $R$ , such that $(P + Q) + R \neq P + (Q + R)$ ?

Fortunately, we have proof that this will not be the case.

Using Bezout's Theorem

Given two polynomials of degrees $m$ and $n$ , then they will intersect at exactly $mn$ points (counting multiplicity), and no more unless they have a component in common.

If we are to draw lines that are the result of summing $(A + B) + C$ , we see that it yields 3 lines, and all 3 lines will intersect at exactly 9 points.

Likewise for $A + (B + C)$ .

If we are to treat both sets of lines as curves on a projective plane, then both sets of lines can be thought of as cubic polynomials, and all of them will intersect at exactly 9 points, including the points crossing $(A + B) + C$ and $A + (B + C)$ .

Using Cayley-Bacharach theorem

Given three points $P$ , $Q$ , and $R$ on an elliptic curve, we aim to show that $(P+Q)+R=P+(Q+R)$ .

To prove associativity, we will utilize the Cayley–Bacharach theorem, which asserts that for any cubic curve over an algebraically closed field, if the curve passes through any eight points, it also passes through a ninth point (counting multiplicities), including the point at infinity.

Consider the set of points: $R$ , $P + Q$ , $P$ , $Q$ , $−(P + Q)$ , $Q + R$ , $−(Q + R)$ , and the point at infinity. Suppose we construct two lines: one passing through $P$ and $Q$ intersecting the curve again at $P+Q$ , and another passing through $Q$ and $R$ intersecting the curve again at $Q + R$ . By reflecting these sums $P + Q$ and $(Q + R)$ about the curve, we obtain points $−(P+Q)$ and $−(Q+R)$ .

These intersections provide us with two groups of lines whose intersections with the cubic yield eight distinct points (considering each pair of points contributes an intersection). By the Cayley–Bacharach theorem, any cubic passing through these eight points must also pass through a ninth point, which is exactly where $(P+Q)+R$ intersects the curve, and also where $P+(Q+R)$ intersects.

If these points were different, the sets would intersect at a tenth distinct point, violating Bézout's theorem, which states that a line and a cubic can intersect at no more than three points. Thus, we conclude that $(P+Q)+R=P+(Q+R)$ , proving associativity.

How the Cayley-Bacharach theorem work

By Bezout's Theorem, we're effectively saying that two cubics $C_1$ and $C_2$ in projective space with no common components will intersect at $9$ points (counting with multiplicity). If a $C_3$ passes through all 9 points (counting multiplicity) of the intersections of $C_1$ and $C_2$ , then $C_3$ can only be expressed as the linear combination $a_1C_1 + a_2C_2 = C_3$ , where $a_1,a_2 \in \mathbb{F}$ , by the properties of projective geometry. That is, the degrees of freedom has been restricted to only pass through the $9$ points.

Building on this, the Cayley-Bacharch theorem further refines our understanding of these intersections. The Cayley-Bacharch theorem implies that if $C_3$ shares eight of the nine intersections of that of $C_1$ and $C_2$ , then it must also pass through the ninth intersection point.

Applying this back to the intersections of 3 lines with the curve, what we're trying to do is that if we have a curve, intersect 3 lines on that curve, then constructing a third curve will necessarily require that the third curve is a linear combination of the curve and the 3 lines.

The general idea is, once the first 8 points have already been selected, the degrees of freedom that we now have is highly constrained, to the point that all three curves are linearly dependent on all 9 points.

N.B. multiple lines on a plane forms a polynomial

So earlier I seemed to have treated distinct lines as a single polynomial curve.

Is that even legal?

Yes.

We're all familiar with the equation of the line of the form $y = mx + \beta$ .

But there is nothing stopping us from interpreting it as the impiclit equation $0 = mx + \beta - y$ .

As we can see, that equation of the line is effectively a polynomial. What happens if we compute the product of several lines to give us a polynomial, that is for example $(m_1x+b_1)(m_2x+b_2)(m_3x+b_3) = 0$ ?

Well, if we are to plot out the result of the implicit polynomial, this would yield a curve that looks no different than as if all lines were entirely distinct!

Try it out yourself.

Elliptic curve in finite fields

In the above derivations, if you are familiar with high school math, you'd think that we were working with real numbers.

Yes, perhaps the math would work with real numbers.

But the math would work with whatever math there is with a concept known as "field".

Real numbers are fields.

But cryptography doesn't always work with real numbers.

What they instead work with is finite fields of prime order.

Problem: computers are really bad with real numbers

Computers are really bad with real numbers.

Yes, two CPUs implementing the exact same architecture will come up with the same exact numbers, given the same exact set of instructions, but not everyone is on the same CPU architecture. At the time of writing this, people on their laptops are often on Intel-based systems. Apple has made the push for something based on ARM. And a lot of smartphones are also on ARM-based CPUs. And not to mention, RISC-V is a new contender in the CPU architecture space.

Every one of them will give you different results.

Not to mention, different implementation details will ultimately end up yielding different results. And even small discrepancies can really throw everything off.

Solution? Work exclusively with integers?

We could perhaps ditch real numbers and aim for integers.

But here's the problem with integers: they don't have a very good definition for a multiplicative inverse.

The division problem

Before we start computing divisions of integers, we got to ask ourselves: what is a divison?

Well, as far as humans and counting is concerned, divisions is just trying to discover how many times can one number fit into another.

For example, how many times can $3$ fit into $12$ ? The answer is $4$ .

But if we are to think strictly in terms of group theory, a divison $\frac{a}{b}$ is to take some $a$ and multiplying it by the multiplicative inverse of $b$ . That is, the multiplicative inverse of $b$ is some quantity $c$ such that $bc = 1$ , which is impossible with integers.

Group theory and the multiplicative inverse

Recall that in an Abelian group, we have four properties:

Commutativity
Associativity
Identity element
Inverse

With integer addition and multiplication we get commutativity and associativity. We may have an identity element with additions, but multiplications? What do we get?

Well, we still get 1, but if we are to multiply two integers $a$ and $b$ , can we ever get the number $1$ ?

Of course, with integers this is literally impossible.

Forget real numbers; forget integers. Finite fields of prime order is here to save the day

So we just found out we may have some "identity" element with integers. But we lose the multiplicative inverse with integers. That is, there can never exist two integers $a$ and $b$ where their product will yield $1$ .

This is where we ditch real numbers and the integer space, but instead work with another much smaller integer space called finite fields of prime order.

Working within a finite field means to work with integers $0$ to $p - 1$ , where $p$ is a prime number.

The math with finite fields is very similar to integers and real numbers, but like elliptic curve groups, the "+" operator and—now—multiplication works slightly differently.

All operations not only give the "addition" (as intuitively understood by the act of addition, since we were taught in elementary and high school), but additions greater than equal to the prime $p$ wraps around.

For example, given some finite field with prime $p = 13$ , the sum $10 + 4$ would yield $1$ . The expression is similar to the integer arithmetic $(10 + 4) \text{ mod } 13 = 1$ , but mathematicians prefer to "abbreviate" things using the congruence $10 + 4 \equiv 1 \text{ }(\text{mod } p)$ , with—in our— $p = 13$ .

With finite fields, we most certainly have Abelian group properties, for both the additive and multiplicative groups, but the multiplicative aspects also has one additional property: distributivity.

That is, $a(b + c) = ab + ac$ .

Finite fields actually saving the day for multiplicative inverses

Other than distributivity, we also retain the one important property: multiplicative inverse.

That is, given some $a$ , we can find some $b$ such that:

ab \equiv 1 \text{ }(\text{mod } p)

Again, this is possible, because the modulo operator forces everything to just "wrap around", and we want to find some $b$ (the multiplicative inverse of $a$ ) such that their products "wrap around" to the value $1$ .

Notation for multiplicative inverse

In real numbers, the expression $\frac{1}{a}$ can also be expressed as $a^{-1}$ .

Likewise for finite fields.

And better yet, we can express the property of the multiplicative inverse as:

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

Modular arithmetics

OK, so I used the $\text{mod}$ operator previously.

For those not familiar with that operator, it's pretty much a facet of math that we were taught roughly around the 4th grade.

It's the idea of "division with remainder". This "4th grader math" has the fancy name "Euclidean division", which is named after the mathematician who is known for having formalized and documented it in his work.

It goes like this: take for example the division $10$ divided by $4$ .

$4$ does not divide $10$ .

But $4$ does fit into $10$ up to $2$ times, which would yield the number $8$ . What remains is $2$ .

The $\text{mod}$ operator only cares about the remainder in a Euclidean divison, which in the case of the division $10$ divided by $4$ , the modulo $10 \text{ mod } 4 = 2$ .

Multiplicative inverses in finite fields

OK, with finite fields, we can most certainly have an $a$ and a $b$ such that their product yields $1 \text{ }(\text{mod } p)$ (where $p$ is a prime). Such an operation is literally impossible with integers, but possible with finite fields.

But now, how do we find the multiplicative inverse?

Perhaps using the greatest common divisor ( $\text{gcd}$ )?

For the record, the $\text{gcd}$ function takes two integers, and attempts to find their greatest common divisor.

So, if we are to pick some integer $0 < a < p$ , where $p$ is prime, then the $\text{gcd}(a, p) = 1$ .

We may be onto something.

There's also Bezout's identity.

It stipulates that the $\text{gcd}(a, b)$ is the linear combination:

ax + by = \text{gcd}(a, b)

That is, we can find some x, and some y, such that the above linear combination holds true.

But in the case of $a$ and $p$ , where—recall that— $p$ is prime, we get:

ax + py = \text{gcd}(a, p) = 1

If we compute the modulo of both sides, we get

(ax + py) \text{ mod } p = ((ax \text{ mod } p) + (py \text{ mod } p)) \text{ mod } p

In the above equation, because $py$ is a multiple of $p$ , then $py \text{ mod } p$ effectively "wraps" around to $0$ .

So then

((ax \text{ mod } p) + (py \text{ mod } p)) \text{ mod } p = ((ax \text{ mod } p) + 0) \text{ mod } p = (ax \text{ mod } p)

And thus

ax + py \equiv ax \equiv \text{gcd}(a, p) \equiv 1 \text{ }(\text{mod } p)

The multiplicative inverse

To find the multiplicative inverse, we can take full advantage Bezout's Identity.

Again, in modular arithmetic:

ax + py \equiv \text{gcd}(a, p) \equiv 1 \text{ }(\text{mod } p)

And remember $py \equiv 0 \text{ }(\text{mod } p)$ cancels out, so we're left with:

ax \equiv \text{gcd}(a, p) \equiv 1 \text{ }(\text{mod } p)

We can then use the extended Euclidean algorithm to derive Bezout's identity.

And remember, the whole idea of the multiplicative inverse is that there exists some $a$ and $b$ , such that their product yields $1$ . This means, using Bezout's identity, we can effectively find the multiplicative inverse quite easily.

Euclidean algorithm

Before we talk about the extended Euclidean algorithm, let's first talk about the Euclidean algorithm.

The Euclidean algorithm is just a fancy word for an algorithm that repeatedly applies the Euclidiean division between a dividend and divisor, all the way until we reach 0.

The Euclidean algorithm can be succinctly defined as the recurrence:

\text{gcd}(a, b) = \begin{cases} a &\text{if } b = 0 \\ \text{gcd}(b, a\text{ mod } b) &\text{otherwise} \end{cases}

Extended Euclidean

We've seen a very simple algorithm to compute the greatest common denominator of two (positive) integers.

Now onto the extended Euclidean algorithm, which should help us find the coefficients $x$ an $y$ in Bezout's identity, $ax + ay = gcd(a, b)$ .

If $a$ and $b$ isn't a representation of the base case (that is $b = 0$ ), then the above equation can also be expressed as:

ax + by = gcd(a, b) = gcd(b, a \text{ mod } b)

But, careful, just because $gcd(a, b) = gcd(b, a \text{ mod } b)$ , doesn't mean that $ax + by$ is $bx + (a \text{ mod } a)y$ .

Instead, the $x$ and the $y$ are something different, so we'll use $x'$ and $y'$ , that is:

ax + by = bx' + (a \text{ mod } b)y' = gcd(a, b)

So, we will need to do more algebraic manipulation to make finding $x$ and $y$ easy.

The trick would be to look at one definition of the modulo operator.

One plausible definition of the operator $a \text{ mod } b$ is

a - \lfloor\frac{a}{b}\rfloor b = (a \text{ mod } b)

So we can rewrite the above equation representing one level below the start of the recursion as:

\begin{equation} \begin{split} bx' + (a - \lfloor\frac{a}{b}\rfloor b)y' &= bx' + ay' - \lfloor\frac{a}{b}\rfloor by' \\ &= ay' + b(x' - \lfloor\frac{a}{b}\rfloor y') \\ &= gcd(a, b) \end{split} \end{equation}

Now we see that

ax + bx = ay' + b(x' - \lfloor\frac{a}{b}\rfloor y')

And we can see that $x = y'$ and $y = x' - \lfloor\frac{a}{b}\rfloor y'$ .

Of course, the expression $ay' + b(x' - \lfloor\frac{a}{b}\rfloor y')$ doesn't really tell us much about $x$ and $y$ itself. But, we will get a good insight once we reach the base case.

Recall that going one level below the recursion to gives us $ay' + b(x' - \lfloor\frac{a}{b}\rfloor y')$ which is also equal to $bx' + (a \text{ mod } b)y'$ .

We can clearly draw the parallel between $gcd = gcd(b, a \text{ mod } b)$ . So not only does $\text{gcd}$ have a base case, but so will the recurrence equation.

Once we reach the base case, we'll just set $x' = 1$ , and $y'$ shouldn't matter, since $b$ is equal to zero.

We're going to write some psuedopython to represent the recurrence.

We're not actually going to return some equation. Instead, we're just going to return the $x$ , and $y$ coefficients.

def extended_gcd(a, b):
    if b is 0:
        return (1, 1)
    x1, y1 = extended_gcd(b, a % b)
    return (y1, x1 - (a//b)*y1)

Divisions in finite field

In real numbers, divisions are just that: divisions.

With integers, I did mention divisions become problematic when attempting to naively divide two numbers as if we were trying to divide real numbers.

For example, $\frac{10}{4}$ yields $2.5$ in real numberes, but things get awkward in integers.

Recall also that in real numbers, that there indeed exists some $a$ and $b$ such that $ab = 1$ . This is because a multiplicative inverse for $a$ exists in real numbers. Nothing like that exists in integers.

And this is why we use finite fields.

Finite field math is often coupled with modular arithmetics, and modular arithmetics pretty much has things "wrap around". With the help of the extended Euclidean algorithm, when attempting to find the modular inverse of $a$ , we're looking for something that when multiplied by it, the product will "wrap around" to $1$ .

I've also mentioned that a notation for $\frac{1}{a}$ in real numbers is $a^{-1}$ , and we can do the same in finite fields.

Better yet, many mathematicians express the congruence $aa^{-1} \equiv a^{-1}a \equiv 1 (\text{mod } p)$ (where $p$ is prime) as just

\frac{a}{a} \equiv 1 \text{ }(\text{mod } p)

This brings us to divisions in finite field.

Divisions in finite field simply involves finding the multplicative inverse of the denominator (a.k.a. the divisor). Once found the multiplicative inverse, we take that value and multiply the "dividend" with the computed multiplicative inverse.

The cyclic group

Elliptic curves in finite field forms not only an Abelian group, that is, it satisfies the commutative, associative, identity, and inverse properties, but it also forms a cyclic group.

What it means for something to be a cyclic is that there exists some element in the group—called the Generator—such that its scalar multiplication or exponentiation yields every element in the group.

In the case of elliptic curves, given the coefficients $a$ and $b$ for the Weierstrass equation, and the prime field, there exists a finite number of points on the curve, denoted as $n$ . In a lot of these curves, ther could exist one point $G$ on the curve such that for every coefficient $d$ in ${0, 1, 2, \ldots, n}$ , the multiple $dG$ will yield every point on the curve. In this case, $G$ is known as the generator.

Putting it all together

We've defined the math of finding a third point on an elliptic curve. The act of flipping that "third point" on the curve vertically is the algorithm of an elliptic curve group "addition".

Now that we know about the math, let's put this all together with finite field math.

Recall that real numbers form a field.

Not only is the computation of a third point on the curve can be done in the real number field, but we can also do the same computation with finite field of prime order. Since finite fields are fields, the curve equation works perfectly with finite fields.

The only difference being that everything happens modulo a prime for the finite field, and that division isn't simply the act of finding how many times the divisor fits inside the dividend, but instead, we compute the multiplicative inverse, such that the product of the divisor $a$ by the multiplicative inverse of $a$ yield $aa^{-1} \equiv 1 (\text{mod } p)$ (where $a^{-1}$ is the multiplicative inverse, and that $p$ is prime).

Application to cryptography

Elliptic curve group arithmetic in finite field of prime order is the math that is used to take full advantage of the hardness of the solution to the discrete log problem. And because it is known to be difficult to solve (on a classical computer), it is an excellent cryptographic primitive for various cryptographic schemes in cybersecurity applications.

First thing's first: public and private keys

The discrete log problem stipulates that given some 2-parameter group operation (such the elliptic curve "addition"), given some positive integer $d$ , and a group element $G$ , we can compute the scalar multiplication $nG = R$ , where having access to $G$ and/or $R$ is not at all adequate to find the integer $d$ . In order to recover $d$ , we will actually need to physically steal it.

Thus, the integer $d$ can be regarded as private information, and $G$ , and $R$ can be shared publicly.

In real-world applications, $G$ is typically some standardized parameter, such as the G variable that is defined in the secp256r1 specification. Thus $G$ is never explicitly shared by either communicating parties, but instead has been agreed upon, and already known by everyone, and ahead of time.

The only thing that "belongs" to someone is the scalar multiplication $nG$ . For example, Alice can generate her secret number $d_A$ , and she can use it to derive $d_A G$ . She would share the result of the scalar multiplication $d_A G$ , but she will never share $d_A$ on it's own; it's a secret. Again, by the nature of the hardness of the discrete log problem $d_A$ can never be extracted from $d_A G$ .

In the real world, $d_A$ is the private key, and $d_A G$ is the public key.

The curve parameters

When Alice and Bob wants to engage in a transaction that involves elliptic curves, it is a good idea for them to work with provably secure parameters that many applications are aware of.

Earlier I mentioned "secp256r1".

secp256r1 is an example of standard curve parameters.

It stipulates

the order of the finite field $p$ (the prime number that represents the order of the field, which is the total number of elements in the field)
the value of the $a$ and $b$ coefficients of the equation in Weierstrass form
the generator point $G$

The parameters also includes numbers that would have otherwise needed to be computed, such as the order of the curve $n$ –which is the total number of points on the curve, including the point at infinity.

In fact, the $n$ will be the most helpful, since it's ideal if coefficients avoid ever equaling $n$ , since doing so will yield the point at infinity.

How these points are chosen

Typically, cryptographers would pick some arbitrary prime $p$ , and points $a$ and $b$ . Then count the total number of points on the curve to derive $n$ . If $n$ is a prime, there would only ever be one cyclic subgroup, and thus one generator $G$ , such that multiplying it with every value $d$ in ${1, 2, 3, \cdots n}$ will yield every point on the curve, including the point at infinity.

Next is to find some point $G$ such that $nG$ yields the point at infinity.

Thus we have our $a$ , $b$ , and $p$ parameters of our curve, and the derivations of the order $n$ , and our generator $G$ , such that $nG = \infty$ .

Key exchange, for encryption

ECC isn't typically used for encryption.

That said, we can use ECC for deriving a shared secret, which is then used against a symmetric cipher, such as AES.

So we've established that extracting the scalar coefficient in an elliptic curve scalar multiplication is prohibitively difficult to do.

We've also established that ellitpic curve arithmetic forms an Abelian group, with associative properties.

This means that not only can Alice derive her public key $d_A G$ , but she can then send it to Bob, so that Bob, using his private key $d_B$ can derive $d_B d_A G$ . And Bob can likewise send his public key $d_B G$ to Alice, and she can then compute $d_A d_B G$ .

And due to the commutative nature, $d_A d_B G = d_B d_A G$ .

Both Alice and Bob should land on the same value on the Elliptic curve, and neither of them will have ever shared $d_A$ nor $d_B$ , and no one can extract those values.

How shared secrets are used

Typically, once the shared curve point on an elliptic curve has been established, the $x$ -coordinate of the curve point is used as the input to a key-derivation function (KDF).

Typically, the KDF used is HKDF. It has the most provable security, and it is strongly resistant against key material weakness.

For HKDF, we need some cryptographically-secure salt, and our derived $x$ -coordinate from our key exchange. Once derived, we should then have a secure key, from which it is impossible to derive the shared $x$ -coordinate.

The derived key and a plaintext is then input into a cipher, such as AES-256-GCM (of course, along with cryptographically-random initialization vector).

The decryptor will then take the derived key to decrypt the message.

Digital signatures

Digital signatures involves having Alice prove that she sent a message, by "signing" it using her private key, and Bob can then "verify" the signature against the message using Alice's public key.

The most widely used digital signature algorithm is ECDSA.

This is how it works.

Let's say Alice wants to send a message $m$ to Bob, and she signs it using her private key $d_A$ .

Alice would send to Bob two values, represented in the following tuple:

(r, s) = ((kG)_x, \frac{\text{HASH}(m) + (kG)_xd_A}{k})

Where $k$ is a totally random number between $1$ and $n - 1$ , and $\text{HASH}$ is some hash function such as $SHA-256$ .

And note: that tuple does not represent any point on the curve! $r$ and $s$ are two distinct values.

Alice sends $(r, s)$ to Bob, and when Bob wants to verify the signature using Alice's public key $Q_A$ , he'd compute

\frac{\text{HASH}(m)}{s}G+\frac{r}{s}(Q_A) = R

Bob will absolutely know that the signature is valid if $R_x = r$

How digital signature verification works

Even though Bob has no clue about the values $k$ and $d_A$ that was used by Alice to compute how $r$ and $s$ , but as long as Bob is aware of the overall algorithm, he can know how to derive $kG$ , even if he doesn't know $k$ .

Expanding the above $\frac{\text{HASH}(m)}{s}G+\frac{r}{s}Q_A$ , we get

\frac{\text{HASH}(m)}{s}G+\frac{r}{s}Q_A = \frac{\text{HASH}(m)}{\text{HASH}(m)+(kG)_xd_A}kG + \frac{(kG)_x}{\text{HASH}(m)+(kG)_xd_A}kd_AG

From the above equation, we can factor out $\frac{kG}{\text{HASH}(m)+(kG)_xd_A}$

\frac{\text{HASH}(m)}{\text{HASH}(m)+(kG)_xd_A}kG + \frac{(kG)_x}{\text{HASH}(m)+(kG)_xd_A}kd_AG = (\text{HASH}(m)+(kG)_xd_A)\frac{kG}{\text{HASH}(m)+(kG)_xd_A}

Then the denominator cancels out parts of the nominator, and finally all we are left with is $kG$ , from which, the $x$ -coordinate should equal to Alice's supplied $r$ .

Conclusion

Elliptic curve cryptography leverages group operations on an elliptic curve in finite fields of prime order, in projective plane geometry.

Multiplying the generator $G$ of the curve by some $d$ will yield some point $dG$ in $O(log_2n)$ time by taking advantage of elliptic curve Abelian commutative properties, without ever revealing to anyone what $d$ is. Most importantly, there are no known efficient algorithm to recover $d$ without an exhaustive search. In other words, easy to compute one way, but hard to go the other, which is the basis of most cryptosystems.

We're then able to exploit this property and use it in various cryptographic use cases. The simplest example is deriving a shared secret between Alice and Bob, by having them share each other's publicly available point on the curve, then having each of them then multiply it with their own secret number to derive the shared secret.

Sharing what I learned about limits

Sun, 11 Aug 2024 07:00:00 GMT

So, I was trying to employ the Feynman technique to learn about differentiation of a continuous function, or better yet, be capable of teaching it (so this is more of an inverse of the Feynman technique, I guess?).

For context, when a lay-person looks up how to differentiate a function, they are presented with a bunch of math symbols, confusing them, and ultmately having them give up.

So, I basically went out on a mission to understand differentiation, but I was stuck on the definition of a limit.

I honestly felt stupid the entire time, but I was happy to find out that it is a common problem: people struggle to understand it. Someone even said that people don't understand limits until they get to grad school.

Now that's good to know.

But that doesn't solve the problem.

Good thing is, I think I figured it out, and this article will share what I learned.

The limit

One aspect of the limit that had me stuck was the misconception that one function can equal to another function, no matter how much it intuitively seems that one function does not equal another.

In college, for example, I'd watch instructors confidently state $\lim_{x\rightarrow 0} \frac{x^2}{x} = 0$ , which gave me the incorrect perception that $\frac{0^2}{0} = 0$ .

But that's not what that limit expression is saying at all.

What that limit operator in $\lim_{x\rightarrow a} f(x)$ is saying is that it is giving you something that is really close to the expression $f(x)$ , as $x$ aproaches $a$ , that there isn't really much else that can come close to it. And that thing that it is giving you is called the limit.

Sounds like nonesense

So it's good to know that the concept of attempting to find the limit isn't saying that a particular expression exactly equals another. Instead, it's saying that as a variable $x$ comes close to something, the expression $f(x)$ comes close to something else—which is known as the limit.

This is all well and good.

But for many of you unfamiliar with calculus, you may be reading this and thinking that this sounds nonsense.

The good news is, you aren't alone.

When calculus was first introduced independently by Isaac Newton and Gotfriend Leibniz, people did express skepticism of their approach to differentiation. Yes, mathematicians still did adopt those discoveries, but there were still doubts at that time.

This is where Karl Weierstrass formally gave a definition of a limit, removing all uncertainty…

Except, fast forward today, and many of us still don't quite understand the most accepted definition of a limit, until much later in life.

Definition of a limit

So what is that definition of a limit that everyone seems to be so confused about?

It goes like this:

$f(x)$ approaches the limit $L$ , as $x$ approaches $a$ , if and only if for every $\epsilon > 0$ , there exists a $\delta > 0$ such that if $x$ is within $\delta$ distance away from $a$ , then it must follow that $f(x)$ is within $\epsilon$ distance from $L$

To put it in math terms, the above would translate into:

\lim_{x \rightarrow a} f(x) = L \Longleftrightarrow \forall_{\epsilon > 0}\exists_{\delta > 0} 0 < |x - a| < \epsilon \rightarrow |f(x) - L| < \delta

So what that is effectively saying is that if you are to have $x$ freely move within $\delta$ distance from $a$ , then this act of moving around should have $f(x)$ move no further than $\epsilon$ distance from $L$ .

Of course, we're only asking for one $\delta$ for each $\epsilon$ , so it doesn't make sense to choose a $\delta$ first. Instead, we iterate across all possible $\epsilon$ , and we search for a $\delta$ that will satisfy the implication. If no such $\delta$ is found, vacuously, the existential quantifier that one $\delta$ must exist fails, and a candidate limit is not the limit of the expression.

Example

For people who asked "how come $\lim_{x\rightarrow a}\frac{x^2}{x}$ is $a$ and not something like $a^2$ ?", that is an excellent question.

If we are to follow the definition of the limit to the letter, we can set $a = 4$ as an example, which has $|x - a^2| < \epsilon \rightarrow |x - 4^2| < \epsilon \rightarrow |x - 16| < \epsilon$ as the conclusion. Regardless of what $\delta$ we pick for some $\epsilon$ , there will always be some value of $x$ that will fail to satisfy the conclusion, thus making the entire implication false. And remember, we need to satisfy not just some $\epsilon$ , but absolutly none of the $\epsilon$ should fail to have found a $\delta$ .

Thus

\lim_{x\rightarrow a}\frac{x^2}{x} \neq a^2

Conclusion

Mathematicians are fairly rigourous. For that they will never allow either side of an equation not equal to eachother.

That said, there are some quantities that would be interesting to study not necessarily equal to that point, but near it. And this study is the study of limit.

This is where the definition of a limit comes in, which should help elliminate ambiguities of what can and cannot be near a certain point.

Hopefully you have a better intuition now for what it is the study of limits involves.

First Post

Sun, 28 Jul 2024 07:00:00 GMT

For the longest time, I've been active on private Discord servers, posting microblog posts over to my Fediverse account, and any blog posts that I'd write online, I'd have it be hosted on dev.to.

I never really had a place to blog that I'd call my own.

Until now.

This is the new place where I'd post longer-form articles online. It's pretty much mine, with the caveat being the infrasture that these posts will be hosted on will likely not be something that I self-host on-premise. I'd likely rely on cloud providers, such as Netlify or Vercel.

At the time of writing this post, this blog is powered by Next.js, a metaframework for React to allow to statically render pages at build time, and serve those out to users. If I were to have use used React naively, without any metaframework that allows for build-time rendering, then there wouldn't have been any rendered pages, and instead, browsers would simply download a blank HTML page (e.g. nothing in the page), and a script tag to grab some scripts, which those will instruct the browser how to render the page.

Too slow, and those with JavaScript disabled on their browser will not be able to see the page.

This is different: the pages are pre-populated with content, as you can see here.

A bit about me

I'm Sal, I've been writing software since 2012. I've been fortunate enough to have gained a wealth of experience, from consulting for individuals, to working for fortune 500s. Through this blog, I hope to be able to share what I learn, and I hope to open things up to receive constructive feedback from people.

Looking forward to hearing what readers have to say about what I write.

Sal's Blog

Switching from Next.js to Astro

Onto Astro

What people forgot about React

What this means

My own experience

In Conclusion

Caveat

Helpful topic to teach yourself lattice-based crypto: cosets

Example with Integers

Helpful topic to teach yourself lattice-based crypto: subgroups and Lagrange's theorem

Helpful topic to teach yourself lattice-based crypto: groups

Important topic to teach yourself lattice-based crypto: rings and fields

Helpful topic to teach yourself lattice-based crypto: abstract algebra

A simple proof of the Cayley-Bacharach theorem

Proof

Monads in TypeScript

What are monads

A type for monad

Monad laws

Law 1: Left Identity

Law 2: Right Identity

Law 3: Associativity

Consequence of law 3.

Promises as monads

How is this useful?

More monad patterns

Conclusion

What I value more than clean code

What's the ideal metric instead of clean code, then?

Axioms for easy to reason about code

On ephemerality and code readability

Readable Code

Code ephemerality

Free yourself

Surely there is a time for clean code…

Why those should be "dirty code", too

Code as configuration

Ephemerality and AI

Conclusion

A cute Golang pattern

Primer on Elliptic Curve Cryptography

The Discrete Log Problem (or rather the Elliptic Curve Discrete Log Problem)

The operate\text{operate}operate function

Some math notations, and an introduction to Abelian groups

Abelian group scalar multiplications

The double and add algorithm

Possible Side-Channel attack

Why is it easy to go one way but hard the other

Math of drawing lines across elliptic curves

Projective Geometry

Finding the x-coordinate of the third point

Finding the y-coordinate of the third point

What if the two points on the curve are equal to each other?

A primer on differential calculus

Deriving the slope of the line at a point on the elliptic curve

What if the two points are vertical reflections of each other?

Summary of elliptic curve "addition"

Relating back to Abelian groups

Commutativity

Associativity

Identity element

Existence of an inverse

Bonus: Proof of Associativity

Using Bezout's Theorem

Using Cayley-Bacharach theorem

How the Cayley-Bacharach theorem work

N.B. multiple lines on a plane forms a polynomial

Elliptic curve in finite fields

Problem: computers are really bad with real numbers

Solution? Work exclusively with integers?

The division problem

Group theory and the multiplicative inverse

Forget real numbers; forget integers. Finite fields of prime order is here to save the day

Finite fields actually saving the day for multiplicative inverses

Notation for multiplicative inverse

Modular arithmetics

Multiplicative inverses in finite fields

The multiplicative inverse

Euclidean algorithm

The $\text{operate}$ function