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

TVM: Discrepancy in HASHEXT_KECCAK256: Ignored Cell Refs Cause Inconsistencies with EVM Keccak-256 #1324

Open
yongjun925 opened this issue Oct 27, 2024 · 0 comments

Comments

@yongjun925
Copy link

Describe the issue

The HASHEXT_KECCAK256 implementation in TON differs from the Keccak-256 implementation in the EVM. In TON, the HASHEXT_KECCAK256 does not handle Cell refs, leading to a discrepancy in hash results compared to the EVM, which could potentially cause hash conflicts.

What behavior did you expect?

I expected HASHEXT_KECCAK256 in TON to process Cell refs similarly to the EVM’s Keccak-256 implementation, ensuring consistent hash results across both platforms.

What was the actual behavior?

The current behavior of HASHEXT_KECCAK256 in TON only hashes the Cell data without taking the refs into account, resulting in different hash values compared to the EVM’s Keccak-256 for the same data structure.

How reliably can you reproduce the issue, what are the steps to do so?

(int) keccack256_single(slice _t0) asm "1 PUSHINT HASHEXT_KECCAK256";
int op = in_msg_body~load_uint(32);
if (op == op::keccack256()) {
dump(in_msg_bodyload_uint(64));
~dump(in_msg_body);
~dump(keccack256_single(in_msg_body));
}

messageBody1 x{0000006800000000000000000300007DDE0000334B0000000000000000000000008157668EC72C279C20C9D7387B7B711FCF713A4D0000271AEFAB5D355AD91A98BCBACEA3854E0EECB83942801BE6722B9A941317F050E2A668656C6C6F20776F726C642068656C6C6F20776F726C64202168656C6C6F20776F726C642068}
x{656C6C6F20776F726C64202168656C6C6F20776F726C642068656C6C6F20776F726C642021}
Output result1: 112128826363682873612496808615290492480709047111283954187881755354176156987312

messageBody2 x{0000006800000000000000000300007DDE0000334B0000000000000000000000008157668EC72C279C20C9D7387B7B711FCF713A4D0000271AEFAB5D355AD91A98BCBACEA3854E0EECB83942801BE6722B9A941317F050E2A668656C6C6F20776F726C642068656C6C6F20776F726C64202168656C6C6F20776F726C642068}
x{656C6C6F20776F726C64202168656C6C6F20776F726C642068656C6C6F20776F726C64202168656C6C6F20776F726C642068656C6C6F20776F726C64202168656C6C6F20776F726C642068656C6C6F20776F726C642021}
Output result2: 112128826363682873612496808615290492480709047111283954187881755354176156987312

hexToBigInt(
keccak256(
'0x0300007DDE0000334B0000000000000000000000008157668EC72C279C20C9D7387B7B711FCF713A4D0000271AEFAB5D355AD91A98BCBACEA3854E0EECB83942801BE6722B9A941317F050E2A668656C6C6F20776F726C642068656C6C6F20776F726C64202168656C6C6F20776F726C642068' as '0x',
),
)
Output result3: 112128826363682873612496808615290492480709047111283954187881755354176156987312

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

No branches or pull requests

1 participant