From 86feb4ebe5417bd8e1de85dee493adef0163e867 Mon Sep 17 00:00:00 2001
From: Conrado Gouvea
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.
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).
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.
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)
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:
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.
G.Order()
- 1]. Refer to {{frost-randomscalar}} for implementation guidance.G.Order()
- 1].H
): BLAKE2b-512 1 (BLAKE2b with 512-bit output and 16-byte personalization string), and Nh = 64.
+ H
): BLAKE2b-512 1 (BLAKE2b with 512-bit output and 16-byte personalization string), and Nh = 64.
G.Order()
.G.Order()
. (This is equivalent to
\(\mathsf{H}^\circledast(m)\)
, as defined by the
\(\mathsf{RedJubjub}\)
- scheme instantiated in 12.)G.Order()
.Signature verification is as specified in 13 for RedJubjub.
+Signature verification is as specified in 13 for RedJubjub.
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.
G.Order()
- 1]. Refer to {{frost-randomscalar}} for implementation guidance.G.Order()
- 1].H
): BLAKE2b-512 1 (BLAKE2b with 512-bit output and 16-byte personalization string), and Nh = 64.
+ H
): BLAKE2b-512 1 (BLAKE2b with 512-bit output and 16-byte personalization string), and Nh = 64.
G.Order()
.G.Order()
. (This is equivalent to
\(\mathsf{H}^\circledast(m)\)
, as defined by the
\(\mathsf{RedPallas}\)
- scheme instantiated in 12.)G.Order()
.Signature verification is as specified in 13 for RedPallas.
+Signature verification is as specified in 13 for RedPallas.
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: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 second step is adding the re-randomization functionality so that each FROST signing generates a re-randomized signature:
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
18, we arrive at c * (sk + randomizer)
as required.
- 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
21, we arrive at c * (sk + randomizer)
as required.randomizer_generate
generates randomizer uniformly at random as required by
\(\mathsf{RedDSA.GenRandom}\)
; and signature generation is compatible with
\(\mathsf{RedDSA.RandomizedPrivate}\)
@@ -269,10 +309,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.
+The security of Re-Randomized FROST with respect to the security assumptions of regular FROST is shown in 4.
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.
17 | +Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 3.1: Payment Addresses and Keys | +
---|
18 | +Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 4.2.2: Sapling Key Components | +
---|
19 | +Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 4.2.3: Orchard Key Components | +
---|
20 | reddsa |
---|
18 | +21 | Prove that the sum of the Lagrange (interpolation) coefficients is equal to 1 |
---|