Polynonce: A Tale of a Novel ECDSA Attack and Bitcoin Tears
https://research.kudelskisecurity.com/2023/03/06/polynonce-a-tale-of-a-novel-ecdsa-attack-and-bitcoin-tears/
doesnt that say what we already know? reusing addresses Bad because public key exposed etc. so what? always use new address. isnt that basically considered best practice already?
I knew, that quantum computers can crack the private key, if the public key is known. With this attack they don't need quantum computers anymore.
i know that as long as no public key is exposed nothing, not even quantum stuff, can get it. but once the public key is known (watch for them in the mempool) its a race as to whether the attacker can crack your private key and take over that tx (rbf), before it gets mined into the blockchain.
thats my basic understanding. feel free to correct me.
Interesting read. I'd say vroom is not correct here, exposing your public key does not mean quantum computers can crack private key. At least that's not what the article is about.
(Please provide source if this is the case).
vapourminer is closer to the truth here, but it's not just about exposing your public key. Exposing pub key with 1 signature isn't the risk described, based on trying to find a common demoninator to private key. The risk is about exposing pub key is related to nonces, in this case, nonce reuse. Because then determining the private key, based on two different signatures with same nonce, becomes a lot more straight forward.
Notably, they weren't able to hack any wallets with different nonces, or addresses that used a single nonce (they didn't even try) but this is somewhat besides the point based on the "mishap" of ECDSA implementations which creates this vulnerability of repeated nonce use. Somebody can no doubt explain it better and more accurately than me, but after reading the article in full, I get the jist of it.
Ultimately, this isn't really information that we didn't already know - hence it's always been recommended to use different addresses due to possibility of "reverse engineering" signatures (ie those with the common variable of nonces, when those variables become a constant due to implementation error). Even the first implementation of Bitcoin in 2019 protected against this with the use of change addresses it's worth noting.
It's only newer implementations that have encouraged (or forced) address reuse that becomes the problem here, combined with nonce reuse.