Ode To Java And The Point At Infinity

Ode To Java And The Point At Infinity

And so Java is on the naughty step again. Basically, in Java 15, 16, 17 and 18, it allowed a zero value within the r and s values of an ECDSA signature. As it did not check for a zero value, it allowed gave a validate signature identification for a zero value for r and s. Luckily, languages such as Rust, make it plain that the ECDSA method that r and s are non-zero scalar values:

So, why is a zero scalar such a problem in elliptic curve cryptography (ECC)? Well, first we will do some of the basics.

So How Does ECC Work?

Well, let’s start by explaining the basics of ECC. For this, we start with an elliptic curve equation, such as:

y² = x³ + 7 (mod 17)

If we only have integer values for our points, we will get points at [here]:
(1, 12) (1, 5) (2, 7) (2, 10) (3, 0) (5, 8) (5, 9) (6, 6) (6, 11) (8, 14) (8, 3) (10, 2) (10, 15) (12, 1) (12, 16) (15, 4) and (15, 13).

We see that some of the x axis values are not possible. As an example if we take x=2, we get:

2³ + 7 (mod 17) = 15 (mod 17)

7² (mod 17) = 15 (mod 17)

and so we have a point at (2,7). In ECC, we then perform scalar operations, and where we take a point, and then add it a number of times. If we add a point G, n times, we get a new point on the curve at:

P=n.G

In ECC, we always get a new point on the curve (apart from one exception, which we will see later in the article). Normally, we then define a base point (G), and then operate on that point either with a scale (such as n.G) or where we add two points together (such as G+G). For the secp256k1 curve (as used in Bitcoin and Ethereum), we have a base point at (55066263022277343669578718895168534326250603453777594175500187360389116729240, 32670510020758816978083085130507043184471273380659243275938904335757337482424). If we add G and G, or determine 2.G, we get another point at [here]:

2.G= (89565891926547004231252920425935692360644145829622209833684329913297188986597, 12158399299693830322967808612713398636155367887041628176798871954788371653930)

In hexadecimal, this point is:

(0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798,  0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8)

And so we have two simple operations: point add and point multiply, and that these are the basis for our ECC methods. Normally we take a random scalar value (n) and define this as our private key, and then derive our public key (P) as:

P = n.G

If n is random and large enough, we could not be able to derive it, even if we have P and G.

So what about zero?

Everything has been plain up to now. ECC is a powerful and fast method for computing a public key. But what about x=0? We didn’t discuss that one! Well, if we let x equal zero, we will not find a y-axis point for this:

y² = x³ + 7 (mod 17)

So x=0 doesn’t exist! But if I have:

P = 0.G

what will I get? Well, this is:

P = 1.G — 1G

And which is as valid as our point additions. So let’s create a simple secp256k1 (K256) calculator in Golang. First, we determine 1.G:

A sample run of that gives:

Curve: secp256k1, Point: 79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798, 483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8

If we now modify the code for 2.G:

We get 2.G:

Curve: secp256k1, Point: c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5, 1ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a

But, what happens when we do a subtraction?

This is 1.G — 1.G, and will give us 0.G. The output is now:

Curve: secp256k1, Point: 0000000000000000000000000000000000000000000000000000000000000000, 0000000000000000000000000000000000000000000000000000000000000000

We have thus broken the rule that we should always get a valid point, as (0,0) does not exist for the secp256k1 curve. This point is actually defined as the point at infinity. But different types of curves represent this point in different ways. In sepc256k1 and P256, we get a point at (0,0).

Conclusions

And, so beware of the point at infinity, as it shouldn’t happen in normal calculations. If you want to try it out, try here:

For and for ECC:

https://asecuritysite.com/ecc