From 8836e22610c4575b7c46f8a31e3819de1ac7efbf Mon Sep 17 00:00:00 2001 From: Conrado Gouvea Date: Mon, 16 Jan 2023 19:20:31 -0300 Subject: [PATCH] add initial Rationale section --- zip-0312.rst | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) diff --git a/zip-0312.rst b/zip-0312.rst index 66663400..61bc25a9 100644 --- a/zip-0312.rst +++ b/zip-0312.rst @@ -372,6 +372,8 @@ as follows: :: + + Ciphersuites ------------ @@ -465,6 +467,66 @@ Authorization Signatures as specified in [#protocol-concretespendauthsig]_. Signature verification is as specified in [#protocol-concretespendauthsig]_ 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 :math:`\mathsf{RedDSA.Validate}` function specified in +[#protocol-concretereddsa]_: + +- The FROST signature, when split into R and S in the first step of + :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 + 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 + :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. + 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 + :math:`\mathsf{RedDSA.Validate}` will pass, since FROST ensures the exact same + equation will be valid as described in [#frost-primeorderverify]_. + +The second step is adding the re-randomization functionality so that each FROST +signing generates a re-randomized signature: + +- 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. +- 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 + :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. +- 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 + :math:`\mathsf{RedDSA.GenRandom}`; and signature generation is compatible with + :math:`\mathsf{RedDSA.RandomizedPrivate}`, + :math:`\mathsf{RedDSA.RandomizedPublic}`, :math:`\mathsf{RedDSA.Sign}` and + :math:`\mathsf{RedDSA.Validate}` as explained in the previous item. + + Reference implementation ======================== @@ -480,6 +542,7 @@ References .. [#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 `_ .. [#protocol-concretereddsa] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7: RedDSA, RedJubjub, and RedPallas `_