From eb00e2d63b4e1011ec155638bd05e8307a2d08ba Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Sun, 5 Feb 2023 03:15:18 +0000 Subject: [PATCH 1/3] ZIP 216: add "Retroactive applicability" section and clarify that the zero point is not valid for pk_d. Also correct the omission of the nk field of a Sapling full or extended full viewing key. Signed-off-by: Daira Hopwood --- zip-0216.html | 175 ++++++++++++++++++++++++++++++++++++++------------ zip-0216.rst | 83 +++++++++++++++++++----- 2 files changed, 202 insertions(+), 56 deletions(-) diff --git a/zip-0216.html b/zip-0216.html index 1dc50d982..a8778e90d 100644 --- a/zip-0216.html +++ b/zip-0216.html @@ -18,14 +18,16 @@ 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

+

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

+

The terms "settled" and "full validator" in this document are to be interpreted as described in 3.

+

The terms "Mainnet" and "Testnet" in this document are to be interpreted as described in 4.

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 +

The Sapling specification was originally written with the intent that all values, including Jubjub points, are strongly typed with canonical representations. 9 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 20 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
@@ -58,7 +60,7 @@
                 \(\mathsf{repr}_{\mathbb{J}}\)
             , and
                 \(q_{\mathbb{J}}\)
-             be as defined in 6.

+             be as defined in 9.

             
Define a non-canonical compressed encoding of a Jubjub point to be a sequence of
                 \(256\)
              bits,
@@ -80,7 +82,7 @@
                 \(\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:

+            
In Sapling Spend descriptions 6:

             

                 
    
                     
  • the
@@ -92,7 +94,7 @@
                      RedDSA signature.
    • 
                 

             

-            
In transactions 10:

+            
In transactions 13:

             

                 
    
                     
  • the
@@ -106,7 +108,7 @@
             

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

+             field of a Sapling transmitted note ciphertext 8:

             

                 
    
                     
  • 
@@ -116,7 +118,7 @@
             

             
(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 all cases, but is consensus-critical only in the case of a shielded coinbase output. 14)

             
There are some additional fields in the consensus protocol that encode Jubjub points, but where non-canonical encodings MUST already be rejected as a side-effect of existing consensus rules.

             
In Sapling Spend descriptions:

             

@@ -129,7 +131,7 @@
                     
                 
             

-            
In Sapling Output descriptions 4:

+            
In Sapling Output descriptions 7:

             

                 
    
                     
  • 
@@ -145,7 +147,7 @@
             
    In addition, Sapling addresses and full viewing keys MUST be considered invalid when imported if they contain non-canonical Jubjub point encodings, or encodings of points that are not in the prime-order subgroup
                 \(\mathbb{J}^{(r)}\)
             . These requirements MAY be enforced in advance of NU5 activation.
    
-            
    In Sapling addresses 8:
    
+            
    In Sapling addresses 11:
    
             
    
                 
      
                     
    • the encoding of
@@ -153,23 +155,51 @@
                     .
      • 
                 
    
             
    
-            
    In Sapling full viewing keys 9 and extended full viewing keys 11:
    
+            
    In Sapling full viewing keys 12 and extended full viewing keys 16:
    
             
    
                 
      
                     
    • the encoding of
                         \(\mathsf{ak}\)
+                    
      • 
+                    
    • the encoding of
+                        \(\mathsf{nk}\!\)
                     .
      • 
                 
    
             
    
-            
    (
+            
    
+                \(\mathsf{pk_d}\)
+             and
                 \(\mathsf{ak}\)
              also MUST NOT encode the zero point
-                \(\mathcal{O}_{\mathbb{J}}\)
-            .)
    
+                \(\mathcal{O}_{\mathbb{J}}\!\)
+            .
    
+            
    (Some versions of the Zcash protocol specification mistakenly allowed
+                \(\mathsf{pk_d}\)
+             to be the zero point. This was corrected in version 2023.4.0 15 23 to match the implementation in librustzcash as of 22, which has been used in zcashd since zcashd v2.1.2.)
    
             
    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.
    
+            
    Retroactive applicability 
    
+                
    As originally specified, this ZIP required that the new validity rules be applied only after NU5 activation. This was necessary because a transaction containing a non-canonical Jubjub point encoding could have been included in any block before NU5 activation.
    
+                
    However, now that NU5 is a settled upgrade on the Zcash Mainnet and Testnet chains 3 4, it can be observed that there were no such non-canonical encodings in publically visible transaction fields before the Mainnet and Testnet NU5 activations. Therefore, a full validator MAY enforce the above specification retroactively.
    
+                
    It remains possible that there could be non-canonical
+                    \(\mathsf{pk}\star_{\mathsf{d}}\)
+                 encodings in plaintexts obtained by decrypting the
+                    \(\mathsf{C^{out}}\)
+                 field of a Sapling transmitted note ciphertext. Such encodings MUST be rejected by the decryption procedure in 8 after NU5 activation. An implementation MAY also reject them before NU5 activation. Doing so cannot lead to loss of funds sent to a Sapling address that has been correctly generated as specified in 5, because such an address cannot have
+                    \(\mathsf{ivk} = 0\!\)
+                , which is the only case in which
+                    \(\mathsf{pk}\star_{\mathsf{d}}\)
+                 could be non-canonical.
    
+                
    Note: There are no such non-canonical
+                    \(\mathsf{pk}\star_{\mathsf{d}}\)
+                 encodings in the
+                    \(\mathsf{C^{out}}\)
+                 components of shielded coinbase outputs (which are required by consensus to be decryptable by an all-zero
+                    \(\mathsf{ovk}\)
+                 14).
    
+

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.

+

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 18 (which activated with the Canopy network upgrade 19) 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.
    • @@ -197,13 +227,14 @@ , and BLS12-381 \(\mathbb{G}_2\) are not affected.

    -

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

    +

    Encodings of elliptic curve points on the Pallas and Vesta curves in the NU5 proposal 10 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.

+

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 an early alpha version of the zebrad node implementation would have been susceptible to this issue.

Deployment

-

This ZIP is proposed to activate with Network Upgrade 5. Requirements on points encoded in payment addresses and full viewing keys MAY be enforced in advance of NU5 activation.

+

This ZIP activated with Network Upgrade 5. Requirements on points encoded in payment addresses and full viewing keys MAY be enforced in advance of NU5 activation.

+

zcashd PR #6399 21 retroactively enforces canonical encoding of Jubjub points for the entire chain history, as described in the Retroactive applicability section.

References

@@ -218,78 +249,118 @@ - +
2Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal]Zcash Protocol Specification, Version 2023.4.0 or later
- +
- +
3Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.4: Spend DescriptionsZcash Protocol Specification, Version 2023.4.0. Section 3.3: The Block Chain
- +
- +
4Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.5: Output DescriptionsZcash Protocol Specification, Version 2023.4.0. Section 3.3: Mainnet and Testnet
- +
- +
5Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.19.3 Decryption using a Full Viewing Key (Sapling and Orchard)Zcash Protocol Specification, Version 2023.4.0. Section 4.2.2: Sapling Key Components
- +
- +
6Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.3: JubjubZcash Protocol Specification, Version 2023.4.0. Section 4.4: Spend Descriptions
- +
- +
7Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and VestaZcash Protocol Specification, Version 2023.4.0. Section 4.5: Output Descriptions
- +
- +
8Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.1: Sapling Payment AddressesZcash Protocol Specification, Version 2023.4.0. Section 4.19.3 Decryption using a Full Viewing Key (Sapling and Orchard)
- +
- +
9Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing KeysZcash Protocol Specification, Version 2023.4.0. Section 5.4.9.3: Jubjub
- +
- +
10Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and ConsensusZcash Protocol Specification, Version 2023.4.0. Section 5.4.9.6: Pallas and Vesta
- +
+ + + +
11Zcash Protocol Specification, Version 2023.4.0. Section 5.6.3.1: Sapling Payment Addresses
+ + + + + + + +
12Zcash Protocol Specification, Version 2023.4.0. Section 5.6.3.3: Sapling Full Viewing Keys
+ + + + + + + +
13Zcash Protocol Specification, Version 2023.4.0. Section 7.1: Transaction Encoding and Consensus
+ + + + + + + +
14Zcash Protocol Specification, Version 2023.4.0. Section 7.1.2: Transaction Consensus Rules
+ + + + + + + +
15Zcash Protocol Specification, Version 2023.4.0. Section 10: Change History — 2023.4.0
+ + + + @@ -297,7 +368,7 @@
16 ZIP 32: Shielded Hierarchical Deterministic Wallets. Sapling extended full viewing keys
- + @@ -305,7 +376,7 @@
1217 ZIP 200: Network Upgrade Mechanism
- + @@ -313,7 +384,7 @@
1318 ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules
- + @@ -321,11 +392,35 @@
1419 ZIP 251: Deployment of the Canopy Network Upgrade
- +
1520 jubjub Rust crate
+ + + + + + + +
21zcash/zcash PR 6399: Retroactively enable ZIP 216 before NU5 activation
+ + + + + + + +
22zcash/librustzcash PR 109: PaymentAddress encapsulation
+ + + + + + + +
23zcash/zips issue 664: `Sapling pk_d should not allow the zero point
diff --git a/zip-0216.rst b/zip-0216.rst index 70a35ecd2..18f4deac3 100644 --- a/zip-0216.rst +++ b/zip-0216.rst @@ -20,6 +20,12 @@ The key word "MUST" in this document is to be interpreted as described in RFC 21 The term "network upgrade" in this document is to be interpreted as described in ZIP 200. [#zip-0200]_ +The terms "settled" and "full validator" in this document are to be interpreted as +described in [#protocol-blockchain]_. + +The terms "Mainnet" and "Testnet" in this document are to be interpreted as described +in [#protocol-networks]_. + Abstract ======== @@ -113,7 +119,7 @@ Sapling transmitted note ciphertext [#protocol-decryptovk]_: (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-txnencoding]_) +[#protocol-txnconsensus]_) There are some additional fields in the consensus protocol that encode Jubjub points, but where non-canonical encodings MUST already be rejected as a side-effect of @@ -150,14 +156,47 @@ In Sapling addresses [#protocol-saplingpaymentaddrencoding]_: In Sapling full viewing keys [#protocol-saplingfullviewingkeyencoding]_ and extended full viewing keys [#zip-0032-extfvk]_: - - the encoding of :math:`\mathsf{ak}`. + - the encoding of :math:`\mathsf{ak}` + - the encoding of :math:`\mathsf{nk}\!`. + +:math:`\mathsf{pk_d}` and :math:`\mathsf{ak}` also MUST NOT encode the zero point +:math:`\mathcal{O}_{\mathbb{J}}\!`. -(:math:`\mathsf{ak}` also MUST NOT encode the zero point :math:`\mathcal{O}_{\mathbb{J}}`.) +(Some versions of the Zcash protocol specification mistakenly allowed :math:`\mathsf{pk_d}` +to be the zero point. This was corrected in version 2023.4.0 [#protocol-2023.4.0]_ +[#zips-issue664]_ to match the implementation in librustzcash as of [#librustzcash-pr109]_, +which has been used in `zcashd` since `zcashd` v2.1.2.) 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. +Retroactive applicability +------------------------- + +As originally specified, this ZIP required that the new validity rules be applied only +after NU5 activation. This was necessary because a transaction containing a non-canonical +Jubjub point encoding could have been included in any block before NU5 activation. + +However, now that NU5 is a settled upgrade on the Zcash Mainnet and Testnet chains +[#protocol-blockchain]_ [#protocol-networks]_, it can be observed that there were no such +non-canonical encodings in publically visible transaction fields before the Mainnet and +Testnet NU5 activations. Therefore, a full validator MAY enforce the above specification +retroactively. + +It remains possible that there could be non-canonical :math:`\mathsf{pk}\star_{\mathsf{d}}` +encodings in plaintexts obtained by decrypting the :math:`\mathsf{C^{out}}` field of a +Sapling transmitted note ciphertext. Such encodings MUST be rejected by the decryption +procedure in [#protocol-decryptovk]_ after NU5 activation. An implementation MAY also +reject them before NU5 activation. Doing so cannot lead to loss of funds sent to a Sapling +address that has been correctly generated as specified in [#protocol-saplingkeycomponents]_, +because such an address cannot have :math:`\mathsf{ivk} = 0\!`, which is the only case in +which :math:`\mathsf{pk}\star_{\mathsf{d}}` could be non-canonical. + +Note: There are no such non-canonical :math:`\mathsf{pk}\star_{\mathsf{d}}` encodings in +the :math:`\mathsf{C^{out}}` components of shielded coinbase outputs (which are required +by consensus to be decryptable by an all-zero :math:`\mathsf{ovk}` [#protocol-txnconsensus]_). + Rationale ========= @@ -200,32 +239,44 @@ 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. +production implementation of Zcash, but an early alpha version of the `zebrad` node +implementation would have been susceptible to this issue. Deployment ========== -This ZIP is proposed to activate with Network Upgrade 5. Requirements on points encoded in -payment addresses and full viewing keys MAY be enforced in advance of NU5 activation. +This ZIP activated with Network Upgrade 5. Requirements on points encoded in payment +addresses and full viewing keys MAY be enforced in advance of NU5 activation. + +`zcashd` PR #6399 [#zcashd-pr6399]_ retroactively enforces canonical encoding of Jubjub +points for the entire chain history, as described in the `Retroactive applicability`_ +section. References ========== .. [#RFC2119] `RFC 2119: Key words for use in RFCs to Indicate Requirement Levels `_ -.. [#protocol] `Zcash Protocol Specification, Version 2021.2.16 or later [NU5 proposal] `_ -.. [#protocol-spenddesc] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.4: Spend Descriptions `_ -.. [#protocol-outputdesc] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.5: Output Descriptions `_ -.. [#protocol-decryptovk] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 4.19.3 Decryption using a Full Viewing Key (Sapling and Orchard) `_ -.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.3: Jubjub `_ -.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.4.9.6: Pallas and Vesta `_ -.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.1: Sapling Payment Addresses `_ -.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 5.6.3.3: Sapling Full Viewing Keys `_ -.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2021.2.16 [NU5 proposal]. Section 7.1: Transaction Encoding and Consensus `_ +.. [#protocol] `Zcash Protocol Specification, Version 2023.4.0 or later `_ +.. [#protocol-blockchain] `Zcash Protocol Specification, Version 2023.4.0. Section 3.3: The Block Chain `_ +.. [#protocol-networks] `Zcash Protocol Specification, Version 2023.4.0. Section 3.3: Mainnet and Testnet `_ +.. [#protocol-saplingkeycomponents] `Zcash Protocol Specification, Version 2023.4.0. Section 4.2.2: Sapling Key Components `_ +.. [#protocol-spenddesc] `Zcash Protocol Specification, Version 2023.4.0. Section 4.4: Spend Descriptions `_ +.. [#protocol-outputdesc] `Zcash Protocol Specification, Version 2023.4.0. Section 4.5: Output Descriptions `_ +.. [#protocol-decryptovk] `Zcash Protocol Specification, Version 2023.4.0. Section 4.19.3 Decryption using a Full Viewing Key (Sapling and Orchard) `_ +.. [#protocol-jubjub] `Zcash Protocol Specification, Version 2023.4.0. Section 5.4.9.3: Jubjub `_ +.. [#protocol-pallasandvesta] `Zcash Protocol Specification, Version 2023.4.0. Section 5.4.9.6: Pallas and Vesta `_ +.. [#protocol-saplingpaymentaddrencoding] `Zcash Protocol Specification, Version 2023.4.0. Section 5.6.3.1: Sapling Payment Addresses `_ +.. [#protocol-saplingfullviewingkeyencoding] `Zcash Protocol Specification, Version 2023.4.0. Section 5.6.3.3: Sapling Full Viewing Keys `_ +.. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2023.4.0. Section 7.1: Transaction Encoding and Consensus `_ +.. [#protocol-txnconsensus] `Zcash Protocol Specification, Version 2023.4.0. Section 7.1.2: Transaction Consensus Rules `_ +.. [#protocol-2023.4.0] `Zcash Protocol Specification, Version 2023.4.0. Section 10: Change History — 2023.4.0 `_ .. [#zip-0032-extfvk] `ZIP 32: Shielded Hierarchical Deterministic Wallets. Sapling extended full viewing keys `_ .. [#zip-0200] `ZIP 200: Network Upgrade 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 `_ +.. [#zcashd-pr6399] `zcash/zcash PR 6399: Retroactively enable ZIP 216 before NU5 activation `_ +.. [#librustzcash-pr109] `zcash/librustzcash PR 109: PaymentAddress encapsulation `_ +.. [#zips-issue664] `zcash/zips issue 664: `Sapling pk\_d should not allow the zero point `_ From 43d6e9a670e8699ec62df8beef969fa4840f4596 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Sun, 5 Feb 2023 03:42:16 +0000 Subject: [PATCH 2/3] ZIP 216: cosmetics. Signed-off-by: Daira Hopwood --- zip-0216.html | 34 +++++++++++++++++----------------- zip-0216.rst | 28 ++++++++++++++-------------- 2 files changed, 31 insertions(+), 31 deletions(-) diff --git a/zip-0216.html b/zip-0216.html index a8778e90d..956d8af33 100644 --- a/zip-0216.html +++ b/zip-0216.html @@ -40,14 +40,14 @@ -coordinate zero:

  • - \((0, 1)\) + \((0, 1)\!\) , which is the identity;
  • - \((0, -1)\) + \((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\) + \(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. In fact, for some of the fields that would otherwise be affected, the issue does not occur because there are already consensus rules that prohibit small-order points, and this incidentally prohibits non-canonical encodings.

@@ -55,25 +55,25 @@

Specification

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

Define a non-canonical compressed encoding of a Jubjub point to be a sequence of \(256\) bits, - \(b\) + \(b\!\) , such that \(\mathsf{abst}_{\mathbb{J}}(b) \neq \bot\) and - \(\mathsf{repr_{\mathbb{J}}}\big(\mathsf{abst}_{\mathbb{J}}(b)\big) \neq b\) + \(\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)\) + \(\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 a \(\mathtt{0x01}\) byte, followed by @@ -112,7 +112,7 @@

  • - \(\mathsf{pk}\star_{\mathsf{d}}\) + \(\mathsf{pk}\star_{\mathsf{d}}\!\) .
@@ -127,8 +127,8 @@ \(\mathtt{cv}\)
  • - \(\mathtt{rk}\) -
    • + \(\mathtt{rk}\!\) + .

    In Sapling Output descriptions 7:

    @@ -138,20 +138,20 @@ \(\mathtt{cv}\)
  • - \(\mathtt{ephemeralKey}\) + \(\mathtt{ephemeralKey}\!\) .

    • These fields cannot by consensus contain small-order points. All of the points with non-canonical encodings are small-order.

    Implementations MAY choose to reject non-canonical encodings of the above four fields early in decoding of a transaction. This eliminates the risk that parts of the transaction could be re-serialized from their internal representation to a different byte sequence than in the original transaction, e.g. when calculating transaction IDs.

    In addition, Sapling addresses and full viewing keys MUST be considered invalid when imported if they contain non-canonical Jubjub point encodings, or encodings of points that are not in the prime-order subgroup - \(\mathbb{J}^{(r)}\) + \(\mathbb{J}^{(r)}\!\) . These requirements MAY be enforced in advance of NU5 activation.

    In Sapling addresses 11:

    • the encoding of - \(\mathsf{pk_d}\) + \(\mathsf{pk_d}\!\) .
    @@ -219,11 +219,11 @@ \(\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\) + \(\mathbb{G}_1\!\) , BN-254 - \(\mathbb{G}_2\) + \(\mathbb{G}_2\!\) , BLS12-381 - \(\mathbb{G}_1\) + \(\mathbb{G}_1\!\) , and BLS12-381 \(\mathbb{G}_2\) are not affected.

    diff --git a/zip-0216.rst b/zip-0216.rst index 18f4deac3..1fde96cd9 100644 --- a/zip-0216.rst +++ b/zip-0216.rst @@ -59,11 +59,11 @@ 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. +- :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`. +: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 @@ -85,16 +85,16 @@ required 4 specification revisions to get right, conclusively demonstrates the p Specification ============= -Let :math:`\mathsf{abst}_{\mathbb{J}}`, :math:`\mathsf{repr}_{\mathbb{J}}`, and +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`. +: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)`. +: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 a :math:`\mathtt{0x01}` byte, followed by :math:`30` zero bytes, and then a :math:`\mathtt{0x80}` byte. @@ -115,7 +115,7 @@ In transactions [#protocol-txnencoding]_: 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}}`. + - :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. @@ -128,12 +128,12 @@ existing consensus rules. In Sapling Spend descriptions: - :math:`\mathtt{cv}` - - :math:`\mathtt{rk}` + - :math:`\mathtt{rk}\!`. In Sapling Output descriptions [#protocol-outputdesc]_: - :math:`\mathtt{cv}` - - :math:`\mathtt{ephemeralKey}`. + - :math:`\mathtt{ephemeralKey}\!`. These fields cannot by consensus contain small-order points. All of the points with non-canonical encodings are small-order. @@ -146,12 +146,12 @@ transaction IDs. In addition, Sapling addresses and full viewing keys MUST be considered invalid when imported if they contain non-canonical Jubjub point encodings, or encodings of points -that are not in the prime-order subgroup :math:`\mathbb{J}^{(r)}`. These requirements +that are not in the prime-order subgroup :math:`\mathbb{J}^{(r)}\!`. These requirements \MAY be enforced in advance of NU5 activation. In Sapling addresses [#protocol-saplingpaymentaddrencoding]_: - - the encoding of :math:`\mathsf{pk_d}`. + - the encoding of :math:`\mathsf{pk_d}\!`. In Sapling full viewing keys [#protocol-saplingfullviewingkeyencoding]_ and extended full viewing keys [#zip-0032-extfvk]_: @@ -226,8 +226,8 @@ 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 +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 NU5 proposal From 14e6fb2ced968f00463792d9f2b0f864d8e03eea Mon Sep 17 00:00:00 2001 From: Daira Emma Hopwood Date: Thu, 2 Mar 2023 13:33:37 +0000 Subject: [PATCH 3/3] ZIP 216: apply suggestions from ZIP sync meeting. Co-authored-by: Deirdre Connolly Signed-off-by: Daira Emma Hopwood --- zip-0216.html | 20 ++++++++++++++------ zip-0216.rst | 9 +++++---- 2 files changed, 19 insertions(+), 10 deletions(-) diff --git a/zip-0216.html b/zip-0216.html index 956d8af33..5313eee47 100644 --- a/zip-0216.html +++ b/zip-0216.html @@ -175,7 +175,7 @@ .

    (Some versions of the Zcash protocol specification mistakenly allowed \(\mathsf{pk_d}\) - to be the zero point. This was corrected in version 2023.4.0 15 23 to match the implementation in librustzcash as of 22, which has been used in zcashd since zcashd v2.1.2.)

    + to be the zero point. This was corrected in version 2023.4.0 15 24 to match the implementation in librustzcash as of 23, which has been used in zcashd since zcashd v2.1.2.)

    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.

    Retroactive applicability

    As originally specified, this ZIP required that the new validity rules be applied only after NU5 activation. This was necessary because a transaction containing a non-canonical Jubjub point encoding could have been included in any block before NU5 activation.

    @@ -230,11 +230,11 @@

    Encodings of elliptic curve points on the Pallas and Vesta curves in the NU5 proposal 10 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 an early alpha version of the zebrad node implementation would have been susceptible to this issue.

    +

    This ZIP eliminates a potential source of consensus divergence between differing full node implementations. As of February 2023, no known divergence of this type exists for any production implementation of Zcash, but an early alpha version of the zebrad node implementation would have been susceptible to this issue.

    Deployment

    This ZIP activated with Network Upgrade 5. Requirements on points encoded in payment addresses and full viewing keys MAY be enforced in advance of NU5 activation.

    -

    zcashd PR #6399 21 retroactively enforces canonical encoding of Jubjub points for the entire chain history, as described in the Retroactive applicability section.

    +

    zcashd PRs #6000 21 and #6399 22 retroactively enforce canonical encoding of Jubjub points for the entire chain history, as described in the Retroactive applicability section.

    References

    @@ -397,10 +397,18 @@
    - +
    + + + +
    21zcash/zcash PR 6000: Enable ZIP 216 for blocks prior to NU5 activation
    + + + + @@ -408,7 +416,7 @@
    22 zcash/zcash PR 6399: Retroactively enable ZIP 216 before NU5 activation
    - + @@ -416,7 +424,7 @@
    2223 zcash/librustzcash PR 109: PaymentAddress encapsulation
    - + diff --git a/zip-0216.rst b/zip-0216.rst index 1fde96cd9..0e1e542bf 100644 --- a/zip-0216.rst +++ b/zip-0216.rst @@ -238,7 +238,7 @@ 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 +implementations. As of February 2023, no known divergence of this type exists for any production implementation of Zcash, but an early alpha version of the `zebrad` node implementation would have been susceptible to this issue. @@ -249,9 +249,9 @@ Deployment This ZIP activated with Network Upgrade 5. Requirements on points encoded in payment addresses and full viewing keys MAY be enforced in advance of NU5 activation. -`zcashd` PR #6399 [#zcashd-pr6399]_ retroactively enforces canonical encoding of Jubjub -points for the entire chain history, as described in the `Retroactive applicability`_ -section. +`zcashd` PRs #6000 [#zcashd-pr6000]_ and #6399 [#zcashd-pr6399]_ retroactively enforce +canonical encoding of Jubjub points for the entire chain history, as described in the +`Retroactive applicability`_ section. References @@ -277,6 +277,7 @@ References .. [#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 `_ +.. [#zcashd-pr6000] `zcash/zcash PR 6000: Enable ZIP 216 for blocks prior to NU5 activation `_ .. [#zcashd-pr6399] `zcash/zcash PR 6399: Retroactively enable ZIP 216 before NU5 activation `_ .. [#librustzcash-pr109] `zcash/librustzcash PR 109: PaymentAddress encapsulation `_ .. [#zips-issue664] `zcash/zips issue 664: `Sapling pk\_d should not allow the zero point `_
    2324 zcash/zips issue 664: `Sapling pk_d should not allow the zero point