Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

web3_sha3 is return incorrect hashes #2507

Closed
AdvancedStyle opened this issue Oct 7, 2016 · 5 comments
Closed

web3_sha3 is return incorrect hashes #2507

AdvancedStyle opened this issue Oct 7, 2016 · 5 comments
Assignees
Labels
M4-core ⛓ Core client code / Rust. Z0-unconfirmed 🤔 Issue might be valid, but it’s not yet known.

Comments

@AdvancedStyle
Copy link

When using Parity "web3_sha3" call over RPC it is return hashes that do not match keccak-256 hashes generated by other tools.

For example in Parity:
curl -s -X POST 127.0.0.1:8545 --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x7ee1cc30f12731068b31c440512b8aaa44277ab7"],"id":1}' -H "Content-Type: application/json"

Returns:
0xd1dfd81cc922f8d23d3fc2a9e402eb814d80aca61bc0061838a67404526da305

In GETH console:
web3.sha3('0x7ee1cc30f12731068b31c440512b8aaa44277ab7');

Returns:
0x553a9ec495cafcb7c037c18d3afd3a60be1e0cbd5c16fbb13ea3480789328630

This online hashing tool agrees with GETH:
http://emn178.github.io/online-tools/keccak_256.html

@tomusdrw tomusdrw added Z0-unconfirmed 🤔 Issue might be valid, but it’s not yet known. M4-core ⛓ Core client code / Rust. labels Oct 7, 2016
@tomusdrw tomusdrw self-assigned this Oct 7, 2016
@tomusdrw
Copy link
Collaborator

tomusdrw commented Oct 7, 2016

Parity is hashing raw bytes not strings. Don't see a point of hashing a string instead of bytes:

$ echo -n -e '\x7e\xe1\xcc\x30\xf1\x27\x31\x06\x8b\x31\xc4\x40\x51\x2b\x8a\xaa\x44\x27\x7a\xb7' > file
$ rhash --sha3-256 file
d1dfd81cc922f8d23d3fc2a9e402eb814d80aca61bc0061838a67404526da305  file

@tomusdrw
Copy link
Collaborator

tomusdrw commented Oct 7, 2016

I think you can use web3.sha3('0x..', { encoding: 'hex' }); to get the same results. Seems that the conversion is done in web3 library, try using geth's API directly - it should return the same results as us.

Also please test with $ parity --geth and geth attach - the results should be the same.
Re-open if it's not the case.

@tomusdrw tomusdrw closed this as completed Oct 7, 2016
@AdvancedStyle
Copy link
Author

AdvancedStyle commented Oct 7, 2016

sha3 is used for address capitalization, so that for example:
0x7ee1cc30f12731068b31c440512b8aaa44277ab7

Capitalized for sumcheck validation is:
0x7eE1cC30f12731068b31c440512b8AAa44277AB7

Where the corresponding character in the sha3 hash it used to determine if the character in the address should be upper or lower case. If using the Parity hash it would result in a different set of uppercase characters. And the resulting address would appear as invalid.

(Note it was running parity in --geth mode when testing)

@tomusdrw
Copy link
Collaborator

tomusdrw commented Oct 7, 2016

So you need to encode the string 0x7ee1cc30f12731068b31c440512b8aaa44277ab7 to bytes: 0x307837656531636333306631323733313036386233316334343035313262386161613434323737616237.

Running:

$ curl -s -X POST 127.0.0.1:8545 --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x307837656531636333306631323733313036386233316334343035313262386161613434323737616237"],"id":1}' -H "Content-Type: application/json"
{"jsonrpc":"2.0","result":"0x553a9ec495cafcb7c037c18d3afd3a60be1e0cbd5c16fbb13ea3480789328630","id":1}

results in expected hash.

I believe geth's behaviour should be the same - it's just web3 library encoding the input for you.

@AdvancedStyle
Copy link
Author

Ok great, thanks, got it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
M4-core ⛓ Core client code / Rust. Z0-unconfirmed 🤔 Issue might be valid, but it’s not yet known.
Projects
None yet
Development

No branches or pull requests

2 participants