From e4ed372840db43f98a6454d60500039c18165426 Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Thu, 28 Apr 2022 21:04:17 +0100 Subject: [PATCH] ZIP 316: specify that at least the first 20 characters of a UA/UVK MUST be shown. fixes #571 Signed-off-by: Daira Hopwood --- zip-0316.html | 4 ++++ zip-0316.rst | 16 ++++++++++++++++ 2 files changed, 20 insertions(+) diff --git a/zip-0316.html b/zip-0316.html index bd2227e4..eaac572f 100644 --- a/zip-0316.html +++ b/zip-0316.html @@ -295,10 +295,14 @@ Discussions-To: <https://g
  • Consumers MUST reject Unified Addresses/Viewing Keys in which any constituent Item does not meet the validation requirements of its encoding, as specified in this ZIP and the Zcash Protocol Specification 2.
  • 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.
  • 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

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

    +

    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

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

    diff --git a/zip-0316.rst b/zip-0316.rst index 03d5b171..78f85a64 100644 --- a/zip-0316.rst +++ b/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 ----------------