mirror of https://github.com/zcash/zips.git
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:
commit
78f61ebc25
|
@ -295,10 +295,14 @@ Discussions-To: <<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
16
zip-0316.rst
|
@ -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
|
||||
----------------
|
||||
|
|
Loading…
Reference in New Issue