The CGGMP protocol contains a mechanism that allows participants to identify at least one participant that deviated from the protocol, in the case where the parties fail to get a valid signature on a given message.
In the long run, we'd like to support this, but accurate identification will require some changes to the way we currently do error reporting, as well as implementation of additional, optional rounds of communication for some failure cases in signing and presigning.
[ ] We need to add an optional participant ID field to ProtocolError so we can gradually fill in blame
[ ] We need to implement all the "low hanging fruit" in keygen, auxinfo, and presign -- assigning blame in all the cases that are easy to identify, like receiving malformed input or failing ZK proofs.
[ ] We need to change the error handling so that generic cryptography components (e.g. Paillier, curve points, ZKPs) don't try to assign blame or handle protocol logic; those errors should be processed and handled by the protocol implementations (e.g. the keygen, auxinfo, presign and sign modules). Once this is done, we can add additional logic in the protocol implementations to convert errors as appropriate (e.g. from a generic CryptoError::ProofVerificationFailure to a specific, external-facing Error::ProtocolError)
[ ] We need to design and approach and implement the extra rounds in presign and sign
[ ] At each phase, we should update the README to explain the current state of identifiable abort, so that callers understand what the current library capabilities are and how they differ from the paper.
The CGGMP protocol contains a mechanism that allows participants to identify at least one participant that deviated from the protocol, in the case where the parties fail to get a valid signature on a given message.
In the long run, we'd like to support this, but accurate identification will require some changes to the way we currently do error reporting, as well as implementation of additional, optional rounds of communication for some failure cases in signing and presigning.
ProtocolErrorso we can gradually fill in blamekeygen,auxinfo,presignandsignmodules). Once this is done, we can add additional logic in the protocol implementations to convert errors as appropriate (e.g. from a genericCryptoError::ProofVerificationFailureto a specific, external-facingError::ProtocolError)