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

Lack of agreement despite broadcast #577

Open
real-or-random opened this issue Nov 15, 2023 · 1 comment
Open

Lack of agreement despite broadcast #577

real-or-random opened this issue Nov 15, 2023 · 1 comment
Labels
blocked P-Low ❄️ Priority: Low. Issue should be worked on after routine work is done

Comments

@real-or-random
Copy link

real-or-random commented Nov 15, 2023

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".)

@chelseakomlo
Copy link
Collaborator

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!

@chelseakomlo chelseakomlo added blocked P-Low ❄️ Priority: Low. Issue should be worked on after routine work is done labels Dec 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked P-Low ❄️ Priority: Low. Issue should be worked on after routine work is done
Projects
Status: Product Backlog
Development

No branches or pull requests

2 participants