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

ZIP 316: more changes to include UVKs and Metadata Items where applicable. 

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-12-28 15:30:15 +00:00
parent 200e243e14
commit 1d75ed6548
2 changed files with 41 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
zip-0316.html
View File

@ -282,14 +282,14 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<li>Within a single UA or UVK, all HD-derived Receivers, FVKs, and IVKs SHOULD represent an Address or Viewing Key for the same account (as used in the ZIP 32 or BIP 44 Account level).</li>
<li>For Transparent Addresses, the Receiver Encoding does not include the first two bytes of a raw encoding.</li>
<li>There is intentionally no Typecode defined for a Sprout Shielded Payment Address or Sprout Incoming Viewing Key. Since it is no longer possible (since activation of ZIP 211 in the Canopy network upgrade <a id="id21" class="footnote_reference" href="#zip-0211">17</a>) to send funds into the Sprout chain value pool, this would not be generally useful.</li>
<li>Consumers MUST ignore constituent Addresses/Viewing Keys with Typecodes they do not recognize.</li>
<li>Consumers MUST ignore constituent Items with Typecodes they do not recognize.</li>
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which the same Typecode appears more than once, or that include both P2SH and P2PKH Transparent Addresses, or that contain only a Transparent Address.</li>
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which <em>any</em> constituent address does not meet the validation requirements of its Receiver Encoding, as specified in the Zcash Protocol Specification <a id="id22" class="footnote_reference" href="#protocol-nu5">2</a>.</li>
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which <em>any</em> constituent Item does not meet the validation requirements of its encoding, as specified in this ZIP and the Zcash Protocol Specification <a id="id22" class="footnote_reference" href="#protocol-nu5">2</a>.</li>
<li>Consumers MUST reject Unified Addresses/Viewing Keys in which the constituent Items are not ordered in ascending Typecode order. Note that this is different to priority order, and does not affect which Receiver in a Unified Address should be used by a Sender.</li>
<li>There MUST NOT be additional bytes at the end of the raw encoding that cannot be interpreted as specified above.</li>
</ul>
<section id="rationale-for-item-ordering"><h4><span class="section-heading">Rationale for item ordering</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-item-ordering"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>The rationale for requiring Items to be canonically ordered by Typecode is that it enables implementations to use an in-memory representation that discards ordering, while retaining the same round-trip serialization of a UA/UIVK (provided that unrecognized items are retained).</p>
<p>The rationale for requiring Items to be canonically ordered by Typecode is that it enables implementations to use an in-memory representation that discards ordering, while retaining the same round-trip serialization of a UA / UVK (provided that unrecognized items are retained).</p>
</section>
</section>
<section id="adding-new-types"><h3><span class="section-heading">Adding new types</span><span class="section-anchor"> <a rel="bookmark" href="#adding-new-types"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
@ -349,10 +349,10 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<ul>
<li>An adversary is given
<span class="math">\(q\)</span>
Unified Addresses, generated honestly.</li>
<li>The attack goal is to produce a “partially colliding” valid Unified Address that:
Unified Addresses/Viewing Keys, generated honestly.</li>
<li>The attack goal is to produce a “partially colliding” valid Unified Address/Viewing Key that:
<ol suffix=")" type="a">
<li>has a string encoding matching that of <em>one of</em> the input Addresses on some subset of characters (for concreteness, consider the first
<li>has a string encoding matching that of <em>one of</em> the input Addresses/Viewing Keys on some subset of characters (for concreteness, consider the first
<span class="math">\(n\)</span>
and last
<span class="math">\(m\)</span>
@ -365,21 +365,21 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
</ul>
<p>Security goal (<strong>nonmalleability</strong>):</p>
<ul>
<li>In this variant, part b) above is replaced by the meaning of the new Address being “usefully” different than the Address it is based on, even though the adversary does not know any of the private keys. For example, if it were possible to delete a shielded constituent Address from a UA leaving only a Transparent Address, that would be a significant malleability attack.</li>
<li>In this variant, part b) above is replaced by the meaning of the new Address/Viewing Key being “usefully” different than the one it is based on, even though the adversary does not know any of the private keys. For example, if it were possible to delete a shielded constituent Address from a UA leaving only a Transparent Address, that would be a significant malleability attack.</li>
</ul>
<section id="discussion"><h4><span class="section-heading">Discussion</span><span class="section-anchor"> <a rel="bookmark" href="#discussion"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>There is a generic brute force attack against near second preimage resistance. The adversary generates UAs at random with known keys, until one has an encoding that partially collides with one of the
<p>There is a generic brute force attack against near second preimage resistance. The adversary generates UAs / UVKs at random with known keys, until one has an encoding that partially collides with one of the
<span class="math">\(q\)</span>
target Addresses. It may be possible to improve on this attack by making use of properties of checksums, etc.</p>
targets. It may be possible to improve on this attack by making use of properties of checksums, etc.</p>
<p>The generic attack puts an upper bound on the achievable security: if it takes work
<span class="math">\(w\)</span>
to produce and verify a UA, and the size of the character set is
to produce and verify a UA / UVK, and the size of the character set is
<span class="math">\(c,\)</span>
then the generic attack costs
<span class="math">\(\sim \frac{w \cdot
c^{n+m}}{q}.\)</span>
</p>
<p>There is also a generic brute force attack against nonmalleability. The adversary modifies the target Address slightly and computes the corresponding decoding, then repeats until the decoding is valid and also useful to the adversary (e.g. it would lead to the Sender using a Transparent Address). With
<p>There is also a generic brute force attack against nonmalleability. The adversary modifies the target UA / UVK slightly and computes the corresponding decoding, then repeats until the decoding is valid and also useful to the adversary (e.g. it would lead to the Sender using a Transparent Address). With
<span class="math">\(w\)</span>
defined as above, the cost is
<span class="math">\(w/p\)</span>
@ -587,8 +587,8 @@ c^{n+m}}{q}.\)</span>
<span class="math">\(\ell_M \leq 128\)</span>
bytes. A UA containing a Transparent Address, a Sapling Address, and an Orchard Address, would have
<span class="math">\(\ell_M = 128\)</span>
bytes. The restriction to a single Address with a given Typecode (and at most one Transparent Address) means that this is also the maximum length as of NU5 activation.</p>
<p>For longer UAs (when other Typecodes are added), the cost increases to 6 BLAKE2b compressions for
bytes. The restriction to a single Address with a given Typecode (and at most one Transparent Address) means that this is also the maximum length of a Unified Address containing only defined Receiver Types as of NU5 activation.</p>
<p>For longer UAs (when other Receiver Types are added) or UVKs, the cost increases to 6 BLAKE2b compressions for
<span class="math">\(128 &lt; \ell_M \leq 192,\)</span>
and 10 BLAKE2b compressions for
<span class="math">\(192 &lt; \ell_M \leq 256,\)</span>

54
zip-0316.rst
View File

@ -485,8 +485,8 @@ Requirements for both Unified Addresses and Unified Viewing Keys
upgrade [#zip-0211]_) to send funds into the Sprout chain value
pool, this would not be generally useful.
* Consumers MUST ignore constituent Addresses/Viewing Keys with
Typecodes they do not recognize.
* Consumers MUST ignore constituent Items with Typecodes they do not
recognize.
* Consumers MUST reject Unified Addresses/Viewing Keys in which the
same Typecode appears more than once, or that include both P2SH and
@ -494,8 +494,8 @@ Requirements for both Unified Addresses and Unified Viewing Keys
Address.
* Consumers MUST reject Unified Addresses/Viewing Keys in which *any*
constituent address does not meet the validation requirements of its
Receiver Encoding, as specified in the Zcash Protocol Specification
constituent Item does not meet the validation requirements of its
encoding, as specified in this ZIP and the Zcash Protocol Specification
[#protocol-nu5]_.
* Consumers MUST reject Unified Addresses/Viewing Keys in which the
@ -512,7 +512,7 @@ Rationale for item ordering
The rationale for requiring Items to be canonically ordered by Typecode
is that it enables implementations to use an in-memory representation
that discards ordering, while retaining the same round-trip serialization
of a UA/UIVK (provided that unrecognized items are retained).
of a UA / UVK (provided that unrecognized items are retained).
Adding new types
@ -625,14 +625,15 @@ Jumbling
Security goal (**near second preimage resistance**):
* An adversary is given :math:`q` Unified Addresses, generated honestly.
* An adversary is given :math:`q` Unified Addresses/Viewing Keys, generated
honestly.
* The attack goal is to produce a “partially colliding” valid Unified
Address that:
Address/Viewing Key that:
a) has a string encoding matching that of *one of* the input
Addresses on some subset of characters (for concreteness, consider
the first :math:`n` and last :math:`m` characters, up to some bound
on :math:`n+m`);
Addresses/Viewing Keys on some subset of characters (for concreteness,
consider the first :math:`n` and last :math:`m` characters, up to some
bound on :math:`n+m`);
b) is controlled by the adversary (for concreteness, the adversary
knows *at least one* of the private keys of the constituent
Addresses).
@ -640,8 +641,8 @@ Security goal (**near second preimage resistance**):
Security goal (**nonmalleability**):
* In this variant, part b) above is replaced by the meaning of the new
Address being “usefully” different than the Address it is based on, even
though the adversary does not know any of the private keys. For example,
Address/Viewing Key being “usefully” different than the one it is based on,
even though the adversary does not know any of the private keys. For example,
if it were possible to delete a shielded constituent Address from a UA
leaving only a Transparent Address, that would be a significant malleability
attack.
@ -649,19 +650,19 @@ Security goal (**nonmalleability**):
Discussion
''''''''''
There is a generic brute force attack against near second preimage
resistance. The adversary generates UAs at random with known keys, until
one has an encoding that partially collides with one of the :math:`q` target
Addresses. It may be possible to improve on this attack by making use of
properties of checksums, etc.
There is a generic brute force attack against near second preimage resistance.
The adversary generates UAs / UVKs at random with known keys, until one has an
encoding that partially collides with one of the :math:`q` targets. It may be
possible to improve on this attack by making use of properties of checksums,
etc.
The generic attack puts an upper bound on the achievable security: if it
takes work :math:`w` to produce and verify a UA, and the size of the character
The generic attack puts an upper bound on the achievable security: if it takes
work :math:`w` to produce and verify a UA / UVK, and the size of the character
set is :math:`c,` then the generic attack costs :math:`\sim \frac{w \cdot
c^{n+m}}{q}.`
There is also a generic brute force attack against nonmalleability. The
adversary modifies the target Address slightly and computes the corresponding
adversary modifies the target UA / UVK slightly and computes the corresponding
decoding, then repeats until the decoding is valid and also useful to the
adversary (e.g. it would lead to the Sender using a Transparent Address).
With :math:`w` defined as above, the cost is :math:`w/p` where :math:`p` is
@ -799,13 +800,14 @@ The cost is dominated by 4 BLAKE2b compressions for :math:`\ell_M \leq 128`
bytes. A UA containing a Transparent Address, a Sapling Address, and an
Orchard Address, would have :math:`\ell_M = 128` bytes. The restriction
to a single Address with a given Typecode (and at most one Transparent
Address) means that this is also the maximum length as of NU5 activation.
Address) means that this is also the maximum length of a Unified Address
containing only defined Receiver Types as of NU5 activation.
For longer UAs (when other Typecodes are added), the cost increases to 6
BLAKE2b compressions for :math:`128 < \ell_M \leq 192,` and 10 BLAKE2b
compressions for :math:`192 < \ell_M \leq 256,` for example. The maximum
cost for which the algorithm is defined would be 196608 BLAKE2b compressions
at :math:`\ell_M = \ell^\mathsf{MAX}_M` bytes.
For longer UAs (when other Receiver Types are added) or UVKs, the cost
increases to 6 BLAKE2b compressions for :math:`128 < \ell_M \leq 192,` and
10 BLAKE2b compressions for :math:`192 < \ell_M \leq 256,` for example. The
maximum cost for which the algorithm is defined would be 196608 BLAKE2b
compressions at :math:`\ell_M = \ell^\mathsf{MAX}_M` bytes.
A naïve implementation of the :math:`\mathsf{F4Jumble}^{-1}` function would
require roughly :math:`\ell_M` bytes plus the size of a BLAKE2b hash state.