Curve point divided by integer - is it possible?

[NotATether]

I am building a secp256k1 class in Node.js to use in my tools, and I know that numbers in a group already have a multiplicative inverse - and how to calculate it - I have point multiplication already implemented but I am not sure if there is such a factor k^-1 such that

k^-1P * kP = P

Is it simply the inverse of k mod curve order n?

This is supposed to be to implement the division operation P/k.

Also - I don't think multiplicative inverse of points (i.e. P^-1, not group numbers) exists, does it?

[1714698196]

1714698196

[1714698196]

1714698196

[1714698196]

1714698196

[j2002ba2]

I am building a secp256k1 class in Node.js to use in my tools, and I know that numbers in a group already have a multiplicative inverse - and how to calculate it - I have point multiplication already implemented but I am not sure if there is such a factor k^-1 such that

k^-1P * kP = P

Modulo prime number for every number (except zero) there's unique inverse. That is, the sequence of all inverse is a permutation of all positive numbers.

Is it simply the inverse of k mod curve order n?

Since the curve order is n, then k^-1 is mod n as well.

This is supposed to be to implement the division operation P/k.

Also - I don't think multiplicative inverse of points (i.e. P^-1, not group numbers) exists, does it?

I cannot guess what you mean.

[NotATether]

This is supposed to be to implement the division operation P/k.

~

I cannot guess what you mean.

Basically, we can already do kP, so I want to know if P/k = k-1P is doable.

When I said:

Also - I don't think multiplicative inverse of points (i.e. P^-1, not group numbers) exists, does it?

I was wondering if two points could be multiplied with each other, as opposed to a point and a number e.g. P*Q.

[garlonicon]

Basically, we can already do kP, so I want to know if P/k = k-1P is doable.

Yes, of course. For example you can double a point or halve a point by multiplying it by 7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a1. It's that simple, for example after halving Satoshi's key you can get:

Code:

04 678AFDB0FE5548271967F1A67130B7105CD6A828E03909A67962E0EA1F61DEB6 49F6BC3F4CEF38C4F35504E51EC112DE5C384DF7BA0B8D578A4C702B6BF11D5F 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa Satoshi
04 DEF2F43AFAA185045DDE45A7EA5621C45D3F9B2C2E96DB7260E0D617C2B0F09F CF30AED022D0932E39B68C5B618D11248EA94B08644E80605ED825A278405435 1CMjuddbCMYTYBxCLHvw9CXPynVHcey2Eh Satoshi/2

The same you can do for any number. Division is just multiplication by inverse.

I was wondering if two points could be multiplied with each other

No, because then ECDSA would be broken.

[NotATether]

Yes, of course. For example you can double a point or halve a point by multiplying it by 7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a1.

Apologies for my ignorance but I might recognize this constant from somewhere, is this number n/2 (which means for halfing I can just do k^n-1 I think)?

[pooya87]

Apologies for my ignorance but I might recognize this constant from somewhere, is this number n/2 (which means for halfing I can just do k^n-1 I think)?

No it is 1/2 (mod N).
Since we don't exactly have a division defined each [point divided by number] operation is changed into [point] * [modular multiplicative inverse of the divisor].
So P/2 becomes P*2^-1 where 2^-1 is computed by solving 2*x ≡ 1 (mod N)
And x is 0x7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a1

FWIW: N/2 = 0x7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0

[gmaxwell]

If you wanted to be silly you could also implement dividing a point by a scalar more directly.

One efficient way of computing a modular inverse is to use the extended GCD algorithm. A GCD starts with a vector of the number to be inverted and the modulus and applies a series of primitive transformations to the numbers which preserve their GCD and reduce their magnitude, until eventually you end up with the [1,0] vector. An extended GCD has an additional vector of numbers mod n which runs along side it and which it applies the same primitive transformations to, which ends up being the modular inverse at the end.  If the GCD you use is a binary GCD then all the transformation operations you perform are simple operations you can perform on curve points. So if you slap ecc points in place of this this secondary vector, the algorithm will divide a curve point by a number directly.

However, given that scalar operations are so much faster than curve operations, this would be slower than computing the inverse and then using a fast scalar/point multiply algorithm.  But I think it could be fairly said to be an algorithm for directly dividing a curve point by a scalar, although a rather silly one.

I was wondering if two points could be multiplied with each other, as opposed to a point and a number e.g. P*Q.

You cannot.  As garlonicon noted that it would break a lot of ECC protocols if you could.  Probably the simplest example is that in ECDH key agreement: Alice has private key a and sends aG and Bob has private key b and sends bG, and their joint shared secret is H(abG) which they can both compute by multiplying what they received with their own private key and hashing it.  But a passive observer can't multiply the two points, and so they can't compute the shared secret.

In pairing cryptography which is built with specialized elliptic curves that have a precisely engineered weakness you effectively gain an ability to multiply curve points, but only once: the result is in a different group.  But this extra ability alone lets you create all kinds of fancy cryptographic protocols that you can't create with plain ECC (or only exist in interactive form for plain ECC).

One thing that can be done if I know three points and their discrete logs: A=aG, B=bG, C=abG, I can write a proof that convinces you that C is the product of A and B (and that I know their discrete logs), without revealing to you anything else.  But you can't perform the computation yourself.

[BlackHatCoiner]

Probably the simplest example is that in ECDH key agreement: Alice has private key a and sends aG and Bob has private key b and sends bG, and their joint shared secret is H(abG) which they can both compute by multiplying what they received with their own private key and hashing it.  But a passive observer can't multiply the two points, and so they can't compute the shared secret.

I'm no familiar with ECDH, but why would an observer want to compute aG and bG assuming he knows about abG? He can't do anything with aG & bG even if he divides abG to get them. It's like saying that if you had a public key, which was result from the multiplication of two others, and I somehow could reveal them I could also sign from them.

The observer could not compute the shared secret, could he?

No, because then ECDSA would be broken.

How can you defeat the system if you're able of multiplying two points instead of a number and a point?

[j2002ba2]

How can you defeat the system if you're able of multiplying two points instead of a number and a point?

Multiplying two points allows us to square as well, and consequently rise to any power. Then we can work in the multiplicative group, which has order N-1, and excludes the point at infinity (0,0). ​The biggest factor of N-1 is only 108 bits. Using Pohlig-Hellman in conjunction with Pollard-Rho (or BSGS for smaller factors, and exhaustive search for the smallest) we find k with cost O(2⁵⁴) multiply operations.

[gmaxwell]

I'm no familiar with ECDH, but why would an observer want to compute aG and bG assuming he knows about abG? He can't do anything with aG & bG even if he divides abG to get them. It's like saying that if you had a public key, which was result from the multiplication of two others, and I somehow could reveal them I could also sign from them.

For key agreement the passive observer sees aG sent by alice, and bG sent by bob.  The observer cannot compute abG -- their shared secret.  If they could multiply points they could multiply what they saw aG and bG and get the shared secret and read their traffic.

[BlackHatCoiner]

how Alice can calculate Bob privatekey , and how Bob calculate Alice private key?
from transaction or it has nothing to do with transaction?

It doesn't have to do (directly) with the transaction, you only need the public keys; if they reused their addresses then their public keys would be exposed (so that's how you'd get them). As said by the folks above, if elliptic curve point multiplication was possible you could raise to any power as well. Using Pohlig-Hellman in conjunction with Pollard-Rho would lead you to k with only 2⁵⁴ multiply operations. Knowing k means, you're one equation away for finding out the private key (d).

what is aG and bG?

Since a and b are private keys, then aG is Alice's public key and bG, Bob's public key.

[vjudeu]

SO the question : if some one sent to me transaction in to my "Pubkey" address, which I know private*G, so I know the pubkey of delivery of transaction.
How to calculate privatekey of second pubkey?
if a*G (my pubkey) then do I : a*pubkey2 , and what next?

If you are Alice, you know "a" and "bG", so you can do "a*bG" that is equal to "abG". If you are Bob, you know "b" and "aG", so you can do "b*aG" that is equal to "abG". In this way, Alice and Bob can create shared secret that is unknown to everyone else. If public key multiplication would be directly possible, then anyone could calculate that shared key and read the whole traffic between Alice and Bob.

[vjudeu]

yes but how to ALice can calculate private key of BOB?

She cannot. All she can do is multiplying his public key by her private key.

Edit: for example Alice only has that things:

Code:

+---------------------------------------------------------------------+
| Alice's computer:                                                   |
+---------------------------------------------------------------------+
| Alice's private key:                                                |
| a294bf599609918d80a43321326215d9cd95bf5462901d0c734ee0c785ae2e95    |
| Bob's public key:                                                   |
| 03 552336062684334EC2FD3CA6929BF0975C8FDEFB967342F4B38F1759C63F55CF |
| Shared key:                                                         |
| 03 DEFB20FD5EE58BFCDE96CFBF1C93B2498787F8B024FDCCF4F1DB3DD230EE759F |
+---------------------------------------------------------------------+

And Bob only has that things:

Code:

+---------------------------------------------------------------------+
| Bob's computer:                                                     |
+---------------------------------------------------------------------+
| Bob's private key:                                                  |
| 84d324b55a6e1d94e66cca1daa00377d7fff9de18bdcdaa59de87e5c4a9713ea    |
| Alice's public key:                                                 |
| 03 3E6501A24451EBA3459C32C4C67ED5365FD09991DAD6C96F9DADE780B5DED602 |
| Shared key:                                                         |
| 03 DEFB20FD5EE58BFCDE96CFBF1C93B2498787F8B024FDCCF4F1DB3DD230EE759F |
+---------------------------------------------------------------------+

[NotATether]

A related problem, I'm implementing secp256k1 multiplication now that I completed and tested add & double, and this is the pseudocode Wikipedia has  about the subject:

Code:

   R0 ← 0
  R1 ← P
  for i from m downto 0 do
      if di = 0 then
          R1 ← point_add(R0, R1)
          R0 ← point_double(R0)
      else
          R0 ← point_add(R0, R1)
          R1 ← point_double(R1)
  return R0

I initially thought that d is just a binary decomposition of the multiplicand i.e. 3 => 11b, 6 => 110b, etc. But this doesn't seem to produce the correct results.

3*G (G+G+G) should give me this result (mod p):

Hex:
-6cf75fe6da73cefb6cbb07a0762add64ace37ba7c90664f79fe0eeb431fc536
-c77084f09cd217ebf01cc819d5c80ca99aff5666cb3ddce4934602897b4715bd

decimal:
-3080428797605589366822325834758234751155007324101155494826970452699058783542 -90209061256745311731914079131285931446821116410824268969537695047367247992253

but my implementation of Montgomery ladder is not returning that, so I'm wondering if the d array is supposed to be something else.

[garlonicon]

3*G (G+G+G) should give me this result (mod p):

Hex:
-6cf75fe6da73cefb6cbb07a0762add64ace37ba7c90664f79fe0eeb431fc536
-c77084f09cd217ebf01cc819d5c80ca99aff5666cb3ddce4934602897b4715bd

No, it should be:

Code:

04 79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8   G
04 C6047F9441ED7D6D3045406E95C07CD85C778E4B8CEF3CA7ABAC09B95C709EE5 1AE168FEA63DC339A3C58419466CEAEEF7F632653266D0E1236431A950CFE52A   2*G
04 F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9 388F7B0F632DE8140FE337E62A37F3566500A99934C2231B6CB9FD7584B8E672   3*G

I don't know how you get these numbers from your example. Maybe try implementing it by using smaller numbers and later just increase them? Some related article: https://www.coindesk.com/markets/2014/10/19/the-math-behind-the-bitcoin-protocol/.

We start from base point:

Code:

x=79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
y=483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8

Then we double that point:

Code:

modulo=FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
c=3*x*x/2*y
c=3*(79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798)^2/2*483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
c=3*8550e7d238fcf3086ba9adcf0fb52a9de3652194d06cb5bb38d50229b854fc49/9075b4ee4d4788cabb49f7f81c221151fa2f68914d0aa833388fa11ff621a970
c=8ff2b776aaf6d91942fd096d2f1f7fd9aa2f64be71462131aa7f067e28fef8ac/9075b4ee4d4788cabb49f7f81c221151fa2f68914d0aa833388fa11ff621a970
c=8ff2b776aaf6d91942fd096d2f1f7fd9aa2f64be71462131aa7f067e28fef8ac*b7e31a064ed74d314de79011c5f0a46ac155602353dc3d340fbeaeec9767a6a6
c=cb35b28428101a303eb9d1235992ac63f58857c2f631ee6936d3aebbeddcd1b1
rx=c*c-2*x
rx=cb35b28428101a303eb9d1235992ac63f58857c2f631ee6936d3aebbeddcd1b1^2-2*79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
rx=b9814c9235a6f4c5db86059a32ce92e661af8801e88b8e5a5f910c708a60d1e6-f37cccfdf3b97758ab40c52b9d0e160e0537f9b65b9c51b2b3e502b62df02f30
rx=c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5
ry=c*(x-rx)-y
ry=cb35b28428101a303eb9d1235992ac63f58857c2f631ee6936d3aebbeddcd1b1*(79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798-c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5)-483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
ry=cb35b28428101a303eb9d1235992ac63f58857c2f631ee6936d3aebbeddcd1b1*b3b9e6eab7ef3e3f255b222738c68e2ea6246e8fa0deec31ae4677a0ba8774e2-483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
ry=631c4375cce1879f016a8015547df397f50de6add8ec24fabfac02394be0b9e2-483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
ry=1ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a

As you can see, we have:

Code:

rx=c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5
ry=1ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a

That matches 2*G:

Code:

04 C6047F9441ED7D6D3045406E95C07CD85C778E4B8CEF3CA7ABAC09B95C709EE5 1AE168FEA63DC339A3C58419466CEAEEF7F632653266D0E1236431A950CFE52A   2*G

Then, we add these two points:

Code:

modulo=FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
px=79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
py=483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
qx=C6047F9441ED7D6D3045406E95C07CD85C778E4B8CEF3CA7ABAC09B95C709EE5
qy=1AE168FEA63DC339A3C58419466CEAEEF7F632653266D0E1236431A950CFE52A
c=(qy-py)/(qx-px)
c=(1AE168FEA63DC339A3C58419466CEAEEF7F632653266D0E1236431A950CFE52A-483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8)/(C6047F9441ED7D6D3045406E95C07CD85C778E4B8CEF3CA7ABAC09B95C709EE5-79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798)
c=d2a68e877f99fed44620881d385be245fade7e1c8be17cc7871c611855bf0ca1/4c4619154810c1c0daa4ddd8c73971d159db91705f2113ce51b9885e4578874d
c=d2a68e877f99fed44620881d385be245fade7e1c8be17cc7871c611855bf0ca1*ac946f7cd9ccebb8d59803e73c7d12aa395b2eb7e59a8ba119742df442fc6604
c=342119815c0f816f31f431a9fe98a6c76d11425ecaeaecf2d0ef6def197c56b0
rx=c*c-px-qx
rx=342119815c0f816f31f431a9fe98a6c76d11425ecaeaecf2d0ef6def197c56b0^2-79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798-C6047F9441ED7D6D3045406E95C07CD85C778E4B8CEF3CA7ABAC09B95C709EE5
rx=38f37014ce22fc29cf19f28a5ce4da091445536c3e2cff318ba07c2a3048f518-79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798-C6047F9441ED7D6D3045406E95C07CD85C778E4B8CEF3CA7ABAC09B95C709EE5
rx=bf350995d446407d79798ff48e5dcf0211a95691105ed65831adface1950d9af-C6047F9441ED7D6D3045406E95C07CD85C778E4B8CEF3CA7ABAC09B95C709EE5
rx=f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9
ry=c*(px-rx)-py
ry=342119815c0f816f31f431a9fe98a6c76d11425ecaeaecf2d0ef6def197c56b0*(79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798-f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9)-483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
ry=342119815c0f816f31f431a9fe98a6c76d11425ecaeaecf2d0ef6def197c56b0*808ddc7d6783f89c0c6c130fd5e9b8dd4d6a3495aa5e8f28d3f090465a17dcce-483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
ry=80ca558689d1ac796d8833e23848fbff62185de1db4777350901ce057fc9bb2a-483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
ry=388f7b0f632de8140fe337e62a37f3566500a99934c2231b6cb9fd7584b8e672

As you can see, we have:

Code:

rx=f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9
ry=388f7b0f632de8140fe337e62a37f3566500a99934c2231b6cb9fd7584b8e672

That matches 3*G:

Code:

04 F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9 388F7B0F632DE8140FE337E62A37F3566500A99934C2231B6CB9FD7584B8E672   3*G

[NotATether]

I don't know how you get these numbers from your example.

Thank you very much for the demonstration.

It turns out that the modulus function in my bigint dependency library is broken and spits out negative numbers that aren't mod the curve prime. After adding the prime to these negative numbers (and making my addition/multiplication check for points at infinity properly), I get the same results as your example.

[pooya87]

It turns out that the modulus function in my bigint dependency library is broken and spits out negative numbers that aren't mod the curve prime.

If you are using a general BigInteger implementation that is not specifically made for Elliptic Curve cryptography and Modular Arithmetic, then returning a negative number is the correct behavior. In other words -4 % 3 = -1 and it is only in a finite field (like in ECC) that we only return numbers that are positive and between 0 and prime. ie. -1 ≡ 2 (mod 3).

[NotATether]

Alright looks like I got another problem with test cases.

I'm trying to verify if my implementation works correctly with different factors k. I used this list https://crypto.stackexchange.com/questions/784/are-there-any-secp256k1-ecdsa-test-examples-available , and it works properly for numbers 1-20 (those are the only small numbers in the linked test), but it is making different results for the huge factors.

Code:

k: 112233445566778896
x: 1be8dea0c9f0b2e7224c7f8c04b4a61bd886b4c5bf36fea76a2ae187d6db7c7a
y: 948dcc4e2d53c91436e1e4e53469b8331e05b19c2aebae5b026e75bd468b8d38

k: 112233445566778890877738208276250624
x: ecf54f4a4757d5273b3d38b51a6714739a327d89c2a599b7fec860bb523adce8
y: 9fb325c337b783bd6bae40bfe77d957750687e8359f2340108a704c429dd1233

k: 28948022309329048855892746252171976963317496166410141009864396001978282409984
x: 2a9e8dfe3cce6bab3e82d82a5688544c0c7b55dc31978b4de2ccb3b7d466d561
y: 1dfeda5c16e651fbac7b5ad608b96cf5e01eaec17a02182f96ccf5252e76373

k: 57896044618658097711785492504343953926634992332820282019728792003956564819968
x: b23790a42be63e1b251ad6c94fdef07271ec0aada31db6c3e8bd32043f8be384
y: fc6b694919d55edbe8d50f88aa81f94517f004f4149ecb58d10a473deb19880e

k: 86844066927987146567678238756515930889952488499230423029593188005934847229952
x: 71e935c8e1f54f25a6424274ab07e7891873c3b1a27a6c40b805264597a6257f
y: 78d93e59f47c22513ded86ba47ae2a52ef2523540cf70f7a5b217461d1b1e582

k: 115792089237316195423570985008687907853269984665640564039457584007913129639936
x: dd3625faef5ba06074669716bbd3788d89bdde815959968092f76cc4eb9a9787
y: 7a188fa3520e30d461da2501045731ca941461982883395937f68d00c644a573

k: 115792089237316195423570985008687907853269984665640564039457584007913129639936
x: dd3625faef5ba06074669716bbd3788d89bdde815959968092f76cc4eb9a9787
y: 7a188fa3520e30d461da2501045731ca941461982883395937f68d00c644a573

k: 115792089237316195423570985008687907853269984665640564039457584007913129639936
x: dd3625faef5ba06074669716bbd3788d89bdde815959968092f76cc4eb9a9787
y: 7a188fa3520e30d461da2501045731ca941461982883395937f68d00c644a573

It's failing for all these (and I assume for the other huge numbers in the list which I didn't test as well).

It is difficult to find another calculator to test my results against. Can someone verify if these are actually wrong (or correct, but the test vectors are wrong)?

[BlackHatCoiner]

Can someone verify if these are actually wrong (or correct, but the test vectors are wrong)?

The first five k values return me the correct x and y coordinates. The remaining three do not belong into the secp256k1 curve.

Specifically, on secp256k1, the number of valid keys denoted as n would be any value between 1 and n-1 where n is equal with “fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141”. The k value, you left the same in the last three results, is bigger than that.

Decimally:

Code:

115792089237316195423570985008687907852837564279074904382605163141518161494336 (highest value for k)
115792089237316195423570985008687907853269984665640564039457584007913129639936 (your k)

By the way, I noticed that both 1 and n-1 give you the same x coordinate, but not the same y. What's the reasoning behind this?

[NotATether]

The first five k values return me the correct x and y coordinates. The remaining three do not belong into the secp256k1 curve.

Specifically, on secp256k1, the number of valid keys denoted as n would be any value between 1 and n-1 where n is equal with “fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141”. The k value, you left the same in the last three results, is bigger than that.

So my output (the ones on the curve anyway) is correct? And not the test case output?

By the way, I noticed that both 1 and n-1 give you the same x coordinate, but not the same y. What's the reasoning behind this?

I noticed this from my testing, it looks like that k and n-k have the same X coordinate but inverted (curve order - y) Y coordinate.