Signer may send a signature valid for both send() and claim() about burner-wallet HOT 3 CLOSED

Sorry for the long delay. What is the status of this issue? Should we put a PR in on the contract?

from burner-wallet.

@catageek can you explain a little more?

The signature can then be used by the attacker in claim() after 100 blocks.

This part is not clear. How can it be used after 100 blocks? From my understanding, it gets locked in the contract.
I think that a fix to create a unique key even if an id is reused could be:
keccak256(id, destination, nonce, contract address)

from burner-wallet.

@riusricardo It's a misunderstanding of my part. In fact the Claim() can be done immediately before the expiration delay (which is 100 blocks).

I think that a fix to create a unique key even if an id is reused could be: keccak256(id, destination, nonce, contract address)

Yes, contract address being the address of the Wallet. To avoid signature domain collision, each contract should have a unique key that no other contract will generate, so keccak256(Id) in send() should be keccak256(Id, nonce, factory contract address, msg.sender) to be sure that the data is signed for your contract and not replayed from something else.

EDIT: I changed the order of arguments to keccak256(Id, nonce, factory contract address, msg.sender) in send() to never collide with keccak256(Id, destination, nonce, contract address) in claim()

from burner-wallet.