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

dkg: research TrailOfBits FROST post #3031

Closed
gsora opened this issue Apr 10, 2024 · 1 comment
Closed

dkg: research TrailOfBits FROST post #3031

gsora opened this issue Apr 10, 2024 · 1 comment
Assignees
Labels
protocol Protocol Team tickets

Comments

@gsora
Copy link
Collaborator

gsora commented Apr 10, 2024

🎯 Problem to be solved

TrailOfBits published a blog post detailing research on FROST and DoS implications.

Research if the proposed approach applies to our FROST DKG dependency.

@gsora gsora self-assigned this Apr 10, 2024
@github-actions github-actions bot added the protocol Protocol Team tickets label Apr 10, 2024
@gsora
Copy link
Collaborator Author

gsora commented Apr 16, 2024

Gave this issue some brain time.

The issue is described by TrailOfBits as follows:

...what would happen if a participant used a polynomial pi(x) of degree T greater than t? Since p(x) is equal to the sum p1(x) + p2(x) + … + pn(x), the degree of p(x) would then be T rather than t, meaning that the signing protocol would require T + 1 rather than t + 1 participants to complete successfully. If this change were not detected by other participants, it would allow any of the participants to surreptitiously render the shared key unusable by choosing a threshold that was strictly greater than the total number of participants. If the DKG protocol were used to generate a shared key as part of a threshold signature scheme (like one of the schemes referenced in the introduction), any attempt to sign a message with t + 1 participants would fail.
...
Clearly, this type of malicious behavior could be prevented by simply checking the length of the coefficient commitment vector (Ai,0, Ai,1, …, Ai,T) published by each participant and aborting if any of the lengths is found to be different from t + 1.

This was caught when we did our first audit, marked as high-priority issue, fixed by yours truly.

image

Bottom line: Kryptology itself doesn't check for this specific corner case, but defensive programming saved our bread once again, since Charon checks for it right after P2P message exchange happens.

It would be great to double-check with ToB but I'm reasonably sure our DKG is safe

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
protocol Protocol Team tickets
Projects
None yet
Development

No branches or pull requests

2 participants