mirror of https://github.com/zcash/zips.git
add initial Rationale section
This commit is contained in:
parent
8fa30b0f44
commit
8836e22610
63
zip-0312.rst
63
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>`_
|
||||
|
|
Loading…
Reference in New Issue