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
The book currently gives a rather detailed description of broadcast (kudos for that!), and emphasizes that the first round needs to send over broadcast, see https://frost.zfnd.org/tutorial/dkg.html.
I don't think this is sufficient for typical scenarios:
Consider the following attack, say in a 2-of-3 with participants A, B, C. A is malicious and B and C are honest.
A, B, C run round 1 honestly (over broadcast).
Malicious participant A sends wrong shares to honest B but correct shares to honest C.
C concludes that the DKG has finished, and sends money to the resulting threshold public key. [1]
B and C are 2 honest participants, but they can't sign. The money is lost.
I believe what is necessary is to run another round of broadcast at the end, to confirm that all participants not only agree on the common parameters, but only on the fact that DKG has succeeded. C should only conclude that DKG was successful when it has confirmation from everyone else. Note that running an instance echo broadcast with aborts as the last step of the DKG solves the problem only partially. Participant A could always equivocate in the last round of the echo broadcast, making B believe that something went wrong while making C believe everything is alright. (In this situation, B must not conclude that the protocol didn't work and delete shares. B is rather in some indeterminate state...)
@jonasnick and I are currently working on a draft spec for DKGs for FROST. We rely on the broadcast abstraction in the Olaf paper, which moves the broadcast for exactly this reason to the end of the protocol. Our draft spec contains a variant of echo broadcast with signatures. That has the advantage that participants will receive a "certificate" (transferable proof) of success of a DKG run, and can use this to convince every other signer that DKG has succeeded. This ensures that if messages arrive eventually, everyone will eventually learn that DKG was successful (and in case of success, eventually everyone leaves the indeterminate state). See https://github.com/jonasnick/bip-frost-dkg for our current write-up, but be aware that some of the text is currently outdated, and we're actively working on it. See this section for the echo broadcast with signatures. I hope we'll have a somewhat stable version soon.
[1] You could object that C isn't supposed to draw this conclusion, but then I'd wonder how C or anyone else is ever supposed to use the threshold public key.
[2] See also Section 4 in the Olaf paper, where we consider a variant of PedPop with a final broadcast round. (Caveat: While we mention the agreement problem, we later establish only unforgeabiliity formally, but the problem that arises from the lack of agreement is rather "correctness".)
The text was updated successfully, but these errors were encountered:
Thanks @real-or-random! Yes, we are aware of this issue. It is good to know that you all are working on a spec for DKGs for FROST, we'll look at that for inspiration. Let us know if you would like reviews or comments as that spec progresses!
The book currently gives a rather detailed description of broadcast (kudos for that!), and emphasizes that the first round needs to send over broadcast, see https://frost.zfnd.org/tutorial/dkg.html.
I don't think this is sufficient for typical scenarios:
Consider the following attack, say in a 2-of-3 with participants A, B, C. A is malicious and B and C are honest.
I believe what is necessary is to run another round of broadcast at the end, to confirm that all participants not only agree on the common parameters, but only on the fact that DKG has succeeded. C should only conclude that DKG was successful when it has confirmation from everyone else. Note that running an instance echo broadcast with aborts as the last step of the DKG solves the problem only partially. Participant A could always equivocate in the last round of the echo broadcast, making B believe that something went wrong while making C believe everything is alright. (In this situation, B must not conclude that the protocol didn't work and delete shares. B is rather in some indeterminate state...)
@jonasnick and I are currently working on a draft spec for DKGs for FROST. We rely on the broadcast abstraction in the Olaf paper, which moves the broadcast for exactly this reason to the end of the protocol. Our draft spec contains a variant of echo broadcast with signatures. That has the advantage that participants will receive a "certificate" (transferable proof) of success of a DKG run, and can use this to convince every other signer that DKG has succeeded. This ensures that if messages arrive eventually, everyone will eventually learn that DKG was successful (and in case of success, eventually everyone leaves the indeterminate state). See https://github.com/jonasnick/bip-frost-dkg for our current write-up, but be aware that some of the text is currently outdated, and we're actively working on it. See this section for the echo broadcast with signatures. I hope we'll have a somewhat stable version soon.
[1] You could object that C isn't supposed to draw this conclusion, but then I'd wonder how C or anyone else is ever supposed to use the threshold public key.
[2] See also Section 4 in the Olaf paper, where we consider a variant of PedPop with a final broadcast round. (Caveat: While we mention the agreement problem, we later establish only unforgeabiliity formally, but the problem that arises from the lack of agreement is rather "correctness".)
The text was updated successfully, but these errors were encountered: