Hacker News Reader

Comment by cypherpunks01 | Hacker News Reader

A huge problem with signing EVM transactions using hardware wallets is that is common to be blind signing messages. The device has no knowledge of the SAFE EVM contract functions or any other context, it just asks you to sign an gobblygook opaque binary message so you may have no idea what's being signed, is my experience using multiple different vendor HW wallets. Not sure if that's what happened, but possible this type of problem contributed to the exploit. BTC TXs are simple enough that all HW wallets can basically display what's happening, but with turing-complete arbitrary computations in EVM this becomes very difficult.

View on HN

In almost all cases EVM smart contract interaction looks like a function call which can be easily decoded into JSON if you know ABI.

HW wallet doesn't need to understand the contract logic, it just needs ABI, which is generally a simpler task. Also it can show the name of function you're calling as selector is a hash of a name.

Safe is a bit more complex as it also wraps it in EIP-712 message, but that can also be decoded in a systematic way.

> with turing-complete arbitrary computations in EVM this becomes very difficult.

I have very limited knowledge about EVM, but those computations are bounded by gas, right? Evaluating them is a finite process.

But the space of their effects on the Blockchain state is vast. You need software to translate those effects to a form human can interpret as "what I want"/"not what I want".

Ie. engineering work needs to happen in the UI they used to confirm the tx

Yes, each opcode has a gas cost. Some are quite expensive, like writing storage (changing network state). Each block has a target gas limit. Say 30 million. A single transaction cannot exceed that. Additionally, a transaction specifies a bid on how much they are willing to spend, in ether, per gas. That said, transferring funds does not typically require significant gas.

What you suggest is possible (evaluate the side effects of the transaction and present that information to the prospective signer). But at present they don't do that. I'm not sure about this specific case but often it's just a supplied text string (that can say anything) that's displayed. Basically the system depends on trust in whatever came up with the transaction payload.

You can at least display the parameters that you're passing into a contract function. That keeps you from getting hacked when interacting with a well-known trustworthy contract.

Thanks for spelling this out, the explanation makes a lot of sense.

You'd think they could at least show a blockie representing the contract, or reputational party who cryptographically vouched for it.

Sometimes you have the right contract, but an attacker is making you pass in different parameters than you think. The most popular hardware wallets don't help you with this; the Ledger Nano S for example just alerts you that you're passing some kind of data to the contract, so you're relying on your computer to show the details. This is a problem when, for example, you're interacting with a token or wallet contract, and you think you're telling it to transfer $ to Alice, but actually it's $$$$ to Bob.

But there are better options with larger screens, which actually display contract parameters on the secure device.

Reply on news.ycombinator.com