From 3a96a2f75b150eec634e50754431c5435103fe69 Mon Sep 17 00:00:00 2001 From: Conrado Gouvea Date: Fri, 15 Jul 2022 18:38:08 -0300 Subject: [PATCH] Fixed threat model; cleaning up; added references --- zip-frost.rst | 88 ++++++++++++++++++++++++--------------------------- 1 file changed, 41 insertions(+), 47 deletions(-) diff --git a/zip-frost.rst b/zip-frost.rst index ad5c12be..6ef1bab8 100644 --- a/zip-frost.rst +++ b/zip-frost.rst @@ -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 `_ .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ .. [#FROST] `Draft RFC: Two-Round Threshold Schnorr Signatures with FROST `_ -.. [#protocol] `Zcash Protocol Specification, Version 2022.3.0 or later `_ -.. [#protocol-introduction] `Zcash Protocol Specification, Version 2020.1.24. Section 1: Introduction `_ -.. [#zip-0000] `ZIP 0: ZIP Process `_ +.. [#protocol-concretereddsa] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7: RedDSA, RedJubjub, and RedPallas `_ +.. [#protocol-concretespendauthsig] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.7.1: Spend Authorization Signature (Sapling and Orchard) `_ +.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.3: Jubjub `_ +.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2022.3.4 [NU5]. Section 5.4.9.6: Pallas and Vesta `_