boltlabs-inc / tss-ecdsa

An implementation of a threshold ECDSA signature scheme
Other
12 stars 5 forks source link

Implement the complete interactive signing protocol #372

Open marsella opened 1 year ago

marsella commented 1 year ago

Currently, the implementation of signing in the implementation does not match the signing protocol in the paper. The implementation generates a signature share locally and leaves it up to the calling application to decide where to send the shares and how to reconstruct them. The paper continues on, sending the share to all other participants and allowing each party to reconstruct the final signature. This allows identifiable abort and is also what the paper proves to be secure.

Furthermore, the paper describes both interactive and non-interactive versions of the protocol. In the former, the participants run presigning and continue immediately to run signing. In the latter, they generate a batch of presign records, then later consume them one at a time to sign messages. For our case, the primary difference between these two approaches is whether you need to create new session Identifier; in the interactive version you can use the same one for presigning and signing; in the non-interactive version you cannot.

A complete implementation would include both the non-interactive signing protocol (described in this epic) and the interactive signing protocol, which chains together the existing presign + new signing protocols into a single executable Participant for ease of use. For this epic, we'll focus on expanding the public API to include the interactive protocol.

Since the interactive protocol is dependent on the non-interactive protocol's signing step, we'll implement that as an independent module that can be used in both signing approaches. This epic does not include implementing the public API for the non-interactive protocol, but it will be relatively straightforward to do add after this epic is complete.

See also: discussion on signing audit #356.

To complete this epic (interactive signing), we need to expand the protocol implementation to include the full signing protocol. This means:

indomitableSwan commented 1 year ago

This description is confusing, because in one place it says that to implement the "complete" protocol, you need both interactive and non-interactive, the title says to implement the "whole" protocol, but then you narrow it to "non-interactive" as a parenthetical towards the end.

I recommend splitting this epic into interactive and non-interactive epics, and starting with interactive.

marsella commented 1 year ago

I updated the issue title and description to try to make it more obvious what this is about.

I had written out all the issues with the assumption that we'd do non-interactive signing first because it's easier; we don't have to figure out how to call presigning as a subprotocol, and once we have the non-interactive signing protocol implemented, we can call it as a subprotocol of interactive signing. But you correctly point out that interactive signing is the thing we actually want to use first.