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

ZIP 316: at least the first 20 characters of a UA/UVK MUST be shown

zip-0316.html

@@ -295,10 +295,14 @@
                     <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>

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
 ----------------