1° That was not my point. My point was that creating a malicious contract that a user might trust is now easier than before with your description. Since the description would be correct, the underlying code could, of course, do something else.
2° I looked it up, and Ledger actually has such a system already. They call it clear signing with EIP-712. It works similarly to what I suggested—no guesswork needed. However, I think they use a central database to query on the fly to save space on the device. If they stored it entirely on the device for some high-stakes contracts, it could work fine along with some contract address whitelisting, even with the correct translation for the user.
www ledger com / blog / securing-message-signing
Probably, the lack of standards, frequent upgrades, and extensibility for these existential use cases has prevented hardware manufacturers from implementing this correctly. Which was my point all along—if you read my previous posts—that these existential use cases should be standardized.
I’m sorry, but reading this reply, specially the second point, makes me think you haven’t read the OP.
Can you describe exactly why you think this is the case? What are you imagining are the steps an attacker would take, the user would take, and how this proposed change would have an impact on that process.
The change here does not propose anything that would alter the mechanism by which a contract establishes initial trust with the user and convinces them to send their money to the contract in the first place. It only makes it so once a user has entrusted a contract with their money they can trustlessly interact with it from an offline device without needing to worry about man in the middle attacks like we saw with ByBit.
1 Like
1° @GCdePaula Have you read the Ledger documentation? This is exactly what Ledger has been able to do for years by merely using EIP-712, and @MicahZoltu claimed was impossible. Also, translations can easily be supported with that solution, whereas your proposal would struggle significantly with heavy string manipulations. If hardware wallets implemented this entirely on the device with some whitelisting of contract addresses, and if every signer used a different brand hardware wallet, this would surely have prevented the Bybit hack. We don’t need even more complexity that increases the attack surface and requires extra signing—we need more standardization for these high-stakes use cases.
2° @MicahZoltu I think I’ve explained it pretty well in three posts already.
We simply disagree, and that’s fine. I’ll leave it at that.
Best of luck with your proposal.
If you had read the post, you’d know about EIP-712 (typed data) and clear signing, why it is not enough alone, and that my proposal uses typed data and clear signing as part of the solution.
I don’t know where you’re getting this. The K&R from 1978 could already format strings to the necessary degree. The added compute costs and mitigations are addressed in the original post.
The users interacted with the correct address, but signed a transaction (to the correct address) with a spoofed payload. It’s not possible that a transaction sent to contract A can make contract A change the state of contract B, as @MicahZoltu has already explained.
Not really, no.
I think this is the end of the conversation from my side. Cheers!
After this, I think we should note that this proposal is not limited to transactions with 712 signatures. Normal transactions can also benefit by adding the description text field as the first argument of every public function.
1 Like