The Zcash ArboretumThe Complete Arboretum PDF

3 Key generation

This section states the status of key generation in RFC 9591 and ZIP 312 and the two protocols that output the threshold key material of Definition 2.5: key generation by a trusted dealer and distributed key generation. Each is proved to output valid key material and is classified by Definition 1.1.

3.1 Trusted-dealer key generation

RFC 9591 places key generation out of its scope and, for completeness, specifies key generation by a trusted dealer in Appendix C (“Trusted Dealer Key Generation”); Section 1 (“Introduction”) says so. Its Section 5 (“Two-Round FROST Signing Protocol”) names the two mechanisms by which the key material of Definition 2.5 may be configured, a trusted dealer and a distributed key generation protocol, and specifies neither beyond that appendix. ZIP 312 specifies no key generation (“Non-requirements”). Its “Key Generation” requires key generation to be consistent with FROST, referring to the dealer appendix of RFC 9591 for guidance, and names the spend authorising key 𝖺𝗌𝗄 as the key to be shared. It records that 𝖺𝗌𝗄 is usually derived from the spending key 𝗌𝗄 but need not be; that not deriving it permits distributed key generation, since the key so generated is unpredictable; and that not deriving it prevents recovery of the secret from a seed phrase, which the ZIP notes may be desirable for FROST. The security analysis of Bellare, Tessaro and Zhu (ePrint 2022/833, in its current revision, whose preliminary version is part of the analysis RFC 9591 cites) models key generation as an algorithm run by a trusted party. Two protocols output key material: the dealer of RFC 9591, Appendix C, in this subsection, and the distributed key generation of ePrint 2020/852, Figure 1, in §3.2.

Assumption 3.1 (Honest dealer).

The dealer runs Construction 3.2 as written:

  1. 1.

    it samples s and the coefficients a1,…,at−1 uniformly and independently from its own randomness;

  2. 2.

    it reveals s, the coefficients and the shares only as the construction prescribes, the share of Pj to Pj alone;

  3. 3.

    it deletes s, the coefficients and the shares once the shares are distributed.

The adversary of Definition 2.11 does not control the dealer and never obtains its state.

The three clauses are the trust requirements of RFC 9591, Appendix C: the dealer is trusted to generate good randomness, to delete secret values after distributing the shares, and to keep secret values confidential; the appendix further requires that the dealer delete the secret key and the secret key shares upon completion.

Construction 3.2 (Dealer sharing of a threshold key).

Let (t,n) be threshold parameters with identifiers 1,…,n (Definition 2.1), over the group 𝔾 of prime order q with generator B and scalar field 𝔽q. The dealer proceeds as follows.

  1. 1.

    It samples the signing key s←$𝔽q uniformly and a1,…,at−1←$𝔽q independently and uniformly.

  2. 2.

    It sets a0:=s and

    f⁢(X):=∑k=0t−1ak⁢Xk∈𝔽q⁢[X],

    a sharing of s by Crypto Guide, Construction “Shamir t-of-n secret sharing”.

  3. 3.

    For j=1,…,n it sends the secret share (j,𝑠𝑘j), with 𝑠𝑘j:=f⁢(j), to Pj over a mutually authenticated confidential channel (Definition 2.10, type (c)).

  4. 4.

    It sends the coefficient commitments

    Ak:=[ak]⁢B,k=0,…,t−1,

    to every party, the participants and the Coordinator, by consistent broadcast (Definition 2.10, type (d)).

  5. 5.

    It deletes s, the coefficients and the shares.

Participant Pj aborts if its view of (A0,…,At−1) differs from that of another party, and aborts if

[𝑠𝑘j]⁢B≠∑k=0t−1[jk]⁢Ak.

Every party computes the group information

𝑃𝐾:=A0,𝑃𝐾i:=∑k=0t−1[ik]⁢Ak(i=1,…,n)

by Lemma 2.6; by this computation every party learns every verification share. Output: the share (j,𝑠𝑘j) to Pj, and (𝑃𝐾,𝑃𝐾1,…,𝑃𝐾n) to every party. The dealer knows s. Class (Definition 1.1): specified.

The construction is that of RFC 9591, Appendix C, with its Appendices C.1 (“Shamir Secret Sharing”) and C.2 (“Verifiable Secret Sharing”). The secret is generated uniformly at random and must be derived from at least Ns bytes of entropy, Ns being the length of an encoded scalar; Appendix D (“Random Scalar Generation”) gives the generation of uniform scalars. The shares are the evaluations of f at 1,…,n, the secret prepended to the coefficients, and an identifier is never 0 (Appendix C.1). The commitment is the vector of the [ak]⁢B; a participant must abort if it does not hold the same view of it as the other participants, which a secure broadcast channel ensures (Appendix C), and must abort if its share fails the check, the failure being investigated out of band (Appendix C.2). The channel for shares is mutually authenticated and provides confidentiality and integrity (Appendix C). Consistent broadcast realises the first abort rule: under Definition 2.10, type (d), every honest recipient outputs the same vector or every honest recipient aborts.

Proposition 3.3 (Validity of dealt key material).

Let the commitments of Construction 3.2 travel by consistent broadcast (Definition 2.10, type (d)).

  1. (i)

    Under Assumption 3.1, if the broadcast does not abort, no honest participant aborts, and the shares (j,𝑠𝑘j) with the group information (𝑃𝐾,𝑃𝐾1,…,𝑃𝐾n) are valid key material for s (Definition 2.5), with 𝑃𝐾=[s]⁢B.

  2. (ii)

    Without Assumption 3.1, the commitments determine a unique polynomial f∗=∑kak∗⁢Xk of degree at most t−1 with [ak∗]⁢B=Ak for every k; a participant whose check passes holds 𝑠𝑘j=f∗⁢(j); and every honest party computes the same group information, that of f∗. The shares that pass and the group information are thus consistent with the one polynomial f∗, whose constant term logB⁡A0 the dealer chooses freely.

  3. (iii)

    Under Assumption 3.1, for every set C of fewer than t participants there is a randomised algorithm that, given 𝑃𝐾=[s]⁢B alone, outputs a tuple distributed identically to the joint view of C: its shares and the commitments. The commitments reveal [s]⁢B and nothing further to C.

Proof.

(i) By steps (1) to (3), 𝑠𝑘j=f⁢(j) for the polynomial f of degree at most t−1 with f⁢(0)=s. Each honest share passes its check by the identity ∑k[jk]⁢Ak=[f⁢(j)]⁢B displayed in Crypto Guide, Construction “Feldman verifiable secret sharing”, and consistent broadcast from an honest dealer that does not abort gives every honest party the dealer’s vector, so no honest participant aborts. Lemma 2.6, part (i), gives 𝑃𝐾=A0=[f⁢(0)]⁢B=[s]⁢B and 𝑃𝐾j=[f⁢(j)]⁢B=[𝑠𝑘j]⁢B, which are the conditions of Definition 2.5.

(ii) Consistent broadcast gives every honest party the same vector (A0,…,At−1), or every honest party aborts. By Crypto Guide, Proposition “What the Feldman check certifies”, that vector determines the unique f∗ with ak∗=logB⁡Ak, a check passes if and only if 𝑠𝑘j=f∗⁢(j), and nothing constrains f∗⁢(0). Lemma 2.6, part (i), applied to f∗, gives the common group information 𝑃𝐾=[f∗⁢(0)]⁢B and 𝑃𝐾j=[f∗⁢(j)]⁢B.

(iii) Suppose first |C|=t−1. By Crypto Guide, Theorem “Perfect secrecy below the threshold”, the shares (𝑠𝑘i)i∈C are jointly uniform on 𝔽qt−1 whatever s is. Given the shares, the points [f⁢(0)]⁢B=𝑃𝐾 and [f⁢(i)]⁢B=[𝑠𝑘i]⁢B, i∈C, are t values of the map x↦[f⁢(x)]⁢B at distinct points; since each Ak is a fixed 𝔽q-linear combination of these values (interpolation in the exponent), the commitments are a function of 𝑃𝐾 and the shares. The algorithm samples t−1 uniform scalars as the shares and computes the commitments so; this is the argument of Crypto Guide, Remark “The leak, and where it is harmless”. If |C|<t−1, then, since t≤n, some set C′⊇C of t−1 participants exists; the view of C is a projection of that of C′, and the algorithm for C′ followed by the projection serves for C. □

Remark 3.4 (Key material of an Orchard-protocol key).

For an Orchard-protocol key the shared secret is 𝖺𝗌𝗄 (ZIP 312, “Key Generation”). The output of Construction 3.2 then passes through Construction 6.7 in §6.3 and is completed by Construction 6.8. ZIP 312 also admits a dealer that shares an 𝖺𝗌𝗄 derived from a spending key; that 𝖺𝗌𝗄 is not sampled as in Assumption 3.1, clause (1), and §7.3 treats both cases.

3.2 Distributed key generation

Assumption 3.5 (The proof-of-knowledge hash).

The challenge hash

Hdkg:{1,…,n}×{0,1}∗×𝔾×𝔾→𝔽q

of Construction 3.6, applied to an injective encoding of its input (identifier, context string, point, point), is modelled as a random oracle (Crypto Guide, §“The random oracle model”) independent of every other hash of the volume, in particular of the ciphersuite hashes of Assumption 4.2.

An instantiation achieves the independence by domain separation: a random oracle restricted to prefix-free tags yields independent random oracles (Crypto Guide, §“Domain separation and personalisation”, Proposition “Domain separation yields independent oracles”). No ZIP fixes Hdkg or the context string for the Pallas ciphersuite of ZIP 312: that ciphersuite defines the hashes H1 to H5 and HR only (“FROST(Pallas, BLAKE2b-512)”), and key generation is outside the ZIP’s scope (“Key Generation”). The volume therefore takes Hdkg as the named oracle of Assumption 3.5.

Construction 3.6 (Pedersen key generation with proofs of knowledge).

Let (t,n) be threshold parameters (Definition 2.1) and Hdkg the hash of Assumption 3.5. Before Round One the participants agree, by means outside the construction, on a context string Φ∈{0,1}∗ unique to the ceremony.

Round One, participant Pi:

  1. 1.

    It samples ai,0,…,ai,t−1←$𝔽q independently and uniformly and sets fi⁢(X):=∑k=0t−1ai,k⁢Xk.

  2. 2.

    It proves knowledge of ai,0: it samples νi←$𝔽q and sets

    Ri:=[νi]⁢B,ci:=Hdkg⁢(i,Φ,[ai,0]⁢B,Ri),
    μi:=νi+ai,0⁢ci,σi:=(Ri,μi).
  3. 3.

    It computes Ai,k:=[ai,k]⁢B for k=0,…,t−1.

  4. 4.

    It sends (Ai,0,…,Ai,t−1,σi) to every other party, the Coordinator included, by consistent broadcast (Definition 2.10, type (d)).

  5. 5.

    For every ℓ≠i it computes cℓ:=Hdkg⁢(ℓ,Φ,Aℓ,0,Rℓ) and aborts unless

    Rℓ=[μℓ]⁢B−[cℓ]⁢Aℓ,0.

    If every check passes, it deletes the proofs σℓ.

Round Two, participant Pi:

  1. 1.

    It sends fi⁢(ℓ) to each Pℓ, ℓ≠i, over a mutually authenticated confidential channel (Definition 2.10, type (c)), keeps fi⁢(i), and deletes fi and the values sent.

  2. 2.

    For every ℓ≠i it aborts unless

    [fℓ⁢(i)]⁢B=∑k=0t−1[ik]⁢Aℓ,k.
  3. 3.

    It sets 𝑠𝑘i:=∑ℓ=1nfℓ⁢(i) and deletes the fℓ⁢(i).

Group information. Every party sets Ak:=∑ℓ=1nAℓ,k for k=0,…,t−1 and computes

𝑃𝐾:=A0,𝑃𝐾j:=∑k=0t−1[jk]⁢Ak(j=1,…,n)

by Lemma 2.6.

Output: (i,𝑠𝑘i) to Pi, and (𝑃𝐾,𝑃𝐾1,…,𝑃𝐾n) to every party. A failed check leads to abort only; its cause is investigated out of band.

The construction is that of ePrint 2020/852, Figure 1, in additive notation: the paper’s g, ϕi,k, k, si, Yi and Y are B, Ai,k, νi, 𝑠𝑘i, 𝑃𝐾i and 𝑃𝐾. The paper’s Section 5.1 describes it as Pedersen’s protocol, n parallel runs of Crypto Guide, Construction “Feldman verifiable secret sharing”, one with each participant as dealer, each share being the sum of the n shares received. Round One, step (2), is the Fiat–Shamir transform of Crypto Guide, Construction “Schnorr identification” (§“The Schnorr identification protocol”; §“The Fiat–Shamir transform: from interactive to non-interactive”), with statement Ai,0, witness ai,0, and the prover’s identifier and Φ bound into the challenge; the verification equation of step (5) is that of the identification protocol rearranged. ePrint 2020/852, Figure 1, binds the context string into the challenge to prevent replay of proofs across ceremonies, a design claim that no cited source proves (Remark 3.9). The last part of Figure 1 computes every verification share from the broadcast commitments, which is how parties other than Pj learn 𝑃𝐾j.

Consistent broadcast of Round One is a hypothesis of the construction: ePrint 2020/852, Section 5.1, assumes that participants hold a consistent view of the commitments and does not provide it. A participant that sent different commitment vectors to different parties would lead them to compute different group information: different verification shares, and different group keys when the constant terms Aℓ,0 differ.

Lemma 3.7 (Sum of dealt sharings).

Let f1,…,fn∈𝔽q⁢[X] have degree at most t−1, with coefficients aℓ,k and coefficient commitments Aℓ,k=[aℓ,k]⁢B. Then f:=∑ℓ=1nfℓ has degree at most t−1, constant term f⁢(0)=∑ℓaℓ,0, and coefficient commitments

[∑ℓ=1naℓ,k]⁢B=∑ℓ=1nAℓ,k,k=0,…,t−1;

and f⁢(j)=∑ℓfℓ⁢(j) for every j∈𝔽q.

Proof.

Polynomial addition adds coefficients and does not raise the degree, so the coefficient of Xk in f is ∑ℓaℓ,k, zero for k≥t. Evaluation at a point is additive in the polynomial. The map a↦[a]⁢B is a group homomorphism 𝔽q→𝔾, which gives the commitments. □

Proposition 3.8 (Validity of distributed key material).

Consider an execution of Construction 3.6 without abort in which the Round One messages travel by consistent broadcast. For each ℓ let fℓ∗ be the unique polynomial of degree at most t−1 whose coefficient commitments are Aℓ,0,…,Aℓ,t−1, let f∗:=∑ℓfℓ∗, and let 𝑠𝑘j:=f∗⁢(j) for every identifier j. Then:

  1. (i)

    every honest participant Pi outputs 𝑠𝑘i=f∗⁢(i);

  2. (ii)

    every honest party computes the same group information, 𝑃𝐾=[f∗⁢(0)]⁢B and 𝑃𝐾j=[f∗⁢(j)]⁢B;

  3. (iii)

    the shares 𝑠𝑘j with this group information are valid key material (Definition 2.5) for the signing key

    s=f∗⁢(0)=∑ℓ=1nlogB⁡Aℓ,0.

If every participant is honest, fℓ∗=fℓ for every ℓ.

Proof.

The polynomials fℓ∗ exist and are unique by Crypto Guide, Proposition “What the Feldman check certifies”. An honest Pi broadcasts the commitments of its own fi, so fi=fi∗ and its kept value is fi⁢(i)=fi∗⁢(i). Each received fℓ⁢(i), ℓ≠i, passed the check of Round Two, step (2), so equals fℓ∗⁢(i) by the same proposition. Hence 𝑠𝑘i=∑ℓfℓ∗⁢(i)=f∗⁢(i) by Lemma 3.7, which is (i). Consistent broadcast gives every honest party the same Aℓ,k, hence the same Ak=∑ℓAℓ,k, which by Lemma 3.7 are the coefficient commitments of f∗, of degree at most t−1. Lemma 2.6, part (i), applied to f∗ gives 𝑃𝐾=[f∗⁢(0)]⁢B and 𝑃𝐾j=[f∗⁢(j)]⁢B=[𝑠𝑘j]⁢B, which is (ii); with the shares 𝑠𝑘j=f∗⁢(j) these are the conditions of Definition 2.5, which is (iii), and f∗⁢(0)=∑ℓfℓ∗⁢(0)=∑ℓlogB⁡Aℓ,0. If every participant is honest, each broadcasts the commitments of its own polynomial, so fℓ∗=fℓ. □

Remark 3.9 (Rogue keys and robustness).

The statements of this remark are design claims of ePrint 2020/852; none is a theorem. The proofs of knowledge of Round One, step (2), are the change from Pedersen’s protocol: the paper adds them against rogue-key attacks, in which a participant chooses its commitment as a function of the others’ commitments to bias the group key, in the setting t≥n/2 (Section 5.1). No source cited in this volume proves Construction 3.6 secure, or proves FROST as RFC 9591 specifies it unforgeable with it; §7.3 states what is known (Remark 7.13). The protocol is not robust: any failed proof or share check aborts the whole execution and its cause is investigated out of band (Figure 1; Section 3), so one participant can prevent key generation.

Construction 3.6 is designed but unspecified for Zcash (Definition 1.1). The protocol is published (ePrint 2020/852, Figure 1), but no RFC or ZIP specifies a distributed key generation: RFC 9591 places key generation out of scope (Section 1), and ZIP 312 specifies none (“Key Generation”). ZIP 2005 (Proposed), “Usage with FROST”, names the FROST distributed key generation protocol without a specification behind the reference; the revision of ZIP 312 proposed in pull request 895 names a different key-generation protocol, so its adoption would not specify this one. Its Zcash instantiation, the hash Hdkg and the context string Φ, is fixed by no ZIP (Assumption 3.5).