<p>If you know two signatures about one random number, you can calculate the private key.</p>

CC BY-SA 3.0
2018-04-09T06:43:46.797Z
2018-04-09T06:43:46.797Z
Denis Leonov
<p>It's simple!!</p>
<p>1.
<a href="https://blockchain.info/tx/56ec7ca7dfea1c105acf0974331686e973b737e1fd97fc7f970a0cf0882ba7ac?format=hex" rel="nofollow noreferrer">https://blockchain.info/tx/56ec7ca7dfea1c105acf0974331686e973b737e1fd97fc7f970a0cf0882ba7ac?format=hex</a></p>
<p>2.
<a href="https://2xoin.com/getRSZfromRawTX/" rel="nofollow noreferrer">https://2xoin.com/getRSZfromRawTX/</a></p>
<pre><code>&quot;sigR&quot;: &quot;00db0c51cc634a4096374b0b895584a3ca2fb3bea4fd0ee2361f8db63a650fcee6&quot;,
&quot;sigS&quot;: &quot;59a23e4521da413a2c7d0f9a668eedc2e5eac88347c67c48dcca0128fda1cad7&quot;,
&quot;sigZ&quot;: &quot;4b2cdf712dc7d3fac8e7ed63b3a2e806556ca7d5c30ed5f4b34dbb2a12b0c18f&quot;,
&quot;pubKey&quot;: &quot;02ac75a5bd9640d55b8300fad347740ac447e4604fbc59260c2dce39f356a0558f&quot;,

&quot;sigR&quot;: &quot;00db0c51cc634a4096374b0b895584a3ca2fb3bea4fd0ee2361f8db63a650fcee6&quot;,
&quot;sigS&quot;: &quot;39d5e056231a5823dc0957e3d0fa3923ce71f781ad67140a6433fe6829bdf811&quot;,
&quot;sigZ&quot;: &quot;1cd506860c52d7e042f56b33a856b94fdefa3bcc808a06dd3b82619db2c01969&quot;,
&quot;pubKey&quot;: &quot;02ac75a5bd9640d55b8300fad347740ac447e4604fbc59260c2dce39f356a0558f&quot;,
</code></pre>
<ol start="3">
<li></li>
</ol>
<p>possible k  = 539</p>
<p>Public Key: C 02db0c51cc634a4096374b0b895584a3ca2fb3bea4fd0ee2361f8db63a650fcee6</p>
<p>possible k  = fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0363c08</p>
<p>Public Key:
C 03db0c51cc634a4096374b0b895584a3ca2fb3bea4fd0ee2361f8db63a650fcee6  !!!!!</p>
<p>Privkey = 79c7f119413edb1a9a9a2ea655196e0e3b6380b6d612dcc69c7c143816c8ef29</p>
<p>C L1JSKFNgNh7FyNw642ofHzivm8ua4EqpEqZyVQ8rmC6q6S9RgzYj</p>
<p>Here is the answer to your question!</p>

CC BY-SA 4.0
2021-02-12T09:16:43.980Z
2021-02-12T09:16:43.980Z
Igor-S74
<p>ECDSA signatures are pairs (r,s) where r=(k<em>G).x mod n, and s = (m + r</em>x)/k mod n, where x is the secret key, k is the random nonce, and m is the message.</p>
<p>If you have two s values s1 and s2 for the same secret key and with the same nonce k (and thus the same value r), the following holds:</p>
<ul>
<li>s1 = (m1 + r*x)/k</li>
<li>s2 = (m2 + r*x)/k</li>
</ul>
<p>From that we can derive:</p>
<ul>
<li>s1 * k = m1 + r*x</li>
<li>s2 * k = m2 + r*x</li>
<li>(s1 - s2) * k = m1 - m2</li>
<li>k = (m1 - m2) / (s1 - s2)</li>
<li>x = (s1 * (m1 - m2) / (s1 - s2) - m1) / r</li>
<li>x = (m1<em>s2 - m2</em>s1) / (r*(s1 - s2))
(all mod n)</li>
</ul>
<p>So not only did you make it trivial to detect signatures with the same nonce (they have a recognizable r value), there is a trivial formula to compute the private key once someone sees two signatures.</p>
<p>This kind of attack has been known and actively exploited on the Bitcoin network since at least 2013: <a href="https://bitcointalk.org/index.php?topic=271486.0" rel="nofollow noreferrer">https://bitcointalk.org/index.php?topic=271486.0</a> . Don't reuse k values. Use RFC6979 to deterministically but securely generate them.</p>
<p>Also note that it's not sufficient that the nonces are <em>different</em>. They also can't be related in a known way. For example, you can't use k for one signature, and k+1 for the next work.</p>

CC BY-SA 3.0
2018-04-08T12:55:05.620Z
Thank you. I wanted deterministic signatures so I just entered a fixed number for my unit tests. But RFC6979 is a much better solution.
Thorkil Værge
CC BY-SA 4.0
2019-04-14T12:18:05.093Z
I ended up implementing RFC6979 and it made interacting with the signatures much easier.
Thorkil Værge
CC BY-SA 4.0
2018-04-08T12:37:43.443Z
2021-09-09T11:33:52.317Z
2021-09-09T11:33:52.317Z
Pieter Wuille
<p>I wrote my own ECDSA signature algorithm just for the purpose of creating unit tests. </p>

<p>With it I created two signatures which went into transaction <a href="https://blockchain.info/tx/56ec7ca7dfea1c105acf0974331686e973b737e1fd97fc7f970a0cf0882ba7ac" rel="noreferrer">56ec7ca7df...</a>, sending from <a href="https://blockchain.info/address/1GXFXm3esL7Hh8rmvAme1YHKhYAnT1d7Sr" rel="noreferrer">1GXFXm3es...</a>. These signatures used the same k values, although k values must never be reused.</p>

<p>Later on, someone was able to steal 0.0016 btc from 1GXFXm3es.... and send them to 17WRjamox6VhTUaHsTWfFnMNDYHvwCtWio.</p>

<p>So someone must be monitoring the blockchain for mistakes like this and stealing funds if they encounter them.</p>

<p>How do you derive the private key from two signatures that share the same k value?</p>

CC BY-SA 3.0
2018-04-09T17:51:54.660Z
For some more info about how to find `k` values while taking into account transaction malleability, see my answer:  https://bitcoin.stackexchange.com/a/35850/6091
David Grayson
<security><ecdsa><hacking><theft><math>
How do you derive the private key from two signatures that share the same k value?
Thorkil Værge
# How do you derive the private key from two signatures that share the same k value?

(Asked by: username_0 on 2018-04-08)

I wrote my own ECDSA signature algorithm just for the purpose of creating unit tests.

With it I created two signatures which went into transaction [56ec7ca7df...](https://blockchain.info/tx/56ec7ca7dfea1c105acf0974331686e973b737e1fd97fc7f970a0cf0882ba7ac), sending from [1GXFXm3es...](https://blockchain.info/address/1GXFXm3esL7Hh8rmvAme1YHKhYAnT1d7Sr). These signatures used the same k values, although k values must never be reused.

Later on, someone was able to steal 0.0016 btc from 1GXFXm3es.... and send them to 17WRjamox6VhTUaHsTWfFnMNDYHvwCtWio.

So someone must be monitoring the blockchain for mistakes like this and stealing funds if they encounter them.

How do you derive the private key from two signatures that share the same k value?

**Tags:** security, ecdsa, hacking, theft, math

> **Comments:**
> **username_1**: For some more info about how to find `k` values while taking into account transaction malleability, see my answer:  https://bitcoin.stackexchange.com/a/35850/6091  

---

## 3 answers

### Answer by username_4 on 2018-04-08. Score: 26 | Accepted answer

ECDSA signatures are pairs (r,s) where r=(k*G).x mod n, and s = (m + r*x)/k mod n, where x is the secret key, k is the random nonce, and m is the message.

If you have two s values s1 and s2 for the same secret key and with the same nonce k (and thus the same value r), the following holds:

* s1 = (m1 + r\*x)/k
* s2 = (m2 + r\*x)/k

From that we can derive:

* s1 \* k = m1 + r\*x
* s2 \* k = m2 + r\*x
* (s1 - s2) \* k = m1 - m2
* k = (m1 - m2) / (s1 - s2)
* x = (s1 \* (m1 - m2) / (s1 - s2) - m1) / r
* x = (m1*s2 - m2*s1) / (r\*(s1 - s2))
  (all mod n)

So not only did you make it trivial to detect signatures with the same nonce (they have a recognizable r value), there is a trivial formula to compute the private key once someone sees two signatures.

This kind of attack has been known and actively exploited on the Bitcoin network since at least 2013: <https://bitcointalk.org/index.php?topic=271486.0> . Don't reuse k values. Use RFC6979 to deterministically but securely generate them.

Also note that it's not sufficient that the nonces are *different*. They also can't be related in a known way. For example, you can't use k for one signature, and k+1 for the next work.

> **Comments:**
> **username_0**: Thank you. I wanted deterministic signatures so I just entered a fixed number for my unit tests. But RFC6979 is a much better solution.  
> **username_0**: I ended up implementing RFC6979 and it made interacting with the signatures much easier.  

---

### Answer by username_2 on 2018-04-09. Score: 0

If you know two signatures about one random number, you can calculate the private key.


---

### Answer by username_3 on 2021-02-12. Score: 0

It's simple!!
1.
https://blockchain.info/tx/56ec7ca7dfea1c105acf0974331686e973b737e1fd97fc7f970a0cf0882ba7ac?format=hex
2.
https://2xoin.com/getRSZfromRawTX/
"sigR": "00db0c51cc634a4096374b0b895584a3ca2fb3bea4fd0ee2361f8db63a650fcee6",
"sigS": "59a23e4521da413a2c7d0f9a668eedc2e5eac88347c67c48dcca0128fda1cad7",
"sigZ": "4b2cdf712dc7d3fac8e7ed63b3a2e806556ca7d5c30ed5f4b34dbb2a12b0c18f",
"pubKey": "02ac75a5bd9640d55b8300fad347740ac447e4604fbc59260c2dce39f356a0558f",

"sigR": "00db0c51cc634a4096374b0b895584a3ca2fb3bea4fd0ee2361f8db63a650fcee6",
"sigS": "39d5e056231a5823dc0957e3d0fa3923ce71f781ad67140a6433fe6829bdf811",
"sigZ": "1cd506860c52d7e042f56b33a856b94fdefa3bcc808a06dd3b82619db2c01969",
"pubKey": "02ac75a5bd9640d55b8300fad347740ac447e4604fbc59260c2dce39f356a0558f",




possible k  = 539
Public Key: C 02db0c51cc634a4096374b0b895584a3ca2fb3bea4fd0ee2361f8db63a650fcee6
possible k  = fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0363c08
Public Key:
C 03db0c51cc634a4096374b0b895584a3ca2fb3bea4fd0ee2361f8db63a650fcee6  !!!!!
Privkey = 79c7f119413edb1a9a9a2ea655196e0e3b6380b6d612dcc69c7c143816c8ef29
C L1JSKFNgNh7FyNw642ofHzivm8ua4EqpEqZyVQ8rmC6q6S9RgzYj
Here is the answer to your question!


---

