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
...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.
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
🎯 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.
The text was updated successfully, but these errors were encountered: