1
$\begingroup$

I have been studing ECDSA signature/verify for a while. By my understanding: the standard ECDSA signature/verify process (which we find on text book) are like below: enter image description here - A sender combines message and its ECC public key (pk), do hash, then using ECC sk (private key) to generate signature; it then append the signature with the message (ECC pk include), send all these to receiver;

  • The receiver do ECDSA verify by using the ECC pk, the message and the signature output true or false;

Question1: for EOS signature verify process looks not likely align to a standard ECDSA signature verify above:

A EOS node may need do two kinds of ECDSA signature verify:

1). Check each Tx signature--from code it use a routine naming as get_signature_keys, indicate it recovers the pk? Then follow up by a routine naming as check_authorization (this does not like a real signature verification, I couldn't understand what a "check authorization" means--by all mean it does not like a signature verify);

2). Check a Block's signature, this routine (name as "verify_signee") however, looks likely a real ECDSA signature verify.

Question2: I know BTC/ETH may adopt quite different method as they are PoW so each miner must do signature verification for each Tx inside a block, but as they have much more time (several minutes) than in EOS, they would be using the standard ECDSA verification?

|improve this question
$\endgroup$
1
$\begingroup$

The two questions are somehow related. The answer to your question (2) is no. In BTC/ETH, signature verification is like the first method you mentioned: the verifier extracts the public key from the signature, hash it, and compare the results to the address where the coin comes. If so, the signature is valid.

The main reason why this is used instead of the normal ECDSA verification is that when you verify a signature, you don't have the public key, but only an address that is the hash of the public key. Therefore you cannot verify using the normal procedure. The key recovery procedure is another way to verify signatures without much security loss.

Edit to add: The signature is generated using the normal ECDSA signature algorithm. Recovering the public key from a signature is a well-known trick. For example, it is documented in Section 4.1.6 of SEC 1. See also one of the answers for this question for a better explanation. Note it is possible to recover two candidate public keys from a signature, but as I said, this is not going to result in much security loss. See the discussion here.

Now for the "check authorization" part, a transaction in EOS may require authorization from one or more accounts. So the system verifies that the transaction has been signed by all of the necessary signatures to grant the specified authorization.

Then for the block signature verification, in EOS, there are only 21 producers that can generate blocks. Each producer has a producer key. This is the key for signing blocks and identifying themselves. This key cannot sign transactions on EOS, it can only sign blocks. Therefore it cannot transfer or claim EOS. The producer public key is known by parties who verify blocks, thus the normal ECDSA verification is used.

|improve this answer
$\endgroup$
  • $\begingroup$ Thanks for the reply. Some follow up question: 1. "the verifier extracts the public key from the signature, hash it, and compare the results to the address where the coin comes. If so, the signature is valid“ --> this is somewhat I feel not secure at all, as another guy can do the same thing, recover the publick key and generate a "fake transaction" (in which he can use his own signature, but another one's public key's hash etc..)--my understanding is for a public-key algorithm only very a signature you can confirm this is a "true" transaction? $\endgroup$ – LeonMSH Sep 6 at 2:21
  • $\begingroup$ Question2: "the system verifies that the transaction has been signed by all of the necessary signatures to grant the specified authorization." I don't understand the motivation of this, also not sure about what kinds of "authorization" check were done. I am not sure if this is something logicly link with ”get_signature_keys“ routine? Is here signature verify was done or not? cover the multi-signature as well? $\endgroup$ – LeonMSH Sep 6 at 2:27
  • $\begingroup$ (1) No that won't happen. From $A$'s signature $sig_{sk_A}(M)$, you can extract $A$'s public key $pk_A$, but not other $B$'s public key $pk_B$ (except a negligible probability). The attack you described will fail because the verification fails $H(pk_A)\ne H(pk_B)$. (2) Authorisation is more complex than that, for more information see here: medium.com/coinmonks/eos-permission-management-2c0c1634fe39 $\endgroup$ – Changyu Dong Sep 6 at 8:55
  • 1
    $\begingroup$ See added text in the answer. $\endgroup$ – Changyu Dong Sep 10 at 9:01
  • 1
    $\begingroup$ Not really. The main cost of ECDSA verification comes from two scalar multiplication operations. To recover a public key you need two scalar multiplication operations as well. $\endgroup$ – Changyu Dong Sep 10 at 11:20
0
$\begingroup$

Thanks so much for help from @Changyu Dong.

Here I'd like to put another chart to show my understand to a EOS based ECDSA Tx sign and verify process.. If anything not right please just correct and further discuss is welcome..

enter image description here

The EOS client signing process refer to a lot from here: https://eosforce.github.io/Documentation/#/zh-cn/eosforce_client_develop_guild?id=_3-%e4%ba%a4%e6%98%93

|improve this answer
$\endgroup$
  • 1
    $\begingroup$ Correct. The details are a little different, but all Bitcoin-like blockchains follow same process to this. $\endgroup$ – conr2d Sep 12 at 13:44
  • $\begingroup$ @conr2d does EOS/ETH/BTC signer (usually the wallet) always generate the recovery id (v) for making the verifier working easier? otherwise verifier has to do up to 4 times (or usually 1~2 times, each 50% chance) guess to find the correct public key by comparing the address. Furthermore what is the initial purpose for doing that rather than simply disclosing the public key directly? To making the hacking effort a little harder? or reduce the transaction size? $\endgroup$ – LeonMSH Sep 17 at 4:34

Your Answer

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

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