related posts
481 sats \ 5 replies \ @Eximpius 6 Mar 2023
"We broke 762 unique wallets. All of these had a zero balance.".... lmao, so.... they think they "hacked" a wallet because they got a private key in their equation and then the wallets were empty...?? LMAO They have no way to even check their work.. LMAO LMAO LMAO... They basically got a random answer, checked the wallet, and are claiming they hacked it.... I can come up with random math too and get a private key lmao.... ENTROPY
reply
322 sats \ 2 replies \ @zuspotirko 6 Mar 2023
You are mistaken.
The DSA signature scheme is assumed to be a EUF-CMA or sEUF-CMA hard problem. However, after decades there has been no formal proof to be reducable to the DL-assumption (or Computational Diffie Hellman assumption or Decisional Diffie Hellman assumption). We also think that the mathematical problems on an elliptic curve and under Zp* are equivalent.
This is in stark contrast to the Schnorr Signature Sheme where there is a formal proof in the random oracle model under DL assumption to be EUF-CMA.
Any news about findings about DSA in Zp* or elliptic curve are worrisome. We basically wish that there shouldn't even be something to talk about. Especially any hints that there is a connection between signature, nonce and private key. Which is what this paper hints at.
To people that aren't familiar with cryptography: This might sound chinese to you. But what we're talking about here realistically is that in a few decades somebody finds out that the signature scheme is reducable to DL, DH or DDH - which would be huge news in cryptography but would still mean that nobody can forge signatures without breaking DL, DH or DDH - which they can't. Also, if somebody was to find a connection between signature, nonce and private key - that doesn't mean its exploitable by PPT algorthms - which wouldn't be surprising due to DSAs structure.
reply
22 sats \ 0 replies \ @0fje0 7 Mar 2023
Even though I understood almost none of your comment, I'm glad we have people around that seem to understand these things.
It made me read the paper and it broadened my knowledge. For that, I thank you.
reply
0 sats \ 0 replies \ @0260378aef 7 Mar 2023
Not sEUF-CMA, i.e. not strongly unforgeable due to the sign flip of the s value in ECDSA, but i take it you're treating that as academic since the assumption is that that is the only malleability (still, it's a very relevant malleability!)
reply
0 sats \ 0 replies \ @Eximpius 6 Mar 2023
Might as well sit there and enter random seeds if you try this bullshit
reply
0 sats \ 0 replies \ @Caleb 6 Mar 2023
You can look at transaction history.
reply
24 sats \ 0 replies \ @faithandcredit 6 Mar 2023
it was a nice read i dont think they meant to imply any fud. they are just sharing their work
reply
516 sats \ 5 replies \ @l0k18 6 Mar 2023
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.
reply
0 sats \ 0 replies \ @l0k18 7 Mar 2023
https://twitter.com/danielvf/status/1563168400234258433
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
0 sats \ 1 reply \ @selfish_gene 6 Mar 2023
сначала будут взламывать кошелёк сатоши. а потом узнаем что на это понадобилось 100 лет или 1000 или 25000
reply
1 sat \ 0 replies \ @t4es5ter5 7 Mar 2023
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
0 sats \ 1 reply \ @mcguffin 6 Mar 2023 freebie
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?
100 sats \ 0 replies \ @02cfd5f452 7 Mar 2023
Extract from article:
The estimated cost of the attack was about 285 USD. We broke 762 unique wallets. All of these had a zero balance. Interestingly enough, we could break all these wallets, not because of a linear or quadratic recurrence but because there was at least one repeated nonce in the signatures. So, it looks like the common mishap of ECDSA implementations using a repeated nonce was the cause of trouble.
reply
2 sats \ 0 replies \ @Lumor 6 Mar 2023
Makes one wonder if they actually did stop early with Ethereum or got lucky.. :)
reply
0 sats \ 0 replies \ @Busybe3z 7 Mar 2023
😮
reply
0 sats \ 1 reply \ @DarthCoin 6 Mar 2023
What a bullshit crap
reply
2 sats \ 0 replies \ @notgeld 6 Mar 2023
They literally say you how many times you should avoid re-using keys. This is good.
reply
0 sats \ 0 replies \ @Emzy 7 Mar 2023 freebie
They only recovered private keys where the nonce was used twice. This type of attack is known and mitigated in #Bitcoin for many years. ( see: deterministic nonces)
#Bitcoin Core uses RFC6979 deterministic nonces since 2014 and all alternative Wallet implementations should do also.
So this should be not a problem for #Bitcoin.
RFC6979 git comit:
https://github.com/bitcoin/bitcoin/commit/3060e360980f3e80db1d903085d759338ab27f4a
0 sats \ 1 reply \ @mcguffin 6 Mar 2023 freebie
Despite others poo-poo'ing this work, I think it's 1) indeed novel but de rigeur cryptanalytic research, and 2) a reasonably well-written exposition of a well-known and long-theorized cryptanalytic weakness of ECDSA actually being exploited adversarially "in the wild", with real economic consequences. That's pretty cool!
However, framing it as a novel attack is somewhat risible given that the actual novel part, the "polynonce attack", was irrelevant to finding those 773 private keys (they all used repeated nonces and so could each have been broken much more easily). And "773 wallets broken" should instead be "exposing 773 real-world cryptanalytic breaks of Bitcoin security due to faulty Bitcoin wallets"
For someone who knows nothing about EC cryptography, it would be illuminating and useful to learn the biggest flaw in ECDSA: how utterly crucial it is to use a truly random nonce for each and every signature, and if your wallet doesn't, someone's gonna snatch yo' coins. But the hyped-up headline and misleading framing makes it sound like typical clickbait academic journalism crap.