Simpler signing and verifying procedure

[MrChico]

To make the life of developers on ethereum, many encountering the tools of cryptography for the first time, the ECDSA for signing and verifying a message should be as simple as possible (but no simpler).
I believe that the current procedure is more complicated than necessary, which gives rise to confusion:
http://ethereum.stackexchange.com/questions/1777/workflow-on-signing-a-string-with-private-key-followed-by-signature-verification
http://ethereum.stackexchange.com/questions/710/how-can-i-verify-a-cryptographic-signature-that-was-produced-by-an-ethereum-addr/718#

I propose that the intermediate steps of hashing the message should be removed, and that developers shouldn't have to deal with ECDSA values r, s and v at all, just a 65 byte signature.
The procedure would then be as simple as:
With web3 or in the javascript console:

signature = web3.eth_sign(address, message)

Which could then be directly used in a solidity contract as:

function verify(message, signature, address) returns (bool valid) {
   address signer = ecrecover(message, signature);
   if (signer == address) {
      return true;
   }
   else {
      return false;
   }
}

If there are use cases where one wants to sign a message that has already been hashed, then this option could be passed as an option to the functions, like: signature = eth_sign(address, hash, {hashed: true}) or ecrecover(hash, signature, {hashed: true})

A prerequisite of this is of course that all clients return the signature in the same format, so first this issue needs to be addressed.

[axic]

Why do you want to mix hashing into ecrecover?

Possible alternatives:

• eth_sign could be changed to return the s/r/v values instead of a combined signature.
• Solidity as a language (or implemented via a library with a Solidity-assembly snippet) can support the parsing of that signature into the fields required by the precompiled contract

(I am using ecrecover in many projects.)

[MrChico]

Because of simplicity. I think most use cases involves verifying a message that is known to the verifier, and so since hashing will always be a part of the procedure, I think it should be mixed in.

But keeping backwards compatibility in mind, your approach could be a bit more elegant elegant.

[axic]

I think ecrecover is not used predominantly with message signing (as you have regular transactions to prove the sender), but for validating data signed by a non-Ethereum system. This is maybe contrary to its original intent.

It is used in btcrelay to check Bitcoin transaction signatures and in Quroum to check Bitcoin signed messages. Those obviously require different hashing and encapsulation methods. If at all possible I would not include hashing as a parameter in the precompiled contract.

Having a more user friendly implementation in Solidity with appropriate helpers seems like a good solution.

While speaking of this I am not entirely happy that ecrecover returns an Ethereum address and not a public key -- then again that would require another call to sha3.

[revanistT3-zz]

Does this help crypto abstraction?

[MrChico]

I think ecrecover is not used predominantly with message signing (as you have regular transactions to prove the sender), but for validating data signed by a non-Ethereum system. This is maybe contrary to its original intent.

With payment channel like solutions I think it is, but you are right that with the use in BTCRelay and similair scenarios bundling hashing with ecrecover doesn't make much sense.

Having a more user friendly implementation in Solidity with appropriate helpers seems like a good solution.

I agree. Essentially what I want is that developers shouldn't have to worry about ECDSA values, they just need a signature.

[axic]

@MrChico since we have assembly support in Solidity, this is a piece of cake: https://gist.github.com/axic/5b33912c6f61ae6fd96d6c4a47afde6d

[MrChico]

Great solution @axic!
Note that the v + 27 should not be need when geth starts returning signatures in the canonical form.
I will close this now

[axic]

@MrChico can you point me to the issue where that change was discussed? Other implementations, such as testrpc should follow that too.

[MrChico]

@axic
js testrpc already returns the signature in the correct format. ethereum/go-ethereum#2053 is the goteams discussion on the topic

[anrodon]

Is there any way to verify a signature with Web3?

[frozeman]

@anrodon not yet

[axic]

Thanks @MrChico, updated the gist to support both.

[graup]

I still agree that this simplified function should be part of Solidity. If you look into signing messages for the first time, the current way and documentation isn't easy enough (http://solidity.readthedocs.io/en/latest/units-and-global-variables.html?highlight=ecrecover#mathematical-and-cryptographic-functions)

[GaikwadPratik]

@anrodon, you might want to check https://web3js.readthedocs.io/en/1.0/web3-eth-personal.html#ecrecover documentation. It says we can use web3.personal.ecrecover function.

[web3dopamine]

@MrChico
can you specify the data types of the verify function ??
function verify(bytes32 message, string ??? signature, address address) returns (bool valid) {
}

doc says web.eth.sign returns string

[MrChico]

@dhaileytaha check out the library contract by @axic https://gist.github.com/axic/5b33912c6f61ae6fd96d6c4a47afde6d.
function ecverify(bytes32 hash, bytes sig, address signer) returns (bool)

[alexaltair]

@MrChico Does closing this issue mean it's been decided not to include these helpers into solidity itself (as a precompiled contract or whatever)? I can find a lot of example implementations on the internet, but it'd be really good to have a canonical version sanctioned by the ethereum development team.