Strange buffer hex post signature

[woywoy123]

Hello there,

First off, absolutely amazing project. I am trying to compare the output of the library to something like eth_account for python and Web3. I found this strange offset f842a0 after signing a simple message. The full source code is given in the screenshot below. Notice I am using the private key as was given in the Examples section of the docs.

The above code, seems to return the following signature:

f842a0
40911813bd523b3dbc83f5eb06d024fb43d09609068842dba37c53527fabc33e
a0
3ec391e743b820de01600842f7b23af1b19786e5778766f7e94798bfe500807a

With input keccak hash being:
85f11dc9d9ca7c444897e464dcc1bf1b936931cba10fe3b7b4e58b516a6851a8

What I find relatively interesting is that doing the exact same operation using eth_account, one yields the following signature;

0x40911813bd523b3dbc83f5eb06d024fb43d09609068842dba37c53527fabc33e
3ec391e743b820de01600842f7b23af1b19786e5778766f7e94798bfe500807a
1c

Notice how there are two intermediate hex strings within the signatures (f842a0 and a0). I am not quite sure where these are originating from.

[mhw0]

Hello @woywoy123 I'm glad you liked the project.

Please, give me some time to investigate this thing. Also, It would be great if you sent me the code, not a screenshot :) Thank you!

[DerXanRam]

Hello there,

First off, absolutely amazing project. I am trying to compare the output of the library to something like eth_account for python and Web3. I found this strange offset f842a0 after signing a simple message. The full source code is given in the screenshot below. Notice I am using the private key as was given in the Examples section of the docs.

The above code, seems to return the following signature:

f842a0 40911813bd523b3dbc83f5eb06d024fb43d09609068842dba37c53527fabc33e a0 3ec391e743b820de01600842f7b23af1b19786e5778766f7e94798bfe500807a

With input keccak hash being: 85f11dc9d9ca7c444897e464dcc1bf1b936931cba10fe3b7b4e58b516a6851a8

What I find relatively interesting is that doing the exact same operation using eth_account, one yields the following signature;

0x40911813bd523b3dbc83f5eb06d024fb43d09609068842dba37c53527fabc33e 3ec391e743b820de01600842f7b23af1b19786e5778766f7e94798bfe500807a 1c

Notice how there are two intermediate hex strings within the signatures (f842a0 and a0). I am not quite sure where these are originating from.

bro can u provide full code sample please?

[woywoy123]

@DerXanRam @mhw0

Apologies for the delay, here is a minimal example as shown in the screenshot =)

void ExampleSignature()
{
    uint8_t privkey[] = {
                            0xdf, 0x57, 0x08, 0x9f, 0xeb, 0xba, 0xcf, 0x7b,
                            0xa0, 0xbc, 0x22, 0x7d, 0xaf, 0xbf, 0xfa, 0x9f,
                            0xc0, 0x8a, 0x93, 0xfd, 0xc6, 0x8e, 0x1e, 0x42,
                            0x41, 0x1a, 0x14, 0xef, 0xcf, 0x23, 0x65, 0x6e
    };

    uint8_t test_[1] = {0x04};

    uint8_t keccak[32];
    uint8_t keccak_eth[32]; 


    std::stringstream ss; 
    eth_keccak256(keccak, reinterpret_cast<uint8_t*>(&test_), 1); 
    for (uint8_t x : keccak){ss << std::hex << std::setfill('0') << std::setw(2) << (int)x;}
    std::cout << ss.str() << std::endl;

    ss.str(""); 
    eth_keccak256p(keccak_eth, keccak, 32); 
    for (uint8_t x : keccak_eth){ss << std::hex << std::setfill('0') << std::setw(2) << (int)x;}
    std::cout << ss.str() << std::endl;

    eth_ecdsa_signature sign_data;
    eth_ecdsa_sign(&sign_data, privkey, keccak_eth);

    uint8_t* r = sign_data.r; 
    uint8_t* s = sign_data.s; 
    
    ss.str("");
    for (unsigned int u(0); u < 32; ++u){ss << std::hex << (int)r[u];}
    std::cout << ss.str() << std::endl; 

    ss.str("");
    for (unsigned int u(0); u < 32; ++u){ss << std::hex << (int)s[u];}
    std::cout << ss.str() << std::endl; 
}

[woywoy123]

Also another thing that caught my attention was the chainid when one uses it for v. It seems that eth_account yields a different result, not sure why this is. In my usecase, I just subtract 28 - sign_data.v, which seems to be somewhat consistent with what they have.

[DerXanRam]

Also another thing that caught my attention was the chainid when one uses it for v. It seems that eth_account yields a different result, not sure why this is. In my usecase, I just subtract 28 - sign_data.v, which seems to be somewhat consistent with what they have.

sorry i don't understand what u say. And using the above code my result is little bit different. the output i got is

f343681465b9efe82c933c3e8748c70cb8aa06539c361de20f72eac04e766393
85f11dc9d9ca7c444897e464dcc1bf1b936931cba10fe3b7b4e58b516a6851a8
40911813bd523b3dbc83f5eb6d024fb43d096968842dba37c53527fabc33e
3ec391e743b820de160842f7b23af1b19786e5778766f7e94798bfe50807a

[woywoy123]

Apologies for the very delayed response, I have been rather busy. I have created a simple example of what I am suggesting to be inconsistent:

from eth_account.messages import encode_defunct
from eth_account import Account
from uuid import uuid1, UUID
from web3 import Web3, utils
import hashlib
import requests
import binascii

signer = Account.from_key(wallet_private_key)
addr = binascii.a2b_hex(wallet_address[2:])

for i in range(1000):
    x = uuid1()
    para = [
            (4).to_bytes(),
            x.bytes,
            addr,
            'IDEX-USDC'.encode(),
            (0).to_bytes(),
            (1).to_bytes(),
            '1.00000000'.encode(),
            (1).to_bytes(),
            ''.encode(),
            ''.encode(),
            ''.encode(),
            (0).to_bytes(),
            (0).to_bytes(),
            (0).to_bytes(8)
    ]
    # 64 -> 8*6
    d = Web3.keccak(b"".join(para)).hex()
    sig = signer.sign_message(encode_defunct(hexstr = d))
    print(sig.v)
    print(sig.signature.hex())
    sig = sig.signature

If you insert the same UUID into the above, you may notice that the signature produced by eth_account is slightly different than what is being generated with libethc. Specifically, "v" is the issue.