From 6e6893d8323103013163586eb7e3c53e929a14b4 Mon Sep 17 00:00:00 2001 From: Conrado Gouvea Date: Fri, 19 Jul 2024 21:54:01 -0300 Subject: [PATCH] address comment, update spec ref, add paper ref --- README.rst | 4 +- rendered/index.html | 4 +- rendered/zip-0312.html | 153 ++++++++++++++++++++++------------------- zips/zip-0312.rst | 40 ++++++----- 4 files changed, 106 insertions(+), 95 deletions(-) diff --git a/README.rst b/README.rst index b6600f8e..2725e4e5 100644 --- a/README.rst +++ b/README.rst @@ -135,7 +135,7 @@ written. 309 Blind Off-chain Lightweight Transactions (BOLT) Reserved 310 Security Properties of Sapling Viewing Keys Draft 311 Zcash Payment Disclosures Draft - 312 Shielded Multisignatures using FROST Reserved + 312 FROST for Spend Authorization Multisignatures Draft 314 Privacy upgrades to the Zcash light client protocol Reserved 315 Best Practices for Wallet Implementations Draft 318 Associated Payload Encryption Reserved @@ -267,7 +267,7 @@ Index of ZIPs 309 Blind Off-chain Lightweight Transactions (BOLT) Reserved 310 Security Properties of Sapling Viewing Keys Draft 311 Zcash Payment Disclosures Draft - 312 Shielded Multisignatures using FROST Reserved + 312 FROST for Spend Authorization Multisignatures Draft 313 Reduce Conventional Transaction Fee to 1000 zatoshis Obsolete 314 Privacy upgrades to the Zcash light client protocol Reserved 315 Best Practices for Wallet Implementations Draft diff --git a/rendered/index.html b/rendered/index.html index 2744c6d5..dfdadc94 100644 --- a/rendered/index.html +++ b/rendered/index.html @@ -100,7 +100,7 @@ 309 Blind Off-chain Lightweight Transactions (BOLT) Reserved 310 Security Properties of Sapling Viewing Keys Draft 311 Zcash Payment Disclosures Draft - 312 Shielded Multisignatures using FROST Reserved + 312 FROST for Spend Authorization Multisignatures Draft 314 Privacy upgrades to the Zcash light client protocol Reserved 315 Best Practices for Wallet Implementations Draft 318 Associated Payload Encryption Reserved @@ -213,7 +213,7 @@ 309 Blind Off-chain Lightweight Transactions (BOLT) Reserved 310 Security Properties of Sapling Viewing Keys Draft 311 Zcash Payment Disclosures Draft - 312 Shielded Multisignatures using FROST Reserved + 312 FROST for Spend Authorization Multisignatures Draft 313 Reduce Conventional Transaction Fee to 1000 zatoshis Obsolete 314 Privacy upgrades to the Zcash light client protocol Reserved 315 Best Practices for Wallet Implementations Draft diff --git a/rendered/zip-0312.html b/rendered/zip-0312.html index 4c0dbd3e..f69ad06e 100644 --- a/rendered/zip-0312.html +++ b/rendered/zip-0312.html @@ -19,7 +19,7 @@ License: MIT Discussions-To: <https://github.com/zcash/zips/issues/382> Pull-Request: <https://github.com/zcash/zips/pull/662>

Terminology

-

{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. 2

+

{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. 2

The terms below are to be interpreted as follows:

Unlinkability
@@ -27,17 +27,17 @@ Pull-Request: <https://githu

Abstract

-

This proposal adapts FROST 3, 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 shielded pools.

+

This proposal adapts FROST 3, 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 Sapling and Orchard shielded protocols as deployed in Zcash.

Motivation

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.

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 (or generated already split using a distributed protocol) 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 third-party services sharing custody of a wallet, or a group of people managing shared funds, for example.

-

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.

+

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. This variant is named "Re-Randomized FROST" and has been described in 4.

Requirements

Threat Model

@@ -50,7 +50,7 @@ Pull-Request: <https://githu

When employing re-randomizable FROST as specified in this ZIP, the goal is to split the spend authorization private key \(\mathsf{ask}\) 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.

-

This fits well into the "Coordinator" role from the FROST specification 4. The Coordinator is responsible for sending the message to be signed to all participants, and to aggregate the signature shares.

+

This fits well into the "Coordinator" role from the FROST specification 5. The Coordinator is responsible for sending the message to be signed to all participants, and to aggregate the signature shares.

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_PARTICIPANTS participants, as specified in FROST.
    • @@ -60,38 +60,38 @@ Pull-Request: <https://githu

Non-requirements

    -
  • This ZIP does not support removing the Coordinator role, as described in 5.
    • +
  • This ZIP does not support removing the Coordinator role, as described in 6.
  • This ZIP does not prevent key share holders from linking the signing operation to a transaction in the blockchain.
    • -
  • Like the FROST specification 3, this ZIP does not specify a key generation procedure; but refer to that specification for guidelines.
    • +
  • Like the FROST specification 3, 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.

Specification

-

Algorithms in this section are specified using Python pseudo-code, in the same fashion as the FROST specification 3.

-

The types Scalar, Element, and G are defined in 6, 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 multiplication, where the protocol spec would use +

Algorithms in this section are specified using Python pseudo-code, in the same fashion as the FROST specification 3.

+

The types Scalar, Element, and G are defined in 7, 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 multiplication, where the protocol spec would use \([k] P\) with the group implied by \(P\) .

An additional per-ciphersuite hash function is used, denote HR(m), which receives an arbitrary-sized byte string and returns a Scalar. It is defined concretely in the Ciphersuites section.

+

Key Generation

+

While key generation is out of scope for this ZIP and the FROST spec 3, it needs to be consistent with FROST, see 9 for guidance. The spend authorization private key + \(\mathsf{ask}\) + 14 is the particular key that must be used in the context of this ZIP. Note that the + \(\mathsf{ask}\) + is usually derived from the spending key + \(\mathsf{sk}\) + , though that is not required. Not doing so allows using distributed key generation, since the key it generates is unpredictable. Note however that not deriving + \(\mathsf{ask}\) + from + \(\mathsf{sk}\) + prevents using seed phrases to recover the original secret (which may be something desirable in the context of FROST).

+

Re-randomizable FROST

-

To add re-randomization to FROST, follow the specification 3 with the following modifications.

-

Key Generation

-

While key generation is out of scope for this ZIP and the FROST spec 3, it needs to be consistent with FROST, see 8 for guidance. The spend authorization private key - \(\mathsf{ask}\) - 13 is the particular key that must be used in the context of this ZIP. Note that the - \(\mathsf{ask}\) - is usually derived from the spending key - \(\mathsf{sk}\) - , though that is not required. Not doing so allows using distributed key generation, since the key it generates is unpredictable. Note however that not deriving - \(\mathsf{ask}\) - from - \(\mathsf{sk}\) - prevents using seed phrases to recover the original secret (which may be something desirable in the context of FROST).

-
+

To add re-randomization to FROST, follow the specification 3 with the following modifications.

Randomizer Generation

-

A new helper function is defined, which generates a randomizer. The encode_signing_package is defined as the byte serialization of the msg, commitment_list values as described in 10. Implementations MAY choose another encoding as long as all values (the message, and the identifier, binding nonce and hiding nonce for each participant) are unambiguously encoded.

-

The function random_bytes(n) is defined in 3 and it returns a buffer with n bytes sampled uniformly at random. The constant Ns is also specified in 3 and is the size of a serialized scalar.

+

A new helper function is defined, which generates a randomizer. The encode_signing_package is defined as the byte serialization of the msg, commitment_list values as described in 11. Implementations MAY choose another encoding as long as all values (the message, and the identifier, binding nonce and hiding nonce for each participant) are unambiguously encoded.

+

The function random_bytes(n) is defined in 3 and it returns a buffer with n bytes sampled uniformly at random. The constant Ns is also specified in 3 and is the size of a serialized scalar.

randomizer_generate():
 
 Inputs:
@@ -113,7 +113,7 @@ def randomizer_generate(msg, commitment_list):
   return HR(randomizer_input)

Round One - Commitment

-

Roune One is exactly the same as specified 3. But for context, it involves these steps:

+

Roune One is exactly the same as specified 3. But for context, it involves these steps:

  • 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.
  • The nonces are stored locally by the signer and kept private for use in the second round.
    • @@ -143,37 +143,37 @@ def randomizer_generate(msg, commitment_list):

Ciphersuites

FROST(Jubjub, BLAKE2b-512)

-

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 12.

+

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 13.

    -
  • Group: Jubjub 14 with base point +
  • Group: Jubjub 15 with base point \(\mathcal{G}^{\mathsf{Sapling}}\) - as defined in 12. + as defined in 13.
    • Order: \(r_\mathbb{J}\) - as defined in 14.
      • -
    • Identity: as defined in 14.
      • + as defined in 15. +
    • Identity: as defined in 15.
    • RandomScalar(): Implemented by returning a uniformly random Scalar in the range [0, G.Order() - 1]. Refer to {{frost-randomscalar}} for implementation guidance.
    • SerializeElement(P): Implemented as \(\mathsf{repr}_\mathbb{J}(P)\) - as defined in 14
      • + as defined in 15
    • DeserializeElement(P): Implemented as \(\mathsf{abst}_\mathbb{J}(P)\) - as defined in 14, returning an error if + as defined in 15, returning an error if \(\bot\) is returned. Additionally, this function validates that the resulting element is not the group identity element, returning an error if the check fails.
    • SerializeScalar: Implemented by outputting the little-endian 32-byte encoding 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].
    • -
  • Hash (H): BLAKE2b-512 1 (BLAKE2b with 512-bit output and 16-byte personalization string), and Nh = 64. +
  • Hash (H): BLAKE2b-512 1 (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().
    • 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(). (This is equivalent to \(\mathsf{H}^\circledast(m)\) , as defined by the \(\mathsf{RedJubjub}\) - scheme instantiated in 11.)
      • + scheme instantiated in 12.)
    • 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().
    • H4(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubM", m).
    • H5(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubC", m).
      • @@ -181,40 +181,40 @@ def randomizer_generate(msg, commitment_list):
-

Signature verification is as specified in 12 for RedJubjub.

+

Signature verification is as specified in 13 for RedJubjub.

FROST(Pallas, BLAKE2b-512)

-

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 12.

+

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 13.

    -
  • Group: Pallas 15 with base point +
  • Group: Pallas 16 with base point \(\mathcal{G}^{\mathsf{Orchard}}\) - as defined in 12. + as defined in 13.
    • Order: \(r_\mathbb{P}\) - as defined in 15.
      • -
    • Identity: as defined in 15.
      • + as defined in 16. +
    • Identity: as defined in 16.
    • RandomScalar(): Implemented by returning a uniformly random Scalar in the range [0, G.Order() - 1]. Refer to {{frost-randomscalar}} for implementation guidance.
    • SerializeElement(P): Implemented as \(\mathsf{repr}_\mathbb{P}(P)\) - as defined in 15.
      • + as defined in 16.
    • DeserializeElement(P): Implemented as \(\mathsf{abst}_\mathbb{P}(P)\) - as defined in 15, failing if + as defined in 16, failing if \(\bot\) is returned. Additionally, this function validates that the resulting element is not the group identity element, returning an error if the check fails.
    • SerializeScalar: Implemented by outputting the little-endian 32-byte encoding 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].
    • -
  • Hash (H): BLAKE2b-512 1 (BLAKE2b with 512-bit output and 16-byte personalization string), and Nh = 64. +
  • Hash (H): BLAKE2b-512 1 (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().
    • 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(). (This is equivalent to \(\mathsf{H}^\circledast(m)\) , as defined by the \(\mathsf{RedPallas}\) - scheme instantiated in 11.)
      • + scheme instantiated in 12.)
    • 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().
    • H4(m): Implemented by computing BLAKE2b-512("FROST_RedPallasM", m).
    • H5(m): Implemented by computing BLAKE2b-512("FROST_RedPallasC", m).
      • @@ -222,14 +222,14 @@ def randomizer_generate(msg, commitment_list):
-

Signature verification is as specified in 12 for RedPallas.

+

Signature verification is as specified in 13 for RedPallas.

Rationale

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 \(\mathsf{RedDSA.Validate}\) - function specified in 11:

+ function specified in 12:

  • The FROST signature, when split into R and S in the first step of \(\mathsf{RedDSA.Validate}\) @@ -244,7 +244,7 @@ def randomizer_generate(msg, commitment_list):
  • 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 uniformly at random, which is true for FROST.
  • The above will ensure that the verification equation in \(\mathsf{RedDSA.Validate}\) - will pass, since FROST ensures the exact same equation will be valid as described in 7.
    • + will pass, since FROST ensures the exact same equation will be valid as described in 8.

The second step is adding the re-randomization functionality so that each FROST signing generates a re-randomized signature:

    @@ -256,8 +256,8 @@ def randomizer_generate(msg, commitment_list): , which refers to the randomizer as \(\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 17, we arrive at c * (sk + randomizer) as required. -
  • The re-randomization procedure must be exactly the same as in 11 to ensure that re-randomized keys are uniformly distributed and signatures are unlinkable. This is also true; observe that randomizer_generate generates randomizer uniformly at random as required by +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 18, we arrive at c * (sk + randomizer) as required.
    • +
  • The re-randomization procedure must be exactly the same as in 12 to ensure that re-randomized keys are uniformly distributed and signatures are unlinkable. This is also true; observe that randomizer_generate generates randomizer uniformly at random as required by \(\mathsf{RedDSA.GenRandom}\) ; and signature generation is compatible with \(\mathsf{RedDSA.RandomizedPrivate}\) @@ -269,9 +269,10 @@ sum(lambda_i). Since sum(lambda_i * sk_i) == sk per the Sham \(\mathsf{RedDSA.Validate}\) as explained in the previous item.
+

The security of Re-Randomized FROST with respect to the security assumptions of regular FROST is shown in 4.

Reference implementation

-

The reddsa crate 16 contains a re-randomized FROST implementation of both ciphersuites.

+

The reddsa crate 17 contains a re-randomized FROST implementation of both ciphersuites.

References

@@ -294,62 +295,70 @@ sum(lambda_i). Since sum(lambda_i * sk_i) == sk per the Sham - + + + +
3Draft RFC: Two-Round Threshold Schnorr Signatures with FROSTRFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures
+ + + + +
4Re-Randomized FROST
- - + +
4Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Section 5: Two-Round FROST Signing Protocol5RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Section 5: Two-Round FROST Signing Protocol
- - + +
5Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Section 7.3: Removing the Coordinator Role6RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Section 7.3: Removing the Coordinator Role
- - + +
6Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Section 3.1: Prime-Order Group7RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Section 3.1: Prime-Order Group
- - + +
7Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Appendix B: Schnorr Signature Generation and Verification for Prime-Order Groups8RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Appendix B: Schnorr Signature Generation and Verification for Prime-Order Groups
- - + +
8Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Appendix B: Trusted Dealer Key Generation9RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Appendix B: Trusted Dealer Key Generation
- - + +
9Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Appendix C: Random Scalar Generation10RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Appendix C: Random Scalar Generation
- + @@ -357,7 +366,7 @@ sum(lambda_i). Since sum(lambda_i * sk_i) == sk per the Sham
1011 The ZF FROST Book, Serialization Format
- + @@ -365,7 +374,7 @@ sum(lambda_i). Since sum(lambda_i * sk_i) == sk per the Sham
1112 Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7: RedDSA, RedJubjub, and RedPallas
- + @@ -373,7 +382,7 @@ sum(lambda_i). Since sum(lambda_i * sk_i) == sk per the Sham
1213 Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7.1: Spend Authorization Signature (Sapling and Orchard)
- + @@ -381,7 +390,7 @@ sum(lambda_i). Since sum(lambda_i * sk_i) == sk per the Sham
1314 Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 4.15: Spend Authorization Signature (Sapling and Orchard)
- + @@ -389,7 +398,7 @@ sum(lambda_i). Since sum(lambda_i * sk_i) == sk per the Sham
1415 Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.3: Jubjub
- + @@ -397,7 +406,7 @@ sum(lambda_i). Since sum(lambda_i * sk_i) == sk per the Sham
1516 Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.6: Pallas and Vesta
- + @@ -405,7 +414,7 @@ sum(lambda_i). Since sum(lambda_i * sk_i) == sk per the Sham
1617 reddsa
- + diff --git a/zips/zip-0312.rst b/zips/zip-0312.rst index df1531b3..0033cba5 100644 --- a/zips/zip-0312.rst +++ b/zips/zip-0312.rst @@ -59,7 +59,8 @@ people managing shared funds, for example. 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. +of FROST with re-randomization support. This variant is named "Re-Randomized +FROST" and has been described in [#frost-rerandomized]_. Requirements @@ -137,15 +138,8 @@ receives an arbitrary-sized byte string and returns a Scalar. It is defined concretely in the Ciphersuites section. -Re-randomizable FROST ---------------------- - -To add re-randomization to FROST, follow the specification [#FROST]_ with the -following modifications. - - Key Generation -'''''''''''''' +-------------- While key generation is out of scope for this ZIP and the FROST spec [#FROST]_, it needs to be consistent with FROST, see [#frost-tdkg]_ for guidance. The spend @@ -159,6 +153,13 @@ using seed phrases to recover the original secret (which may be something desirable in the context of FROST). +Re-randomizable FROST +--------------------- + +To add re-randomization to FROST, follow the specification [#FROST]_ with the +following modifications. + + Randomizer Generation ''''''''''''''''''''' @@ -252,9 +253,6 @@ to the ``randomizer`` as following: - ``group_public_key = group_public_key + G.ScalarBaseMult(randomizer)`` - - - Ciphersuites ------------ @@ -421,6 +419,9 @@ signing generates a re-randomized signature: :math:`\mathsf{RedDSA.RandomizedPublic}`, :math:`\mathsf{RedDSA.Sign}` and :math:`\mathsf{RedDSA.Validate}` as explained in the previous item. +The security of Re-Randomized FROST with respect to the security assumptions of +regular FROST is shown in [#frost-rerandomized]_. + Reference implementation ======================== @@ -434,13 +435,14 @@ References .. [#BLAKE] `BLAKE2: simpler, smaller, fast as MD5 `_ .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#FROST] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST `_ -.. [#frost-protocol] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Section 5: Two-Round FROST Signing Protocol `_ -.. [#frost-removingcoordinator] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Section 7.3: Removing the Coordinator Role `_ -.. [#frost-primeordergroup] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Section 3.1: 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 `_ -.. [#frost-tdkg] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Appendix B: Trusted Dealer Key Generation `_ -.. [#frost-randomscalar] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST. Appendix C: Random Scalar Generation `_ +.. [#FROST] `RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures `_ +.. [#frost-rerandomized] `Re-Randomized FROST `_ +.. [#frost-protocol] `RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Section 5: Two-Round FROST Signing Protocol `_ +.. [#frost-removingcoordinator] `RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Section 7.3: Removing the Coordinator Role `_ +.. [#frost-primeordergroup] `RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Section 3.1: Prime-Order Group `_ +.. [#frost-primeorderverify] `RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Appendix B: Schnorr Signature Generation and Verification for Prime-Order Groups `_ +.. [#frost-tdkg] `RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Appendix B: Trusted Dealer Key Generation `_ +.. [#frost-randomscalar] `RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. Appendix C: Random Scalar Generation `_ .. [#frost-serialization] `The ZF FROST Book, Serialization Format `_ .. [#protocol-concretereddsa] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7: RedDSA, RedJubjub, and RedPallas `_ .. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7.1: Spend Authorization Signature (Sapling and Orchard) `_
1718 Prove that the sum of the Lagrange (interpolation) coefficients is equal to 1