You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 text was updated successfully, but these errors were encountered:
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.
ProtocolError
so we can gradually fill in blamekeygen
,auxinfo
,presign
andsign
modules). Once this is done, we can add additional logic in the protocol implementations to convert errors as appropriate (e.g. from a genericCryptoError::ProofVerificationFailure
to a specific, external-facingError::ProtocolError
)The text was updated successfully, but these errors were encountered: