mirror of https://github.com/zcash/zips.git
addressed comments from ZIP sync
This commit is contained in:
Conrado Gouvea
parent
665acefc63
commit
80a22f4010
|
|
@ -23,10 +23,9 @@ be interpreted as described in RFC 2119. [#RFC2119]_
|
|||
|
||||
The terms below are to be interpreted as follows:
|
||||
|
||||
{Term to be defined}
|
||||
{Definition.}
|
||||
{Another term}
|
||||
{Definition.}
|
||||
Unlinkability
|
||||
The impossibility of determining if two transactions were generated by the same
|
||||
party.
|
||||
|
||||
|
||||
Abstract
|
||||
|
|
@ -47,9 +46,9 @@ private key is what effectively allows the user to spend funds.
|
|||
|
||||
This is a security-critical step, since anyone who obtains access to the private
|
||||
key will be able to spend the user's funds. For this reason, one interesting
|
||||
possibility is to require multiple users to allow the transaction to go through.
|
||||
possibility is to require multiple parties to allow the transaction to go through.
|
||||
This can be accomplished with threshold signatures, where the private key is
|
||||
split between users in a way that a threshold (e.g. 2 out of 3) of them must
|
||||
split between parties in a way that a threshold (e.g. 2 out of 3) of them must
|
||||
sign the transaction in order to create the final signature. This enables scenarios
|
||||
such as users and exchanges sharing custody of a wallet, for example.
|
||||
|
||||
|
|
@ -81,13 +80,14 @@ shielded transaction:
|
|||
as an auxiliary (secret) input, among others.
|
||||
|
||||
When employing re-randomized FROST as specified in this ZIP, the goal is to
|
||||
split the spend authorization private key :math:`\mathsf{ask}` among multiple possible signers. This means
|
||||
that the proof generation will still be generated by a single participant, likely
|
||||
the one that created the transaction in the first place. Note that this user already controls the
|
||||
privacy of the transaction since they are responsible for creating the proof.
|
||||
split the spend authorization private key :math:`\mathsf{ask}` among multiple
|
||||
possible signers. This means that the proof generation will still be generated
|
||||
by a single participant, likely the one that created the transaction in the first
|
||||
place. Note that this user already controls the privacy of the transaction since
|
||||
they are responsible for creating the proof.
|
||||
|
||||
This fits well into the "Coordinator" role from the FROST specification. The
|
||||
Coordinator is responsible for sending the message to be signed to all participants,
|
||||
This fits well into the "Coordinator" role from the FROST specification [#frost-protocol]_.
|
||||
The Coordinator is responsible for sending the message to be signed to all participants,
|
||||
and to aggregate the signature shares.
|
||||
|
||||
With those considerations in mind, the threat model considered in this ZIP is:
|
||||
|
|
@ -104,19 +104,43 @@ With those considerations in mind, the threat model considered in this ZIP is:
|
|||
Non-requirements
|
||||
================
|
||||
|
||||
- This ZIP does not support removing the Coordinator role, as described in #[FROST]_.
|
||||
- This ZIP does not support removing the Coordinator role, as described in #[frost-removingcoordinator]_.
|
||||
- This ZIP does not prevent key share holders from linking the signing operation to a transaction in the blockchain.
|
||||
- Like the FROST specification [#FROST], this ZIP does not specify a key generation
|
||||
procedure; but refer to that specification for guidelines.
|
||||
- Network privacy is not in scope for this ZIP, and must be obtained with other
|
||||
tools if desired.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
Algorithms in this section are specified using Python pseudo-code, in the same
|
||||
fashion as the FROST specification [#FROST]_.
|
||||
|
||||
The types Scalar, Element, and G are defined in #[frost-primeordergroup]_, as well
|
||||
as the notation for elliptic-curve arithmetic, which uses the additive notation.
|
||||
|
||||
|
||||
Re-randomized FROST
|
||||
-------------------
|
||||
|
||||
To add re-randomization to FROST, follow the specification [#FROST]_ with the
|
||||
following modifications.
|
||||
|
||||
|
||||
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 guidance. The
|
||||
spend authorization private key :math:`\mathsf{ask}` [#protocol-spendauthsig]_
|
||||
is the particular key that must be used in the context of this ZIP. Note that
|
||||
while Sapling allows creating it directly, in Orchard it is always derived
|
||||
from the spending key :math:`\mathsf{ask}`. This means that a trusted
|
||||
dealer key generation process might be required as detailed in [#frost-tdkg]_.
|
||||
|
||||
|
||||
Randomizer Generation
|
||||
'''''''''''''''''''''
|
||||
|
||||
|
|
@ -157,6 +181,18 @@ as follows: ::
|
|||
return binding_factor
|
||||
|
||||
|
||||
Round One - Commitment
|
||||
''''''''''''''''''''''
|
||||
|
||||
Roune One is exactly the same as specified #[FROST]_. But for context, it
|
||||
involves these steps:
|
||||
|
||||
- Each signer generates nonces and their corresponding public commitments.
|
||||
A nonce is a pair of Scalar values, and a commitment is a pair of Element values.
|
||||
- The nonces are stored locally by the signer and kept private for use in the second round.
|
||||
- The commitments are sent to the Coordinator.
|
||||
|
||||
|
||||
Round Two - Signature Share Generation
|
||||
''''''''''''''''''''''''''''''''''''''
|
||||
|
||||
|
|
@ -278,7 +314,8 @@ The `aggregate` function is changed to incorporate the randomizer as follows: ::
|
|||
Inputs:
|
||||
- group_commitment, the group commitment returned by compute_group_commitment,
|
||||
an Element in G.
|
||||
- sig_shares, a set of signature shares z_i, Scalar values, for each signer,
|
||||
- sig_shares, a set of signature shares z_i, Scalar values, for each signer
|
||||
that participated in Round One,
|
||||
of length NUM_SIGNERS, where MIN_SIGNERS <= NUM_SIGNERS <= MAX_SIGNERS.
|
||||
- group_public_key, public key corresponding to the group signing key,
|
||||
- challenge, the challenge returned by compute_challenge, a Scalar.
|
||||
|
|
@ -315,12 +352,13 @@ Authorization Signatures as specified in [#protocol-concretespendauthsig]_.
|
|||
- RandomNonZeroScalar: Implemented by generating a random 32-byte string that
|
||||
is not equal to the all-zero string and invoking DeserializeScalar on the result.
|
||||
- SerializeElement(P): Implemented as :math:`\mathsf{repr}_\mathbb{J}(P)` as defined in [#protocol-jubjub]_
|
||||
- DeserializeElement(P): Implemented as :math:`\mathsf{abst}_\mathbb{J}(P)` as defined in [#protocol-jubjub]_
|
||||
- DeserializeElement(P): Implemented as :math:`\mathsf{abst}_\mathbb{J}(P)` as defined in [#protocol-jubjub]_,
|
||||
failing if :math:`\bot` is returned.
|
||||
- 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
|
||||
between the value 0 and G.Order() - 1.
|
||||
in the range \[0, G.Order() - 1\].
|
||||
|
||||
- Hash (`H`): BLAKE2b-512 [#BLAKE]_ (BLAKE2b with 512-bit output and 16-byte personalization string),
|
||||
and Nh = 64.
|
||||
|
|
@ -355,12 +393,13 @@ Authorization Signatures as specified in [#protocol-concretespendauthsig]_.
|
|||
- RandomNonZeroScalar: Implemented by generating a random 32-byte string that
|
||||
is not equal to the all-zero string and invoking DeserializeScalar on the result.
|
||||
- SerializeElement(P): Implemented as :math:`\mathsf{repr}_\mathbb{P}(P)` as defined in [#protocol-pallasandvesta]_
|
||||
- DeserializeElement(P): Implemented as :math:`\mathsf{abst}_\mathbb{P}(P)` as defined in [#protocol-pallasandvesta]_
|
||||
- DeserializeElement(P): Implemented as :math:`\mathsf{abst}_\mathbb{P}(P)` as defined in [#protocol-pallasandvesta]_,
|
||||
failing if :math:`\bot` is returned.
|
||||
- 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
|
||||
between the value 0 and G.Order() - 1.
|
||||
in the range \[0, G.Order() - 1\].
|
||||
|
||||
- Hash (`H`): BLAKE2b-512 [#BLAKE]_ (BLAKE2b with 512-bit output and 16-byte personalization string),
|
||||
and Nh = 64.
|
||||
|
|
@ -391,7 +430,12 @@ References
|
|||
.. [#BLAKE] `BLAKE2: simpler, smaller, fast as MD5 <https://blake2.net/#sp>`_
|
||||
.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <https://www.rfc-editor.org/rfc/rfc2119.html>`_
|
||||
.. [#FROST] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST <https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-05.html>`_
|
||||
.. [#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-05.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-05.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-05.html#section-3.1>`_
|
||||
.. [#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-05.html#appendix-B>`_
|
||||
.. [#protocol-concretereddsa] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7: RedDSA, RedJubjub, and RedPallas <https://protocol/protocol.pdf#concretereddsa>`_
|
||||
.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7.1: Spend Authorization Signature (Sapling and Orchard) <protocol/protocol.pdf#concretespendauthsig>`_
|
||||
.. [#protocol-spendauthsig] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 4.15: Spend Authorization Signature (Sapling and Orchard) <protocol/protocol.pdf#spendauthsig>`_
|
||||
.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.3: Jubjub <protocol/protocol.pdf#jubjub>`_
|
||||
.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.6: Pallas and Vesta <https://protocol/protocol.pdf#pallasandvesta>`_
|
||||
|
|
|
|||
Loading…
Reference in New Issue