> After investigation I discovered that 20 different accounts had sent a transaction to the attacker’s address, but only 9 were accounts which previously reused a nonce. What about the other 11? How did the attacker get their money? I’m not sure.
Perhaps a transaction reusing a nonce made it to the mempool, but the attacker, watching the mempool, immediately submitted (or even cooperated with a mining pool to) a transaction emptying the sending account, using a much larger fee to push out the other transaction. That would leave no trace of the nonce reuse on chain.
That is a viable possibility, yes. You wouldn't need a "much larger fee" though, just 120% of the other transaction's fee would be enough to secure prioritisation over it.
One thing I would point out is that when calculating r, the equation r=k*G mod N is somewhat misleading. G is not a number, but rather an (X,Y) point on an elliptic curve. There is a way to "add" two points on an elliptic curve but it is a group operation which is very unlike normal addition. "Multiplication" still exists between a scalar and a point but refers to a number of point self-additions.
So really R=k*G generates a new point R, where k is the nonce and G is a point that is part of the ECDSA standard. Then r is taken as the x-coordinate of R.
It is easy to derive k in b=k*a mod N if you know a and b, but nearly impossible to derive k in B=k*A if B is k self additions of A on an elliptic curve.
Crypto wallet vulnerabilities related to ECDSA nonce reuse were already a thing in 2013 [1], so it's not surprising that there are bots waiting for this.
Well, yes. If you're not willing to lose 100% of your investment to any security hole that may be discovered anywhere in the entire stack of software running on any machine from which you access your crypto account, you shouldn't invest in crypto.
Arguably, bug bounties are always paid for by users. A vendor might write the bounty-winner’s check, but the source of the vendor’s funds is the vendor’s customers.
Dan: Maybe I’m like a predator in this environment where… In this case, I was a white hat hacker, but maybe I’m a black hat hacker. Maybe I’m trying to take money from a smart contract. And I think I’m so smart. Like I put a bunch of effort into figuring out this way to steal this money from it. And as soon as I go to do that, just this whale comes up from the deep and just devours me whole. I think I’m actually at the top of the food chain and I’m not even close.
Sorry for maybe asking a stupid question, but if i understand correctly, the nounce is just a secret as the private key. But the nounce is not needed for the signature check? So, it can be choosen random and then simply forgotten after signature generation?
After first quick google search, it looks like there is also the term nounce use here but it is deterministic and just counted up which does not seem to fit with the article: https://developpaper.com/the-nonce-of-ethereum/
Am I missing something?
The nonce used for ECDSA signatures is not the same as the nonce used for Ethereum signature. The term "nonce" is a general term that is used in any number of systems to mean a value which should only be used once, and might apply to any number of layers or protocols in a given system.
There are various techniques people use for them: a careful counter, a precise timestamp, a hash of the rest of the data, or a random number. Often you can choose as the user... as long as you don't use the same value twice; alternatively, your choice of nonce might be verified by your counter-party (as with Ethereum's account nonces).
The consequences of using the same value twice will also differ: your request might be rejected/ignored, you might be penalized or cause an error, it might expose your identity to a system where you were otherwise anonymous, or it might allow someone to calculate your private key. The high-level idea is what matters, not the specifics.
Perhaps a transaction reusing a nonce made it to the mempool, but the attacker, watching the mempool, immediately submitted (or even cooperated with a mining pool to) a transaction emptying the sending account, using a much larger fee to push out the other transaction. That would leave no trace of the nonce reuse on chain.
So really R=k*G generates a new point R, where k is the nonce and G is a point that is part of the ECDSA standard. Then r is taken as the x-coordinate of R.
It is easy to derive k in b=k*a mod N if you know a and b, but nearly impossible to derive k in B=k*A if B is k self additions of A on an elliptic curve.
[1] https://bitcoin.org/en/alert/2013-08-11-android
Deleted Comment
Deleted Comment
https://corecursive.com/064-ethereum-rescue-with-dan-robinso...
Dead Comment
There are various techniques people use for them: a careful counter, a precise timestamp, a hash of the rest of the data, or a random number. Often you can choose as the user... as long as you don't use the same value twice; alternatively, your choice of nonce might be verified by your counter-party (as with Ethereum's account nonces).
The consequences of using the same value twice will also differ: your request might be rejected/ignored, you might be penalized or cause an error, it might expose your identity to a system where you were otherwise anonymous, or it might allow someone to calculate your private key. The high-level idea is what matters, not the specifics.