ZcashFoundation / frost

Rust implementation of FROST (Flexible Round-Optimised Schnorr Threshold signatures) by the Zcash Foundation
https://frost.zfnd.org
Other
138 stars 51 forks source link

Returns culprit for `Error::InvalidSecretShare` #725

Open grishasobol opened 2 weeks ago

grishasobol commented 2 weeks ago

The culprit() is None for InvalidSecretShare: https://github.com/ZcashFoundation/frost/blob/dcf17732f791cd5c69aeed5bb4ff60d019a57ee8/frost-core/src/error.rs#L128-L136

This is not expected behaviour because this error can be returned in DKG round 3 https://github.com/ZcashFoundation/frost/blob/dcf17732f791cd5c69aeed5bb4ff60d019a57ee8/frost-core/src/keys/dkg.rs#L525-L528

So, because this error can be caused by other participant, I think culprit must be added to InvalidSecretShare.

conradoplg commented 1 week ago

Thanks for the report! I believe it's not possible to identify a culprit in that step. That's Round 2, Step 2 of the DKG as described in the paper. There, the participant is receiving the round2::Packages from other participants and computing their own long-lived signing share from all of them. The verification covers all of the received packages and if it fails it is not possible to identify the culprit.

grishasobol commented 1 week ago

Thanks for the report! I believe it's not possible to identify a culprit in that step. That's Round 2, Step 2 of the DKG as described in the paper. There, the participant is receiving the round2::Packages from other participants and computing their own long-lived signing share from all of them. The verification covers all of the received packages and if it fails it is not possible to identify the culprit.

Thank you for your reply. Are you completely sure about your answer? Because as far as I can see round2 verifies packages received in round1 from all participants. So, if look on round2 handling i participant:

// The only one place which is not verified.
// Participant `i` generated it using packages from round1, which can be verified on round2.
// So, if this is an incorrect package that can be only, because participant `i` made a mistake or offense.
f_ell_i = round2_packege_from_i_to_me.signing_share;

// Аlready validated by `round2` on my side - so sure about correctness.
commitment = round1_package_from_i.commitment; 

// This is my secret key generated by `round2`, which has verification of packages from other participant,
// so I'm sure about it 
secret_key = my_round2_secret_key;

// So, as described in comment `f_ell_i` - `f_ell_i` is only one which can be incorrect and is only because of participant `i` actions.
verify(f_ell_i, commitment, secret_key)

About article which you provide:

Gennaro et al. [15] demonstrate a weakness of Pedersen’s DKG [23] such that a
misbehaving participant can bias the distribution of the resulting shared secret by issuing complaints against a participant after seeing the shares issued to them by this
participant, thereby disqualifying them from contributing to the key generation. To
address this issue, the authors define a modification to Pedersen’s DKG to utilize both
Feldman’s VSS as well as a verifiable secret sharing scheme by Pedersen [24] resulting in a three-round protocol. To prevent adversaries from adaptively disqualifying
participants based on their input, the authors add an additional “commitment round”,
such that the value of the resulting secret is determined after participants perform this
commitment round (before having revealed their inputs).

So, as I can see in the article, the three-round DKG does not have this issue.

grishasobol commented 1 week ago

@conradoplg

conradoplg commented 1 week ago

Oh you're right, I got confused, thanks. We'll work on this!