Bug: func createIdentity() always fails

[rommex]

Describe the bug

We are trying to integrate the SDK with our app and we find that the method createIdentity() constantly fails in line 41 of the SigningKey.swift file:

let recoveredKey = try KeyUtilx.recoverPublicKeyKeccak256(from: signature.rawData, message: message)

Expected behavior

I tried to replicate this flow with the standard SECP256K1 library (signing + recovery) and it works with one condition:

Signing as well as recovery is done with the keccak hash of the message, not the message itself (as you have currently in the line 41)

Steps to reproduce the bug

Just try to create an identity

[nplasterer]

Thanks for the bug report @rommex I'm not able to reproduce this on my end. We test createIdentity() in the example app and in the test suite. Everything seems to be working as expected. Do you mind sharing some more context on the code you're writing?
If you're looking for a more in-depth iOS example I can direct you towards our https://github.com/xmtp-labs/xmtp-inbox-ios.

[rommex]

Hi @nplasterer thanks for your response.

I had to take some time to investigate and found out that it's not the signing process itself that was causing the problem, but the fact that I omitted this line of code which seems to be present in your code:

bytes[bytes.count - 1] = 1 - bytes[bytes.count - 1] % 2

Basically your code alters the last byte of the signature to 0 or 1 depending on the last byte of the original signature.
Could you please explain / refer me to some docs about this change?
I'm seeing this for the first time and I wonder why it is needed.

As I understand your code alters all signatures, even coming from external wallets like MetaMask etc

Thanks!

[jazzz]

Basically your code alters the last byte of the signature to 0 or 1 depending on the last byte of the original signature.

The last byte of the signature is the ECDSA recoveryID. It's used to tell which EC point to use during recovery. Individual projects sometimes choose to use special encodings of this value( e.g: EIP-155, and BIP-137 )

XMTP uses the canonical values [0,1] as the protocol is chain agnostic. Since signers make different assumptions about how the V value should be encoded, our SDKS force all signatures it into the base range for maximum interop.