diff --git a/README.rst b/README.rst index d1671737..bd40c37c 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/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/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" diff --git a/index.html b/index.html index 2811a51c..d3c0245b 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 diff --git a/zip-0216.rst b/zip-0216.rst index 83707929..ac904c89 100644 --- a/zip-0216.rst +++ b/zip-0216.rst @@ -1,8 +1,208 @@ :: ZIP: 216 - Title: Require Canonical Point Encodings - Owners: Daira Hopwood - Status: Reserved + Title: Require Canonical Jubjub Point Encodings + Owners: Jack Grigg + Daira Hopwood + Status: Proposed Category: Consensus + Created: 2021-02-11 + License: MIT Discussions-To: + + +Terminology +=========== + +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 +======== + +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. [#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 :math:`u\!`-coordinate is +zero, there are two encodings that will be accepted: + +.. code-block:: 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 points on the Jubjub curve with :math:`u\!`-coordinate zero: + +- :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 +============= + +Let :math:`\mathsf{abst}_{\mathbb{J}}`, :math:`\mathsf{repr}_{\mathbb{J}}`, and +:math:`q_{\mathbb{J}}` be as defined in [#protocol-jubjub]_. + +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. + + +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. + +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 (: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 +=================================== + +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 +========== + +.. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#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 `_