search

ZenGo-X / multi-party-ecdsa

Rust implementation of {t,n}-threshold ECDSA (elliptic curve digital signature algorithm).
GNU General Public License v3.0
975 stars 308 forks source link

Sign test gg20 #102

Closed nmahendru closed 3 years ago

nmahendru commented 3 years ago

I am intentionally opening a draft PR to show you where I am heading and get some early feedback in case I am going totally wrong. This is definitely not the final version of how I want to structure this. @omershlo

I have totally skipped the blame steps for signing. That I am planning to keep for a future PR. I still need to grok that part better.

I still have to:

  1. Add structures for all input/output pairs for keygen and sign.
  2. Right now the KeyPairResult has to be broken down so that until sign_stage8 there is no need for anything from keypair generation. That is essential for one round.
  3. Add comments all along for things that have to be private(encrypted for the intended party). Seems to be a long list.
  4. Some improvements to the interface like not passing full objects if only one of the items of the objects are needed in a stage.
omershlo commented 3 years ago

I suggest to add some kID for each keygen and sID for every signature. should be useful in many ways:

omershlo commented 3 years ago

The test file is becoming massive, any chance you move the orchestrator tests to a new file?

omershlo commented 3 years ago

general question: shouldn't you write this code as executable program ? (as in the examples or other programs that consume this lib? )

nmahendru commented 3 years ago

All the todo items are done and ready for review now. @omershlo

omershlo commented 3 years ago

One important note: in GG20, in case support for Identifiable abort is required (which is how the current protocol is implemented) : ALL messages must be broadcast message: either encrypted values or plain values. but all messages must be accessible to all parties.

nmahendru commented 3 years ago

One important note: in GG20, in case support for Identifiable abort is required (which is how the current protocol is implemented) : ALL messages must be broadcast message: either encrypted values or plain values. but all messages must be accessible to all parties.

To implement that i was planning to to write another api for each case where their is an identify step. That would return all values plaintext and then the orchestrator can run the blame protocol.

nmahendru commented 3 years ago

I suggest to add some kID for each keygen and sID for every signature. should be useful in many ways:

  • multi parallel sessions
  • checking that signing is done with the matching keygen etc

Yup. This is already getting massive. Next pr. I would want to add some consistency check to the messages as well.

nmahendru commented 3 years ago

general question: shouldn't you write this code as executable program ? (as in the examples or other programs that consume this lib? )

Indeed. Will do that for encryption. Use rocket to write a http server around this

nmahendru commented 3 years ago

One important note: in GG20, in case support for Identifiable abort is required (which is how the current protocol is implemented) : ALL messages must be broadcast message: either encrypted values or plain values. but all messages must be accessible to all parties.

skipping identify abort.

doronz2 commented 3 years ago

I am intentionally opening a draft PR to show you where I am heading and get some early feedback in case I am going totally wrong. This is definitely not the final version of how I want to structure this. @omershlo

I have totally skipped the blame steps for signing. That I am planning to keep for a future PR. I still need to grok that part better.

I still have to:

  1. Add structures for all input/output pairs for keygen and sign.
  2. Right now the KeyPairResult has to be broken down so that until sign_stage8 there is no need for anything from keypair generation. That is essential for one round.
  3. Add comments all along for things that have to be private(encrypted for the intended party). Seems to be a long list.
  4. Some improvements to the interface like not passing full objects if only one of the items of the objects are needed in a stage.

I am intentionally opening a draft PR to show you where I am heading and get some early feedback in case I am going totally wrong. This is definitely not the final version of how I want to structure this. @omershlo

I have totally skipped the blame steps for signing. That I am planning to keep for a future PR. I still need to grok that part better.

I still have to:

  1. Add structures for all input/output pairs for keygen and sign.
  2. Right now the KeyPairResult has to be broken down so that until sign_stage8 there is no need for anything from keypair generation. That is essential for one round.
  3. Add comments all along for things that have to be private(encrypted for the intended party). Seems to be a long list.
  4. Some improvements to the interface like not passing full objects if only one of the items of the objects are needed in a stage.

Given the above stage, it looks good to me