From b336b8936dff509ed87f8374225e84b14c00b736 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Thu, 11 Mar 2021 18:53:45 +0000 Subject: [PATCH] ZIP 216: non-canonical encodings of SpendDescription.{cv, rk} and OutputDescription.{cv, epk} will already be rejected. Signed-off-by: Daira Hopwood --- zip-0216.html | 51 ++++++++++++++++++++++++++++++--------------------- zip-0216.rst | 40 +++++++++++++++++++++++++++++----------- 2 files changed, 59 insertions(+), 32 deletions(-) diff --git a/zip-0216.html b/zip-0216.html index 756bbce8..fafac2ef 100644 --- a/zip-0216.html +++ b/zip-0216.html @@ -48,7 +48,8 @@ Discussions-To: <https://g \(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.)

+

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.

+

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 @@ -80,12 +81,6 @@ Discussions-To: <https://g

In Sapling Spend descriptions 3:

    -
  • - \(\mathtt{cv}\) -
    • -
  • - \(\mathtt{rk}\) -
  • the \(\underline{R}\) component (i.e. the first @@ -95,18 +90,7 @@ Discussions-To: <https://g RedDSA signature.
-

In Sapling Output descriptions 4:

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

In transactions 10:

+

In transactions 10:

  • the @@ -120,7 +104,7 @@ Discussions-To: <https://g

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 5:

(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. 10)

+

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:

+
+
    +
  • + \(\mathtt{cv}\) +
    • +
  • + \(\mathtt{rk}\) +
    • +
+
+

In Sapling Output descriptions 4:

+
+
    +
  • + \(\mathtt{cv}\) +
    • +
  • + \(\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)}\) . These requirements MAY be enforced in advance of NU5 activation.

diff --git a/zip-0216.rst b/zip-0216.rst index c4740c7c..9dd86423 100644 --- a/zip-0216.rst +++ b/zip-0216.rst @@ -67,10 +67,13 @@ and used those to derive transaction IDs, would derive different IDs than nodes 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.) +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. + +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 @@ -95,16 +98,9 @@ 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 @@ -119,6 +115,28 @@ Sapling transmitted note ciphertext [#protocol-decryptovk]_: consensus-critical only in the case of a shielded coinbase output. [#protocol-txnencodingandconsensus]_) +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: + + - :math:`\mathtt{cv}` + - :math:`\mathtt{rk}` + +In Sapling Output descriptions [#protocol-outputdesc]_: + + - :math:`\mathtt{cv}` + - :math:`\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