I have been investigating message signing using an Ethereum account, and have become somewhat bemused by the different signatures that I receive from different clients and different libraries.

I have attempted to get answers by contacting library/client creators directly but have gotten no definitive answers.

When I utilise jsonrpc to send off a signing (web3.eth.sign) request to a Parity (1.6.6) backend, and a Geth (1.6.1) backend I get the following signatures back:

Geth 0xf6e5ce6040407c688c54c4b15949923e94651790afe4c53070c4765869cdbd713e4ea40b3b6f4a59397cb6a0880f265e9d1a0d1ed97fa9b757dc3799086fe6b91c

Parity 0x1cf6e5ce6040407c688c54c4b15949923e94651790afe4c53070c4765869cdbd713e4ea40b3b6f4a59397cb6a0880f265e9d1a0d1ed97fa9b757dc3799086fe6b9

Now.. I do not have an in depth understanding of elliptical curve cryptography, but i can see here that Geth returns a RSV format signature, and Parity a VRS.

Question 1 Is there a consistent way of determining which format the signature is in (for backwards compatibility)?

Now.. I am trying to work with these signatures using the fantastic ethereumjs-util library.

Utilising their ecsign method returns me a completely different signature:


I managed to recreate this signature from my Geth/Parity signatures by calling their toRpcSig method with the r,s, and v values extracted from the Geth/Parity sigs.

Looking at the code it seems to concatenate Buffer versions of these values and converts the result to a string.

Question 2 Why does ethereumjs-util do this?

The end result is that geth, Parity, and ethereumjs-util all return different signatures when signing an arbitrary message. Etherscan, and etherchain have signature verification libraries which believe the ethereumjs-util signature to be correct. This may well be because they use the library under the hood. If this is correct..

Question 3 Why do Geth and Parity both return incorrect message signatures?

There seems to be a lot of github discussions etc about appending prefixes to messages before signing them etc, yet seemingly no-one has addressed the issue of client inconsistencies in signing.. which in my opinion is pretty important.

  • 1
    Are you aware of this discussion? Might wish to subscribe. github.com/paritytech/parity/issues/5490 – Afr May 8 '17 at 9:56
  • Thanks for the link. i had seen that diagram elsewhere. So essentially as of yet there is no client consensus on what a valid signature is? – Thomas Clowes May 8 '17 at 10:56
  • Gavin just posted a statement in the issue linked above. He says parity follows the Ethereum wiki specification. – Afr May 9 '17 at 13:51
  • To make matters worse, TREZOR went in a different direction and decided to not use message.length as a returned ASCII integer, but convert it into a varInt. It's a shit-show. – EvilJordan Feb 11 '18 at 4:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.