<p>Copying the summary from my mailing list <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018384.html" rel="noreferrer">post</a> on this topic:</p>
<blockquote>
<ul>
<li>To stay within the realm of provably security it's advisable to make sure ECDSA key and Schnorr keys use distinct hardened derivation steps.</li>
<li>Even if you don't, you're really just back to the level of assurance we had about unhardened BIP32 ECDSA keys before a proof was known (which I think most people aren't even aware of).</li>
</ul>
</blockquote>
<p>There are no known attacks against reuse of keys across ECDSA and Schnorr (at least as long as the nonces are unrelated/unpredictable, but if that's not the case, you also have a problem with reuse within ECDSA or within Schnorr).</p>
<p>There is however also no security proof for reuse across, as far as I know, but that's not really worse than what the situation for ECDSA alone until recently.</p>

CC BY-SA 4.0
2021-08-04T21:44:45.050Z
However I should add, using the same deterministic nonce scheme (eg. rfc6979) across ECDSA and Schnorr, and signing the same message with both will leak the key!
Anunay
CC BY-SA 4.0
2021-08-04T21:48:07.700Z
That's true, though not a risk in the current transaction signing scheme, as the message is guaranteed to be different for both (hash is computed differently, and also hash commits to the output bwing spent, which commits indirectly to the script).
Pieter Wuille
CC BY-SA 4.0
2021-08-04T18:23:32.977Z
2021-08-04T18:23:32.977Z
Pieter Wuille
<p>I think I've seen a comment by Greg Maxwell about this but am having trouble finding it. I think there was some risk when signing the same message with the same key with both algorithms?</p>
<p>In this <a href="https://crypto.stackexchange.com/questions/34863/ec-schnorr-signature-multiple-standard">related question</a>, I see that ECDSA signature outputs <code>(h, s)</code> but Schnorr outputs <code>(r, s)</code>. So in ECDSA, <code>r</code> is kept as a secret value but it is revealed in Schnorr -- does that somehow make the private key recoverable?</p>

CC BY-SA 4.0
2021-08-04T15:31:04.467Z
I think OP is referring to [this mail](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018381.html) on the bitcoin-dev mailing list
Anunay
<ecdsa><schnorr-signatures><math>
Are there risks to using the same private key for both ECDSA and Schnorr signatures?
pinhead
# Are there risks to using the same private key for both ECDSA and Schnorr signatures?

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

I think I've seen a comment by Greg Maxwell about this but am having trouble finding it. I think there was some risk when signing the same message with the same key with both algorithms?

In this [related question](https://crypto.stackexchange.com/questions/34863/ec-schnorr-signature-multiple-standard), I see that ECDSA signature outputs `(h, s)` but Schnorr outputs `(r, s)`. So in ECDSA, `r` is kept as a secret value but it is revealed in Schnorr -- does that somehow make the private key recoverable?

**Tags:** ecdsa, schnorr-signatures, math

> **Comments:**
> **username_1**: I think OP is referring to [this mail](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018381.html) on the bitcoin-dev mailing list  

---

## 1 answers

### Answer by username_2 on 2021-08-04. Score: 5 | Accepted answer

Copying the summary from my mailing list [post](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018384.html) on this topic:

> * To stay within the realm of provably security it's advisable to make sure ECDSA key and Schnorr keys use distinct hardened derivation steps.
> * Even if you don't, you're really just back to the level of assurance we had about unhardened BIP32 ECDSA keys before a proof was known (which I think most people aren't even aware of).

There are no known attacks against reuse of keys across ECDSA and Schnorr (at least as long as the nonces are unrelated/unpredictable, but if that's not the case, you also have a problem with reuse within ECDSA or within Schnorr).

There is however also no security proof for reuse across, as far as I know, but that's not really worse than what the situation for ECDSA alone until recently.

> **Comments:**
> **username_1**: However I should add, using the same deterministic nonce scheme (eg. rfc6979) across ECDSA and Schnorr, and signing the same message with both will leak the key!  
> **username_2**: That's true, though not a risk in the current transaction signing scheme, as the message is guaranteed to be different for both (hash is computed differently, and also hash commits to the output bwing spent, which commits indirectly to the script).  

---

