As was mentioned prior, the article that detailed this attack is mistaken and this issue has nothing to do with create vs create2. The create opcode does not calculate a secp256k1 key, so I’m not sure what your benchmarks are trying to prove.
We are comparing the time it takes to sha3(1024 bits) key vs sha3(unique secp256k1 key). You are free to calculate the difference between these two, and by all accounts this should be more than a factor of 1,000, which is why its being used in this ongoing attack on the network.
Sorry that my calculations weren’t clear, but yes - what i’m saying is that calculating a secp256k1 key is hard to do in an accelerated mode, because it is memory-hard calculation, which is common in KDF construction. I think we all know hash functions are fast.
I’m looking for a vanity wallet generator to make this easier, but it looks like the eth vanity wallet generators mostly use the sha3() shortcut, and aren’t even trying to generate a keypair:
It looks like this project is generating a keypair, you are welcome to run it:
I can help your confusion. profanity does public key derivation for address mining of both CREATE addresses and EOAs. My benchmark did it for CREATE. Both methods do public key derivation. ERADICATE2 does CREATE2, and so does not do public key derivation. I measured that CREATE2 is 34x faster than CREATE, not 1000x+ faster.
The final step of address calculation is keccak; private key account addresses are a hash of their public key. In python using web3 and coincurve this is:
The CPU-based vanity generators are far behind the GPU-based ones.
Worth noting that keys generated by profanity are mostly pwned due to low initial seed entropy. I have a patch but upstream is not maintained any-longer.
I’m pretty sure if you used profanity to generate homomorphs you’d find it is slower than 34x, and that was and still is my entire point. Bitcoin doesn’t use sha3(1024bit string) to generate identities and they aren’t being exploited like we are. The only way to conduct this attack on bitcoin is using a tool like profanity.
Yes, profanity keys are weak… who’s side are you on here? Why do you care how strong the attacker’s keys are? Forcing the attacker to use both expensive and weak keys is a good thing.
Correct me if I’m wrong, but I don’t believe there is any concern with CPU consumption of the EVM because processing power is increasing, and our demands on the network are capped. (Remember when we had PoW? That didn’t seem to be a problem…)
We have developed proper KDFs that prefer CPU execution over GPU for this exact purpose. bcrypt with a cost factor of 2 or 4 would make a difference for a GPU but not a CPU. Or pbkdf2 with a small number of iterations and using the public-key as both the input and salt:
pbkdf2_sha3(public_key, public_key, 1000, 20)
I don’t think this change would even be measurable. Not fixing this issue however, is measurable and we can see its getting worse over time.
We use computational effort to ensure safety of the system as a whole. At no point did anyone recommend “slowing down” the EVM - we still forming blocks every ~12s right?
There are ways of patching this issue with using little or no resources.
For example, networks that use base58 representation of wallets instead of base16 make the computation of homomophs more expensive, this is due to the fact that base58 encodes ~5.858-bits of information per character, where as base16 can only encode 4-bits. Simply using a greater encoding density wouldn’t incur any performance impact on behalf of the network, and the community would benefit from having smaller wallet addresses. Everyone wins from this change, except of course: the attacker.
The age of a bug doesn’t make it any less valuable in an attacker’s hands. Just because the bug is well known, doesn’t make it any less effective. Just because someone you respect wrote insecure code, doesn’t mean that the author doesn’t regret doing so. Hindsight is 2020, and I’m sure that every victim will tell you that this is worth fixing. By all accounts if we do not address this problem, it will become worse.
Now there are multiple ways of addressing this issue. Punting and requiring 3rd party vendors to come up with their own patch is an one approach, but I’m not sure it is in the best interest of the community. We have these powerful computers at our command, shouldn’t they be used to make a more trustworthy system at every level?