ZenGo-X / multi-party-ecdsa

Rust implementation of {t,n}-threshold ECDSA (elliptic curve digital signature algorithm).

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Anyone knows how to verify the generated threshold signature in solidity?

KunPengRen opened this issue · comments

Is it possible to verify the generated signature in solidity code?
Is there some work done this?

Extend question?
How to generate the {r,s,v} format ecdsa signature?

the problem is solved, I will add some method soon if someone needs

Step one, get the public from the local key store where in the last filed of the json file and with format {'x':'', y:''}, and then use some tools to generate the Ethereum address from public, I follow the aritle https://programmer.ink/think/specific-process-of-ethereum-generating-address-from-public-key.html

Step two, change the signature format to ethereum format, which r+s+v(1b(recid=0) or 1c(recid=1))

Step three, recover the etherum address from solidity and check with step one result, you can use my contract code recoverSigner() https://gist.github.com/KunPengRen/b0561cdcc62b96c8d11f53fca684f47b

Hey @KunPengRen, how did you retrieve the public key? That's the part I'm currently trying to figure out

I am a bit confused with the local-sharei.json file that is generated from gg_keygen.rs. I am trying to use it to retrieve the public key to verify the signature as well.

pk_vec is the public key vector? If that is the case, shouldn't it be in (x,y) format as it is a point in an Elliptic Curve?

Moreover, is keys_linear the share of the private key owned by each party?

@alexreyes and @KunPengRen do you have any thoughts on this?

Thanks!

I guess the simple answer is that the public key vector is represented in its compressed form.

@alexreyes have you figured out how to retrieve the public key?

@manel1874 Nope I never did get it to consistently work

I only just started reading this repo, so I have no idea how to parse out the pubkey from the local keystore. However, if you have a signature by the key, you can recover the raw public key from the signature. Given r, s and the message, compute: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Public_key_recovery . This is what ecrecover in Solidity does under the hood.

Thanks @duncancmt! I recovered a raw public key from the signature elements (r,s,recid). However, the retrieved public key is not equal to any of the possible elements in the local-sharei.txt. I compared with y (which I believe is the real public key), y_sum_s and pk_vec (here I summed all three EC points). None of them was equal to the retrieved public key.

Most probably I am not converting well the hex vector from local-sharei.txt. But I am not being able to verify the GG20 generated threshold signature in general (I am using Python).

I was able to find the solution. So basically the gg20 examples aren't compatible with ethereum. They don't hash the message using keccak256.

I forked the repo and changed the examples to produce ethereum compatible signatures. https://github.com/narayanprusty/multi-party-ecdsa

I have also changed the instructions in the readme for gg20 signing. And have added a JS script to recover the address from the signature. I signed the same message multiple times and got the same address from all the signatures.

commented

@narayanprusty
Thanks for your repo! Using your JS script I think I can reconstruct the signer address from the signature. The last piece would be getting the address from public key and verify it's the same.

Do you know how to construct the public key from the local-sharei.json? I did a diff on local-share1.json and local-share2.json, identified that same parts are: pk_vec, paillier_key_vec, y_sum_s, h1_h2_n_tilde_vec. Not sure which one(s) should be used. Appreciate it!

commented

I worked it out for gg20. Sharing my findings

  1. y_sum_s is the public key: reference
  2. The Ethereum address can be retrieved by ethers (reference). Can refer to my code snippet as well: https://gist.github.com/hcheng826/1de690d61bd408bcbb8bfb99513ab2f2