diff --git a/rendered/zip-0312.html b/rendered/zip-0312.html index f69ad06e..2d73165a 100644 --- a/rendered/zip-0312.html +++ b/rendered/zip-0312.html @@ -75,9 +75,49 @@ Pull-Request: <https://githu .

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 +

While FROST key generation is out of scope for this ZIP and the FROST spec 3, it needs to be consistent with FROST; see 9 for general guidance. This section assumes all participants have run either a trusted dealer or distributed key generation process, and each participant has their signing key share sk_i and the group public key PK. Trusted dealer key generation MAY be used; distributed key generation SHOULD be used.

+

To define a spending or viewing key that uses FROST, the Sapling and Orchard key trees 18 19 are adjusted as follows:

+ +

The remaining parts of the Sapling and Orchard key trees SHOULD be generated from a common spending key + \(\mathsf{sk}\) + as described in 18 19, with the exception of \(\mathsf{ask}\) - 14 is the particular key that must be used in the context of this ZIP. Note that the + which SHOULD NOT be derived from + \(\mathsf{sk}\) + (and can't possibly be derived, if distributed key generation was used). Deriving + \(\mathsf{ask}\) + from + \(\mathsf{sk}\) + MAY be done if the application requires to backup the unsplit key, but this is generally not recommended since it forces the usage of trusted dealer key generation.

+

In order for all participants to agree on the value of + \(\mathsf{sk}\) + , one of the following options SHOULD be carried out:

+ +

... (TODO: Finish specifying how the other common parts of the Sapling and Orchard key trees are derived for participants, perhaps in terms of a common + \(\mathsf{sk}\) + or a common HD path.)

+

(Old remaining content below, which might change after the above TODO.) Note that the \(\mathsf{ask}\) is usually derived from the spending key \(\mathsf{sk}\) @@ -88,10 +128,10 @@ Pull-Request: <https://githu 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.

+

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

+

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 +153,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:

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

+

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 15 with base point +
  • Group: Jubjub 15 with base point \(\mathcal{G}^{\mathsf{Sapling}}\) - as defined in 13. + as defined in 13.
    • Order: \(r_\mathbb{J}\) - as defined in 15.
      • -
    • Identity: as defined in 15.
      • + 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 15
      • + as defined in 15
    • DeserializeElement(P): Implemented as \(\mathsf{abst}_\mathbb{J}(P)\) - as defined in 15, 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 12.)
      • + 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 +221,40 @@ def randomizer_generate(msg, commitment_list):
-

Signature verification is as specified in 13 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 13.

+

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 16 with base point +
  • Group: Pallas 16 with base point \(\mathcal{G}^{\mathsf{Orchard}}\) - as defined in 13. + as defined in 13.
    • Order: \(r_\mathbb{P}\) - as defined in 16.
      • -
    • Identity: as defined in 16.
      • + 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 16.
      • + as defined in 16.
    • DeserializeElement(P): Implemented as \(\mathsf{abst}_\mathbb{P}(P)\) - as defined in 16, 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 12.)
      • + 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 +262,14 @@ def randomizer_generate(msg, commitment_list):
-

Signature verification is as specified in 13 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 12:

+ function specified in 12:

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

-

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

+

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

Reference implementation

-

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

+

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

References

@@ -403,10 +443,34 @@ sum(lambda_i). Since sum(lambda_i * sk_i) == sk per the Sham
- +
+ + + +
17Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 3.1: Payment Addresses and Keys
+ + + + + + + +
18Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 4.2.2: Sapling Key Components
+ + + + + + + +
19Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 4.2.3: Orchard Key Components
+ + + + @@ -414,7 +478,7 @@ sum(lambda_i). Since sum(lambda_i * sk_i) == sk per the Sham
20 reddsa
- + diff --git a/zips/zip-0312.rst b/zips/zip-0312.rst index f2b13eb1..7d4f4034 100644 --- a/zips/zip-0312.rst +++ b/zips/zip-0312.rst @@ -141,8 +141,12 @@ concretely in the Ciphersuites section. 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 general guidance. +While FROST 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 general +guidance. This section assumes all participants have run either a trusted dealer +or distributed key generation process, and each participant has their signing +key share `sk_i` and the group public key `PK`. Trusted dealer key generation +MAY be used; distributed key generation SHOULD be used. To define a spending or viewing key that uses FROST, the Sapling and Orchard key trees [#protocol-saplingkeycomponents]_ [#protocol-orchardkeycomponents]_ are @@ -151,14 +155,39 @@ adjusted as follows: - The Spend validating key :math:`\mathsf{ak}` is replaced by the FROST group public key `PK` [#frost-protocol]_. - The Spend authorizing key :math:`\mathsf{ask}` is replaced by the logical - signing key that corresponds to the group public key `PK`. By design, this - key is never explicitly constructed, and instead is represented by any - sufficient subset of the participant FROST signing key shares `sk_i`. + signing key that corresponds to the group public key `PK`. By design, this key + is never explicitly constructed (unless trusted dealer key generation was + used), and instead is represented by any sufficient subset of the participant + FROST signing key shares `sk_i`. -The remaining parts of the Sapling and Orchard key trees are generated from -a common... (TODO: Finish specifying how the other common parts of the -Sapling and Orchard key trees are derived for participants, perhaps in terms -of a common `sk` or a common HD path.) +The remaining parts of the Sapling and Orchard key trees SHOULD be generated +from a common spending key :math:`\mathsf{sk}` as described in +[#protocol-saplingkeycomponents]_ [#protocol-orchardkeycomponents]_, with the +exception of :math:`\mathsf{ask}` which SHOULD NOT be derived from +:math:`\mathsf{sk}` (and can't possibly be derived, if distributed key +generation was used). Deriving :math:`\mathsf{ask}` from :math:`\mathsf{sk}` MAY +be done if the application requires to backup the unsplit key, but this is +generally not recommended since it forces the usage of trusted dealer key +generation. + +In order for all participants to agree on the value of :math:`\mathsf{sk}`, one +of the following options SHOULD be carried out: + +- One participant generates a random :math:`\mathsf{sk}` and sends it to the + others via an encrypted and authenticated channel. This option SHOULD be used + if trusted dealer key generation was used, and the :math:`\mathsf{sk}` value + can be sent along with the FROST shares during key generation. This option MAY + be used if distributed key generation was used, if participants find it + acceptable to trust one participant to correctly generate :math:`\mathsf{sk}`. +- Participants generate a :math:`\mathsf{sk}` in distributed manner using TODO. + This option SHOULD be used if distributed key generation was used. +- (TODO: evaluate if it is secure) Participants derive :math:`\mathsf{sk}` from + the public keys of the particpants (`PK_i` in [#FROST]_) via (TODO: specify + mechanism to hash all PK_i and derive sk) + +... (TODO: Finish specifying how +the other common parts of the Sapling and Orchard key trees are derived for +participants, perhaps in terms of a common :math:`\mathsf{sk}` or a common HD path.) (Old remaining content below, which might change after the above TODO.) Note that the :math:`\mathsf{ask}` is usually derived from the spending key @@ -465,5 +494,8 @@ References .. [#protocol-spendauthsig] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 4.15: Spend Authorization Signature (Sapling and Orchard) `_ .. [#protocol-jubjub] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.3: Jubjub `_ .. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.6: Pallas and Vesta `_ +.. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 3.1: Payment Addresses and Keys `_ +.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 4.2.2: Sapling Key Components `_ +.. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 4.2.3: Orchard Key Components `_ .. [#crate-reddsa] `reddsa `_ .. [#sum-lambda-proof] `Prove that the sum of the Lagrange (interpolation) coefficients is equal to 1 `_
1821 Prove that the sum of the Lagrange (interpolation) coefficients is equal to 1