zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Fixed threat model; cleaning up; added references

This commit is contained in:
Conrado Gouvea 2022-07-15 18:38:08 -03:00
parent 54dbd57d76
commit 3a96a2f75b
1 changed files with 41 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

88
zip-frost.rst
View File

@ -41,14 +41,17 @@ signatures in the Zcash protocol, for the Sapling and Orchard network upgrades.
Motivation
==========
In the Zcash protocol, Spend Authorization Signatures are employed to effectively
authorize a transaction. The ability to generate these signatures with the user's
In the Zcash protocol, Spend Authorization Signatures are employed to authorize
a transaction. The ability to generate these signatures with the user's
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 entities to allow the transaction to go through.
This can be accomplished with threshold signatures, where... (TODO: explain)
possibility is to require multiple users 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
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
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
as Sapling or Orchard spend authorization signatures.
- 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.
Threat Model
@ -79,7 +82,7 @@ shielded transaction:
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
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
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.
@ -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
unlinkability and privacy, but should not be able to create signed transactions
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
================
- The control of the transaction privacy is not distributed among participants
and is trusted with the Coordinator.
- This ZIP does not support removing the Coordinator role, as described in #[FROST]_.
- This ZIP does not prevent key share holders from breaking the privacy
of the transaction.
Specification
@ -211,7 +218,7 @@ computation of the binding factor. It is specified as the following: ::
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: ::
Inputs:
@ -292,27 +299,23 @@ The `aggregate` function is changed to incorporate the randomizer as follows: ::
Ciphersuites
------------
FROST(RedJubjub, BLAKE2b-512)
FROST(Jubjub, BLAKE2b-512)
'''''''''''''''''''''''''''''
This ciphersuite uses Jubjub for the Group and BLAKE2b-512 for the Hash function `H`
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]_)
- Identity: as defined in [#protocol]_
- Order: 6554484396890773809930967563523245729705921265872317281365359162392183254199 (see [#protocol-jubjub]_)
- Identity: as defined in [#protocol-jubjub]_
- RandomScalar: Implemented by generating a random 64-byte string and invoking
DeserializeScalar on the result
- 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 `LEBS2OSP_{ℓG}(repr_G(P))`, where LEBS2OSP and repr_G
are defined in [#protocol]_
[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]_
- 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]_
- SerializeScalar: Implemented by outputting the little-endian 32-byte encoding
of the Scalar value.
- 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
the 64 bytes as a little-endian integer, and reducing the resulting integer
modulo L = 6554484396890773809930967563523245729705921265872317281365359162392183254199.
[TODO: what context string to use?]
- H2(m): LEOS2IP_{ℓ_H}(H(m)) (mod G.Order())
/ Implemented by computing BLAKE2b-512("Zcash_RedJubjubH", m), interpreting
- H2(m): Implemented by computing BLAKE2b-512("Zcash_RedJubjubH", m), interpreting
the 64 bytes as a little-endian integer, and reducing the resulting integer
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)
[TODO: what context string to use?]
- H4(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubN", m), interpreting
the 64 bytes as a little-endian integer, and reducing the resulting integer
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`
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]_)
- Identity: as defined in [#protocol]_
- Order: 0x40000000000000000000000000000000224698fc0994a8dd8c46eb2100000001 (see [#protocol-pallasandvesta]_)
- Identity: as defined in [#protocol-pallasandvesta]_
- RandomScalar: Implemented by generating a random 64-byte string and invoking
DeserializeScalar on the result
- 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 `LEBS2OSP_{ℓG}(repr_G(P))`, where LEBS2OSP and repr_G
are defined in [#protocol]_
[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]_
- 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]_
- SerializeScalar: Implemented by outputting the little-endian 32-byte encoding
of the Scalar value.
- 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
the 64 bytes as a little-endian integer, and reducing the resulting integer
modulo L = 0x40000000000000000000000000000000224698fc0994a8dd8c46eb2100000001.
[TODO: what context string to use?]
- H2(m): LEOS2IP_{ℓ_H}(H(m)) (mod G.Order())
/ Implemented by computing BLAKE2b-512("Zcash_RedPallasH", m), interpreting
- H2(m): Implemented by computing BLAKE2b-512("Zcash_RedPallasH", m), interpreting
the 64 bytes as a little-endian integer, and reducing the resulting integer
modulo L = 0x40000000000000000000000000000000224698fc0994a8dd8c46eb2100000001.
[TODO: use original expression or expand the definitions as above?]
- H1(m): Implemented by computing BLAKE2b-512("FROST_RedPallasD", m).
[TODO: what context string to use?]
(This is equivalent to :math:`\mathsf{H}^\circledast(m)`, as defined in
[#protocol-concretereddsa]_ parametrized with [#protocol-pallasandvesta]_.)
- H3(m): Implemented by computing BLAKE2b-512("FROST_RedPallasD", m).
- H4(m): Implemented by computing BLAKE2b-512("FROST_RedPallasN", m), interpreting
the 64 bytes as a little-endian integer, and reducing the resulting integer
modulo L = 0x40000000000000000000000000000000224698fc0994a8dd8c46eb2100000001.
[TODO: what context string to use?]
Reference implementation
@ -398,6 +391,7 @@ 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>`_
.. [#protocol] `Zcash Protocol Specification, Version 2022.3.0 or later <protocol/protocol.pdf>`_
.. [#protocol-introduction] `Zcash Protocol Specification, Version 2020.1.24. Section 1: Introduction <protocol/protocol.pdf#introduction>`_
.. [#zip-0000] `ZIP 0: ZIP Process <zip-0000.rst>`_
.. [#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-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>`_