From fd63a498f27af90f585d97b9914d510bda43802d Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Thu, 11 Feb 2021 22:32:13 +0000 Subject: [PATCH 1/7] ZIP 216: Main draft --- zip-0216.rst | 115 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 113 insertions(+), 2 deletions(-) diff --git a/zip-0216.rst b/zip-0216.rst index 83707929..12a5176c 100644 --- a/zip-0216.rst +++ b/zip-0216.rst @@ -2,7 +2,118 @@ ZIP: 216 Title: Require Canonical Point Encodings - Owners: Daira Hopwood - Status: Reserved + Owners: Jack Grigg + Daira Hopwood + Status: Draft Category: Consensus + Created: 2021-02-11 + License: BSD-2-Clause Discussions-To: + + +Terminology +=========== + +The key words "MUST" and "MUST NOT" in this document is to be interpreted as described +in RFC 2119. [#RFC2119]_ + + +Abstract +======== + +This ZIP fixes an oversight in the implementation of the Sapling consensus rules, by +correctly rejecting all non-canonical representations of Jubjub points. + + +Motivation +========== + +The Sapling specification was written with the intent that all values were strongly-typed +with canonical representations. This has significant advantages for security analysis, +because it allows the protocol to be modelled with just the abstract types. + +The intention of the Jubjub implementation (both in the [jubjub]_ crate and its prior +implementations) was to ensure that only canonical point encodings would be accepted by +the decoding logic. However, an oversight in the implementation allowed an edge case to +slip through: for each point on the curve where the $u$ coordinate is zero, there are two +encodings that will be accepted: + +```rust +// Fix the sign of `u` if necessary +let flip_sign = Choice::from((u.to_bytes()[0] ^ sign) & 1); +let u_negated = -u; +let final_u = Fq::conditional_select(&u, &u_negated, flip_sign); +``` + +This code accepts either sign bit, because `u_negated == u`. + +There are two such points on the Jubjub curve: + +- `(0, -1)`, which is a point of order two, and thus rejected by the implementation + anywhere that a prime-order subgroup point is specified. +- `(0, 1)`, which is the identity, and thus is an element of the prime-order subgroup. + +The non-canonical identity creates a consensus issue because unlike other non-canonical +points that are rejected, a non-canonical identity that is decoded and then encoded, does +not produce the original encoding. For example, if a non-canonical encoding appeared in a +transaction field, then node implementations that store points internally as abstract +curve points, and used those to derive transaction IDs, would derive different IDs than +nodes which store transactions as bytes (such as `zcashd`). + + +Specification +============= + +TODO: Define a non-canonical Jubjub point encoding. + +When this ZIP activates, all places within the Sapling consensus protocol where Jubjub +points occur MUST reject non-canonical Jubjub point encodings. + +- Sapling addresses: + - `pk_d` +- Sapling Spend description: + - `cv` + - `rk` + - The `R` component of the `spendAuthSig` RedDSA signature. +- Sapling Output description: + - `cv` + - `ephemeralKey` +- The `R` component of the `bindingSigSapling` RedDSA signature. + +Rationale +========= + +Zcash previously had a similar issue with non-canonical representations of points in +Ed25519 public keys and signatures. In that case, given the prevalence of Ed25519 +signatures in the wider ecosystem, the decision was made in ZIP 215 [#zip-0215]_ (which +activated with the Canopy network upgrade [#zip-0251]_) to allow non-canonical +representations of points. + +Here, we are motivated instead to reject these non-canonical points: + +- The chance of the identity occuring anywhere within Sapling transactions from + implementations following the standard protocol is cryptographically negligible. +- This re-enables the aforementioned simpler security analysis of the Sapling protocol. +- The Jubjub curve has a vastly-smaller scope of usage than Curve25519. + + +Security and Privacy Considerations +=================================== + +This ZIP eliminates a potential source of consensus divergence between differing full node +implementations. At the time of writing (February 2021), no such divergence exists for any +production implementation of Zcash, but the alpha-stage `zebrad` node implementation would +be susceptible to this issue. + + +Deployment +========== + +TBD + + +References +========== + +.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.8.3: Jubjub `_ +.. [#zip-0215] `ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules `_ From acf88b883cbb8664e76d605b742acfbf6e62b9a4 Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Thu, 11 Feb 2021 22:34:00 +0000 Subject: [PATCH 2/7] ZIP 216: Rename to only apply to Jubjub points --- zip-0216.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zip-0216.rst b/zip-0216.rst index 12a5176c..8a11850f 100644 --- a/zip-0216.rst +++ b/zip-0216.rst @@ -1,7 +1,7 @@ :: ZIP: 216 - Title: Require Canonical Point Encodings + Title: Require Canonical Jubjub Point Encodings Owners: Jack Grigg Daira Hopwood Status: Draft From c4a863096cab4271ed2ba743e48e299b3065695c Mon Sep 17 00:00:00 2001 From: Jack Grigg Date: Thu, 11 Feb 2021 22:38:22 +0000 Subject: [PATCH 3/7] ZIP 216: Fix references --- zip-0216.rst | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/zip-0216.rst b/zip-0216.rst index 8a11850f..e7f6337a 100644 --- a/zip-0216.rst +++ b/zip-0216.rst @@ -28,15 +28,16 @@ correctly rejecting all non-canonical representations of Jubjub points. Motivation ========== -The Sapling specification was written with the intent that all values were strongly-typed -with canonical representations. This has significant advantages for security analysis, -because it allows the protocol to be modelled with just the abstract types. +The Sapling specification was written with the intent that all values, including Jubjub +points, are strongly-typed with canonical representations. [#protocol-jubjub]_ This has +significant advantages for security analysis, because it allows the protocol to be +modelled with just the abstract types. -The intention of the Jubjub implementation (both in the [jubjub]_ crate and its prior -implementations) was to ensure that only canonical point encodings would be accepted by -the decoding logic. However, an oversight in the implementation allowed an edge case to -slip through: for each point on the curve where the $u$ coordinate is zero, there are two -encodings that will be accepted: +The intention of the Jubjub implementation (both in the `jubjub` crate [#jubjub-crate]_ +and its prior implementations) was to ensure that only canonical point encodings would be +accepted by the decoding logic. However, an oversight in the implementation allowed an +edge case to slip through: for each point on the curve where the $u$ coordinate is zero, +there are two encodings that will be accepted: ```rust // Fix the sign of `u` if necessary @@ -115,5 +116,7 @@ TBD References ========== +.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ .. [#protocol-jubjub] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.8.3: Jubjub `_ +.. [#jubjub-crate] `jubjub `_ .. [#zip-0215] `ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules `_ From 5a92818183fe6a9b4da1cd0b3393fa1d261a942c Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Wed, 17 Feb 2021 21:47:41 +0000 Subject: [PATCH 4/7] Apply suggestions from code review Co-authored-by: Deirdre Connolly --- zip-0216.rst | 42 ++++++++++++++++++++++++------------------ 1 file changed, 24 insertions(+), 18 deletions(-) diff --git a/zip-0216.rst b/zip-0216.rst index e7f6337a..864cec1b 100644 --- a/zip-0216.rst +++ b/zip-0216.rst @@ -22,21 +22,21 @@ Abstract ======== This ZIP fixes an oversight in the implementation of the Sapling consensus rules, by -correctly rejecting all non-canonical representations of Jubjub points. +rejecting all non-canonical representations of Jubjub points. Motivation ========== The Sapling specification was written with the intent that all values, including Jubjub -points, are strongly-typed with canonical representations. [#protocol-jubjub]_ This has +points, are strongly typed with canonical representations. [#protocol-jubjub]_ This has significant advantages for security analysis, because it allows the protocol to be modelled with just the abstract types. The intention of the Jubjub implementation (both in the `jubjub` crate [#jubjub-crate]_ and its prior implementations) was to ensure that only canonical point encodings would be accepted by the decoding logic. However, an oversight in the implementation allowed an -edge case to slip through: for each point on the curve where the $u$ coordinate is zero, +edge case to slip through: for each point on the curve where the $u$-coordinate is zero, there are two encodings that will be accepted: ```rust @@ -48,18 +48,18 @@ let final_u = Fq::conditional_select(&u, &u_negated, flip_sign); This code accepts either sign bit, because `u_negated == u`. -There are two such points on the Jubjub curve: +There are two points on the Jubjub curve with $u$-coordinate zero: - `(0, -1)`, which is a point of order two, and thus rejected by the implementation anywhere that a prime-order subgroup point is specified. - `(0, 1)`, which is the identity, and thus is an element of the prime-order subgroup. -The non-canonical identity creates a consensus issue because unlike other non-canonical -points that are rejected, a non-canonical identity that is decoded and then encoded, does -not produce the original encoding. For example, if a non-canonical encoding appeared in a -transaction field, then node implementations that store points internally as abstract -curve points, and used those to derive transaction IDs, would derive different IDs than -nodes which store transactions as bytes (such as `zcashd`). +The non-canonical identity encoding creates a consensus issue because unlike other +non-canonical points that are rejected, a non-canonical identity encoding that is decoded +and then encoded, does not produce the original encoding. For example, if a non-canonical +encoding appeared in a transaction field, then node implementations that store points +internally as abstract curve points, and used those to derive transaction IDs, would +derive different IDs than nodes which store transactions as bytes (such as `zcashd`). Specification @@ -67,11 +67,14 @@ Specification TODO: Define a non-canonical Jubjub point encoding. -When this ZIP activates, all places within the Sapling consensus protocol where Jubjub -points occur MUST reject non-canonical Jubjub point encodings. +When this ZIP activates, the following places within the Sapling consensus protocol +where Jubjub points occur MUST reject non-canonical Jubjub point encodings. (This +is all of the places where Jubjub points occur in compressed representations.) - Sapling addresses: - `pk_d` +- Full viewing keys and extended full viewing keys: + - `ak` - Sapling Spend description: - `cv` - `rk` @@ -80,6 +83,7 @@ points occur MUST reject non-canonical Jubjub point encodings. - `cv` - `ephemeralKey` - The `R` component of the `bindingSigSapling` RedDSA signature. +TODO: specify when addresses, full viewing keys, and note plaintexts are checked. Rationale ========= @@ -90,12 +94,14 @@ signatures in the wider ecosystem, the decision was made in ZIP 215 [#zip-0215]_ activated with the Canopy network upgrade [#zip-0251]_) to allow non-canonical representations of points. -Here, we are motivated instead to reject these non-canonical points: +In Sapling, we are motivated instead to reject these non-canonical points: -- The chance of the identity occuring anywhere within Sapling transactions from - implementations following the standard protocol is cryptographically negligible. +- The chance of the identity occurring anywhere within the Sapling components of + transactions from implementations following the standard protocol is cryptographically + negligible. - This re-enables the aforementioned simpler security analysis of the Sapling protocol. -- The Jubjub curve has a vastly-smaller scope of usage than Curve25519. +- The Jubjub curve has a vastly-smaller scope of usage in the general cryptographic + ecosystem than Curve25519 and Ed25519. Security and Privacy Considerations @@ -110,7 +116,7 @@ be susceptible to this issue. Deployment ========== -TBD +This ZIP is proposed to activate with Network Upgrade 5. References @@ -118,5 +124,5 @@ References .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ .. [#protocol-jubjub] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.8.3: Jubjub `_ -.. [#jubjub-crate] `jubjub `_ +.. [#jubjub-crate] `jubjub Rust crate `_ .. [#zip-0215] `ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules `_ From 65026436b79e0f603eb73070ded5f786ce8c4a61 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Sun, 28 Feb 2021 21:11:55 +0000 Subject: [PATCH 5/7] * Don't imply that the non-canonical encoding of (0, -1) is not a problem; it is. * Rewrite Specification section. * Additions to Rationale section. * Wording improvements. * Note the history of adjustments to the protocol spec. * Fix rst syntax. * Change license to MIT. * MUST NOT is not used. * Move draft to Proposed. Signed-off-by: Daira Hopwood --- README.rst | 2 +- zip-0216.rst | 170 +++++++++++++++++++++++++++++++++++++-------------- 2 files changed, 126 insertions(+), 46 deletions(-) diff --git a/README.rst b/README.rst index e0df0f2c..4d24254e 100644 --- a/README.rst +++ b/README.rst @@ -92,7 +92,7 @@ Index of ZIPs 213 Shielded Coinbase Final 214 Consensus rules for a Zcash Development Fund Implemented (zcashd) 215 Explicitly Defining and Modifying Ed25519 Validation Rules Implemented (zcashd) - 216 Require Canonical Point Encodings Reserved + 216 Require Canonical Jubjub Point Encodings Proposed 217 Aggregate Signatures Reserved 218 User-Defined Assets and Wrapped Assets Reserved 219 Disabling Addition of New Value to the Sapling Chain Value Pool Reserved diff --git a/zip-0216.rst b/zip-0216.rst index 864cec1b..ac904c89 100644 --- a/zip-0216.rst +++ b/zip-0216.rst @@ -4,18 +4,21 @@ Title: Require Canonical Jubjub Point Encodings Owners: Jack Grigg Daira Hopwood - Status: Draft + Status: Proposed Category: Consensus Created: 2021-02-11 - License: BSD-2-Clause + License: MIT Discussions-To: Terminology =========== -The key words "MUST" and "MUST NOT" in this document is to be interpreted as described -in RFC 2119. [#RFC2119]_ +The key word "MUST" in this document is to be interpreted as described in RFC 2119. +[#RFC2119]_ + +The term "network upgrade" in this document is to be interpreted as described in +ZIP 200. [#zip-0200]_ Abstract @@ -28,62 +31,111 @@ rejecting all non-canonical representations of Jubjub points. Motivation ========== -The Sapling specification was written with the intent that all values, including Jubjub -points, are strongly typed with canonical representations. [#protocol-jubjub]_ This has -significant advantages for security analysis, because it allows the protocol to be +The Sapling specification was originally written with the intent that all values, including +Jubjub points, are strongly typed with canonical representations. [#protocol-jubjub]_ This +has significant advantages for security analysis, because it allows the protocol to be modelled with just the abstract types. The intention of the Jubjub implementation (both in the `jubjub` crate [#jubjub-crate]_ and its prior implementations) was to ensure that only canonical point encodings would be accepted by the decoding logic. However, an oversight in the implementation allowed an -edge case to slip through: for each point on the curve where the $u$-coordinate is zero, -there are two encodings that will be accepted: +edge case to slip through: for each point on the curve where the :math:`u\!`-coordinate is +zero, there are two encodings that will be accepted: -```rust -// Fix the sign of `u` if necessary -let flip_sign = Choice::from((u.to_bytes()[0] ^ sign) & 1); -let u_negated = -u; -let final_u = Fq::conditional_select(&u, &u_negated, flip_sign); -``` +.. code-block:: rust -This code accepts either sign bit, because `u_negated == u`. + // Fix the sign of `u` if necessary + let flip_sign = Choice::from((u.to_bytes()[0] ^ sign) & 1); + let u_negated = -u; + let final_u = Fq::conditional_select(&u, &u_negated, flip_sign); -There are two points on the Jubjub curve with $u$-coordinate zero: +This code accepts either sign bit, because ``u_negated == u``. -- `(0, -1)`, which is a point of order two, and thus rejected by the implementation - anywhere that a prime-order subgroup point is specified. -- `(0, 1)`, which is the identity, and thus is an element of the prime-order subgroup. +There are two points on the Jubjub curve with :math:`u\!`-coordinate zero: -The non-canonical identity encoding creates a consensus issue because unlike other -non-canonical points that are rejected, a non-canonical identity encoding that is decoded -and then encoded, does not produce the original encoding. For example, if a non-canonical -encoding appeared in a transaction field, then node implementations that store points -internally as abstract curve points, and used those to derive transaction IDs, would -derive different IDs than nodes which store transactions as bytes (such as `zcashd`). +- :math:`(0, 1)`, which is the identity; +- :math:`(0, -1)`, which is a point of order two. + +Each of these has a single non-canonical encoding in which the value of the sign bit is +:math:`1`. + +This creates a consensus issue because (unlike other non-canonical point encodings that +are rejected) either of the above encodings can be decoded, and then re-encoded to a +*different* encoding. For example, if a non-canonical encoding appeared in a transaction +field, then node implementations that store points internally as abstract curve points, +and used those to derive transaction IDs, would derive different IDs than nodes which +store transactions as bytes (such as `zcashd`). + +This issue is not known to cause any security vulnerability, beyond the risk of +consensus incompatibility. Adjustments to the protocol specification were made in +versions 2020.1.8, 2020.1.9, 2020.1.15, and 2021.1.17 to match the `zcashd` implementation. +(The fact that this required 4 specification revisions to get right, conclusively +demonstrates the problem.) Specification ============= -TODO: Define a non-canonical Jubjub point encoding. +Let :math:`\mathsf{abst}_{\mathbb{J}}`, :math:`\mathsf{repr}_{\mathbb{J}}`, and +:math:`q_{\mathbb{J}}` be as defined in [#protocol-jubjub]_. -When this ZIP activates, the following places within the Sapling consensus protocol -where Jubjub points occur MUST reject non-canonical Jubjub point encodings. (This -is all of the places where Jubjub points occur in compressed representations.) +Define a non-canonical compressed encoding of a Jubjub point to be a sequence of +:math:`256` bits, :math:`b`, such that :math:`\mathsf{abst}_{\mathbb{J}}(b) \neq \bot` +and :math:`\mathsf{repr_{\mathbb{J}}}\big(\mathsf{abst}_{\mathbb{J}}(b)\big) \neq b`. + +Non-normative note: There are two such bit sequences, +:math:`\mathsf{I2LEOSP}_{\ell_{\mathbb{J}}}(2^{255} + 1)` and +:math:`\mathsf{I2LEOSP}_{\ell_{\mathbb{J}}}(2^{255} + q_{\mathbb{J}} - 1)`. +The Sapling protocol uses little-endian ordering when converting between bit and +byte sequences, so the first of these sequences corresponds to :math:`31` zero bytes +followed by a :math:`\mathtt{0x80}` byte. + +Once this ZIP activates, the following places within the Sapling consensus protocol +where Jubjub points occur MUST reject non-canonical Jubjub point encodings. + +In Sapling Spend descriptions [#protocol-spenddesc]_: + + - :math:`\mathtt{cv}` + - :math:`\mathtt{rk}` + - the :math:`\underline{R}` component (i.e. the first :math:`32` bytes) of the + :math:`\mathtt{spendAuthSig}` RedDSA signature. + +In Sapling Output descriptions [#protocol-outputdesc]_: + + - :math:`\mathtt{cv}` + - :math:`\mathtt{ephemeralKey}`. + +In transactions [#protocol-txnencodingandconsensus]_: + + - the :math:`\underline{R}` component (i.e. the first :math:`32` bytes) of the + :math:`\mathtt{bindingSigSapling}` RedDSA signature. + +In the plaintext obtained by decrypting the :math:`\mathsf{C^{out}}` field of a +Sapling transmitted note ciphertext [#protocol-decryptovk]_: + + - :math:`\mathsf{pk}\star_{\mathsf{d}}`. + +(This affects decryption of :math:`\mathsf{C^{out}}` in all cases, but is +consensus-critical only in the case of a shielded coinbase output. +[#protocol-txnencodingandconsensus]_) + + +In addition, Sapling addresses and full viewing keys MUST be considered invalid if +they contain non-canonical Jubjub point encodings when imported. + +In Sapling addresses [#protocol-saplingpaymentaddrencoding]_: + + - the encoding of :math:`\mathsf{pk_d}`. + +In Sapling full viewing keys [#protocol-saplingfullviewingkeyencoding]_ and extended +full viewing keys [#zip-0032-extfvk]_: + + - the encoding of :math:`\mathsf{ak}`. + +The above is intended to be a complete list of the places where compressed encodings +of Jubjub points occur in the Zcash consensus protocol and in plaintext, address, or +key formats. -- Sapling addresses: - - `pk_d` -- Full viewing keys and extended full viewing keys: - - `ak` -- Sapling Spend description: - - `cv` - - `rk` - - The `R` component of the `spendAuthSig` RedDSA signature. -- Sapling Output description: - - `cv` - - `ephemeralKey` -- The `R` component of the `bindingSigSapling` RedDSA signature. -TODO: specify when addresses, full viewing keys, and note plaintexts are checked. Rationale ========= @@ -103,6 +155,23 @@ In Sapling, we are motivated instead to reject these non-canonical points: - The Jubjub curve has a vastly-smaller scope of usage in the general cryptographic ecosystem than Curve25519 and Ed25519. +The necessary checks are very simple and do not require cryptographic operations, +therefore the performance impact will be negligible. + +The public inputs of Jubjub points to the Spend circuit (:math:`\mathsf{rk}` and +:math:`\mathsf{cv^{old}}`) and Output circuit (:math:`\mathsf{cv^{new}}` and +:math:`\mathsf{epk}`) are not affected because they are represented in affine +coordinates as elements of the correct field +(:math:`\mathbb{F}_{r_\mathbb{S}} = \mathbb{F}_{q_\mathbb{J}}`), +and so no issue of encoding canonicity arises. + +Encodings of elliptic curve points on Curve25519, BN-254 :math:`\mathbb{G}_1`, +BN-254 :math:`\mathbb{G}_2`, BLS12-381 :math:`\mathbb{G}_1`, and +BLS12-381 :math:`\mathbb{G}_2` are not affected. + +Encodings of elliptic curve points on the Pallas and Vesta curves in the Orchard proposal +[#protocol-pallasandvesta]_ are also not affected. + Security and Privacy Considerations =================================== @@ -123,6 +192,17 @@ References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2020.1.15. Section 5.4.8.3: Jubjub `_ -.. [#jubjub-crate] `jubjub Rust crate `_ +.. [#protocol] `Zcash Protocol Specification, Version 2021.1.17 or later [Orchard proposal] `_ +.. [#protocol-spenddesc] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 4.4: Spend Descriptions `_ +.. [#protocol-outputdesc] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 4.5: Output Descriptions `_ +.. [#protocol-decryptovk] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 4.19.3 Decryption using a Full Viewing Key (Sapling and Orchard) `_ +.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.8.3: Jubjub `_ +.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.8.6: Pallas and Vesta `_ +.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.6.4: Sapling Payment Addresses `_ +.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.6.7: Sapling Full Viewing Keys `_ +.. [#protocol-txnencodingandconsensus] `Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 7.1: Transaction Encoding and Consensus `_ +.. [#zip-0032-extfvk] `ZIP 32: Shielded Hierarchical Deterministic Wallets. Sapling extended full viewing keys `_ +.. [#zip-0200] `ZIP 200: Network Upgrade Activation Mechanism `_ .. [#zip-0215] `ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules `_ +.. [#zip-0251] `ZIP 251: Deployment of the Canopy Network Upgrade `_ +.. [#jubjub-crate] `jubjub Rust crate `_ From afc3ae4d1b3f0a02892ba1e7fc2aff9a51f373d2 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Sun, 28 Feb 2021 21:24:26 +0000 Subject: [PATCH 6/7] edithtml.sh: fix to links of the form "foo.rst#anchor". Signed-off-by: Daira Hopwood --- edithtml.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/edithtml.sh b/edithtml.sh index 0e6cb413..8f75e56c 100755 --- a/edithtml.sh +++ b/edithtml.sh @@ -33,7 +33,7 @@ EOF rm -f "$2".prefix fi -sed -i.sedbak 's|||g' "$2" +sed -i.sedbak 's|||g' "$2" sed -i.sedbak 's|<\(https:[^&]*\)>|\<\1\>|g' "$2" perl -i.sedbak -p0e 's|
\s*.?\s*([^<]*(?:[^<]*[^<]*)?)|
\3 |g' "$2" From faf27e276d94f7dd8c7eb0ebdc2837b2d4003ac7 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Mon, 1 Mar 2021 23:53:42 +0000 Subject: [PATCH 7/7] ZIP 216: generate HTML and update index. Signed-off-by: Daira Hopwood --- css/style.css | 4 +- index.html | 2 +- zip-0216.html | 305 +++++++++++++++++++++++++++++++++++++++++++++++++- 3 files changed, 304 insertions(+), 7 deletions(-) diff --git a/css/style.css b/css/style.css index f004bbd2..177999d6 100644 --- a/css/style.css +++ b/css/style.css @@ -98,7 +98,7 @@ p { } li { - margin-bottom: 0.825rem; + margin-bottom: 0.2rem; } li ul { @@ -106,7 +106,7 @@ li ul { } ul, ol, table { - margin-bottom: calc( 1rem + 1ex ); + margin-bottom: calc( 0.5rem + 0.5ex ); } p, ul, ol, dl, table { diff --git a/index.html b/index.html index 529beb15..d4a4d9f2 100644 --- a/index.html +++ b/index.html @@ -65,7 +65,7 @@ 213 Shielded Coinbase Final 214 Consensus rules for a Zcash Development Fund Implemented (zcashd) 215 Explicitly Defining and Modifying Ed25519 Validation Rules Implemented (zcashd) - 216 Require Canonical Point Encodings Reserved + 216 Require Canonical Jubjub Point Encodings Proposed 217 Aggregate Signatures Reserved 218 User-Defined Assets and Wrapped Assets Reserved 219 Disabling Addition of New Value to the Sapling Chain Value Pool Reserved diff --git a/zip-0216.html b/zip-0216.html index 808262e2..0f2b09f0 100644 --- a/zip-0216.html +++ b/zip-0216.html @@ -1,17 +1,314 @@ - ZIP 216: Require Canonical Point Encodings + ZIP 216: Require Canonical Jubjub Point Encodings + 
ZIP: 216
-Title: Require Canonical Point Encodings
-Owners: Daira Hopwood <daira@electriccoin.co>
-Status: Reserved
+Title: Require Canonical Jubjub Point Encodings
+Owners: Jack Grigg <jack@electriccoin.co>
+        Daira Hopwood <daira@electriccoin.co>
+Status: Proposed
 Category: Consensus
+Created: 2021-02-11
+License: MIT
 Discussions-To: <https://github.com/zcash/zips/issues/400>
+

Terminology

+

The key word "MUST" in this document is to be interpreted as described in RFC 2119. 1

+

The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 12

+
+

Abstract

+

This ZIP fixes an oversight in the implementation of the Sapling consensus rules, by rejecting all non-canonical representations of Jubjub points.

+
+

Motivation

+

The Sapling specification was originally written with the intent that all values, including Jubjub points, are strongly typed with canonical representations. 6 This has significant advantages for security analysis, because it allows the protocol to be modelled with just the abstract types.

+

The intention of the Jubjub implementation (both in the jubjub crate 15 and its prior implementations) was to ensure that only canonical point encodings would be accepted by the decoding logic. However, an oversight in the implementation allowed an edge case to slip through: for each point on the curve where the + \(u\!\) + -coordinate is zero, there are two encodings that will be accepted:

+ 
// Fix the sign of `u` if necessary
+let flip_sign = Choice::from((u.to_bytes()[0] ^ sign) & 1);
+let u_negated = -u;
+let final_u = Fq::conditional_select(&u, &u_negated, flip_sign);
+

This code accepts either sign bit, because u_negated == u.

+

There are two points on the Jubjub curve with + \(u\!\) + -coordinate zero:

+
    +
  • + \((0, 1)\) + , which is the identity;
    • +
  • + \((0, -1)\) + , which is a point of order two.
    • +
+

Each of these has a single non-canonical encoding in which the value of the sign bit is + \(1\) + .

+

This creates a consensus issue because (unlike other non-canonical point encodings that are rejected) either of the above encodings can be decoded, and then re-encoded to a different encoding. For example, if a non-canonical encoding appeared in a transaction field, then node implementations that store points internally as abstract curve points, and used those to derive transaction IDs, would derive different IDs than nodes which store transactions as bytes (such as zcashd).

+

This issue is not known to cause any security vulnerability, beyond the risk of consensus incompatibility. Adjustments to the protocol specification were made in versions 2020.1.8, 2020.1.9, 2020.1.15, and 2021.1.17 to match the zcashd implementation. (The fact that this required 4 specification revisions to get right, conclusively demonstrates the problem.)

+
+

Specification

+

Let + \(\mathsf{abst}_{\mathbb{J}}\) + , + \(\mathsf{repr}_{\mathbb{J}}\) + , and + \(q_{\mathbb{J}}\) + be as defined in 6.

+

Define a non-canonical compressed encoding of a Jubjub point to be a sequence of + \(256\) + bits, + \(b\) + , such that + \(\mathsf{abst}_{\mathbb{J}}(b) \neq \bot\) + and + \(\mathsf{repr_{\mathbb{J}}}\big(\mathsf{abst}_{\mathbb{J}}(b)\big) \neq b\) + .

+

Non-normative note: There are two such bit sequences, + \(\mathsf{I2LEOSP}_{\ell_{\mathbb{J}}}(2^{255} + 1)\) + and + \(\mathsf{I2LEOSP}_{\ell_{\mathbb{J}}}(2^{255} + q_{\mathbb{J}} - 1)\) + . The Sapling protocol uses little-endian ordering when converting between bit and byte sequences, so the first of these sequences corresponds to + \(31\) + zero bytes followed by a + \(\mathtt{0x80}\) + byte.

+

Once this ZIP activates, the following places within the Sapling consensus protocol where Jubjub points occur MUST reject non-canonical Jubjub point encodings.

+

In Sapling Spend descriptions 3:

+
+
    +
  • + \(\mathtt{cv}\) +
    • +
  • + \(\mathtt{rk}\) +
    • +
  • the + \(\underline{R}\) + component (i.e. the first + \(32\) + bytes) of the + \(\mathtt{spendAuthSig}\) + RedDSA signature.
    • +
+
+

In Sapling Output descriptions 4:

+
+
    +
  • + \(\mathtt{cv}\) +
    • +
  • + \(\mathtt{ephemeralKey}\) + .
    • +
+
+

In transactions 10:

+
+
    +
  • the + \(\underline{R}\) + component (i.e. the first + \(32\) + bytes) of the + \(\mathtt{bindingSigSapling}\) + RedDSA signature.
    • +
+
+

In the plaintext obtained by decrypting the + \(\mathsf{C^{out}}\) + field of a Sapling transmitted note ciphertext 5:

+
+
    +
  • + \(\mathsf{pk}\star_{\mathsf{d}}\) + .
    • +
+
+

(This affects decryption of + \(\mathsf{C^{out}}\) + in all cases, but is consensus-critical only in the case of a shielded coinbase output. 10)

+

In addition, Sapling addresses and full viewing keys MUST be considered invalid if they contain non-canonical Jubjub point encodings when imported.

+

In Sapling addresses 8:

+
+
    +
  • the encoding of + \(\mathsf{pk_d}\) + .
    • +
+
+

In Sapling full viewing keys 9 and extended full viewing keys 11:

+
+
    +
  • the encoding of + \(\mathsf{ak}\) + .
    • +
+
+

The above is intended to be a complete list of the places where compressed encodings of Jubjub points occur in the Zcash consensus protocol and in plaintext, address, or key formats.

+
+

Rationale

+

Zcash previously had a similar issue with non-canonical representations of points in Ed25519 public keys and signatures. In that case, given the prevalence of Ed25519 signatures in the wider ecosystem, the decision was made in ZIP 215 13 (which activated with the Canopy network upgrade 14) to allow non-canonical representations of points.

+

In Sapling, we are motivated instead to reject these non-canonical points:

+
    +
  • The chance of the identity occurring anywhere within the Sapling components of transactions from implementations following the standard protocol is cryptographically negligible.
    • +
  • This re-enables the aforementioned simpler security analysis of the Sapling protocol.
    • +
  • The Jubjub curve has a vastly-smaller scope of usage in the general cryptographic ecosystem than Curve25519 and Ed25519.
    • +
+

The necessary checks are very simple and do not require cryptographic operations, therefore the performance impact will be negligible.

+

The public inputs of Jubjub points to the Spend circuit ( + \(\mathsf{rk}\) + and + \(\mathsf{cv^{old}}\) + ) and Output circuit ( + \(\mathsf{cv^{new}}\) + and + \(\mathsf{epk}\) + ) are not affected because they are represented in affine coordinates as elements of the correct field ( + \(\mathbb{F}_{r_\mathbb{S}} = \mathbb{F}_{q_\mathbb{J}}\) + ), and so no issue of encoding canonicity arises.

+

Encodings of elliptic curve points on Curve25519, BN-254 + \(\mathbb{G}_1\) + , BN-254 + \(\mathbb{G}_2\) + , BLS12-381 + \(\mathbb{G}_1\) + , and BLS12-381 + \(\mathbb{G}_2\) + are not affected.

+

Encodings of elliptic curve points on the Pallas and Vesta curves in the Orchard proposal 7 are also not affected.

+
+

Security and Privacy Considerations

+

This ZIP eliminates a potential source of consensus divergence between differing full node implementations. At the time of writing (February 2021), no such divergence exists for any production implementation of Zcash, but the alpha-stage zebrad node implementation would be susceptible to this issue.

+
+

Deployment

+

This ZIP is proposed to activate with Network Upgrade 5.

+
+

References

+ + + + + + + +
1RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
+ + + + + + + +
2Zcash Protocol Specification, Version 2021.1.17 or later [Orchard proposal]
+ + + + + + + +
3Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 4.4: Spend Descriptions
+ + + + + + + +
4Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 4.5: Output Descriptions
+ + + + + + + +
5Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 4.19.3 Decryption using a Full Viewing Key (Sapling and Orchard)
+ + + + + + + +
6Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.8.3: Jubjub
+ + + + + + + +
7Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.4.8.6: Pallas and Vesta
+ + + + + + + +
8Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.6.4: Sapling Payment Addresses
+ + + + + + + +
9Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 5.6.7: Sapling Full Viewing Keys
+ + + + + + + +
10Zcash Protocol Specification, Version 2021.1.17 [Orchard proposal]. Section 7.1: Transaction Encoding and Consensus
+ + + + + + + +
11ZIP 32: Shielded Hierarchical Deterministic Wallets. Sapling extended full viewing keys
+ + + + + + + +
12ZIP 200: Network Upgrade Activation Mechanism
+ + + + + + + +
13ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules
+ + + + + + + +
14ZIP 251: Deployment of the Canopy Network Upgrade
+ + + + + + + +
15jubjub Rust crate
+
\ No newline at end of file