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

Merge pull request #609 from daira/zip-0316-first20 

ZIP 316: at least the first 20 characters of a UA/UVK MUST be shown
This commit is contained in:
Kris Nuttycombe 2022-04-28 14:27:07 -06:00 committed by GitHub
parent aec1fef7cd e4ed372840
commit 78f61ebc25
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 20 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
zip-0316.html
View File

@ -295,10 +295,14 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/482">https://g
<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="id23" 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>
<li>If the encoding of a Unified Address/Viewing Key is shown to a user in an abridged form due to lack of space, at least the first 20 characters MUST be included.</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" class="section-anchor" 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 / UVK (provided that unrecognized items are retained).</p>
</section>
<section id="rationale-for-showing-at-least-the-first-20-characters"><h4><span class="section-heading">Rationale for showing at least the first 20 characters</span><span class="section-anchor"> <a rel="bookmark" href="#rationale-for-showing-at-least-the-first-20-characters"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h4>
<p>Showing fewer than 20 characters of a UA/UVK would potentially allow practical attacks in which the adversary constructs another UA/UVK that matches in the characters shown. When a UA/UVK is abridged it is preferable to show a prefix rather than some other part, both for a more consistent user experience across wallets, and because security analysis of the cost of partial UA/UVK matching attacks is more complicated if checksum characters are included in the characters that are compared.</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" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>It is intended that new Receiver Types and Viewing Key Types SHOULD be introduced either by a modification to this ZIP or by a new ZIP, in accordance with the ZIP Process <a id="id24" class="footnote_reference" href="#zip-0000">13</a>.</p>

16
zip-0316.rst
View File

@ -513,6 +513,10 @@ Requirements for both Unified Addresses and Unified Viewing Keys
* There MUST NOT be additional bytes at the end of the raw encoding
that cannot be interpreted as specified above.
* If the encoding of a Unified Address/Viewing Key is shown to a user
in an abridged form due to lack of space, at least the first 20
characters MUST be included.
Rationale for item ordering
'''''''''''''''''''''''''''
@ -521,6 +525,18 @@ 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).
Rationale for showing at least the first 20 characters
''''''''''''''''''''''''''''''''''''''''''''''''''''''
Showing fewer than 20 characters of a UA/UVK would potentially allow
practical attacks in which the adversary constructs another UA/UVK that
matches in the characters shown. When a UA/UVK is abridged it is
preferable to show a prefix rather than some other part, both for a
more consistent user experience across wallets, and because security
analysis of the cost of partial UA/UVK matching attacks is more
complicated if checksum characters are included in the characters that
are compared.
Adding new types
----------------