<p>The elliptic curve <code>secp256k1</code> is defined over the finite field Z<sub>p</sub>. All the coordinates are 256-bit integers, and all the point additions and coordinates are subject to modulo <code>p</code>.</p>
<p>The large space of numbers and discontinuous nature of elliptic curves makes it infeasible to directly perform a factorization as you posit.</p>

CC BY-SA 4.0
2022-06-23T11:25:43.317Z
Ok, that sums it up perfectly.
Jamo
CC BY-SA 4.0
2022-06-22T15:48:24.880Z
2022-06-22T15:48:24.880Z
Murch
<p>If you naively implement this <code>G * G * G...* G</code> method, you will have to perform an enormous number of operations until get your public key. For instance, if your public key is 2^128, you need to add <code>G</code> to itself 2^128 times, this is computationally unfeasible. However, there is a more optimized algorithm for this, called Double and Add, which computes the public key with O(n) Double and Add step, where <code>n</code> is the bit length of your private key.<br />
However, as far as we know, there is no Deterministically Polynomial Time algorithm to go in the other way. If you go naively again, you'll subtract <code>G</code> from your public key 2^128 times in the above example, until you're left with just <code>G</code>. Again, unfeasible. There is a better algorithm, but is still sub-exponential, and takes an average of 2^128 operations to succeed in secp256k1 (technically O(srqt(n)), where <code>n</code> is the curve order).<br />
The short hawser is: Yes, you can reverse it, but for cryptographically secure keys, you'll need a WHILE until you succeed.</p>

CC BY-SA 4.0
2022-06-19T16:19:54.633Z
2022-06-19T16:19:54.633Z
Davidson Souza
<p>I understand that the public key <code>q</code> is generated by the point addition of <code>g</code> (some secp256 k1 constant) <code>u</code> times such that <code>u</code> is a big number (private key). This process can be simplified in this diagram below.</p>
<p>Hence the formula follows <code>q=u*j</code></p>
<p><a href="https://i.sstatic.net/H4aBp.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/H4aBp.png" alt="enter image description here" /></a>
But why cant I use this diagram below and trace back the public key point to the point of the private key by following the tangents back to the original point. I'm sure I could do this in desmos-graphing or something using some pretty simple linear algebra.</p>

<private-key><public-key><cryptography><ecdsa>
Why can't I reverse secp256k1's public key point in order to determine the private key?
Jamo
# Why can't I reverse secp256k1's public key point in order to determine the private key?

(Asked by: username_0 on 2022-06-19)

I understand that the public key `q` is generated by the point addition of `g` (some secp256 k1 constant) `u` times such that `u` is a big number (private key). This process can be simplified in this diagram below.

Hence the formula follows `q=u*j`

[![enter image description here](https://i.sstatic.net/H4aBp.png)](https://i.sstatic.net/H4aBp.png)
But why cant I use this diagram below and trace back the public key point to the point of the private key by following the tangents back to the original point. I'm sure I could do this in desmos-graphing or something using some pretty simple linear algebra.

**Tags:** private-key, public-key, cryptography, ecdsa


---

## 2 answers

### Answer by username_1 on 2022-06-22. Score: 1 | Accepted answer

The elliptic curve `secp256k1` is defined over the finite field Zp. All the coordinates are 256-bit integers, and all the point additions and coordinates are subject to modulo `p`.

The large space of numbers and discontinuous nature of elliptic curves makes it infeasible to directly perform a factorization as you posit.

> **Comments:**
> **username_0**: Ok, that sums it up perfectly.  

---

### Answer by username_2 on 2022-06-19. Score: 5

If you naively implement this `G * G * G...* G` method, you will have to perform an enormous number of operations until get your public key. For instance, if your public key is 2^128, you need to add `G` to itself 2^128 times, this is computationally unfeasible. However, there is a more optimized algorithm for this, called Double and Add, which computes the public key with O(n) Double and Add step, where `n` is the bit length of your private key.  
However, as far as we know, there is no Deterministically Polynomial Time algorithm to go in the other way. If you go naively again, you'll subtract `G` from your public key 2^128 times in the above example, until you're left with just `G`. Again, unfeasible. There is a better algorithm, but is still sub-exponential, and takes an average of 2^128 operations to succeed in secp256k1 (technically O(srqt(n)), where `n` is the curve order).  
The short hawser is: Yes, you can reverse it, but for cryptographically secure keys, you'll need a WHILE until you succeed.


---

