Strange buffer hex post signature
woywoy123 opened this issue · comments
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.
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!
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?
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;
}
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.
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
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.