zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Include the Human-Readable Part in the padding used to check for malleation. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-07-13 23:51:02 +01:00
parent 5d98ec714a
commit 5e0769d295
2 changed files with 23 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
zip-0316.html
View File

@ -175,7 +175,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
-bit script hash of a P2SH address <a id="id8" class="footnote_reference" href="#p2sh">10</a>, or the
<span class="math">\(160\)</span>
-bit validating key hash of a P2PKH address <a id="id9" class="footnote_reference" href="#p2pkh">9</a>.</p>
<p>We append 16 zero bytes to the concatenated encodings, and then apply the
<p>Let <code>padding</code> be the Human-Readable Part of the Unified Address in US-ASCII, padded to 16 bytes with zero bytes. We append <code>padding</code> to the concatenated encodings, and then apply the
<span class="math">\(\mathsf{F4Jumble}\)</span>
algorithm as described in <a href="#address-hardening">Address Hardening</a>. The output is then encoded with Bech32m <a id="id10" class="footnote_reference" href="#bip-0350">8</a>, ignoring any length restrictions. This is chosen over Bech32 in order to better handle variable-length inputs.</p>
<p>To decode a Unified Address Encoding, a Consumer MUST use the following procedure:</p>
@ -184,7 +184,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<li>Apply
<span class="math">\(\mathsf{F4Jumble}^{-1}\)</span>
(this can also reject if the input is not in the correct range of lengths).</li>
<li>If the result ends in 16 zero bytes, remove them; otherwise reject.</li>
<li>Let <code>padding</code> be the Human-Readable Part, padded to 16 bytes as for encoding. If the result ends in <code>padding</code>, remove these 16 bytes; otherwise reject.</li>
<li>Parse the result as a raw encoding as described above, rejecting the entire Unified Address if it does not parse correctly.</li>
</ul>
<p>For Unified Addresses on Mainnet, the Human-Readable Part (as defined in <a id="id11" class="footnote_reference" href="#bip-0350">8</a>) is “<code>u</code>”. For Unified Addresses on Testnet, the Human-Readable Part is “<code>utest</code>”.</p>
@ -364,12 +364,12 @@ c^{n+m}}{q}\)</span>
bytes.)</p>
</section>
<section id="usage-for-unified-addresses-ufvks-and-uivks"><h4><span class="section-heading">Usage for Unified Addresses, UFVKs, and UIVKs</span><span class="section-anchor"> <a rel="bookmark" href="#usage-for-unified-addresses-ufvks-and-uivks"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>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 16 zero bytes to the raw encoding, then applies
<p>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
<span class="math">\(\mathsf{F4Jumble}\)</span>
before encoding the result with Bech32m.</p>
<p>The Consumer rejects any Bech32m-decoded byte sequence that is less than 48 bytes or greater than 16448 bytes; otherwise it applies
<span class="math">\(\mathsf{F4Jumble}^{-1}\)</span>
. It rejects any result that does not end in 16 zero bytes, before stripping these 16 bytes and parsing the result.</p>
. It rejects any result that does not end in the expected padding, before stripping these 16 bytes and parsing the result.</p>
<p>(48 bytes is the minimum size of a valid UA, UFVK, or UIVK raw encoding plus 16 zero bytes, corresponding to a single Sapling Incoming Viewing Key. 16448 bytes is the largest input/output size supported by
<span class="math">\(\mathsf{F4Jumble}\)</span>
.)</p>
@ -450,6 +450,7 @@ c^{n+m}}{q}\)</span>
</ul>
<p>Note that the size of each piece is at least 24 bytes.</p>
<p>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.</p>
<p>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.</p>
</section>
<section id="efficiency"><h4><span class="section-heading">Efficiency</span><span class="section-anchor"> <a rel="bookmark" href="#efficiency"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The cost is dominated by 4 BLAKE2b compressions for

28
zip-0316.rst
View File

@ -317,11 +317,12 @@ A Receiver Encoding is the raw encoding of a Shielded Payment Address,
or the :math:`160`-bit script hash of a P2SH address [#P2SH]_, or the
:math:`160`-bit validating key hash of a P2PKH address [#P2PKH]_.
We append 16 zero bytes to the concatenated encodings, and then apply
the :math:`\mathsf{F4Jumble}` algorithm as described in `Address Hardening`_.
The output is then encoded with Bech32m [#bip-0350]_, ignoring any
length restrictions. This is chosen over Bech32 in order to better
handle variable-length inputs.
Let ``padding`` be the Human-Readable Part of the Unified Address in
US-ASCII, padded to 16 bytes with zero bytes. We append ``padding`` to
the concatenated encodings, and then apply the :math:`\mathsf{F4Jumble}`
algorithm as described in `Address Hardening`_. The output is then encoded
with Bech32m [#bip-0350]_, ignoring any length restrictions. This is chosen
over Bech32 in order to better handle variable-length inputs.
To decode a Unified Address Encoding, a Consumer MUST use the following
procedure:
@ -329,7 +330,9 @@ procedure:
* Decode using Bech32m, rejecting any address with an incorrect checksum.
* Apply :math:`\mathsf{F4Jumble}^{-1}` (this can also reject if the input
is not in the correct range of lengths).
* If the result ends in 16 zero bytes, remove them; otherwise reject.
* Let ``padding`` be the Human-Readable Part, padded to 16 bytes as for
encoding. If the result ends in ``padding``, remove these 16 bytes;
otherwise reject.
* Parse the result as a raw encoding as described above, rejecting the
entire Unified Address if it does not parse correctly.
@ -513,14 +516,15 @@ Usage for Unified Addresses, UFVKs, and UIVKs
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 16 zero bytes to the raw encoding,
then applies :math:`\mathsf{F4Jumble}` before encoding the result with
Bech32m.
a Unified Address, UFVK, or UIVK appends the HRP, padded to 16 bytes with
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 16448 bytes; otherwise it applies
:math:`\mathsf{F4Jumble}^{-1}`. It rejects any result that does not end
in 16 zero bytes, before stripping these 16 bytes and parsing the result.
in the expected padding, before stripping these 16 bytes and parsing the
result.
(48 bytes is the minimum size of a valid UA, UFVK, or UIVK raw encoding
plus 16 zero bytes, corresponding to a single Sapling Incoming Viewing Key.
@ -574,6 +578,10 @@ 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.
Efficiency
''''''''''