Chris Carlson on Warpcast

Content pfp

0 reply

0 recast

0 reaction

lightclient pfp

"One bad signature will be able to drain your account on Ethereum after EIP-3074." Yes; this is true. 3074 coauthor here! Let me put this concern to rest a bit before it gets more out of hand.

19 replies

23 recasts

96 reactions

lightclient pfp

To start: I'm not aware of any wallets that support signing unprefixed data today. This means that currently, no wallets support 3074. Doesn't matter how many control panels you navigate through or advanced features you turn on. It isn't possible to sign a 3074 message today.

2 replies

0 recast

7 reactions

lightclient pfp

The messages you sign to "login" to dapps use a completely different standard based on EIP-191. This prepends the following data to the message you sign: """ 0x19 <0x45 (E)> <thereum Signed Message:\n" + len(message)> <data to sign> """

1 reply

0 recast

6 reactions

lightclient pfp

That's what makes it impossible to trick someone logging into a dapp to actually sign a valid Ethereum transaction. Transactions are prefixed with single byte values: 0x01 - 2930 tx 0x02 - 1559 tx 0x03 - 4844 tx more info here: https://github.com/ethereum/execution-specs/tree/master/lists/signature-types

1 reply

0 recast

6 reactions

lightclient pfp

3074 plans to use the prefix 0x04. This will disambiguate it from all other types of signable data in Ethereum. Wallets will have to actively opt-in to allowing users to sign these messages.

1 reply

1 recast

6 reactions

lightclient pfp

Depending on how wallets integrate 3074, they could create a situation where their users can more easily be exploited. To understand this, we need to make sure we understand how 3074 signatures work.

1 reply

0 recast

4 reactions

lightclient pfp

The auth msg which the signature is constructed over have the below fields. Importantly, it includes an invoker address. This is the only address under which the signature will be considered valid by AUTH.

1 reply

0 recast

4 reactions

lightclient pfp

For an account to be drained 1) the wallet will need to allow users to sign to any invoker address and 2) the users must not verify the invoker is trustworthy. Do either of those and there is not an issue.

1 reply

0 recast

3 reactions

lightclient pfp

For 1) we hope wallets understand that 3074 invokers are more akin to extensions of their code than they are contracts. Wallets don't give users the freedom to run arbitrary code with access to their pk; similarly, they shouldn't allow users to delegate their account arbitrarily.

1 reply

0 recast

4 reactions

lightclient pfp

So if wallets insecurely integrate 3074 *and* users do not verify the invoker they're interacting with, it is possible to delegate to a malicious invoker. However, it is possible to undo by sending a single tx from the EOA. This revokes all "in-flight" AUTH signatures.

1 reply

0 recast

5 reactions

lightclient pfp

At minimum, wallets should make signing a 3074 message a big deal. This is like exporting-your-private-key level of big deal.

2 replies

0 recast

6 reactions

Chris Carlson pfp

@chrislarsc.eth

Can you clarify? I thought these are supposed to be every-day actions. Is that not true? If so, it seems like it would be awful UX to have “big red scary warning” (that is what exporting-your-private-key UI looks like) every time you sign a 3074 message. Thank you.

1 reply

0 recast

0 reaction

lightclient pfp

An invoker should only require one 3074 AUTH msg to initiate the delegation, then with a different key you can make more regular signatures over tx batches and the like.

0 reply

0 recast

0 reaction