user3667: 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, 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?

user208: Copying the summary from my mailing list post 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.

3667: <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>
 208: <p>Copying the summary from my mailing list <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018384.html" rel="nofollow 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>
