Skip to content

Enforce a consistent view of commitments during DKG #190

@xoloki

Description

@xoloki

In the FIRE protocol, signers can send DkgFailure messages during the DkgEnd stage. Some of these messages make claims that other signers have sent bad public or private shares. The coordinator takes the information in these claims, and checks local copies of the shares to determine who is acting maliciously.

This works as long as all signers have a consistent view of the commitments. However, if a malicious signer was able to manipulate the networking and send different commitments to different users, it would be possible to get a signer declared as malicious for making what in their view was a valid claim.

Specifically, consider the case of signers Alice, Mallory, and Carol, where Carol is acting as the coordinator. Mallory sends a bad DkgPublicShares to Alice, but a good DkgPublicShares to Carol. Alice then sends DkgFailure::BadPublicShares to Carol, who checks and sees that her copy of Alice's DkgPublicShares is valid. So Carol marks Alice as malicious, even though the malicious party was Mallory.

The same attack works for DkgPrivateShares. Mallory sends a good DkgPublicShares to everybody, but sends a bad DkgPrivateShares to Alice (and a good one to Carol). Alice now sends a DkgFailure::BadPrivateShares, which contains a proof of the shared DH key between Alice and Mallory. Carol uses this key to decrypt the private shares between Alice and Mallory, but since her copy of DkgPrivateShares was different from the one that Alice received, she again thinks that Alice made a malicious claim.

To fix this, we will need to enforce a consistent view of the commitments. One possible design is for the coordinator to broadcast the commitments it received, signed with the coordinator public key. Another design would be for every user to broadcast every commitment they receive. The first design has fewer messages, but requires more central control.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Status

Needs Triage

Relationships

None yet

Development

No branches or pull requests

Issue actions