516 sats \ 5 replies \ @l0k18 6 Mar 2023 \ on: Novel ECDSA attack: 773 wallets broken bitcoin
It's best practice to avoid reusing private keys anyway, this is why the recommendation to never use the same address again. I built a message segmenting algorithm that changes one of the keys every new packet but the other key is protected by a blinding factor so only the user knows which one it is. It skates straight through this vulnerability.
Identities encoded in a single private key might be a bad idea if this works. 4 different nonces with the same ECDH private/public key pair combination probably needs to always be different.
Just for prudence it might be wise therefore to adopt a rule where you don't sign more than 3 messages from a single private key, and aim to add a key change to any EC using protocol for identity keys.
It happens when you sign the same message twice. Then the attacker can potentially start to be more able to craft a fake message to fit the signature. The more, the easier. This is another reason why using different addresses every time should be and is generally the norm with bitcoin usage, except for donation addresses. These really should be protected with signatures and issued on demand, but that then requires a hot keychain somewhere.
I think for this reason also a challenge signing protocol should have the signer add their own random value to the provided challenge in order to avoid the other end getting multiply signed identical messages.
reply
сначала будут взламывать кошелёк сатоши. а потом узнаем что на это понадобилось 100 лет или 1000 или 25000
reply
Because it is never spent it will be the hardest to hack. All the old wallets which contains addresses which AFTER spent left some funds on it will be first hacked. That's why all wallets now move funds to a fresh address after spending. This solution seems be to be rock solid (=unhackable) till now!
reply
Does this actually pose a threat to LN authentication e.g. here on SN? When you repeatedly sign login authentication messages with your node privkey and hand them to SN, aren't you opening up this attack vector?