add initial Rationale section

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 <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>`_