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

Strange buffer hex post signature #36

Open
woywoy123 opened this issue Nov 8, 2023 · 6 comments
Open

Strange buffer hex post signature #36

woywoy123 opened this issue Nov 8, 2023 · 6 comments
Assignees

Comments

@woywoy123
Copy link

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.

Screenshot_20231109_072521

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
Copy link
Owner

mhw0 commented Nov 9, 2023

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!

@mhw0 mhw0 self-assigned this Nov 9, 2023
@DerXanRam
Copy link

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.

Screenshot_20231109_072521

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
Copy link
Author

@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
Copy link
Author

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
Copy link

DerXanRam commented Nov 10, 2023

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
Copy link
Author

woywoy123 commented Dec 4, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants