I have seen quite a few examples where both the data and the hash of the data is passed.

The signature is verified using ecrecover which is fine.

The passed hash is also verified against the calculated hash. I do not see what that second verifications adds in terms of message integrity and checking the originator. If the calculated hash is used to verify the signature and it is wrong, the signature verification should fail. Am I missing something ?

function Check(string data, bytes32 hash, bytes32 r, bytes32 s, uint8 v) public returns (bool) {

    var calculatedHash = keccak256(this, data);

    // do we need this ?
    assert(hash == calculatedHash);

    // should not this one be sufficient ?
    assert(msg.sender == ecrecover(calculatedHash, v, r, s));


2 Answers 2


If you need to prove that the data you're trying to validate is as stated then you need to check that it matches the hash that produces a valid signature. Otherwise all you're checking is that the key in question signed something, but not what they signed.

The part your example could have omitted is passing the hash into the function as a parameter. You could have simply calculated the hash again from the data, then checked that the hash was signed with the correct key.

In some workflows you may have created the hash earlier and stored that as the identifier for your contract instead of the data. In that case you can skip passing in the data at this stage, and just work with the hash.

  • So we agree that, when you can calculate the hash, passing it does not add anything. Right ? Commented Oct 16, 2017 at 7:00
  • Right, just the data string would have worked in this example. Then make the hash with that and use ecrecover to check the the signature it right. Commented Oct 16, 2017 at 8:48
  • Why does the signed data always produce the same length output, i.e. 132 characters of data that can be split into r/s/v, if the input can be arbitrary length? A signed message isn't a hash, so why does it produce a fixed size output? Does this imply that eth_sign hashes the message before signing.. Commented Nov 14, 2018 at 23:50
  • ECC signature operations work on 32 bytes of data, so as you suggest a signing function that takes plaintext as a parameter will hash it before signing. (It may also prepend some extra plaintext before hashing to avoid it looking like a normal transaction.) I don't know enough crypto to tell you how that relates to the length of the signature data. Commented Dec 3, 2018 at 1:34

I believe the cryptographic property that this function is trying to verify is integrity:

Enveloped Public Key Encryption (EPKE) is the method of applying public key cryptography and ensuring that an electronic communication is transmitted confidentially, has the contents of the communication protected against being modified (communication integrity)

source wikipedia

Looking at the function in isolation (without any business process context) makes it hard to be certain of what this check function is hoping to achieve, how it is called etc. but my best guess it to prevent a malicious actor from being able to subvert the check by impersonating another account

ecrecover will return the public key, paired with the private key, of the account used to sign this message - the problem with calling this function naively is a sort of "replay attack".

As a malicious actor, let's say that there is a benefit to me being able to impersonation public key P.

Let's also say that there's communication protocol where we give clients a message and ask them to sign it in order to verify their identity to authenticate them.

Let's also say that your system just naively took the contents of a message returned by the client and didn't check the hash of it matches up with the original message.

As a malicious actor, I would be able to impersonation P by looking at the blockchain for the messages that M has returned to you and inject one of those in my response. Ecrecover would return public key P and the check function would be subverted.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.