From bce1d4b69a53710c90b2c07e7c38984ff52334ae Mon Sep 17 00:00:00 2001 From: Tim Ruffing Date: Wed, 19 Jun 2024 19:34:36 +0200 Subject: [PATCH] bip: Write overview of SimplPedPop --- README.md | 99 ++++++++++++++++++++++++++++++++-------- reference/simplpedpop.py | 10 ++-- 2 files changed, 88 insertions(+), 21 deletions(-) diff --git a/README.md b/README.md index 4c3bc66..17fd049 100644 --- a/README.md +++ b/README.md @@ -122,13 +122,14 @@ As a consequence of this broad applicability, there will necessary be scenarios e.g., when setting up multiple signing devices in a single location. In summary, we aim for the following design goals: -- **Standalone**: ChillDKG is fully specified, requiring no external secure channels or consensus mechanism. -- **Conditional agreement**: If a ChillDKG session succeeds for one honest participant, this participant will be able to convince every other honest participant that the session has succeeded. -- **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 scenarios where multiple owners manage the devices from distinct locations. -- **Simple backups**: The capability of ChillDKG to recover devices from a static seed and public recovery data avoids the need for secret per-session backups, enhancing 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. -- **DKG outputs per-participant public keys**: When ChillDKG is used with FROST, partial signature verification is supported. + + - **Standalone**: ChillDKG is fully specified, requiring no external secure channels or consensus mechanism. + - **Conditional agreement**: If a ChillDKG session succeeds for one honest participant, this participant will be able to convince every other honest participant that the session has succeeded. + - **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 scenarios where multiple owners manage the devices from distinct locations. + - **Simple backups**: The capability of ChillDKG to recover devices from a static seed and public recovery data avoids the need for secret per-session backups, enhancing 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. + - **DKG outputs per-participant public keys**: When ChillDKG is used with FROST, partial signature verification is supported. 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, @@ -160,34 +161,95 @@ TODO say here that we only give high-level descriptions and that the code is the To ease understanding of the interface and reference code of ChillDKG, we provide a technical overview of the internals ChillDKG, which includes, as building blocks, the DKG protocols SimplPedPop and EncPedPod, and the equality check protocol CertEq. -The contents of this section are informational and not strictly required to implement or use ChillDKG. +The contents of this section are purely informational and not strictly required to implement or use ChillDKG, +and they will omit some details present in the normative Python reference implementation. We stress that **this document does not endorse the direct use of SimplPedPop or EncPedPod as DKG protocols**. While SimplPedPop and EncPedPop may in principle serve as building blocks of other DKG protocols (e.g., for applications that already incorporate a consensus mechanism), this requires careful further consideration, which is not in the scope of this document. Consequently, implementations should not expose the algorithms of the building blocks as part of a high-level API, which is intended to be safe to use. -Executable specifications of all building blocks are provided as part of the Python reference implementation. +(TODO include links to the code in every subsection) ### SimplPedPop The SimplPedPop scheme has been proposed in [Practical Schnorr Threshold Signatures Without the Algebraic Group Model, section 4](https://eprint.iacr.org/2023/899.pdf) as an variant PedPop protocol [], an extension of Pedersen DKG []. -As all variants of Pedersen DKG, SimplPedPop relies on Feldman's Verifiable Secret Sharing (VSS), -which consist of every participant performing Shamir secret sharing of ... -TODO explain -TODO explain that everything is deterministically derived from a seed (where?) We make the following modifications as compared to the original SimplPedPop proposal: -- Adding individual's participant public keys to the output of the DKG. This allows partial signature verification. -- The participants send VSS commitments to an untrusted coordinator instead of directly to each other. This lets the coordinator aggregate VSS commitments, which reduces communication cost. -- The proofs of knowledge are not included in the data for the equality check. This will reduce the size of the backups in ChillDKG. + + - Individual participants' public keys are added to the output of the DKG. This allows partial signature verification. + - The participants send VSS commitments to an untrusted coordinator instead of directly to each other. This lets the coordinator aggregate VSS commitments, which reduces communication cost. + - The proofs of knowledge are not included in the data for the equality check. This will reduce the size of the backups in ChillDKG. + - A pseudorandom function (based on SHA256) is used to derived all required random values deterministically from a single secret seed. + +The SimplPedPop protocol works as follows: + +1. Every participant `i` creates a `t`-of-`n` sharing of a random secret scalar using Feldman Verifiable Secret Sharing (VSS), a variant of Shamir Secret Sharing. + This involves generating random coefficients `a_i[0], ..., a_i[t-1]` of a polynomial `f_i` of degree `t-1` in the scalar group: + + ``` + f_i(Z) = a_i[0] + a_i[1] * Z + ... a_i[t-1] * Z^(t-1) + ``` + + Here, `f_i(0) = a_i[0]` acts as the secret scalar to be shared. + Participant `i` computes a VSS share `shares[j] = f_i(j+1)` for every participant `j` (including `j = i`), + which is supposed to sent to participant `j` over a private channel. + (This private channel will be instantiated in EncPedPod.) + + Participant `i` then sends a VSS commitment, + which is a vector `com = (com[0], ..., com[t-1]) = (a_i[0] * G, ..., a_i[t-1] * G)` of group elements, + and a BIP340 Schnorr signature `pop` on message `i` with secret key `a_i[0]` to the coordinator. + (The Schnorr signature acts as a *proof of possession*, + i.e., it proves knowledge of the discrete logarithm of `com[i][0] = a_i[0] * G`. + This avoids rogue-key attacks, also known as key cancellation attacks.) + +2. Upon receiving `coms[j] = (coms[j][0], ..., coms[j][t-1])` and `pops[j]` from every participant `j`, + the coordinator aggregates the commitments + by computing the component-wise sum of all `coms[j]` vectors except for their first components `coms[j][0]`, + which are simply concatenated (because the participants will need them to verify the proofs of possession): + + ``` + sum_coms_to_nonconst_terms = (coms[0][1] + ... + coms[0][t-1], ..., coms[n-1][1] + ... + coms[n-1][t-1]) + coms_to_secrets = (coms[0][0], ..., com[n-1][0]) + ``` + + The coordinator sends the vectors `coms_to_secrets`, `sum_coms_to_nonconst_terms`, and `pops` to every participant. + +3. Upon receiving `coms_to_secrets`, `sum_coms_to_nonconst_terms`, and `pops` from the coordinator. + every participant `i` verifies every signature `pops[j]` using message `j` and public key `coms_to_secret[j]`. + If any signature is invalid, participant `i` aborts. + + Otherwise, participant `i` sums the components of `coms_to_secrets`, + and prepends the sum to the `sum_coms_to_nonconst_terms` vector, resulting in a vector `sum_coms`. + (Assuming the coordinator performed its computations correctly, + the vector `sum_coms` is now the complete component-wise sum of the `coms[j]` vectors from every participant `j`. + It acts as a VSS commitment to the sum `f = f_0 + ... + f_{n-1}` of the polynomials of all participants.) + + Participant `i` computes the public share of every participant `j` as follows: + + ``` + pubshares[j] = (j+1)^0 * sum_coms[0] + ... + (j+1)^(t-1) * sum_coms[t-1] + ``` + + Let `shares_sum` be the sum of VSS shares privately obtained from each participant `j`. + Participant `i` checks the validity of `shares_sum` against `sum_coms` + by checking if the equation `shares_sum * G = pubshare[i]` holds. + (Assuming `shares_sum` is the sum of the VSS shares created by other participants, it will be equal to `f(i+1)`.) + + If the check fails, participant `i` aborts. + Otherwise, participant `i` computes the DKG outputs consisting of + this participant's secret share `secshare = shares_sum`, + the threshold public key `threshold_pubkey = sum_coms[0]`, and + all participants' public shares `pubshares`. + +TODO Mention Eq here briefly. ### EncPedPop -EncPedPop is a thin wrapper around that SimplPedPop. -It takes care of encrypting the secret shares, +EncPedPop is a thin wrapper around SimplPedPop. +It takes care of encrypting the VSS shares, so that they can be sent over insecure channels. EncPedPod encrypts the shares to a 33-byte public key @@ -280,6 +342,7 @@ The purpose of this section is to provide a high-level overview of the interface aimed at developers who would like to use a ChillDKG implementation in their applications and systems. ### Use ChillDKG only for FROST + ChillDKG is designed for usage with the FROST Schnorr signature scheme, and its security depends on specifics of FROST. We stress that ChillDKG is not a general-purpose DKG protocol [^no-simulatable-dkg], diff --git a/reference/simplpedpop.py b/reference/simplpedpop.py index 1c77636..895e36a 100644 --- a/reference/simplpedpop.py +++ b/reference/simplpedpop.py @@ -86,13 +86,17 @@ def common_dkg_output(vss_commit, n: int) -> Tuple[GE, List[GE]]: The common parts are the threshold public key and the individual public shares of all participants.""" threshold_pubkey = vss_commit.ges[0] - participant_pubshares = [] + pubshares = [] for i in range(0, n): + # TODO The following computation is the major part of vss_commit.verify(i, ...), + # which we have already computed for i. We should 1) extract the major part of + # VSSCommitment.verify into a separate method, and 2) avoid that we're computing + # it twice here. pk_i = GE.batch_mul( *(((i + 1) ** j, vss_commit.ges[j]) for j in range(0, vss_commit.t())) ) - participant_pubshares += [pk_i] - return threshold_pubkey, participant_pubshares + pubshares += [pk_i] + return threshold_pubkey, pubshares ###