web3.eth.sign have different signatures generated in web3js and web3py

• Version: 3.11.1
• Python: 3.4
• OS: osx

What was wrong?

web3.eth.sign(account,web3.sha3(plaintextdata)) is generating different signatures in web3js and web3py Please include any of the following that are applicable:

• The code which produced the error

def registration_onboarding(unique_key):
    hash_op = web3.sha3('password')
    signature = web3.eth.sign(account,hash_op)
    return signature

So the above code is generating different signatures in web3js and web3py. I doing ecrecover in Solidity and the appending the ‘\x19Ethereum Signed Message\n’+lenght(message)+message in the contract itself and was able to recover the address for a web3js to Solidity call. However the signed message from Python is giving a totally different signature for same steps and same message and the ecrecover is giving incorrect account address. I observed that SHA3 for the both web3js and web3py are matching but the signature is different ?

• What type of node you were connecting to. I have testrpc client running and signing the hash with its account

How can it be fixed?

No idea Fill this section in if you know how this could or should be fixed.

[djrtwo]

@sivachaitanya Looks like web3.py is expecting a string not in hex and encoding it as hex no matter what. So your sha3 is something of the form '0xb68fe43f0d1a0d7aef123722670be50268e15365401c442f8806ef83b612976b' and being hex encoded to something of the form '0x307862363866653433663064316130643761656631323337323236373062653530323638653135333635343031633434326638383036656638336236313239373662'. I tested and if we pass in the double-encoded hex into the web3.js implementation, we get the same signature.

The following in web3.py:

web3.eth.sign(account, 'password')

Is the same as this is web3.js

// 'password' encoded as hex
var encoded = '0x70617373776f7264';
web3.eth.sign(account, encoded);

I’ll need to discuss with @carver and @pipermerriam on how we want this to behave, given the web3.js implementation. Ours should definitely be able to handle the output of web3.eth.sha3 correctly.

[pipermerriam]

@jfdelgad that’s because messages have a prefix prepended to them as part of the signing process to prevent usage of this API for transaction signing.