Issue while trying to verify signature

Question

I am using the following to sign a message

 var str="Trial with signature";
 text=web3.sha3(str);
 var sig=web3.eth.sign(eth.accounts[0],text);

Now after obtaining the hash value from the text and the signature, to verify the same, I use the following contract

contract signature
{
    event ret_addr(address addr);
    function sig_verify(bytes32 hash, bytes sig) returns(address)                       //verifying the signature
    {
        bytes32 r;
        bytes32 s;
        uint8 v;
        assembly 
        {
                r := mload(add(sig, 32))
                s := mload(add(sig, 64))
                v := byte(0, mload(add(sig, 96)))
            }
        if(v<27)
            v+=27;
        ret_addr(ecrecover(hash, v, r, s));
    }
}

The issue is I am not getting the correct address back. Why is this so? It used to work fine earlier but now it is giving some random addresses.

Answer 1

You might need to add a prefix to the data as discussed in issue #3731:

bytes memory prefix = "\x19Ethereum Signed Message:\n32";
hash = sha3(prefix, hash);

Related

• Getting the wrong address back from ecrecover
• workflow on signing a string with private key, followed by signature verification with public key
• I need help with signatures
• Does ecRecover in solidity expects the "\x19Ethereum Signed Message:\n"-prefix
• Should signed text messages use the "\x19Ethereum Signed Message" prefix?
• Totally baffled by ecrecover

Answer 2

Something is wrong with assembly section. You can debug by extending your event like this

event ret_addr(address addr, uint8 v, bytes32 r, bytes32 s);

and call it with corrwsponding variables

ret_addr(ecrecover(hash, v, r, s), v, r, s);

My result:

[
    {
        "topic": "1171b064e2eda38d82ce5fadc8a911d493f2d22ff88013d965c9885638dee60d",
        "event": "ret_addr",
        "args": [
            "0x0",
            "97",
            "0x3078613963356435666332336333663762313130313134313262663536366432",
            "0x3638333437353534666561666665333164363662343539383739373435373562"
        ]
    }
]

As you can see, v is neither 27 nor 28. r and s are not hex encoded but with 0x prefix.