Open grishasobol opened 2 weeks 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.
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.
@conradoplg
Oh you're right, I got confused, thanks. We'll work on this!
The
culprit()
is None forInvalidSecretShare
: https://github.com/ZcashFoundation/frost/blob/dcf17732f791cd5c69aeed5bb4ff60d019a57ee8/frost-core/src/error.rs#L128-L136This 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
.