mirror of https://github.com/zcash/zips.git
Fixed threat model; cleaning up; added references
This commit is contained in:
parent
54dbd57d76
commit
3a96a2f75b
|
@ -41,14 +41,17 @@ signatures in the Zcash protocol, for the Sapling and Orchard network upgrades.
|
||||||
Motivation
|
Motivation
|
||||||
==========
|
==========
|
||||||
|
|
||||||
In the Zcash protocol, Spend Authorization Signatures are employed to effectively
|
In the Zcash protocol, Spend Authorization Signatures are employed to authorize
|
||||||
authorize a transaction. The ability to generate these signatures with the user's
|
a transaction. The ability to generate these signatures with the user's
|
||||||
private key is what effectively allows the user to spend funds.
|
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
|
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
|
key will be able to spend the user's funds. For this reason, one interesting
|
||||||
possibility is to require multiple entities to allow the transaction to go through.
|
possibility is to require multiple users to allow the transaction to go through.
|
||||||
This can be accomplished with threshold signatures, where... (TODO: explain)
|
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
|
||||||
|
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.
|
||||||
|
|
||||||
FROST is one of such threshold signatures protocols. However, it can't be used as-is
|
FROST is one of such threshold signatures protocols. However, it can't be used as-is
|
||||||
since the Zcash protocol also requires re-randomizing public and private keys
|
since the Zcash protocol also requires re-randomizing public and private keys
|
||||||
|
@ -62,7 +65,7 @@ Requirements
|
||||||
- All signatures generated by following this ZIP MUST be verified successfully
|
- All signatures generated by following this ZIP MUST be verified successfully
|
||||||
as Sapling or Orchard spend authorization signatures.
|
as Sapling or Orchard spend authorization signatures.
|
||||||
- The signatures generated by following this ZIP should meet the security criteria
|
- The signatures generated by following this ZIP should meet the security criteria
|
||||||
for Signature with Re-Randomizable Keys as specified in the Zcash protocol [#protocol]_
|
for Signature with Re-Randomizable Keys as specified in the Zcash protocol [#protocol-concretereddsa]_.
|
||||||
- Follow the threat model described below.
|
- Follow the threat model described below.
|
||||||
|
|
||||||
Threat Model
|
Threat Model
|
||||||
|
@ -79,7 +82,7 @@ shielded transaction:
|
||||||
|
|
||||||
When employing re-randomized FROST as specified in this ZIP, the goal is to
|
When employing re-randomized FROST as specified in this ZIP, the goal is to
|
||||||
split the spend authorization private key among multiple participants. This means
|
split the spend authorization private key among multiple participants. This means
|
||||||
that the proof generation will still be generated be a single participant, likely
|
that the proof generation will still be generated by a single participant, likely
|
||||||
the one that created the transaction in the first place and that will actually
|
the one that created the transaction in the first place and that will actually
|
||||||
submit the transaction to the network. Note that his user already controls the
|
submit the transaction to the network. Note that his user already controls the
|
||||||
privacy of the transaction since they are responsible for creating the proof.
|
privacy of the transaction since they are responsible for creating the proof.
|
||||||
|
@ -94,13 +97,17 @@ With those considerations in mind, the threat model considered in this ZIP is:
|
||||||
the unlinkability property). A rogue Coordinator will be able to break
|
the unlinkability property). A rogue Coordinator will be able to break
|
||||||
unlinkability and privacy, but should not be able to create signed transactions
|
unlinkability and privacy, but should not be able to create signed transactions
|
||||||
without the approval of `MIN_SIGNERS` participants, as specified in FROST.
|
without the approval of `MIN_SIGNERS` participants, as specified in FROST.
|
||||||
|
- All key share holders are also trusted with the privacy of the transaction.
|
||||||
|
A future specification may support a scenario where individual key share
|
||||||
|
holders are not trusted with it.
|
||||||
|
|
||||||
|
|
||||||
Non-requirements
|
Non-requirements
|
||||||
================
|
================
|
||||||
|
|
||||||
- The control of the transaction privacy is not distributed among participants
|
- This ZIP does not support removing the Coordinator role, as described in #[FROST]_.
|
||||||
and is trusted with the Coordinator.
|
- This ZIP does not prevent key share holders from breaking the privacy
|
||||||
|
of the transaction.
|
||||||
|
|
||||||
|
|
||||||
Specification
|
Specification
|
||||||
|
@ -211,7 +218,7 @@ computation of the binding factor. It is specified as the following: ::
|
||||||
Signature Share Verification and Aggregation
|
Signature Share Verification and Aggregation
|
||||||
''''''''''''''''''''''''''''''''''''''''''''
|
''''''''''''''''''''''''''''''''''''''''''''
|
||||||
|
|
||||||
The `verify_signature_share` is also changed to incorporate the randomizer,
|
The `verify_signature_share` is changed to incorporate the randomizer,
|
||||||
as follows: ::
|
as follows: ::
|
||||||
|
|
||||||
Inputs:
|
Inputs:
|
||||||
|
@ -292,27 +299,23 @@ The `aggregate` function is changed to incorporate the randomizer as follows: ::
|
||||||
Ciphersuites
|
Ciphersuites
|
||||||
------------
|
------------
|
||||||
|
|
||||||
FROST(RedJubjub, BLAKE2b-512)
|
FROST(Jubjub, BLAKE2b-512)
|
||||||
'''''''''''''''''''''''''''''
|
'''''''''''''''''''''''''''''
|
||||||
|
|
||||||
This ciphersuite uses Jubjub for the Group and BLAKE2b-512 for the Hash function `H`
|
This ciphersuite uses Jubjub for the Group and BLAKE2b-512 for the Hash function `H`
|
||||||
meant to produce signatures indistinguishable from RedJubjub Sapling Spend
|
meant to produce signatures indistinguishable from RedJubjub Sapling Spend
|
||||||
Authorization Signatures as specified in [#protocol]_.
|
Authorization Signatures as specified in [#protocol-concretespendauthsig]_.
|
||||||
|
|
||||||
- Group: Jubjub [#protocol]_
|
- Group: Jubjub [#protocol-jubjub]_
|
||||||
|
|
||||||
- Order: 6554484396890773809930967563523245729705921265872317281365359162392183254199 (see [#protocol]_)
|
- Order: 6554484396890773809930967563523245729705921265872317281365359162392183254199 (see [#protocol-jubjub]_)
|
||||||
- Identity: as defined in [#protocol]_
|
- Identity: as defined in [#protocol-jubjub]_
|
||||||
- RandomScalar: Implemented by generating a random 64-byte string and invoking
|
- RandomScalar: Implemented by generating a random 64-byte string and invoking
|
||||||
DeserializeScalar on the result
|
DeserializeScalar on the result
|
||||||
- RandomNonZeroScalar: Implemented by generating a random 32-byte string that
|
- RandomNonZeroScalar: Implemented by generating a random 32-byte string that
|
||||||
is not equal to the all-zero string and invoking DeserializeScalar on the result.
|
is not equal to the all-zero string and invoking DeserializeScalar on the result.
|
||||||
- SerializeElement(P): Implemented as `LEBS2OSP_{ℓG}(repr_G(P))`, where LEBS2OSP and repr_G
|
- SerializeElement(P): Implemented as :math:`\mathsf{repr}_\mathbb{J}(P)` as defined in [#protocol-jubjub]_
|
||||||
are defined in [#protocol]_
|
- DeserializeElement(P): Implemented as :math:`\mathsf{abst}_\mathbb{J}(P)` as defined in [#protocol-jubjub]_
|
||||||
[TODO: how to specify this? It's awkward to do this way, should we expand
|
|
||||||
the definitions?]
|
|
||||||
- DeserializeElement: Implemented as `abst_G(LEOS2BSP_{ℓG}(P))`, where LEOS2BSP and abst_G
|
|
||||||
are defined in [#protocol]_
|
|
||||||
- SerializeScalar: Implemented by outputting the little-endian 32-byte encoding
|
- SerializeScalar: Implemented by outputting the little-endian 32-byte encoding
|
||||||
of the Scalar value.
|
of the Scalar value.
|
||||||
- DeserializeScalar: Implemented by attempting to deserialize a Scalar from a
|
- DeserializeScalar: Implemented by attempting to deserialize a Scalar from a
|
||||||
|
@ -325,41 +328,34 @@ Authorization Signatures as specified in [#protocol]_.
|
||||||
- H1(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubR", m), interpreting
|
- H1(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubR", m), interpreting
|
||||||
the 64 bytes as a little-endian integer, and reducing the resulting integer
|
the 64 bytes as a little-endian integer, and reducing the resulting integer
|
||||||
modulo L = 6554484396890773809930967563523245729705921265872317281365359162392183254199.
|
modulo L = 6554484396890773809930967563523245729705921265872317281365359162392183254199.
|
||||||
[TODO: what context string to use?]
|
- H2(m): Implemented by computing BLAKE2b-512("Zcash_RedJubjubH", m), interpreting
|
||||||
- H2(m): LEOS2IP_{ℓ_H}(H(m)) (mod G.Order())
|
|
||||||
/ Implemented by computing BLAKE2b-512("Zcash_RedJubjubH", m), interpreting
|
|
||||||
the 64 bytes as a little-endian integer, and reducing the resulting integer
|
the 64 bytes as a little-endian integer, and reducing the resulting integer
|
||||||
modulo L = 6554484396890773809930967563523245729705921265872317281365359162392183254199.
|
modulo L = 6554484396890773809930967563523245729705921265872317281365359162392183254199.
|
||||||
[TODO: use original expression or expand the definitions as above?]
|
(This is equivalent to :math:`\mathsf{H}^\circledast(m)`, as defined in
|
||||||
|
[#protocol-concretereddsa]_ parametrized with [#protocol-jubjub]_.)
|
||||||
- H3(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubDi", m)
|
- H3(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubDi", m)
|
||||||
[TODO: what context string to use?]
|
|
||||||
- H4(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubN", m), interpreting
|
- H4(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubN", m), interpreting
|
||||||
the 64 bytes as a little-endian integer, and reducing the resulting integer
|
the 64 bytes as a little-endian integer, and reducing the resulting integer
|
||||||
modulo L = 6554484396890773809930967563523245729705921265872317281365359162392183254199.
|
modulo L = 6554484396890773809930967563523245729705921265872317281365359162392183254199.
|
||||||
[TODO: what context string to use?]
|
|
||||||
|
|
||||||
|
|
||||||
FROST(RedPallas, BLAKE2b-512)
|
FROST(Pallas, BLAKE2b-512)
|
||||||
'''''''''''''''''''''''''''''
|
'''''''''''''''''''''''''''''
|
||||||
|
|
||||||
This ciphersuite uses Pallas for the Group and BLAKE2b-512 for the Hash function `H`
|
This ciphersuite uses Pallas for the Group and BLAKE2b-512 for the Hash function `H`
|
||||||
meant to produce signatures indistinguishable from RedPallas Sapling Spend
|
meant to produce signatures indistinguishable from RedPallas Sapling Spend
|
||||||
Authorization Signatures as specified in [#protocol]_.
|
Authorization Signatures as specified in [#protocol-concretespendauthsig]_.
|
||||||
|
|
||||||
- Group: Pallas [#protocol]_
|
- Group: Pallas [#protocol-pallasandvesta]_
|
||||||
|
|
||||||
- Order: 0x40000000000000000000000000000000224698fc0994a8dd8c46eb2100000001 (see [#protocol]_)
|
- Order: 0x40000000000000000000000000000000224698fc0994a8dd8c46eb2100000001 (see [#protocol-pallasandvesta]_)
|
||||||
- Identity: as defined in [#protocol]_
|
- Identity: as defined in [#protocol-pallasandvesta]_
|
||||||
- RandomScalar: Implemented by generating a random 64-byte string and invoking
|
- RandomScalar: Implemented by generating a random 64-byte string and invoking
|
||||||
DeserializeScalar on the result
|
DeserializeScalar on the result
|
||||||
- RandomNonZeroScalar: Implemented by generating a random 32-byte string that
|
- RandomNonZeroScalar: Implemented by generating a random 32-byte string that
|
||||||
is not equal to the all-zero string and invoking DeserializeScalar on the result.
|
is not equal to the all-zero string and invoking DeserializeScalar on the result.
|
||||||
- SerializeElement(P): Implemented as `LEBS2OSP_{ℓG}(repr_G(P))`, where LEBS2OSP and repr_G
|
- SerializeElement(P): Implemented as :math:`\mathsf{repr}_\mathbb{P}(P)` as defined in [#protocol-pallasandvesta]_
|
||||||
are defined in [#protocol]_
|
- DeserializeElement(P): Implemented as :math:`\mathsf{abst}_\mathbb{P}(P)` as defined in [#protocol-pallasandvesta]_
|
||||||
[TODO: how to specify this? It's awkward to do this way, should we expand
|
|
||||||
the definitions?]
|
|
||||||
- DeserializeElement: Implemented as `abst_G(LEOS2BSP_{ℓG}(P))`, where LEOS2BSP and abst_G
|
|
||||||
are defined in [#protocol]_
|
|
||||||
- SerializeScalar: Implemented by outputting the little-endian 32-byte encoding
|
- SerializeScalar: Implemented by outputting the little-endian 32-byte encoding
|
||||||
of the Scalar value.
|
of the Scalar value.
|
||||||
- DeserializeScalar: Implemented by attempting to deserialize a Scalar from a
|
- DeserializeScalar: Implemented by attempting to deserialize a Scalar from a
|
||||||
|
@ -372,18 +368,15 @@ Authorization Signatures as specified in [#protocol]_.
|
||||||
- H1(m): Implemented by computing BLAKE2b-512("FROST_RedPallasR", m), interpreting
|
- H1(m): Implemented by computing BLAKE2b-512("FROST_RedPallasR", m), interpreting
|
||||||
the 64 bytes as a little-endian integer, and reducing the resulting integer
|
the 64 bytes as a little-endian integer, and reducing the resulting integer
|
||||||
modulo L = 0x40000000000000000000000000000000224698fc0994a8dd8c46eb2100000001.
|
modulo L = 0x40000000000000000000000000000000224698fc0994a8dd8c46eb2100000001.
|
||||||
[TODO: what context string to use?]
|
- H2(m): Implemented by computing BLAKE2b-512("Zcash_RedPallasH", m), interpreting
|
||||||
- H2(m): LEOS2IP_{ℓ_H}(H(m)) (mod G.Order())
|
|
||||||
/ Implemented by computing BLAKE2b-512("Zcash_RedPallasH", m), interpreting
|
|
||||||
the 64 bytes as a little-endian integer, and reducing the resulting integer
|
the 64 bytes as a little-endian integer, and reducing the resulting integer
|
||||||
modulo L = 0x40000000000000000000000000000000224698fc0994a8dd8c46eb2100000001.
|
modulo L = 0x40000000000000000000000000000000224698fc0994a8dd8c46eb2100000001.
|
||||||
[TODO: use original expression or expand the definitions as above?]
|
(This is equivalent to :math:`\mathsf{H}^\circledast(m)`, as defined in
|
||||||
- H1(m): Implemented by computing BLAKE2b-512("FROST_RedPallasD", m).
|
[#protocol-concretereddsa]_ parametrized with [#protocol-pallasandvesta]_.)
|
||||||
[TODO: what context string to use?]
|
- H3(m): Implemented by computing BLAKE2b-512("FROST_RedPallasD", m).
|
||||||
- H4(m): Implemented by computing BLAKE2b-512("FROST_RedPallasN", m), interpreting
|
- H4(m): Implemented by computing BLAKE2b-512("FROST_RedPallasN", m), interpreting
|
||||||
the 64 bytes as a little-endian integer, and reducing the resulting integer
|
the 64 bytes as a little-endian integer, and reducing the resulting integer
|
||||||
modulo L = 0x40000000000000000000000000000000224698fc0994a8dd8c46eb2100000001.
|
modulo L = 0x40000000000000000000000000000000224698fc0994a8dd8c46eb2100000001.
|
||||||
[TODO: what context string to use?]
|
|
||||||
|
|
||||||
|
|
||||||
Reference implementation
|
Reference implementation
|
||||||
|
@ -398,6 +391,7 @@ References
|
||||||
.. [#BLAKE] `BLAKE2: simpler, smaller, fast as MD5 <https://blake2.net/#sp>`_
|
.. [#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>`_
|
.. [#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] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST <https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-05.html>`_
|
||||||
.. [#protocol] `Zcash Protocol Specification, Version 2022.3.0 or later <protocol/protocol.pdf>`_
|
.. [#protocol-concretereddsa] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7: RedDSA, RedJubjub, and RedPallas <https://protocol/protocol.pdf#concretereddsa>`_
|
||||||
.. [#protocol-introduction] `Zcash Protocol Specification, Version 2020.1.24. Section 1: Introduction <protocol/protocol.pdf#introduction>`_
|
.. [#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>`_
|
||||||
.. [#zip-0000] `ZIP 0: ZIP Process <zip-0000.rst>`_
|
.. [#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