mirror of https://github.com/zcash/zips.git
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:
parent
5d98ec714a
commit
5e0769d295
|
@ -175,7 +175,7 @@ Discussions-To: <<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: <<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
28
zip-0316.rst
|
@ -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
|
||||
''''''''''
|
||||
|
||||
|
|
Loading…
Reference in New Issue