It has been warned that you should not use the same private key to generate both ECDSA signatures and Schnorr signatures. That is because there may be a method for people to extract secret data when the two of them are combined. While there isn’t a confirmed attack that uses this method, as is the case for the nonce-reuse attack, it also has not been proved that such an attack is impossible. The problem is NP-hard – unless you are generating the nonce deterministically or reusing it.
What is Nonce Reuse?
In simple terms, it is when you use the secret nonce
k for two or more signed messages, and the same private key.
Nonce reuse might happen because a wallet uses the same value of
k over and over again – these are considered the least secure systems. They can also happen because they use a standard such as RFC 6979, which calculates the nonce using the following formula (assuming SHA256 message hashes and 256-bit private keys):
Where is the hash of the message, concatenates the byte to itself times, is the private key in bytes, and starts from 0 and increases by one on every iteration until a valid nonce for is found. It nearly always needs only one iteration to get a valid .
The nonce must never be re-used to generate cryptographic signatures, whether for trasactions or for signed messages, because the private key can be cracked by rearranging the message signing equation ( and represent the ECDSA signature), and solving by rearranging the equation:
A similar analysis can be done against RFC 6979 deterministic nonce generation by obtaining the raw transactions or message bytes, and attempting to work on the HMAC-SHA256 inputs and results to find an equation for the two nonces and . For example, observe what happens when the nonces form a linear equation :
Thus, a private key with a linear nonce equation can be computed using . Similar formulas might be possible to derive for , , and so forth.
What does all this have to do with Schnorr?
You see, Schnorr signatures use the same kind of cryptographic operations (point addition, point multiplication, modulus etc.), although the algorithm is completely different from ECDSA. ECDSA’s algorithm is comparativly simple and therefore it is relatively easy to equate two nonces together and solve for the private key, as I have just demonstrated. But Schnorr’s algorithm is very complex and uses tagged hashes in many cases. A tagged hash is simply
SHA256(SHA256(prefix_bytes) || SHA256(prefix_bytes) || data), where
data is the actual data being hashed. This protects the resulting hash from preimage attacks. Since there is no known solution for , it is extremely difficult to equate the two nonces as for ECDSA, since you’d have to break SHA256 by finding a collision.
To be specific, the r,s signature of Schnorr has and , where is some super-strong number generated from doing a bunch of tagged hashes. So even if you knew the nonce , you can’t find because Taproot signatures reveal and not .
But even that cannot protect you when ECDSA and Schnorr signatures are used with the same private key. That is because, the raw transaction hex for Taproot and other kinds of addresses are predictable, since their format is explicitly described in several BIPs. And since private key recovery is possible against ECDSA signatures (see above), if the nonce is generated deterministically using something like RFC 6979, this will be a mortal blow to the Schnorr signature’s security: you can simply craft a message that is the corresponding Taproot raw transaction hex for the non-taproot transaction, and from there, all you have to do is break the hash function guarding the nonce – and you already have the second nonce from ECDSA. There could be multiple layers of hashing, but it won’t matter when a pre-image attack is being carried out.
So when (not if) a SHA256-breaking computer is invented, your private key will immediately be compromised, as the attacker will have a nonce equation and can solve for the private key. Such attacks are not practical today, but you should not unnecessarily leave your funds vulnerable to such careless mistakes. After all, it’s common to leave bitcoins untouched for years.
The takeaway from all this is to generate your nonces properly; with random bytes, from a CSRNG. Deterministic nonces are a security risk.