Error from secp256k1 ECDSA ecdsa_recover_internal

[LawsonGraham]

Discord user ID

No response

Describe your question in detail.

My goal is to securely confirm that a user's ETH address is owned by an Aptos address and vice versa - essentially a 'handshake'.

The way I want to do this is:

1. Have the ethereum wallet sign a message that is hash(aptos address)
2. Have the aptos account call a method verify_eth_address which is called with the user's aptos address signer, alongside the ECDSA signature created by the ethereum wallet

in verify_eth_address, we can verifyL:
aptos address by asserting the hash(aptos address) == message signed
eth address by recovering the signer public key, using keccak to hash that to get the eth address, and asserting recovered eth address == eth address passed in

I have implemented the logic, but I am getting the error:

native fun ecdsa_recover_internal(
│ │ ^^^^^^^^^^^^^^^^^^^^^^
│ │ │
│ │ Test was not expected to error, but it aborted with code 65537 originating in the module 0000000000000000000000000000000000000000000000000000000000000001::secp256k1 rooted here

I have confirmed my args are parse in correctly:

let eth_address = x"<>"; // Your Ethereum address
let message = x"<>"; // Your Aptos address as a message (32 bytes SHA-256 hash)
let signature_bytes = x"efa2bc059fee02ae6ca419fe9b6b7e0825587a818290056729964bf1f81202ba74883695114c2dbf29fe2ed7cb06d3300e9eefaa0b6a19e6c4ab8e8ca39cb910"; // r + s combined
let recovery_id = 27; // Recovery ID

What error, if any, are you getting?

native fun ecdsa_recover_internal(
│ │ ^^^^^^^^^^^^^^^^^^^^^^
│ │ │
│ │ Test was not expected to error, but it aborted with code 65537 originating in the module 0000000000000000000000000000000000000000000000000000000000000001::secp256k1 rooted here

this ecdsa_recover_internal is a native function, so I can't see the logic to try and debug.

What have you tried or looked at? Or how can we reproduce the error?

I've verified args are parsed and loaded in correctly, the hashed messages line up too

I looked through aptos github for the error code, and nothing useful came up. Only relevant this is here: https://github.com/aptos-labs/nft-tutorial/blob/9d13e34eb5482f740f57b5c3e7db71e8d091e7e6/tutorial/step_5/BasicCoin/build/BasicCoin/sources/dependencies/AptosFramework/account.move#L643

this error suggests public key cannot be found... potential issue could be that ETH public keys aren't acceptable on aptos for some reason?

Which operating system are you using?

macOS

Which SDK or tool are you using? (if any)

Aptos CLI

Describe your environment or tooling in detail

No response

[LawsonGraham]

here is code framework btw:

public entry fun verify_accounts_entry(
        aptos_address: &signer,
        message: vector<u8>,
        recovery_id: u8,
        signature_bytes: vector<u8>,
        eth_address: vector<u8>
    ) {
        // Ensure the signature is 64 bytes (r + s)
        assert!(std::vector::length(&signature_bytes) == SIGNATURE_NUM_BYTES, ERR_MALFORMED_SIGNATURE);

        let signature = secp256k1::ecdsa_signature_from_bytes(signature_bytes);
        verify_accounts(aptos_address, message, recovery_id, &signature, eth_address);
    }

    public fun verify_accounts(
        aptos_address: &signer,  // The Aptos account (as the caller)
        message: vector<u8>,
        recovery_id: u8,         // The 'v' value from the Ethereum signature (recovery id)
        signature: &ECDSASignature,
        eth_address: vector<u8>      // The expected Ethereum address (20 bytes)
    ) {
        assert!(vector::length(&eth_address) == ETH_ADDRESS_SIZE, ERR_MALFORMED_ETH_ADDRESS);

        let hashed_message = sha2_256(message);

        let recovered_key_option = secp256k1::ecdsa_recover(hashed_message, recovery_id, signature);
        assert!(option::is_some(&recovered_key_option), ERR_SIGNATURE_RECOVERY_FAILED);
        let recovered_key = option::extract(&mut recovered_key_option);

        let recovered_eth_address = aptos_hash::keccak256(secp256k1::ecdsa_raw_public_key_to_bytes(&recovered_key));
        assert!(recovered_eth_address == eth_address, ERR_ETH_ADDRESS_MISMATCH);
        assert!(signer::address_of(aptos_address) == from_bcs::to_address(message), ERR_APTOS_ADDRESS_MISMATCH);
    }
    ```

[alinush]

Can you post the full code with the Move test and the input data please? 🙏

[alinush]

I think the code you posted above also does the signing, right?

[LawsonGraham]

@alinush yeah, everything I'm doing is included in the repo - feel free to try for yourself. I pushed info on what to do in the README.md. I stepped through all of the ethers signing logic, and I don't believe there's any extra hashing I'm not aware of in my current flow. I do aptosAddress -> keccak256(aptosAddress) -> signature on the message keccak256(aptosAddress) on ethers side.

As another confirmation of this, both the hash on aptos side and on eth side of the message are the same, so I believe it is in signature side of things

[alinush]

What about endianness? And (un)compressed PKs?

[LawsonGraham]

Ok I figured it out - it seems for some reason SigningKey.computePublicKey(process.env.ETHEREUM_PRIVATE_KEY) which I was using to view the public key given my PK has this property:

// raw public key; use uncompressed key with 0x04 prefix
if (bytes.length === 64) {
const pub = new Uint8Array(65);
pub[0] = 0x04;
pub.set(bytes, 1);
bytes = pub;
}

so they were the same public keys, it just appended 0x04 to the front (not sure why they do this)

So, it turns out that my signatures are producing the right output and recovering the Public Key correctly.