bug: Mismatch between processing of typed data when signing and verifying

[njelich]

Is there an existing issue for this?

• I have searched the existing issues

Package Version

^2.9.25

Current Behavior

The verification fails because of additional processing of typed data struct fields that is different between signTypedData and verifyTypedData

Expected Behavior

The verification should pass.

Steps To Reproduce

POC. The address should contain both uppercase and lowercase characters (according to standard formatting).

const signature = await signTypedData(rainbowkitConfig, {
  types,
  domain,
  primaryType: 'WalletData',
  message: {
    address,
  },
})

const verificationResult = await verifyTypedData(rainbowkitConfig, {
  address,
  types,
  signature,
  domain,
  primaryType: 'WalletData',
  message: {
    address,
  },
})

Running the above code, the signTypedData will pass, but the verification will fail.

However, if the address is modified only in the verifyTypedData call, it now passess. This implies some additional processing happening before signTypedData is called in viem.

Link to Minimal Reproducible Example (StackBlitz, CodeSandbox, GitHub repo etc.)

No response

Anything else?

Likely a Viem issue, due to the following code in viem/actions/wallet/signTypedData.ts:

const typedData = stringify(
  { domain: domain ?? {}, message, primaryType, types },
  (_, value) => (isHex(value) ? value.toLowerCase() : value),
)

The PoC provided is for Wagmi, but I believe its clear enough.

[njelich]

Linking: wevm/wagmi#3983

[njelich]

My proposed fix is to remove the toLowerCase line, since that modifies the actual signed data. Changing the verification logic would break support for signatures generated by various external tooling.

This processing could be provided as a utility function that can be optionally included, and thus selectively plugged into both the verify and sign process.

[jxom]

I can't seem to reproduce this with mixed casing on the address. FWIW, the .toLowerCase call in signTypedData wouldn't have an impact on the signature as it is case insensitive. Can you please break this test that I just pushed?

[github-actions]

Hello @njelich.

Please provide a minimal reproduction using StackBlitz, TypeScript Playground (for type issues), or a separate minimal GitHub repository.

Minimal reproductions are required as they save us a lot of time reproducing your config/environment and issue, and allow us to help you faster.

Once a minimal reproduction is added, a team member will confirm it works, then re-open the issue.

[njelich]

The test breaks if the types are changeed from

      types: {
        WalletData: [{ name: 'address', type: 'address' }],
      },

to

      types: {
        WalletData: [{ name: 'address', type: 'string' }],
      },

[njelich]

Digging deeper, it in general processes any string that looks like hex, so for example hexspeak usernames also get mangled a bit.

test('https://github.com/wevm/viem/issues/2306', async () => {
  const typedData = (name: string) =>
    ({
      types: {
        WalletData: [{ name: 'name', type: 'string' }],
      },
      message: {
        name,
      },
      primaryType: 'WalletData',
    }) as const

  const name = '0xDEADBEEF'
  const lowerCaseName = name.toLowerCase() as `0x${string}`

  const address = '0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266'

  const signature = await signTypedData(client, {
    ...typedData(name),
    account: address,
  })

  const signature_2 = await signTypedData(client, {
    ...typedData(lowerCaseName),
    account: address,
  })
  expect(signature === signature_2).toBeFalsy()
})

[jxom]

Thanks for that! Reproduced and fixing now.

[github-actions]

This issue has been locked since it has been closed for more than 14 days.

If you found a concrete bug or regression related to it, please open a new bug report with a reproduction against the latest Viem version. If you have any questions or comments you can create a new discussion thread.