Skip to content

Honest participants could be incorrectly flagged as misbehavior due to potential different views of nonce commitment #124

@SphereDonout

Description

@SphereDonout

FROST protocol (https://eprint.iacr.org/2020/852.pdf) is implemented in https://github.com/taurushq-io/multi-party-sig/tree/main/protocols/frost/ in a decentralized manner, which means there is no signature aggregator (coordinator) to collect the nonce commitments and aggregate the signature shares. Instead, the participants broadcast the nonce commitment directly to other participants.

As pointed out in section 7.5 of RFC 9591,

The requirements for the underlying network channel remain the same in the setting where all participants play the role of the Coordinator, in that all exchanged messages are public and the channel must be reliable. However, in the setting where a player attempts to split the view of all other players by sending disjoint values to a subset of players, the signing operation will output an invalid signature. To avoid this DoS, implementations may wish to define a mechanism where messages are authenticated so that cheating players can be identified and excluded.

However, besides the DoS attack, the different views of nonce commitment caused by malicious participants would allow honest participants to be incorrectly flagged as misbehavior.

Consider a case with 4 participants, where Participant 1 is malicious and the others are honest.

  • Participant 1 sends inconsistent nonce commitments: (D1,E1) to Participants 2 and 3, and (D'1,E'1) to Participant 4.
  • Each participant then computes its signature share based on its local view of the nonce commitments.
    Upon signature share verification,
  • Participant 4’s signature share verification fails on participant 2 and 3, and on participant 1 as it’s malicious.
  • Participant 2 or 3’s signature share verification fails on participant 4 depending on whose message arrival order.
  • Participant 1’s signature share verification succeeds on all participants as it could send out different signature shares based on the receiver’s local view of nonce commitment.

To mitigate this scenario, the nonce commitments should be verified that are identical among all participants.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions