# Why is it impossible to find the private key from the public key?

From what I understand, based on the article A Beginner’s Guide: Private and Public Key Cryptography Deciphered, the public key is generated by performing $n$ tangent plus mirroring operations from the point $G$ over the elliptic curve, where $G$ is defined in secp256k1 and $n$ is a natural number that directly relates to the private key.

As I know the public key and the seed value $G$, I could start a process computing $$G + G, G + G + G, \dots$$ and comparing those results with the public key value until it matches.

If your answer would be that this process is very slow: if this process is slow, the same applies to computing the public key from the private key (because the operations are the same except for the check operation). So, how it is possible to compute the public key in a very fast way?

• "...public key is generated by performing n ... operations". No, this is incorrect. The algorithm to compute the public key from n and G is equivalent to adding G to itself n times, but it only takes about log n steps. – James Reinstate Monica Polk Jul 26 '18 at 13:17
• ... just like you don't calculate 100 * 100 by adding 100 to itself 99 times. – Maarten Bodewes Jul 26 '18 at 13:28
• – dave_thompson_085 Jul 27 '18 at 1:05

My question is: as I know the public key and the seed value G', I could start a process computing G + G, G + G + G, and comparing those results with the public key value until it matches.

You can, but you have to check about 2256 values. This is an extremely big number. So it is computationally infeasible to perform this operation.

If this process is slow, the same applies to, knowing the private key, and compute the public key (Because the operations are the same except for the check operation), so how it is possible to compute the public key in a very fast way?

Because we compute public key in smarter way. You are trying to check all values by continuously do + operation. But to generate public key we use * operation: public = private * G

## So, how it is possible to compute the public key in a very fast way?

From the wikipedia article on Elliptic Curve Cryptography:

The straightforward way of computing a point multiplication is through repeated addition. However, this is a fully exponential approach to computing the multiplication.

As you've noticed, this is slow. Continuing the article:

The simplest method is the double-and-add method,1 similar to multiply-and-square in modular exponentiation.

Exponentiation by squaring is an algorithm that allows us to compute $g^x$ much faster than computing $g*g*g*g*g\dots$. There is an analogous algorithm called double and add for elliptic curve point multiplication. This type of algorithm lets us compute the output in much less time than the naive method:

This algorithm requires $\operatorname{log}_2(d)$ iterations of point doubling and addition to compute the full-point multiplication.

## In fact...

This is basically where the asymmetry and security of these types of problems come from: There is a fast algorithm for computing the public key from the private key, but it's not known whether there is a similarly efficient algorithm for computing the private key from the public key.

These functions are one-way in that they are easy to compute in one direction, and very hard to compute in the other direction. Elliptic curves are nice, but here's an simpler-to-understand one-way function: Consider 3^x mod 7`. Raise 3 to some value, divide by 7 and take the remainder.

Given x, compute the result. This is easy to work forward. You can do it by hand. Try it out for x=5. Even for very large numbers, this is very efficient to compute. The difficulty goes up roughly with the log of the values. (Think about how much harder multiplying 4-digit numbers is than multiplying 3-digit numbers by hand. It's only a little harder and slower, even though the values are ten times larger.)

Now try to do the opposite (this is called the discrete log). If I tell you that the remainder is 5, tell me what x is. This is a much harder problem. In fact, you pretty much have to compute the value for each value of x and try to find one that matches. This is a linear search over the space. Now there are only 7 elements in this space, so that's not so hard. But what if the modulo were much larger? Much, much larger. Every time I add one bit to the size of the modulo, I double your search space.

Most cryptography systems include something like this at their heart. There are a lot of different approaches, and elliptic curves are just one, but they all try to create a one-way function; a function that is easy to compute in one direction and hard to compute in the other.

But what if there is an easy way to compute it in the other direction? Maybe we just haven't figured it out yet. We haven't been able to prove that these problems are hard. There is an open question, in fact, whether these particular kinds of one-way functions even exist. We believe they do, and the discrete log problem seems to be one of them. This is called the P=NP problem. If someone proved P=NP, then most of our cryptographic approaches would be attackable (at least in theory; proving something can be attacked doesn't tell you how). But we're pretty sure that P does not equal NP, and as a practical matter, these functions are currently very hard to attack.