From 436c1ee41f6cdc80ebe4a314c676dd7005fe5b79 Mon Sep 17 00:00:00 2001 From: Daira-Emma Hopwood Date: Wed, 13 Mar 2024 14:08:44 +0000 Subject: [PATCH 1/2] ZIP 316: change the minimum F4Jumble^{-1} input length to allow for any possible Metadata Item with a Transparent P2PKH Receiver. Signed-off-by: Daira-Emma Hopwood --- zip-0316.html | 32 ++++++++++++++++++++++++++++---- zip-0316.rst | 41 ++++++++++++++++++++++++++++++++++------- 2 files changed, 62 insertions(+), 11 deletions(-) diff --git a/zip-0316.html b/zip-0316.html index 31323f82..a138c1ae 100644 --- a/zip-0316.html +++ b/zip-0316.html @@ -666,16 +666,40 @@ c^{n+m}}{q}.\)

In order to prevent the generic attack against nonmalleability, there needs to be some redundancy in the encoding. Therefore, the Producer of a Unified Address, UFVK, or UIVK appends the HRP, padded to 16 bytes with zero bytes, to the raw encoding, then applies \(\mathsf{F4Jumble}\) before encoding the result with Bech32m.

-

The Consumer rejects any Bech32m-decoded byte sequence that is less than 48 bytes or greater than +

The Consumer rejects any Bech32m-decoded byte sequence that is less than 40 bytes or greater than \(\ell^\mathsf{MAX}_M\) bytes; otherwise it applies \(\mathsf{F4Jumble}^{-1}.\) It rejects any result that does not end in the expected 16-byte padding, before stripping these 16 bytes and parsing the result.

-

(48 bytes allows for the minimum size of a shielded UA, UFVK, or UIVK Item encoding to be 32 bytes, taking into account 16 bytes of padding. Although there is currently no shielded Item encoding that short, it is plausible that one might be added in future. + +

Rationale for length restrictions

+

A minimum input length to + \(\mathsf{F4Jumble}^{-1}\) + of 40 bytes allows for the minimum size of a UA/UVK Item encoding to be 24 bytes including the typecode and length, taking into account 16 bytes of padding. This allows for a UA containing only a Transparent P2PKH Receiver and any Metadata Item:

+
    +
  • Transparent P2PKH Receiver Item: +
      +
    • 1-byte typecode
      • +
    • 1-byte encoding of length
      • +
    • 20-byte transparent address hash
      • +
    +
    • +
  • Metadata Item: +
      +
    • 1-byte typecode
      • +
    • 1-byte encoding of length
      • +
    • metadata encoding, potentially 0-length for future Metadata Items
      • +
    +
    • +
+

\(\ell^\mathsf{MAX}_M\) bytes is the largest input/output size supported by \(\mathsf{F4Jumble}.\) - )

+

+

Note that Revision 0 of this ZIP specified a minimum input length to + \(\mathsf{F4Jumble}^{-1}\) + of 48 bytes. Since there were no sets of UA/UVK Item Encodings valid in Revision 0 to which a byte sequence of length between 40 and 47 bytes inclusive could be parsed, the difference between the 40 and 48-byte restrictions is not observable, other than potentially affecting which error is reported. A Consumer supporting Revision 1 of this specification MAY therefore apply either the 48-byte or 40-byte minimum to Revision 0 UA/UVKs.

Heuristic analysis

A 3-round unkeyed Feistel, as shown, is not sufficient:

@@ -751,7 +775,7 @@ c^{n+m}}{q}.\) \(y' \neq y,\) all four pieces are randomized. -

Note that the size of each piece is at least 24 bytes.

+

Note that the size of each piece is at least 20 bytes.

It would be possible to make an attack more expensive by making the work done by a Producer more expensive. (This wouldn't necessarily have to increase the work done by the Consumer.) However, given that Unified Addresses may need to be produced on constrained computing platforms, this was not considered to be beneficial overall.

The padding contains the HRP so that the HRP has the same protection against malleation as the rest of the address. This may help against cross-network attacks, or attacks that confuse addresses with viewing keys.

diff --git a/zip-0316.rst b/zip-0316.rst index 8460dcb2..ac3209f1 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -1098,16 +1098,43 @@ zero bytes, to the raw encoding, then applies :math:`\mathsf{F4Jumble}` before encoding the result with Bech32m. The Consumer rejects any Bech32m-decoded byte sequence that is less than -48 bytes or greater than :math:`\ell^\mathsf{MAX}_M` bytes; otherwise it +40 bytes or greater than :math:`\ell^\mathsf{MAX}_M` bytes; otherwise it applies :math:`\mathsf{F4Jumble}^{-1}.` It rejects any result that does not end in the expected 16-byte padding, before stripping these 16 bytes and parsing the result. -(48 bytes allows for the minimum size of a shielded UA, UFVK, or UIVK Item -encoding to be 32 bytes, taking into account 16 bytes of padding. Although -there is currently no shielded Item encoding that short, it is plausible -that one might be added in future. :math:`\ell^\mathsf{MAX}_M` bytes is -the largest input/output size supported by :math:`\mathsf{F4Jumble}.`) +Rationale for length restrictions +''''''''''''''''''''''''''''''''' + +A minimum input length to :math:`\mathsf{F4Jumble}^{-1}` of 40 bytes +allows for the minimum size of a UA/UVK Item encoding to be 24 bytes +including the typecode and length, taking into account 16 bytes of padding. +This allows for a UA containing only a Transparent P2PKH Receiver and any +Metadata Item: + +* Transparent P2PKH Receiver Item: + + * 1-byte typecode + * 1-byte encoding of length + * 20-byte transparent address hash + +* Metadata Item: + + * 1-byte typecode + * 1-byte encoding of length + * metadata encoding, potentially 0-length for future Metadata Items + +:math:`\ell^\mathsf{MAX}_M` bytes is the largest input/output size +supported by :math:`\mathsf{F4Jumble}.` + +Note that Revision 0 of this ZIP specified a minimum input length to +:math:`\mathsf{F4Jumble}^{-1}` of 48 bytes. Since there were no sets +of UA/UVK Item Encodings valid in Revision 0 to which a byte sequence +of length between 40 and 47 bytes inclusive could be parsed, the +difference between the 40 and 48-byte restrictions is not observable, +other than potentially affecting which error is reported. A Consumer +supporting Revision 1 of this specification MAY therefore apply either +the 48-byte or 40-byte minimum to Revision 0 UA/UVKs. Heuristic analysis '''''''''''''''''' @@ -1149,7 +1176,7 @@ A 4-round Feistel thwarts this and similar attacks. Defining :math:`x` and * if :math:`x' \neq x` and :math:`y' \neq y,` all four pieces are randomized. -Note that the size of each piece is at least 24 bytes. +Note that the size of each piece is at least 20 bytes. It would be possible to make an attack more expensive by making the work done by a Producer more expensive. (This wouldn't necessarily have to From 31fa493afb53dccc31115da9f9d5d0255db91c3a Mon Sep 17 00:00:00 2001 From: Daira-Emma Hopwood Date: Wed, 13 Mar 2024 14:26:38 +0000 Subject: [PATCH 2/2] ZIP 316: say how to maximize interoperability by using Revision 0 UA/UVKs (intentionally without adding any conformance requirement). Signed-off-by: Daira-Emma Hopwood --- zip-0316.html | 1 + zip-0316.rst | 8 ++++++++ 2 files changed, 9 insertions(+) diff --git a/zip-0316.html b/zip-0316.html index a138c1ae..e78df9f0 100644 --- a/zip-0316.html +++ b/zip-0316.html @@ -174,6 +174,7 @@ Discussions-To: <https://g
  • prefix || “view” for Unified Full Viewing Keys on Mainnet;
  • prefix || “viewtest” for Unified Full Viewing Keys on Testnet.
    • +

    While support for Revision 1 UAs/UVKs is still being rolled out across the Zcash ecosystem, a Producer can maximize interoperability by generating a Revision 0 UA/UVK in cases where the conditions on its use are met (i.e. there are no MUST-understand Metadata Items, and at least one shielded item). At some point when Revision 1 UA/UVKs are widely supported, this will be unnecessary and it will be sufficient to always produce Revision 1 UA/UVKs.

    Encoding of Unified Addresses

    Rather than defining a Bech32 string encoding of Orchard Shielded Payment Addresses, we instead define a Unified Address format that is able to encode a set of Receivers of different types. This enables the Consumer of a Unified Address to choose the Receiver of the best type it supports, providing a better user experience as new Receiver Types are added in the future.

    diff --git a/zip-0316.rst b/zip-0316.rst index ac3209f1..eebffe36 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -338,6 +338,14 @@ The Human-Readable Parts of Unified Viewing Keys are defined as: * *prefix* || “``view``” for Unified Full Viewing Keys on Mainnet; * *prefix* || “``viewtest``” for Unified Full Viewing Keys on Testnet. +While support for Revision 1 UAs/UVKs is still being rolled out across +the Zcash ecosystem, a Producer can maximize interoperability by +generating a Revision 0 UA/UVK in cases where the conditions on its +use are met (i.e. there are no MUST-understand Metadata Items, and at +least one shielded item). At some point when Revision 1 UA/UVKs are +widely supported, this will be unnecessary and it will be sufficient +to always produce Revision 1 UA/UVKs. + Encoding of Unified Addresses -----------------------------