Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

signTypedData_v4 not according to specification #106

Open
cammellos opened this issue Oct 29, 2020 · 0 comments · May be fixed by #107
Open

signTypedData_v4 not according to specification #106

cammellos opened this issue Oct 29, 2020 · 0 comments · May be fixed by #107

Comments

@cammellos
Copy link

cammellos commented Oct 29, 2020

I was implementing signTypedData_v4 for our project, and I have used the tests in this repo to make sure our implementation was sound.

I then noticed that geth provided their own https://github.com/ethereum/go-ethereum/blob/43c278cdf93d5469702fd1c2f570dbf3c1718ff0/signer/core/signed_data.go#L323 , so I plugged in the tests from this repo in geth and noticed that the behavior was not consistent.

Upon further investigation, I noticed that currently the behavior of signTypedData_v4 is not according to
https://eips.ethereum.org/EIPS/eip-712 when it comes to encoding arrays.

The eip states:

The array values are encoded as the keccak256 hash of the
concatenated encodeData of their contents

The behavior instead was to encode array values as the keccak256 of the
concatenated keccak256 of the values.

This worked well for primary types, but not for struct, as encodeData
per spec is:

The encoding of a struct instance is enc(value₁) ‖ enc(value₂) ‖ … ‖ enc(valueₙ) , i.e. the concatenation of the
encoded member values in the order that they appear in the type.
Each encoded member value is exactly 32-byte long.

Instead, we are using basically hashStruct instead of encodeData

@Gudahtt Gudahtt added the bug label Jul 15, 2021
@Gudahtt Gudahtt added this to the signTypedData_v5 milestone Sep 16, 2021
@mcmire mcmire self-assigned this Nov 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants