Merge pull request #71 from BlockstreamResearch/202412-blame-text

text: Explain usage aspects of blaming

README.md

@@ -91,7 +91,11 @@ This will enable bandwidth optimizations and is common also in implementations o
 Participants are identified and authenticated via long-term public keys.
 
 The basic building block of ChillDKG is the SimplPedPop protocol (a simplified variant of PedPop),
-which has been proven to be secure when combined with FROST [[CGRS23](https://eprint.iacr.org/2023/899)].
+which has been designed specifically for FROST.
+SimplPedPop is proven to be secure when combined with FROST [[CGRS23](https://eprint.iacr.org/2023/899)],
+and its output contains, in addition to the threshold public key, separate per-participant public shares thereof,
+which allow for partial verification of contributions in a FROST signing session.
+
 Besides external secure channels, SimplPedPop depends on an external *equality check protocol*.
 The equality check protocol serves as an abstraction of a consensus mechanism:
 Its only purpose is to check that, at the end of SimplPedPop, all participants have received identical protocol messages.
@@ -123,6 +127,10 @@ In contrast, a standard PedPop implementation would allow a malicious participan
 If such a key was used directly in a Taproot output, the malicious participant could spend the output through their hidden script path, bypassing the requirement for `t - 1` additional signatures.
 While BIP 341 outlines special precautions for using threshold public keys generated by standard PedPop, ChillDKG eliminates this vulnerability entirely, providing built-in protection against accidental misuse.
 
+If a ChillDKG session fails due to the participants or the coordinator deviating from the protocol,
+any aborting party will be able to identify and blame a single party responsible for the failure
+(assuming the network, and, depending on the circumstances, the coordinator, is reliable).
+
 These features make ChillDKG usable in a wide range of applications.
 As a consequence of this broad applicability, there will necessarily be scenarios in which specialized protocols need less communication overhead and fewer rounds,
 e.g., when setting up multiple signing devices in a single location.
@@ -134,26 +142,23 @@ In summary, we aim for the following design goals:
  - **No restriction on threshold**:  Like the FROST signing protocol, ChillDKG supports any threshold `t <= n`, including `t > n/2` (also called "dishonest majority").
  - **Broad applicability**:  ChillDKG supports a wide range of scenarios, from those where the signing devices are owned and connected by a single individual to those where multiple owners manage the devices from distinct locations.
  - **Simple backups**: ChillDKG allows recovering the DKG output using the host secret key and common recovery data shared among all participants and the coordinator. This eliminates the need for session-specific backups, simplifying user experience.
- - **Untrusted coordinator**: Like FROST, ChillDKG uses a coordinator that relays messages between the participants. This simplifies the network topology, and the coordinator additionally reduces communication overhead by aggregating some of the messages. A malicious coordinator can force the DKG to fail but cannot negatively affect the security of the DKG.
- - **Per-participant public keys**: When ChillDKG is used with FROST, partial signature verification is supported.
+ - **Untrusted coordinator**: Like FROST, ChillDKG uses a coordinator that relays messages between the participants. This simplifies the network topology, and the coordinator additionally reduces communication overhead by aggregating some of the messages. A faulty coordinator can force the DKG to fail but cannot negatively affect the security of the DKG.
+ - **Per-participant public shares**: ChillDKG supports partial signature verification in FROST signing sessions.
  - **Taproot-safe threshold public key**: ChillDKG prevents malicious participants from embedding a hidden [[BIP 341]](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) Taproot commitment to a script path in the threshold public key.
+ - **Blame functionality**: If a ChillDKG session aborts, it is possible to identify and blame a single party responsible for the failure (assuming the network, and, depending on the circumstances, the coordinator, is reliable).
 
 In summary, ChillDKG incorporates solutions for both secure channels and consensus and simplifies backups in practice.
 As a result, it fits a wide range of application scenarios,
 and due to its low overhead, we recommend ChillDKG even if secure communication channels or a consensus mechanism (e.g., a BFT protocol or a reliable broadcast mechanism) are readily available.
 
 #### Why Robustness is Not a Goal
 
-As a consequence of its design goals, ChillDKG does not provide robustness, i.e., the protocol is not guaranteed to succeed in the presence of malicious or faulty participants.
+Despite the blame functionality, ChillDKG does not provide robustness, i.e., the protocol is not designed to succeed in the presence of faulty participants.
 In fact, a single participant can cause the protocol to fail, either due to malicious intent, software bugs, or unreliable communication links.
 In such cases, users must investigate and resolve the issue before the DKG can output key material.
 
-When ChillDKG does not terminate successfully, it is not possible to identify the misbehaving participant unless they misbehave in certain trivial ways.
-While the ability to identify the misbehaving participant, also called *identifiable aborts*, is desirable, we keep this goal out of scope for simplicity.
-(TODO: This may change in a future version of the BIP, but there is no guarantee.)
-
 Adding robustness to ChillDKG would require the coordinator to exclude participants that appear unresponsive or faulty, which degrades the setup already from the beginning from `t`-of-`n` to `(t-1)`-of-`(n-1)`.
-This approach is undesirable in most scenarios, as a malicious coordinator would have the power to exclude participants at will,
+This approach is undesirable in most scenarios, as a faulty coordinator would have the power to exclude participants at will,
 and even if ChillDKG's design did not include a coordinator and participants had direct communication links to each other, it would be unclear how to achieve robustness in a dishonest majority setting.
 
 Moreover, we believe that it is preferable to err on the side of caution even in the case of benign failures.
@@ -408,7 +413,7 @@ The key insight to ensuring conditional agreement is that any participant termin
 obtains a *success certificate* `cert` consisting of the collected list of all `n` signatures on `eq_input`.
 This certificate will, by the above termination rule, convince every other honest participant (who, by integrity, has received `eq_input` as input) to terminate successfully.
 Crucially, this other honest participant will be convinced even after having received invalid or no signatures during the actual run of CertEq,
-due to unreliable networks, an unreliable coordinator, or malicious participants signing more than one value.
+due to unreliable networks, a faulty coordinator, or faulty participants signing more than one value.
 
 Thus, the certificate does not need to be sent during a normal run of CertEq,
 but can instead be presented to other participants later,
@@ -467,6 +472,8 @@ Each participant has a point-to-point communication link to the *coordinator*
 
 If there is no dedicated coordinator, one of the participants can act as the coordinator.
 
+Each participant and the coordinator, and the communication links may either be *honest*, i.e., reliable and adhering to the protocol, or *faulty*, i.e., controlled by an attacker or unreliable (e.g., due to software bugs).
+
 ### Inputs and Output
 
 The inputs of a session consist of a long-term *host secret key* (individual to each participant, not provided by the coordinator) and public *session parameters* (common to all participants and the coordinator).
@@ -515,7 +522,7 @@ and we believe that a general recommendation is not useful.
 ### Recovering Stuck Participants
 
 The mere fact that the coordinator or a participant deems a ChillDKG session successful does not imply that other participants deem it successful yet.
-Indeed, due to failing network links or invalid messages sent by malicious participants,
+Indeed, due to failing communication links or invalid messages sent by malicious participants,
 it is possible that a party has deemed the DKG session successful, but others have not (yet) and thus are stuck in the DKG session.
 In that case, the successful parties can eventually convince the stuck participants to consider the DKG session successful by presenting the recovery data to them.
 The recovery data can, e.g., be attached to the first request to initiate a FROST signing session.
@@ -553,13 +560,34 @@ e.g., stop sending additional funds to addresses derived from it.
 it will still be possible to spend the funds,
 and even recovered participants can participate in signing sessions.)
 
+### Blame Functionality
+
+Any faulty party can make a ChillDKG session abort by sending a message that deviates from the protocol specification.
+To help investigating and resolving these protocol failures, ChillDKG provides *blame functionality*
+that enables honest protocol parties to identify and blame at least one participant suspected to be faulty:[^missing-messages]
+ - If an honest participant aborts the session, then this participant will blame at least one participant or the coordinator.
+ - If an honest coordinator aborts the session, then the coordinator then will blame at least one participant.
+
+[^missing-messages]: If a session is stuck due to missing messages, the receiving party will (trivially) know who has not sent their protocol messages (yet).
+
+The aborting party will be guaranteed that the suspected party is indeed faulty
+*only if* all messages in the ChillDKG session have been transmitted correctly over the communication links,
+and, in case of a participant blaming another participant, if the coordinator is additionally honest.
+
+It is important to understand that this is a conditional statement.
+For example, assume that the condition of a honest coordinator is violated.
+In that case, even if all participants are honest, the malicious coordinator can deviate from the protocol in a way that makes one participant blame another participant, when, in fact, it is the coordinator who is faulty and not the suspected participant.
+
+In some cases,[^incorrect-shares], an aborting participant needs to obtain an auxiliary *blame message* from the coordinator
+before a suspected participant can be determined (see below).
+
+[^incorrect-shares]: Namely, when having received incorrect secret shares.
+
 ### Threat Model and Security Goals
 
-Some participants, the coordinator, and all network links may be malicious, i.e., controlled by an attacker.
 We expect ChillDKG to provide the following informal security goals when it is used to set up keys for the FROST threshold signature scheme.
-
 If a participant deems a protocol session successful (see above), then this participant is assured that:
- - A coalition of at most `t - 1` malicious participants and a malicious coordinator cannot forge a signature under the returned threshold public key on any message `m` for which no signing session with at least one honest participant was initiated. (Unforgeability)[^unforgeability-formal]
+ - A coalition of at most `t - 1` faulty participants and a faulty coordinator cannot forge a signature under the returned threshold public key on any message `m` for which no signing session with at least one honest participant was initiated. (Unforgeability)[^unforgeability-formal]
  - All honest participants who deem the protocol session successful will have correct and consistent protocol outputs.
    In particular, they agree on the threshold public key, the list of public shares, and the recovery data.
    Moreover, any `t` of them have secret shares consistent with the threshold public key.[^correctness-formal]
@@ -576,11 +604,11 @@ If a participant deems a protocol session successful (see above), then this part
 
 The following figure shows an example execution of the participants and the coordinator.
 Arrows indicate network messages between the participants.
-For simplicity, only one participant is depicted;
-all participants run the identical code and send messages in the same steps.
+For simplicity, only one participant is depicted.
+Unless participants abort due to errors, all participants run the same code and send messages in the same steps.
 
 ![The diagram shows the message flow between a participant and a coordinator.
-The first of two phases named "Generation of host public keys" involves the participant invoking the function hostpubkey_gen with parameter hostseckey and sending the returned hostpubkey to the coordinator.
+The first of two phases named "Generation of host public keys" involves the participant invoking the hostpubkey_gen function with parameter hostseckey and sending the returned hostpubkey to the coordinator.
 The second phase named "Session" is initiated by the coordinator sending hostpubkeys and the threshold t to the participant.
 The participant invokes participant_step1 and sends the returned pmsg1 to the coordinator.
 The coordinator invokes coordinator_step1 and sends the returned cmsg1 to the participant.
@@ -591,7 +619,21 @@ The participant invokes participant_finalize, which ends the second phase.
 
 A participant can run multiple sessions with the same hostseckey, provided that the session state as output from any of the "step" functions is not reused.
 Multiple sessions may be run concurrently.
-Whenever a function call fails, the corresponding party will not continue the session.
+
+Whenever an invoked function fails and raises an error, the corresponding party will abort the session and,
+in most cases, blame a participant or the coordinator for the failure of the session.
+However, if a participant aborts during the `participant_step2` function,
+there may be insufficient information determine another participant to blame.
+In this case, an optional *investigation procedure* is available:
+The aborting participant can ask the coordinator for an auxiliary *investigation message* (generated via the `coordinator_investigate` function),
+which will allow the participant to blame a specific other participant (via the `participant_investigate` function).
+
+Applications may choose to let the coordinator always create and send investigation messages,
+(i.e., even if not asked for by an aborting participant).
+While different aborting participants will need different investigation messages,
+an investigation message intended for some participant does not to be kept confidential from other participants.
+Thus, applications may additionally choose to let the coordinator send all `n` investigation messages to all `n` participants
+(e.g., if the communication link from the coordinator to the participants is inherently a broadcast link).
 
 ### API Documentation