Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Returns culprit for Error::InvalidSecretShare #725

Open
grishasobol opened this issue Sep 10, 2024 · 4 comments · May be fixed by #728
Open

Returns culprit for Error::InvalidSecretShare #725

grishasobol opened this issue Sep 10, 2024 · 4 comments · May be fixed by #728
Assignees

Comments

@grishasobol
Copy link

The culprit() is None for InvalidSecretShare:

match self {
Error::InvalidSignatureShare {
culprit: identifier,
}
| Error::InvalidProofOfKnowledge {
culprit: identifier,
} => Some(*identifier),
Error::InvalidSecretShare
| Error::InvalidMinSigners

This is not expected behaviour because this error can be returned in DKG round 3

// Verify the share. We don't need the result.
let _ = secret_share.verify()?;

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

@conradoplg
Copy link
Contributor

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.

@conradoplg conradoplg closed this as not planned Won't fix, can't repro, duplicate, stale Sep 11, 2024
@grishasobol
Copy link
Author

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
Copy link
Author

@conradoplg

@conradoplg
Copy link
Contributor

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

@conradoplg conradoplg reopened this Sep 12, 2024
@conradoplg conradoplg self-assigned this Sep 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Review/QA
Development

Successfully merging a pull request may close this issue.

2 participants