Topic: Why point by point multiplication is undefined in ECDSA? (Read 233 times)

Simple, I just used private keys first, and then converted everything to public keys, just to show, why multiplication is undefined. If you take (27,16) and multiply it by (19,54), then you can get (8,19), but only if your base point is (75,41), and only if you know all points, or all relations between private and public keys. If you change your base point, you will reach something different. That means, by having two public keys alone, you don't know, what is the result.

Addition: you change your base point, everything stays the same
Multiplication: you change your base point, your results are now different

That's why you cannot multiply two public keys directly. Also note that in my examples, I can convert any public key to private key, but this is true only because there are only 67 points on this small curve, and I can easily just check all of them, which is obviously not the case in secp256k1. But after converting it back when using a different base point, you can easily see, why those results are wrong.

Edit: Of course it is. And you have all examples in the linked article, also with signatures, and their verification.

How you calculate this ? (27,16)*(19,54)=( 8,19) ??

There is no such a thing as multiplying 2 public keys to have a valid result, you can't multiply public key 3 with 2 to have the public key of private key 6.

So why are you asking for something that doesn't exist?

Can show point's multiplication example ? Multiplication is not classic double and add....

Very interesting. Maybe we should ask user ranochigo. He could know if this is possible. [I will DM him]

Bro, what formula you use for multiply one point to enother point ?

Bro, can you show calculation on this example:

(27,16)*(19,54)=( 8,19)

?

I NOT UNDERSTAND FORMULA'S WHAT YOU PROVIDE


THX

https://www.coindesk.com/markets/2014/10/19/the-math-behind-the-bitcoin-protocol/

O fu-k !!!


You get a real point in result:

How you get (8,19) ?

What filormula for multiplication ?



(27,16)*(19,54)=( 8,19)
(21,74)*(63,16)=(43,44)
( 9,74)*(29, =(43,44)

Only if you know all of them upfront, or you know all relations between all of your public keys. In other cases, not really, because your private key is always relative to your base point. Let's assume you have some (x,y) point, and you start changing your base point. What could happen?
And then, if you have only (x,y) coordinates, then without a base point, you don't know if after multiplication by itself, you should get the same point, or some different point. That means, if you want to write any point-by-point multiplication, this is not enough:
What you need, is something like that:

In general, if you multiply one by one, you should get one. That means, squaring base point should not change anything, and return the same point. That also means point addition is different than point multiplication, because if you add two points, then you don't have to know the base point.

Yes, of course. If you have private keys, it is perfectly defined operation. The same is true if you combine some public key with some private key.

So this is the reason when I multiply G by itself I can't figure out what is the result! I wonder if there is a way to find the result private key?🤔

Edit, Ok, I admit that I didn't spend enough time to figure it out, after posting this I went out to find out G * G is what?

Here it is  public key :

Private key :

I hope by multiplying point by point, you meant public keys by public keys? if I misunderstood and this is off topic, apology.

Many people wonder, why we cannot multiply point by point in ECDSA. We can add points, subtract them, multiply point by some number, or divide it (by using inversion). The main reason for that, is this operation requires a hidden argument, that is often missed: the base point.

Many times, people think about things like "halving a point" in a similar way, as how we can do that on integers in many programming languages: if we have 9/10, it gives us zero as the result. In ECDSA world, this is not the case.

To better explore, how point by point multiplication could be defined, we can take an elliptic curve you can see in my avatar: "p=79,n=67,base=(1,18),bits=7". It is quite simple, every coordinate takes only one byte, and it can be fully explored, without applying any optimizations, and just by brute forcing everything.

So, we start with our p=79. We can easily check if it is prime, and then find the nearest point, meeting famous equation: y^2=x^3+7. All numbers are small enough, so we can even easily create some 79x79 black bitmap, and set pixel color to white, if for a given (x,y) pair, our left and right side is equal modulo 79. We can even try this for some bigger values, then we could get a nice picture for our desktop background, similar to the stars on the sky at night.

In this way, we can easily grab the nearest point, being (1,18) in this case. Also, we can count all dots, and note that we have 66 points, and the 67th value is just (0,0), point at infinity, which we can reach later, after trying to add the first, and the last point.

So, let's start from the base point, and create the full list of points:
After handling corner cases, we can convert any private key "d" to "(x,y)" pair, representing our public key, and make it rolling ad infinitum:
As we can see, we started from p=79, and y^2=x^3+7, nothing else. We reached n=67, and now we can be 100% sure that it is not just some result we picked. It is the only valid result, that makes things tick, and meets our criteria, being as close to secp256k1 as possible, and using smaller numbers to demonstrate things. By going into bigger numbers, we can get even more convinced, that "n" was not arbitrarily chosen: it was just calculated, by using very well optimized code.

Now, we have everything we need to see, why we cannot multiply point by point. Let's write some multiplications with private keys, and then convert them to corresponding public keys:
And now, let's assume we want to use a different base point, for example (75,41), instead of (1,18). Let's generate the full list of points again, and see, how everything was suddenly changed:
Then, let's write the same multiplications again:
See? Everything is completely different. Everything was changed. We can even take our old points, and see, what private keys are hidden behind them, when we calculate it under our new base point:
See? Point by point multiplication leads to completely wrong results, if it is done directly, based on two points, without calculating things relatively to the base point. I hope this topic will help to better understand, why some operations cannot be done in ECDSA, and how implicit things like base point can change everything, if we forget to consider them in our calculations.