search

ZenGo-X / multi-party-ecdsa

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

GG20 Presignature Generation Questions #151

Open palladionIT opened 2 years ago

palladionIT commented 2 years ago

Hello,

I am still playing around with the awesome code you produced and I really like the way you implemented GG20 in the other dev branch using round-based etc. While working with the code there were a few questions popping up for me that are a little unclear and I would really like to get some input from you. I am also open to discuss things via Telegram but as of now that does not seem possible (see my other issue).

Here are my questions:

  1. When you run the OfflineStage to get a CompletedOfflineStage it would be great if it is possible to persist this result. However, all the fields of the struct are private and the strict itself does not implement the Serialize and Deserialize traits. Is there a specific reason for that? Would it be possible to add the traits and then store the stage on disk for later use to complete the partial signatures in the final round?
  2. In your code for the GG20 offline stage you mention that the CompletedOfflineStage can be used multiple times for the one round signing (see here). To my knowledge there are protocols that leak key share information if presignatures are reused, is this not an issue here?

Please let me know if my questions are unclear or if you need more context. Thanks again for all the work that has gone in making this library!

survived commented 2 years ago

Hi @palladionIT, sorry for confusion, CompletedOfflineProtocol must not be reused. Reusing leaks the private key. We need to fix this comment.

About serialization — probably it's the same reason, storing it at FS makes it easier to accidentally reuse it. But, I think, we can add (de) serialization traits, and add an explicit warning in the docs

palladionIT commented 2 years ago

Thank you for answering my questions. I think it makes sense to have the CompletedOfflineStage (de)serializable because it would support more use cases for the library. However, I agree that it needs thorough documentation to make sure that the feature will not be misused.

naughtyfox commented 2 years ago

Hi everyone! I would like to vote up for adding serialization/deserialization of CompletedOfflineStage struct.

Wizdave97 commented 2 years ago

Hi @survived, thanks for the work on the library, we currently use this library in a blockchain we are developing, my question is, when we run the protocol with the parties and reach the CompletedOfflineStage, we intend to serialize this value and store an encrypted version of it inside the file system, the reason for doing this is that the parties involved in the protocol are the blockchain nodes and the parties are going to be rotated probably every couple of days or a few weeks, so something might cause a node to restart the application after we've reached this stage and we don't want to start running the entire protocol again in this scenario, that's the reason we intend to store the CompletedOfflineStage in the file system, albeit an encrypted version, I'll like to know your opinon on this and if you have any better suggestion.