zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

update with simplified design

This commit is contained in:
Conrado Gouvea 2023-08-21 18:22:26 -03:00
parent e2c611d2cb
commit c0c16432a4
2 changed files with 450 additions and 220 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

383
zip-0312.html
View File

@ -1,16 +1,389 @@
<!DOCTYPE html>
<html>
<head>
<title>ZIP 312: Shielded Multisignatures using FROST</title>
<title>ZIP 312: FROST for Spend Authorization Signatures</title>
<meta charset="utf-8" />
<script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script>
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 312
Title: Shielded Multisignatures using FROST
Status: Reserved
Category: Standards / RPC / Wallet
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/382">https://github.com/zcash/zips/issues/382</a>&gt;</pre>
Title: FROST for Spend Authorization Signatures
Owners: Conrado Gouvea &lt;conrado@zfnd.org&gt;
Chelsea Komlo &lt;ckomlo@uwaterloo.ca&gt;
Deirdre Connolly &lt;deirdre@zfnd.org&gt;
Status: Draft
Category: Wallet
Created: 2022-08-dd
License: MIT
Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/382">https://github.com/zcash/zips/issues/382</a>&gt;
Pull-Request: &lt;<a href="https://github.com/zcash/zips/pull/662">https://github.com/zcash/zips/pull/662</a>&gt;</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>{Edit this to reflect the key words that are actually used.} The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">2</a></p>
<p>The terms below are to be interpreted as follows:</p>
<dl>
<dt>Unlinkability</dt>
<dd>The property of statistical independence of signatures from the signers' long-term keys, ensuring that (for perfectly uniform generation of Randomizers and no leakage of metadata) it is impossible to determine whether two transactions were generated by the same party.</dd>
</dl>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This proposal adapts FROST <a id="id2" class="footnote_reference" href="#frost">3</a>, a threshold signature scheme, to make it unlinkable, which is a requirement for its use in the Zcash protocol. The adapted scheme generates signatures compatible with spend authorization signatures in the Zcash protocol, for the Sapling and Orchard network upgrades.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>In the Zcash protocol, Spend Authorization Signatures are employed to authorize a transaction. The ability to generate these signatures with the user's private key is what effectively allows the user to spend funds.</p>
<p>This is a security-critical step, since anyone who obtains access to the private key will be able to spend the user's funds. For this reason, one interesting possibility is to require multiple parties to allow the transaction to go through. This can be accomplished with threshold signatures, where the private key is split between parties in a way that a threshold (e.g. 2 out of 3) of them must sign the transaction in order to create the final signature. This enables scenarios such as users and exchanges sharing custody of a wallet, for example.</p>
<p>FROST is one of such threshold signature protocols. However, it can't be used as-is since the Zcash protocol also requires re-randomizing public and private keys to ensure unlinkability between transactions. This ZIP specifies a variant of FROST with re-randomization support.</p>
</section>
<section id="requirements"><h2><span class="section-heading">Requirements</span><span class="section-anchor"> <a rel="bookmark" href="#requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li>All signatures generated by following this ZIP must be verified successfully as Sapling or Orchard spend authorization signatures using the appropriate validating key.</li>
<li>The signatures generated by following this ZIP should meet the security criteria for Signature with Re-Randomizable Keys as specified in the Zcash protocol <a id="id3" class="footnote_reference" href="#protocol-concretereddsa">10</a>.</li>
<li>The threat model described below must be taken into account.</li>
</ul>
<section id="threat-model"><h3><span class="section-heading">Threat Model</span><span class="section-anchor"> <a rel="bookmark" href="#threat-model"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>In normal usage, a Zcash user follows multiple steps in order to generate a shielded transaction:</p>
<ul>
<li>The transaction is created.</li>
<li>The transaction is signed with a re-randomized version of the user's spend authorization private key.</li>
<li>The zero-knowledge proof for the transaction is created with the randomizer as an auxiliary (secret) input, among others.</li>
</ul>
<p>When employing re-randomizable FROST as specified in this ZIP, the goal is to split the spend authorization private key
<span class="math">\(\mathsf{ask}\)</span>
among multiple possible signers. This means that the proof generation will still be performed by a single participant, likely the one that created the transaction in the first place. Note that this user already controls the privacy of the transaction since they are responsible for creating the proof.</p>
<p>This fits well into the "Coordinator" role from the FROST specification <a id="id4" class="footnote_reference" href="#frost-protocol">4</a>. The Coordinator is responsible for sending the message to be signed to all participants, and to aggregate the signature shares.</p>
<p>With those considerations in mind, the threat model considered in this ZIP is:</p>
<ul>
<li>The Coordinator is trusted with the privacy of the transaction (which includes the unlinkability property). A rogue Coordinator will be able to break unlinkability and privacy, but should not be able to create signed transactions without the approval of <code>MIN_PARTICIPANTS</code> participants, as specified in FROST.</li>
<li>All key share holders are also trusted with the privacy of the transaction, thus a rogue key share holder will be able to break its privacy and unlinkability.</li>
</ul>
</section>
</section>
<section id="non-requirements"><h2><span class="section-heading">Non-requirements</span><span class="section-anchor"> <a rel="bookmark" href="#non-requirements"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<ul>
<li>This ZIP does not support removing the Coordinator role, as described in #[frost-removingcoordinator]_.</li>
<li>This ZIP does not prevent key share holders from linking the signing operation to a transaction in the blockchain.</li>
<li>Like the FROST specification <a id="id5" class="footnote_reference" href="#frost">3</a>, this ZIP does not specify a key generation procedure; but refer to that specification for guidelines.</li>
<li>Network privacy is not in scope for this ZIP, and must be obtained with other tools if desired.</li>
</ul>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Algorithms in this section are specified using Python pseudo-code, in the same fashion as the FROST specification <a id="id6" class="footnote_reference" href="#frost">3</a>.</p>
<p>The types Scalar, Element, and G are defined in #[frost-primeordergroup]_, as well as the notation for elliptic-curve arithmetic, which uses the additive notation. Note that this notation differs from that used in the Zcash Protocol Specification. For example, <code>G.ScalarMult(P, k)</code> is used for scalar multiplication, where the protocol spec would use
<span class="math">\([k] P\)</span>
with the group implied by
<span class="math">\(P\)</span>
.</p>
<section id="re-randomizable-frost"><h3><span class="section-heading">Re-randomizable FROST</span><span class="section-anchor"> <a rel="bookmark" href="#re-randomizable-frost"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>To add re-randomization to FROST, follow the specification <a id="id7" class="footnote_reference" href="#frost">3</a> with the following modifications.</p>
<section id="key-generation"><h4><span class="section-heading">Key Generation</span><span class="section-anchor"> <a rel="bookmark" href="#key-generation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>While key generation is out of scope for this ZIP and the FROST spec <a id="id8" class="footnote_reference" href="#frost">3</a>, it needs to be consistent with FROST, see <a id="id9" class="footnote_reference" href="#frost-tdkg">8</a> for guidance. The spend authorization private key
<span class="math">\(\mathsf{ask}\)</span>
<a id="id10" class="footnote_reference" href="#protocol-spendauthsig">12</a> is the particular key that must be used in the context of this ZIP. Note that the
<span class="math">\(\mathsf{ask}\)</span>
is usually derived from the spending key
<span class="math">\(\mathsf{sk}\)</span>
, though that is not required. This allows using distributed key generation, since the key it generates is unpredictable. Note however that note deriving
<span class="math">\(\mathsf{ask}\)</span>
from
<span class="math">\(\mathsf{sk}\)</span>
prevents using seed phrases to recover the original secret (which may be something desirable in the context of FROST).</p>
</section>
<section id="randomizer-generation"><h4><span class="section-heading">Randomizer Generation</span><span class="section-anchor"> <a rel="bookmark" href="#randomizer-generation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>A new helper function is defined, which computes
<span class="math">\(\mathsf{RedDSA.GenRandom}\)</span>
:</p>
<pre>randomizer_generate():
Inputs:
- None
Outputs: randomizer, a Scalar
def randomizer_generate():
randomizer_input = random_bytes(64)
return H3(randomizer_input)</pre>
</section>
<section id="round-one-commitment"><h4><span class="section-heading">Round One - Commitment</span><span class="section-anchor"> <a rel="bookmark" href="#round-one-commitment"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Roune One is exactly the same as specified <a id="id11" class="footnote_reference" href="#frost">3</a>. But for context, it involves these steps:</p>
<ul>
<li>Each signer generates nonces and their corresponding public commitments. A nonce is a pair of Scalar values, and a commitment is a pair of Element values.</li>
<li>The nonces are stored locally by the signer and kept private for use in the second round.</li>
<li>The commitments are sent to the Coordinator.</li>
</ul>
</section>
<section id="round-two-signature-share-generation"><h4><span class="section-heading">Round Two - Signature Share Generation</span><span class="section-anchor"> <a rel="bookmark" href="#round-two-signature-share-generation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>In Round Two, the Coordinator generates a random scalar <code>randomizer</code> by calling <code>randomizer_generate</code> and sends it to each signer, over a confidential and authenticated channel, along with the message and the set of signing commitments. (Note that this differs from regular FROST which just requires an authenticated channel.)</p>
<p>In Zcash, the message that needs to be signed is actually the SIGHASH transaction hash, which does not convey enough information for the signers to decide if they want to authorize the transaction or not. Therefore, in practice, more data is needed to be sent (over the same encrypted, authenticated channel) from the Coordinator to the signers, possibly the transaction itself, openings of value commitments, decryption of note ciphertexts, etc.; and the signers must check that the given SIGHASH matches the data sent from the Coordinator, or compute the SIGHASH themselves from that data. However, the specific mechanism for that process is outside the scope of this ZIP.</p>
<p>The <code>sign</code> function remains unchanged, but its inputs must be modified relative to the <code>randomizer</code> as following:</p>
<ul>
<li><code>sk_i = sk_i + randomizer</code></li>
<li><code>group_public_key = group_public_key + G.ScalarBaseMult(randomizer)</code></li>
</ul>
</section>
<section id="signature-share-verification-and-aggregation"><h4><span class="section-heading">Signature Share Verification and Aggregation</span><span class="section-anchor"> <a rel="bookmark" href="#signature-share-verification-and-aggregation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The <code>aggregate</code> function remains unchanged, but its inputs must be modified relative to the <code>randomizer</code> as following:</p>
<ul>
<li><code>group_public_key = group_public_key + G.ScalarBaseMult(randomizer)</code></li>
</ul>
<p>The <code>verify_signature_share</code> function remains unchanged, but its inputs must be modified relative to the <code>randomizer</code> as following:</p>
<ul>
<li><code>PK_i = PK_i + G.ScalarBaseMult(randomizer)</code></li>
<li><code>group_public_key = group_public_key + G.ScalarBaseMult(randomizer)</code></li>
</ul>
</section>
</section>
<section id="ciphersuites"><h3><span class="section-heading">Ciphersuites</span><span class="section-anchor"> <a rel="bookmark" href="#ciphersuites"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<section id="frost-jubjub-blake2b-512"><h4><span class="section-heading">FROST(Jubjub, BLAKE2b-512)</span><span class="section-anchor"> <a rel="bookmark" href="#frost-jubjub-blake2b-512"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>This ciphersuite uses Jubjub for the Group and BLAKE2b-512 for the Hash function <code>H</code> meant to produce signatures indistinguishable from RedJubjub Sapling Spend Authorization Signatures as specified in <a id="id12" class="footnote_reference" href="#protocol-concretespendauthsig">11</a>.</p>
<ul>
<li>Group: Jubjub <a id="id13" class="footnote_reference" href="#protocol-jubjub">13</a> with base point
<span class="math">\(\mathcal{G}^{\mathsf{Sapling}}\)</span>
as defined in <a id="id14" class="footnote_reference" href="#protocol-concretespendauthsig">11</a>.
<ul>
<li>Order:
<span class="math">\(r_\mathbb{J}\)</span>
as defined in <a id="id15" class="footnote_reference" href="#protocol-jubjub">13</a>.</li>
<li>Identity: as defined in <a id="id16" class="footnote_reference" href="#protocol-jubjub">13</a>.</li>
<li>RandomScalar(): Implemented by returning a uniformly random Scalar in the range [0, <code>G.Order()</code> - 1]. Refer to {{frost-randomscalar}} for implementation guidance.</li>
<li>SerializeElement(P): Implemented as
<span class="math">\(\mathsf{repr}_\mathbb{J}(P)\)</span>
as defined in <a id="id17" class="footnote_reference" href="#protocol-jubjub">13</a></li>
<li>DeserializeElement(P): Implemented as
<span class="math">\(\mathsf{abst}_\mathbb{J}(P)\)</span>
as defined in <a id="id18" class="footnote_reference" href="#protocol-jubjub">13</a>, returning an error if
<span class="math">\(\bot\)</span>
is returned. Additionally, this function validates that the resulting element is not the group identity element, returning an error if the check fails.</li>
<li>SerializeScalar: Implemented by outputting the little-endian 32-byte encoding of the Scalar value.</li>
<li>DeserializeScalar: Implemented by attempting to deserialize a Scalar from a little-endian 32-byte string. This function can fail if the input does not represent a Scalar in the range [0, <code>G.Order()</code> - 1].</li>
</ul>
</li>
<li>Hash (<code>H</code>): BLAKE2b-512 <a id="id19" class="footnote_reference" href="#blake">1</a> (BLAKE2b with 512-bit output and 16-byte personalization string), and Nh = 64.
<ul>
<li>H1(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubR", m), interpreting the 64 bytes as a little-endian integer, and reducing the resulting integer modulo <code>G.Order()</code>.</li>
<li>H2(m): Implemented by computing BLAKE2b-512("Zcash_RedJubjubH", m), interpreting the 64 bytes as a little-endian integer, and reducing the resulting integer modulo <code>G.Order()</code>. (This is equivalent to
<span class="math">\(\mathsf{H}^\circledast(m)\)</span>
, as defined by the
<span class="math">\(\mathsf{RedJubjub}\)</span>
scheme instantiated in <a id="id20" class="footnote_reference" href="#protocol-concretereddsa">10</a>.)</li>
<li>H3(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubN", m), interpreting the 64 bytes as a little-endian integer, and reducing the resulting integer modulo <code>G.Order()</code>.</li>
<li>H4(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubM", m).</li>
<li>H5(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubC", m).</li>
</ul>
</li>
</ul>
<p>Signature verification is as specified in <a id="id21" class="footnote_reference" href="#protocol-concretespendauthsig">11</a> for RedJubjub.</p>
</section>
<section id="frost-pallas-blake2b-512"><h4><span class="section-heading">FROST(Pallas, BLAKE2b-512)</span><span class="section-anchor"> <a rel="bookmark" href="#frost-pallas-blake2b-512"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>This ciphersuite uses Pallas for the Group and BLAKE2b-512 for the Hash function <code>H</code> meant to produce signatures indistinguishable from RedPallas Orchard Spend Authorization Signatures as specified in <a id="id22" class="footnote_reference" href="#protocol-concretespendauthsig">11</a>.</p>
<ul>
<li>Group: Pallas <a id="id23" class="footnote_reference" href="#protocol-pallasandvesta">14</a> with base point
<span class="math">\(\mathcal{G}^{\mathsf{Orchard}}\)</span>
as defined in <a id="id24" class="footnote_reference" href="#protocol-concretespendauthsig">11</a>.
<ul>
<li>Order:
<span class="math">\(r_\mathbb{P}\)</span>
as defined in <a id="id25" class="footnote_reference" href="#protocol-pallasandvesta">14</a>.</li>
<li>Identity: as defined in <a id="id26" class="footnote_reference" href="#protocol-pallasandvesta">14</a>.</li>
<li>RandomScalar(): Implemented by returning a uniformly random Scalar in the range [0, <code>G.Order()</code> - 1]. Refer to {{frost-randomscalar}} for implementation guidance.</li>
<li>SerializeElement(P): Implemented as
<span class="math">\(\mathsf{repr}_\mathbb{P}(P)\)</span>
as defined in <a id="id27" class="footnote_reference" href="#protocol-pallasandvesta">14</a>.</li>
<li>DeserializeElement(P): Implemented as
<span class="math">\(\mathsf{abst}_\mathbb{P}(P)\)</span>
as defined in <a id="id28" class="footnote_reference" href="#protocol-pallasandvesta">14</a>, failing if
<span class="math">\(\bot\)</span>
is returned. Additionally, this function validates that the resulting element is not the group identity element, returning an error if the check fails.</li>
<li>SerializeScalar: Implemented by outputting the little-endian 32-byte encoding of the Scalar value.</li>
<li>DeserializeScalar: Implemented by attempting to deserialize a Scalar from a little-endian 32-byte string. This function can fail if the input does not represent a Scalar in the range [0, <code>G.Order()</code> - 1].</li>
</ul>
</li>
<li>Hash (<code>H</code>): BLAKE2b-512 <a id="id29" class="footnote_reference" href="#blake">1</a> (BLAKE2b with 512-bit output and 16-byte personalization string), and Nh = 64.
<ul>
<li>H1(m): Implemented by computing BLAKE2b-512("FROST_RedPallasR", m), interpreting the 64 bytes as a little-endian integer, and reducing the resulting integer modulo <code>G.Order()</code>.</li>
<li>H2(m): Implemented by computing BLAKE2b-512("Zcash_RedPallasH", m), interpreting the 64 bytes as a little-endian integer, and reducing the resulting integer modulo <code>G.Order()</code>. (This is equivalent to
<span class="math">\(\mathsf{H}^\circledast(m)\)</span>
, as defined by the
<span class="math">\(\mathsf{RedPallas}\)</span>
scheme instantiated in <a id="id30" class="footnote_reference" href="#protocol-concretereddsa">10</a>.)</li>
<li>H3(m): Implemented by computing BLAKE2b-512("FROST_RedPallasN", m), interpreting the 64 bytes as a little-endian integer, and reducing the resulting integer modulo <code>G.Order()</code>.</li>
<li>H4(m): Implemented by computing BLAKE2b-512("FROST_RedPallasM", m).</li>
<li>H5(m): Implemented by computing BLAKE2b-512("FROST_RedPallasC", m).</li>
</ul>
</li>
</ul>
<p>Signature verification is as specified in <a id="id31" class="footnote_reference" href="#protocol-concretespendauthsig">11</a> for RedPallas.</p>
</section>
</section>
</section>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>FROST is a threshold Schnorr signature scheme, and Zcash Spend Authorization are also Schnorr signatures, which allows the usage of FROST with Zcash. However, since there is no widespread standard for Schnorr signatures, it must be ensured that the signatures generated by the FROST variant specified in this ZIP can be verified successfully by a Zcash implementation following its specification. In practice this entails making sure that the generated signature can be verified by the
<span class="math">\(\mathsf{RedDSA.Validate}\)</span>
function specified in <a id="id32" class="footnote_reference" href="#protocol-concretereddsa">10</a>:</p>
<ul>
<li>The FROST signature, when split into R and S in the first step of
<span class="math">\(\mathsf{RedDSA.Validate}\)</span>
, must yield the values expected by the function. This is ensured by defining SerializeElement and SerializeScalar in each ciphersuite to yield those values.</li>
<li>The challenge c used during FROST signing must be equal to the challenge c computed during
<span class="math">\(\mathsf{RedDSA.Validate}\)</span>
. This requires defining the ciphersuite H2 function as the
<span class="math">\(\mathsf{H}^\circledast(m)\)</span>
Zcash function in the ciphersuites, and making sure its input will be the same. Fortunately FROST and Zcash use the same input order (R, public key, message) so we just need to make sure that SerializeElement (used to compute the encoded public key before passing to the hash function) matches what
<span class="math">\(\mathsf{RedDSA.Validate}\)</span>
expects; which is possible since both <cite>R</cite> and <cite>vk</cite> (the public key) are encoded in the same way in Zcash.</li>
<li>Note that <code>r</code> (and thus <code>R</code>) will not be generated as specified in RedDSA.Sign. This is not an issue however, since with Schnorr signatures it does not matter for the verifier how the <code>r</code> value was chosen, it just needs to be generated uniformly at random, which is true for FROST.</li>
<li>The above will ensure that the verification equation in
<span class="math">\(\mathsf{RedDSA.Validate}\)</span>
will pass, since FROST ensures the exact same equation will be valid as described in <a id="id33" class="footnote_reference" href="#frost-primeorderverify">7</a>.</li>
</ul>
<p>The second step is adding the re-randomization functionality so that each FROST signing generates a re-randomized signature:</p>
<ul>
<li>Anywhere the public key is used, the randomized public key must be used instead. This is exactly what is done in the functions defined above.</li>
<li>The re-randomization must be done in each signature share generation, such that the aggregated signature must be valid under verification with the randomized public key. The <code>R</code> value from the signature is not influenced by the randomizer so we just need to focus on the <code>z</code> value (using FROST notation). Recall that <code>z</code> must equal to <code>r + (c * sk)</code>, and that each signature share is <code>z_i = (hiding_nonce + (binding_nonce * binding_factor)) +
(lambda_i * c * sk_i)</code>. The first terms are not influenced by the randomizer so we can only look into the second term of each top-level addition, i.e. <code>c
* sk</code> must be equal to <code>sum(lambda_i * c * sk_i)</code> for each participant <code>i</code>. Under re-randomization these become <code>c * (sk + randomizer)</code> (see
<span class="math">\(\mathsf{RedDSA.RandomizedPrivate}\)</span>
, which refers to the randomizer as
<span class="math">\(\alpha\)</span>
) and <code>sum(lambda_i * c * (sk_i + randomizer))</code>. The latter can be rewritten as <code>c * (sum(lambda_i * sk_i) + randomizer *
sum(lambda_i)</code>. Since <code>sum(lambda_i * sk_i) == sk</code> per the Shamir secret sharing mechanism used by FROST, and since <code>sum(lambda_i) == 1</code> <a id="id34" class="footnote_reference" href="#sum-lambda-proof">15</a>, we arrive at <code>c * (sk + randomizer)</code> as required.</li>
<li>The re-randomization procedure must be exactly the same as in <a id="id35" class="footnote_reference" href="#protocol-concretereddsa">10</a> to ensure that re-randomized keys are uniformly distributed and signatures are unlinkable. This is also true; observe that <code>randomizer_generate</code> is exactly the same as
<span class="math">\(\mathsf{RedDSA.GenRandom}\)</span>
; and signature generation is compatible with
<span class="math">\(\mathsf{RedDSA.RandomizedPrivate}\)</span>
,
<span class="math">\(\mathsf{RedDSA.RandomizedPublic}\)</span>
,
<span class="math">\(\mathsf{RedDSA.Sign}\)</span>
and
<span class="math">\(\mathsf{RedDSA.Validate}\)</span>
as explained in the previous item.</li>
</ul>
</section>
<section id="reference-implementation"><h2><span class="section-heading">Reference implementation</span><span class="section-anchor"> <a rel="bookmark" href="#reference-implementation"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>TODO: add links to implementation</p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="blake" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://blake2.net/#sp">BLAKE2: simpler, smaller, fast as MD5</a></td>
</tr>
</tbody>
</table>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="frost" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-14.html">Draft RFC: Two-Round Threshold Schnorr Signatures with FROST</a></td>
</tr>
</tbody>
</table>
<table id="frost-protocol" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-14.html#name-two-round-frost-signing-pro">Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Section 5: Two-Round FROST Signing Protocol</a></td>
</tr>
</tbody>
</table>
<table id="frost-removingcoordinator" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-14.html#name-removing-the-coordinator-ro">Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Section 7.3: Removing the Coordinator Role</a></td>
</tr>
</tbody>
</table>
<table id="frost-primeordergroup" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-14.html#name-prime-order-group">Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Section 3.1: Prime-Order Group</a></td>
</tr>
</tbody>
</table>
<table id="frost-primeorderverify" class="footnote">
<tbody>
<tr>
<th>7</th>
<td><a href="https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-11.html#name-schnorr-signature-generatio">Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Appendix B: Schnorr Signature Generation and Verification for Prime-Order Groups</a></td>
</tr>
</tbody>
</table>
<table id="frost-tdkg" class="footnote">
<tbody>
<tr>
<th>8</th>
<td><a href="https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-14.html#name-trusted-dealer-key-generati">Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Appendix B: Trusted Dealer Key Generation</a></td>
</tr>
</tbody>
</table>
<table id="frost-randomscalar" class="footnote">
<tbody>
<tr>
<th>9</th>
<td><a href="https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-14.html#name-random-scalar-generation">Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Appendix C: Random Scalar Generation</a></td>
</tr>
</tbody>
</table>
<table id="protocol-concretereddsa" class="footnote">
<tbody>
<tr>
<th>10</th>
<td><a href="protocol/protocol.pdf#concretereddsa">Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7: RedDSA, RedJubjub, and RedPallas</a></td>
</tr>
</tbody>
</table>
<table id="protocol-concretespendauthsig" class="footnote">
<tbody>
<tr>
<th>11</th>
<td><a href="protocol/protocol.pdf#concretespendauthsig">Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7.1: Spend Authorization Signature (Sapling and Orchard)</a></td>
</tr>
</tbody>
</table>
<table id="protocol-spendauthsig" class="footnote">
<tbody>
<tr>
<th>12</th>
<td><a href="protocol/protocol.pdf#spendauthsig">Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 4.15: Spend Authorization Signature (Sapling and Orchard)</a></td>
</tr>
</tbody>
</table>
<table id="protocol-jubjub" class="footnote">
<tbody>
<tr>
<th>13</th>
<td><a href="protocol/protocol.pdf#jubjub">Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.3: Jubjub</a></td>
</tr>
</tbody>
</table>
<table id="protocol-pallasandvesta" class="footnote">
<tbody>
<tr>
<th>14</th>
<td><a href="protocol/protocol.pdf#pallasandvesta">Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.6: Pallas and Vesta</a></td>
</tr>
</tbody>
</table>
<table id="sum-lambda-proof" class="footnote">
<tbody>
<tr>
<th>15</th>
<td><a href="https://math.stackexchange.com/questions/1325292/prove-that-the-sum-of-the-lagrange-interpolation-coefficients-is-equal-to-1/1325342#1325342">Prove that the sum of the Lagrange (interpolation) coefficients is equal to 1</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>

287
zip-0312.rst
View File

@ -98,7 +98,7 @@ With those considerations in mind, the threat model considered in this ZIP is:
- The Coordinator is trusted with the privacy of the transaction (which includes
the unlinkability property). A rogue Coordinator will be able to break
unlinkability and privacy, but should not be able to create signed transactions
without the approval of `MIN_SIGNERS` participants, as specified in FROST.
without the approval of ``MIN_PARTICIPANTS`` participants, as specified in FROST.
- All key share holders are also trusted with the privacy of the transaction,
thus a rogue key share holder will be able to break its privacy and unlinkability.
@ -110,7 +110,7 @@ Non-requirements
#[frost-removingcoordinator]_.
- This ZIP does not prevent key share holders from linking the signing operation to a
transaction in the blockchain.
- Like the FROST specification [#FROST], this ZIP does not specify a key generation
- Like the FROST specification [#FROST]_, this ZIP does not specify a key generation
procedure; but refer to that specification for guidelines.
- Network privacy is not in scope for this ZIP, and must be obtained with other
tools if desired.
@ -125,7 +125,7 @@ fashion as the FROST specification [#FROST]_.
The types Scalar, Element, and G are defined in #[frost-primeordergroup]_, as
well as the notation for elliptic-curve arithmetic, which uses the additive
notation. Note that this notation differs from that used in the Zcash Protocol
Specification. For example, `G.ScalarMult(P, k)` is used for scalar
Specification. For example, ``G.ScalarMult(P, k)`` is used for scalar
multiplication, where the protocol spec would use :math:`[k] P` with the group
implied by :math:`P`.
@ -145,8 +145,10 @@ it needs to be consistent with FROST, see [#frost-tdkg]_ for guidance. The
spend authorization private key :math:`\mathsf{ask}` [#protocol-spendauthsig]_
is the particular key that must be used in the context of this ZIP. Note that
the :math:`\mathsf{ask}` is usually derived from the spending key :math:`\mathsf{sk}`,
though that is not required. Doing so might require a trusted dealer key generation
process as detailed in [#frost-tdkg]_ (as opposed to distributed key generation).
though that is not required. This allows using distributed key generation, since
the key it generates is unpredictable. Note however that note deriving :math:`\mathsf{ask}`
from :math:`\mathsf{sk}` prevents using seed phrases to recover the original
secret (which may be something desirable in the context of FROST).
Randomizer Generation
@ -168,41 +170,10 @@ A new helper function is defined, which computes :math:`\mathsf{RedDSA.GenRandom
return H3(randomizer_input)
Binding Factor Computation
''''''''''''''''''''''''''
The `compute_binding_factors` function is changed to receive the `randomizer_commitment`
as follows: ::
Inputs:
- commitment_list = [(i, hiding_nonce_commitment_i, binding_nonce_commitment_i), ...],
a list of commitments issued by each participant, where each element in the list
indicates a NonZeroScalar identifier i and two commitment Element values
(hiding_nonce_commitment_i, binding_nonce_commitment_i). This list MUST be sorted
in ascending order by identifier.
- msg, the message to be signed.
- randomizer_commitment, an element in G.
Outputs:
- binding_factor_list, a list of (NonZeroScalar, Scalar) tuples representing the binding factors.
def compute_binding_factors(commitment_list, msg, randomizer_commitment):
msg_hash = H4(msg)
encoded_commitment_hash = H5(encode_group_commitment_list(commitment_list))
rho_input_prefix = msg_hash || encoded_commitment_hash || G.SerializeElement(randomizer_commitment)
binding_factor_list = []
for (identifier, hiding_nonce_commitment, binding_nonce_commitment) in commitment_list:
rho_input = rho_input_prefix || G.SerializeScalar(identifier)
binding_factor = H1(rho_input)
binding_factor_list.append((identifier, binding_factor))
return binding_factor_list
Round One - Commitment
''''''''''''''''''''''
Roune One is exactly the same as specified #[FROST]_. But for context, it
Roune One is exactly the same as specified [#FROST]_. But for context, it
involves these steps:
- Each signer generates nonces and their corresponding public commitments.
@ -214,11 +185,11 @@ involves these steps:
Round Two - Signature Share Generation
''''''''''''''''''''''''''''''''''''''
In Round Two, the Coordinator generates a random scalar `randomizer` by calling
`randomizer_generate`. Then it computes `randomizer_commitment = G.ScalarBaseMult(randomizer)`
and sends it to each signer, over a confidential and authenticated channel,
along with the message and the set of signing commitments. (Note that this differs
from regular FROST which just requires an authenticated channel.)
In Round Two, the Coordinator generates a random scalar ``randomizer`` by calling
``randomizer_generate`` and sends it to each signer, over a confidential and
authenticated channel, along with the message and the set of signing
commitments. (Note that this differs from regular FROST which just requires an
authenticated channel.)
In Zcash, the message that needs to be signed is actually the SIGHASH
transaction hash, which does not convey enough information for the signers to
@ -230,149 +201,26 @@ that the given SIGHASH matches the data sent from the Coordinator, or compute th
SIGHASH themselves from that data. However, the specific mechanism for that process
is outside the scope of this ZIP.
The `sign` function is changed to receive `randomizer_commitment` and incorporate it
into the computation of the binding factor. It is specified as the following: ::
The ``sign`` function remains unchanged, but its inputs must be modified relative
to the ``randomizer`` as following:
Inputs:
- identifier, identifier i of the participant, a NonZeroScalar.
- sk_i, Signer secret key share, a Scalar.
- group_public_key, public key corresponding to the group signing key,
an Element.
- nonce_i, pair of Scalar values (hiding_nonce, binding_nonce) generated in
round one.
- msg, the message to be signed, a byte string.
- commitment_list =
[(j, hiding_nonce_commitment_j, binding_nonce_commitment_j), ...], a
list of commitments issued in Round 1 by each participant and sent by the Coordinator.
Each element in the list indicates a NonZeroScalar identifier j and two commitment
Element values (hiding_nonce_commitment_j, binding_nonce_commitment_j).
This list MUST be sorted in ascending order by identifier.
- randomizer_commitment, an element in G (sent by the Coordinator).
Outputs:
- sig_share, a signature share, a Scalar.
def sign(identifier, sk_i, group_public_key, nonce_i, msg, commitment_list):
# Compute the randomized group public key
randomized_group_public_key = group_public_key + randomizer_commitment
# Compute the binding factor(s)
binding_factor_list = compute_binding_factors(commitment_list, msg, randomizer_commitment)
binding_factor = binding_factor_for_participant(binding_factor_list, identifier)
# Compute the group commitment
group_commitment = compute_group_commitment(commitment_list, binding_factor_list)
# Compute the interpolating value
participant_list = participants_from_commitment_list(commitment_list)
lambda_i = derive_interpolating_value(identifier, participant_list)
# Compute the per-message challenge
challenge = compute_challenge(group_commitment, randomized_group_public_key, msg)
# Compute the signature share
(hiding_nonce, binding_nonce) = nonce_i
sig_share = hiding_nonce + (binding_nonce * binding_factor) + (lambda_i * sk_i * challenge)
return sig_share
- ``sk_i = sk_i + randomizer``
- ``group_public_key = group_public_key + G.ScalarBaseMult(randomizer)``
Signature Share Verification and Aggregation
''''''''''''''''''''''''''''''''''''''''''''
The `aggregate` function is changed to incorporate the randomizer as follows: ::
The ``aggregate`` function remains unchanged, but its inputs must be modified
relative to the ``randomizer`` as following:
Inputs:
- commitment_list =
[(j, hiding_nonce_commitment_j, binding_nonce_commitment_j), ...], a
list of commitments issued in Round 1 by each participant, where each element
in the list indicates a NonZeroScalar identifier j and two commitment
Element values (hiding_nonce_commitment_j, binding_nonce_commitment_j).
This list MUST be sorted in ascending order by identifier.
- msg, the message to be signed, a byte string.
- sig_shares, a set of signature shares z_i, Scalar values, for each participant,
of length NUM_PARTICIPANTS, where MIN_PARTICIPANTS <= NUM_PARTICIPANTS <= MAX_PARTICIPANTS.
- group_public_key, public key corresponding to the group signing key,
- randomizer, the randomizer Scalar.
- ``group_public_key = group_public_key + G.ScalarBaseMult(randomizer)``
Outputs:
- (R, z), a Schnorr signature consisting of an Element R and Scalar z.
- randomized_group_public_key, the randomized group public key
The ``verify_signature_share`` function remains unchanged, but its inputs must be modified
relative to the ``randomizer`` as following:
def aggregate(commitment_list, msg, sig_shares, group_public_key, randomizer):
# Compute the randomized group public key
randomizer_commitment = G.ScalarBaseMult(randomizer)
randomized_group_public_key = group_public_key + randomizer_commitment
# Compute the binding factors
binding_factor_list = compute_binding_factors(commitment_list, msg, randomizer_commitment)
# Compute the group commitment
group_commitment = compute_group_commitment(commitment_list, binding_factor_list)
# Compute the challenge
challenge = compute_challenge(group_commitment, randomized_group_public_key, msg)
# Compute aggregated signature
z = Scalar(0)
for z_i in sig_shares:
z = z + z_i
return (group_commitment, z + randomizer * challenge), randomized_group_public_key
The `verify_signature_share` is changed to incorporate the randomizer point,
as follows: ::
Inputs:
- identifier, identifier i of the participant, a NonZeroScalar.
- PK_i, the public key for the i-th participant, where PK_i = G.ScalarBaseMult(sk_i),
an Element.
- comm_i, pair of Element values in G (hiding_nonce_commitment, binding_nonce_commitment)
generated in round one from the i-th participant.
- sig_share_i, a Scalar value indicating the signature share as produced in
round two from the i-th participant.
- commitment_list =
[(j, hiding_nonce_commitment_j, binding_nonce_commitment_j), ...], a
list of commitments issued in Round 1 by each participant, where each element
in the list indicates a NonZeroScalar identifier j and two commitment
Element values (hiding_nonce_commitment_j, binding_nonce_commitment_j).
This list MUST be sorted in ascending order by identifier.
- group_public_key, public key corresponding to the group signing key,
an Element.
- msg, the message to be signed, a byte string.
- randomizer_commitment, an element in G.
Outputs:
- True if the signature share is valid, and False otherwise.
def verify_signature_share(identifier, PK_i, comm_i, sig_share_i, commitment_list,
group_public_key, msg, randomizer_commitment):
# Compute the randomized group public key
randomized_group_public_key = group_public_key + randomizer_commitment
# Compute the binding factors
binding_factor_list = compute_binding_factors(commitment_list, msg, randomizer_commitment)
binding_factor = binding_factor_for_participant(binding_factor_list, identifier)
# Compute the group commitment
group_commitment = compute_group_commitment(commitment_list, binding_factor_list)
# Compute the commitment share
(hiding_nonce_commitment, binding_nonce_commitment) = comm_i
comm_share = hiding_nonce_commitment + G.ScalarMult(binding_nonce_commitment, binding_factor)
# Compute the challenge
challenge = compute_challenge(group_commitment, randomized_group_public_key, msg)
# Compute the interpolating value
participant_list = participants_from_commitment_list(commitment_list)
lambda_i = derive_interpolating_value(identifier, participant_list)
# Compute relation values
l = G.ScalarBaseMult(sig_share_i)
r = comm_share + G.ScalarMult(PK_i, challenge * lambda_i)
return l == r
- ``PK_i = PK_i + G.ScalarBaseMult(randomizer)``
- ``group_public_key = group_public_key + G.ScalarBaseMult(randomizer)``
@ -384,17 +232,17 @@ Ciphersuites
FROST(Jubjub, BLAKE2b-512)
''''''''''''''''''''''''''
This ciphersuite uses Jubjub for the Group and BLAKE2b-512 for the Hash function `H`
This ciphersuite uses Jubjub for the Group and BLAKE2b-512 for the Hash function ``H``
meant to produce signatures indistinguishable from RedJubjub Sapling Spend
Authorization Signatures as specified in [#protocol-concretespendauthsig]_.
- Group: Jubjub [#protocol-jubjub]_ with base point :math:``\mathcal{G}^{\mathsf{Sapling}}`
- Group: Jubjub [#protocol-jubjub]_ with base point :math:`\mathcal{G}^{\mathsf{Sapling}}`
as defined in [#protocol-concretespendauthsig]_.
- Order: :math:`r_\mathbb{J}` as defined in [#protocol-jubjub]_.
- Identity: as defined in [#protocol-jubjub]_.
- RandomScalar(): Implemented by returning a uniformly random Scalar in the range
\[0, `G.Order()` - 1\]. Refer to {{frost-randomscalar}} for implementation guidance.
\[0, ``G.Order()`` - 1\]. Refer to {{frost-randomscalar}} for implementation guidance.
- SerializeElement(P): Implemented as :math:`\mathsf{repr}_\mathbb{J}(P)` as defined in [#protocol-jubjub]_
- DeserializeElement(P): Implemented as :math:`\mathsf{abst}_\mathbb{J}(P)` as defined in [#protocol-jubjub]_,
returning an error if :math:`\bot` is returned. Additionally, this function
@ -404,22 +252,22 @@ Authorization Signatures as specified in [#protocol-concretespendauthsig]_.
of the Scalar value.
- DeserializeScalar: Implemented by attempting to deserialize a Scalar from a
little-endian 32-byte string. This function can fail if the input does not
represent a Scalar in the range \[0, `G.Order()` - 1\].
represent a Scalar in the range \[0, ``G.Order()`` - 1\].
- Hash (`H`): BLAKE2b-512 [#BLAKE]_ (BLAKE2b with 512-bit output and 16-byte personalization string),
- Hash (``H``): BLAKE2b-512 [#BLAKE]_ (BLAKE2b with 512-bit output and 16-byte personalization string),
and Nh = 64.
- H1(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubR", m), interpreting
the 64 bytes as a little-endian integer, and reducing the resulting integer
modulo `G.Order()`.
modulo ``G.Order()``.
- H2(m): Implemented by computing BLAKE2b-512("Zcash_RedJubjubH", m), interpreting
the 64 bytes as a little-endian integer, and reducing the resulting integer
modulo `G.Order()`.
modulo ``G.Order()``.
(This is equivalent to :math:`\mathsf{H}^\circledast(m)`, as defined by
the :math:`\mathsf{RedJubjub}` scheme instantiated in [#protocol-concretereddsa]_.)
- H3(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubN", m), interpreting
the 64 bytes as a little-endian integer, and reducing the resulting integer
modulo `G.Order()`.
modulo ``G.Order()``.
- H4(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubM", m).
- H5(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubC", m).
@ -430,17 +278,17 @@ for RedJubjub.
FROST(Pallas, BLAKE2b-512)
''''''''''''''''''''''''''
This ciphersuite uses Pallas for the Group and BLAKE2b-512 for the Hash function `H`
This ciphersuite uses Pallas for the Group and BLAKE2b-512 for the Hash function ``H``
meant to produce signatures indistinguishable from RedPallas Orchard Spend
Authorization Signatures as specified in [#protocol-concretespendauthsig]_.
- Group: Pallas [#protocol-pallasandvesta]_ with base point :math:``\mathcal{G}^{\mathsf{Orchard}}`
- Group: Pallas [#protocol-pallasandvesta]_ with base point :math:`\mathcal{G}^{\mathsf{Orchard}}`
as defined in [#protocol-concretespendauthsig]_.
- Order: :math:`r_\mathbb{P}` as defined in [#protocol-pallasandvesta]_.
- Identity: as defined in [#protocol-pallasandvesta]_.
- RandomScalar(): Implemented by returning a uniformly random Scalar in the range
\[0, `G.Order()` - 1\]. Refer to {{frost-randomscalar}} for implementation guidance.
\[0, ``G.Order()`` - 1\]. Refer to {{frost-randomscalar}} for implementation guidance.
- SerializeElement(P): Implemented as :math:`\mathsf{repr}_\mathbb{P}(P)` as defined in [#protocol-pallasandvesta]_.
- DeserializeElement(P): Implemented as :math:`\mathsf{abst}_\mathbb{P}(P)` as defined in [#protocol-pallasandvesta]_,
failing if :math:`\bot` is returned. Additionally, this function validates that the resulting
@ -449,22 +297,22 @@ Authorization Signatures as specified in [#protocol-concretespendauthsig]_.
of the Scalar value.
- DeserializeScalar: Implemented by attempting to deserialize a Scalar from a
little-endian 32-byte string. This function can fail if the input does not
represent a Scalar in the range \[0, `G.Order()` - 1\].
represent a Scalar in the range \[0, ``G.Order()`` - 1\].
- Hash (`H`): BLAKE2b-512 [#BLAKE]_ (BLAKE2b with 512-bit output and 16-byte personalization string),
- Hash (``H``): BLAKE2b-512 [#BLAKE]_ (BLAKE2b with 512-bit output and 16-byte personalization string),
and Nh = 64.
- H1(m): Implemented by computing BLAKE2b-512("FROST_RedPallasR", m), interpreting
the 64 bytes as a little-endian integer, and reducing the resulting integer
modulo `G.Order()`.
modulo ``G.Order()``.
- H2(m): Implemented by computing BLAKE2b-512("Zcash_RedPallasH", m), interpreting
the 64 bytes as a little-endian integer, and reducing the resulting integer
modulo `G.Order()`.
modulo ``G.Order()``.
(This is equivalent to :math:`\mathsf{H}^\circledast(m)`, as defined by
the :math:`\mathsf{RedPallas}` scheme instantiated in [#protocol-concretereddsa]_.)
- H3(m): Implemented by computing BLAKE2b-512("FROST_RedPallasN", m), interpreting
the 64 bytes as a little-endian integer, and reducing the resulting integer
modulo `G.Order()`.
modulo ``G.Order()``.
- H4(m): Implemented by computing BLAKE2b-512("FROST_RedPallasM", m).
- H5(m): Implemented by computing BLAKE2b-512("FROST_RedPallasC", m).
@ -487,6 +335,7 @@ by the :math:`\mathsf{RedDSA.Validate}` function specified in
:math:`\mathsf{RedDSA.Validate}`, must yield the values expected by the
function. This is ensured by defining SerializeElement and SerializeScalar in
each ciphersuite to yield those values.
- The challenge c used during FROST signing must be equal to the challenge c
computed during :math:`\mathsf{RedDSA.Validate}`. This requires defining the
ciphersuite H2 function as the :math:`\mathsf{H}^\circledast(m)` Zcash
@ -494,13 +343,14 @@ by the :math:`\mathsf{RedDSA.Validate}` function specified in
Fortunately FROST and Zcash use the same input order (R, public key, message)
so we just need to make sure that SerializeElement (used to compute the
encoded public key before passing to the hash function) matches what
:math:`\mathsf{RedDSA.Validate}` expects; which is possible since both
:underline:`R` and :underline:`vk` (the public key) are encoded in the same
way in Zcash.
- Note that `r` (and thus `R`) will not be generated as specified in RedDSA.Sign.
:math:`\mathsf{RedDSA.Validate}` expects; which is possible since both `R` and
`vk` (the public key) are encoded in the same way in Zcash.
- Note that ``r`` (and thus ``R``) will not be generated as specified in RedDSA.Sign.
This is not an issue however, since with Schnorr signatures it does not matter
for the verifier how the `r` value was chosen, it just needs to be generated
for the verifier how the ``r`` value was chosen, it just needs to be generated
uniformly at random, which is true for FROST.
- The above will ensure that the verification equation in
:math:`\mathsf{RedDSA.Validate}` will pass, since FROST ensures the exact same
equation will be valid as described in [#frost-primeorderverify]_.
@ -512,19 +362,25 @@ signing generates a re-randomized signature:
This is exactly what is done in the functions defined above.
- The re-randomization must be done in each signature share generation, such
that the aggregated signature must be valid under verification with the
randomized public key. The `R` value from the signature is not influenced by
the randomizer so we just need to focus on the `z` value (using FROST
notation). Recall that `z` must equal to `r + (c * sk)`. FROST generates
signature shares so that when they are all add up to this value. Under
re-randomization it must be equal to `r + (c * (sk + randomizer))` (see
randomized public key. The ``R`` value from the signature is not influenced by
the randomizer so we just need to focus on the ``z`` value (using FROST
notation). Recall that ``z`` must equal to ``r + (c * sk)``, and that each
signature share is ``z_i = (hiding_nonce + (binding_nonce * binding_factor)) +
(lambda_i * c * sk_i)``. The first terms are not influenced by the randomizer
so we can only look into the second term of each top-level addition, i.e. ``c
* sk`` must be equal to ``sum(lambda_i * c * sk_i)`` for each participant
``i``. Under re-randomization these become ``c * (sk + randomizer)`` (see
:math:`\mathsf{RedDSA.RandomizedPrivate}`, which refers to the randomizer as
:math:`\alpha`). This can be rewritten as `r + (c * sk) + (c * randomizer)`.
In other words, we can simply generate the signature shares using the original
FROST procedure, and then add `(c * randomizer)` to `z` in the aggregate step.
:math:`\alpha`) and ``sum(lambda_i * c * (sk_i + randomizer))``. The latter
can be rewritten as ``c * (sum(lambda_i * sk_i) + randomizer *
sum(lambda_i)``. Since ``sum(lambda_i * sk_i) == sk`` per the Shamir secret
sharing mechanism used by FROST, and since ``sum(lambda_i) == 1``
[#sum-lambda-proof]_, we arrive at ``c * (sk + randomizer)`` as required.
- The re-randomization procedure must be exactly the same as in
[#protocol-concretereddsa]_ to ensure that re-randomized keys are uniformly
distributed and signatures are unlinkable. This is also true; observe that
`randomizer_generate` is exactly the same as
``randomizer_generate`` is exactly the same as
:math:`\mathsf{RedDSA.GenRandom}`; and signature generation is compatible with
:math:`\mathsf{RedDSA.RandomizedPrivate}`,
:math:`\mathsf{RedDSA.RandomizedPublic}`, :math:`\mathsf{RedDSA.Sign}` and
@ -542,15 +398,16 @@ References
.. [#BLAKE] `BLAKE2: simpler, smaller, fast as MD5 <https://blake2.net/#sp>`_
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
.. [#FROST] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST <https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-08.html>`_
.. [#frost-protocol] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Section 5: Two-Round FROST Signing Protocol <https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-08.html#section-5>`_
.. [#frost-removingcoordinator] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Section 7.3: Removing the Coordinator Role <https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-08.html#section-7.3>`_
.. [#frost-primeordergroup] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Section 3.1: Prime-Order Group <https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-08.html#section-3.1>`_
.. [#frost-primeorderverify] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Appendix B: Schnorr Signature Generation and Verification for Prime-Order Groups <https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-11.html#appendix-B>`_
.. [#frost-tdkg] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Appendix B: Trusted Dealer Key Generation <https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-08.html#appendix-B>`_
.. [#frost-randomscalar] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Appendix C: Random Scalar Generation <https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-08.html#appendix-C>`_
.. [#protocol-concretereddsa] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7: RedDSA, RedJubjub, and RedPallas <https://protocol/protocol.pdf#concretereddsa>`_
.. [#FROST] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST <https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-14.html>`_
.. [#frost-protocol] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Section 5: Two-Round FROST Signing Protocol <https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-14.html#name-two-round-frost-signing-pro>`_
.. [#frost-removingcoordinator] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Section 7.3: Removing the Coordinator Role <https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-14.html#name-removing-the-coordinator-ro>`_
.. [#frost-primeordergroup] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Section 3.1: Prime-Order Group <https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-14.html#name-prime-order-group>`_
.. [#frost-primeorderverify] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Appendix B: Schnorr Signature Generation and Verification for Prime-Order Groups <https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-11.html#name-schnorr-signature-generatio>`_
.. [#frost-tdkg] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Appendix B: Trusted Dealer Key Generation <https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-14.html#name-trusted-dealer-key-generati>`_
.. [#frost-randomscalar] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Appendix C: Random Scalar Generation <https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-14.html#name-random-scalar-generation>`_
.. [#protocol-concretereddsa] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7: RedDSA, RedJubjub, and RedPallas <protocol/protocol.pdf#concretereddsa>`_
.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7.1: Spend Authorization Signature (Sapling and Orchard) <protocol/protocol.pdf#concretespendauthsig>`_
.. [#protocol-spendauthsig] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 4.15: Spend Authorization Signature (Sapling and Orchard) <protocol/protocol.pdf#spendauthsig>`_
.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.3: Jubjub <protocol/protocol.pdf#jubjub>`_
.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.6: Pallas and Vesta <https://protocol/protocol.pdf#pallasandvesta>`_
.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.6: Pallas and Vesta <protocol/protocol.pdf#pallasandvesta>`_
.. [#sum-lambda-proof] `Prove that the sum of the Lagrange (interpolation) coefficients is equal to 1 <https://math.stackexchange.com/questions/1325292/prove-that-the-sum-of-the-lagrange-interpolation-coefficients-is-equal-to-1/1325342#1325342>`_