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

Correct minimum length. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-04-22 22:23:41 +01:00
parent 95f596ea16
commit cec980b004
2 changed files with 15 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
zip-0316.html
View File

@ -275,7 +275,7 @@ c^{n+m}}{q}\)</span>
of length
<span class="math">\(\ell_M\)</span>
bytes such that
<span class="math">\(22 \leq \ell_M \leq 16448\)</span>
<span class="math">\(48 \leq \ell_M \leq 16448\)</span>
, define
<span class="math">\(\mathsf{F4Jumble}(M)\)</span>
by:</p>
@ -343,14 +343,14 @@ c^{n+m}}{q}\)</span>
<span class="math">\(128\)</span>
bytes.)</p>
</section>
<section id="usage-for-unified-addresses"><h4><span class="section-heading">Usage for Unified Addresses</span><span class="section-anchor"> <a rel="bookmark" href="#usage-for-unified-addresses"><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 appends 16 zero bytes to the encoding of the sequence of (Typecode, length, addr), then applies
<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
<span class="math">\(\mathsf{F4Jumble}\)</span>
before encoding the result with Bech32m.</p>
<p>The Sender rejects any Bech32m-decoded byte sequence that is less than 22 bytes or greater than 16448 bytes; otherwise it applies
<p>The Sender 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>
<p>(22 bytes is the minimum size of a valid encoded Address sequence, corresponding to just a Transparent Address, and 16448 bytes is the largest input/output size supported by
<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>
</section>

20
zip-0316.rst
View File

@ -449,7 +449,7 @@ length :math:`\ell_H` bytes. Let :math:`G_i` be a XOF (a hash function with
extendable output length) based on :math:`H`, personalized by :math:`i`.
Given input :math:`M` of length :math:`\ell_M` bytes such that
:math:`22 \leq \ell_M \leq 16448`, define :math:`\mathsf{F4Jumble}(M)`
:math:`48 \leq \ell_M \leq 16448`, define :math:`\mathsf{F4Jumble}(M)`
by:
* let :math:`\ell_L = \mathsf{min}(\ell_H, \mathsf{floor}(\ell_M/2))`
@ -482,23 +482,23 @@ concatenation of
(In practice the lengths :math:`\ell_L` and :math:`\ell_R` will be roughly
the same until :math:`\ell_M` is larger than :math:`128` bytes.)
Usage for Unified Addresses
'''''''''''''''''''''''''''
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 appends 16 zero bytes to the encoding of the sequence
of (Typecode, length, addr), then applies :math:`\mathsf{F4Jumble}`
before encoding the result with Bech32m.
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.
The Sender rejects any Bech32m-decoded byte sequence that is less than
22 bytes or greater than 16448 bytes; otherwise it applies
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.
(22 bytes is the minimum size of a valid encoded Address sequence,
corresponding to just a Transparent Address, and 16448 bytes is the largest
input/output size supported by :math:`\mathsf{F4Jumble}`.)
(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 :math:`\mathsf{F4Jumble}`.)
Heuristic analysis
''''''''''''''''''