diff --git a/zip-0316.rst b/zip-0316.rst index 4151433f..32eca790 100644 --- a/zip-0316.rst +++ b/zip-0316.rst @@ -327,13 +327,13 @@ of the consituent Receivers: above Priority List; * :math:`\mathtt{length} : \mathtt{compactSize}` — the length in bytes of - :math:`\mathtt{addr}`; + :math:`\mathtt{addr};` * :math:`\mathtt{addr} : \mathtt{byte[length]}` — the Receiver Encoding. A Receiver Encoding is the raw encoding of a Shielded Payment Address, -or the :math:`160`-bit script hash of a P2SH address [#P2SH]_, or the -:math:`160`-bit validating key hash of a P2PKH address [#P2PKH]_. +or the :math:`160\!`-bit script hash of a P2SH address [#P2SH]_, or the +:math:`160\!`-bit validating key hash of a P2PKH address [#P2PKH]_. Let ``padding`` be the Human-Readable Part of the Unified Address in US-ASCII, padded to 16 bytes with zero bytes. We append ``padding`` to @@ -440,15 +440,16 @@ Requirements for both Unified Addresses and Unified Viewing Keys 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 [#zip-0000]_. +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 [#zip-0000]_. -Experimental types MAY be added using the reserved Typecodes 0xFFFA to 0xFFFF -inclusive. This provides for six simultaneous experiments, which can be -referred to as experiments A to F. This should be sufficient because -experiments are expected to be reasonably short-term, and should otherwise -be either standardized in a ZIP (and allocated a Typecode outside this +Experimental types MAY be added using the reserved Typecodes +:math:`\mathtt{0xFFFA}` to :math:`\mathtt{0xFFFF}` inclusive. This +provides for six simultaneous experiments, which can be referred to +as experiments A to F. This should be sufficient because experiments +are expected to be reasonably short-term, and should otherwise be +either standardized in a ZIP (and allocated a Typecode outside this reserved range) or discontinued. @@ -489,8 +490,8 @@ 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 -set is :math:`c`, then the generic attack costs :math:`\sim \frac{w \cdot -c^{n+m}}{q}`. +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 @@ -505,9 +506,9 @@ Solution We use an unkeyed 4-round Feistel construction to approximate a random permutation. (As explained below, 3 rounds would not be sufficient.) -Let :math:`H_i` be a hash personalized by :math:`i`, with maximum output +Let :math:`H_i` be a hash personalized by :math:`i,` with maximum output length :math:`\ell_H` bytes. Let :math:`G_i` be a XOF (a hash function with -extendable output length) based on :math:`H`, personalized by :math:`i`. +extendable output length) based on :math:`H,` personalized by :math:`i.` Given input :math:`M` of length :math:`\ell_M` bytes such that :math:`48 \leq \ell_M \leq 4194368,` define :math:`\mathsf{F4Jumble}(M)` @@ -520,10 +521,10 @@ by: * let :math:`y = a \oplus H_0(x)` * let :math:`d = x \oplus G_1(y)` * let :math:`c = y \oplus H_1(d)` -* return :math:`c \,||\, d`. +* return :math:`c \,||\, d.` The inverse function :math:`\mathsf{F4Jumble}^{-1}` is obtained in the usual -way for a Feistel construction, by observing that :math:`r = p \oplus q` implies :math:`p = r \oplus q`. +way for a Feistel construction, by observing that :math:`r = p \oplus q` implies :math:`p = r \oplus q.` The first argument to BLAKE2b below is the personalization. @@ -579,31 +580,31 @@ A 3-round unkeyed Feistel, as shown, is not sufficient: Diagram of 3-round unkeyed Feistel construction Suppose that an adversary has a target input/output pair -:math:`(a \,||\, b, c \,||\, d)`, and that the input to :math:`H_0` is -:math:`x`. By fixing :math:`x`, we can obtain another pair +:math:`(a \,||\, b, c \,||\, d),` and that the input to :math:`H_0` is +:math:`x.` By fixing :math:`x,` we can obtain another pair :math:`((a \oplus t) \,||\, b', (c \oplus t) \,||\, d')` such that :math:`a \oplus t` is close to :math:`a` and :math:`c \oplus t` is close -to :math:`c`. -(:math:`b'` and :math:`d'` will not be close to :math:`b` and :math:`d`, +to :math:`c.` +(:math:`b'` and :math:`d'` will not be close to :math:`b` and :math:`d,` but that isn't necessarily required for a valid attack.) A 4-round Feistel thwarts this and similar attacks. Defining :math:`x` and :math:`y` as the intermediate values in the first diagram above: -* if :math:`(x', y')` are fixed to the same values as :math:`(x, y)`, then - :math:`(a', b', c', d') = (a, b, c, d)`; +* if :math:`(x', y')` are fixed to the same values as :math:`(x, y),` then + :math:`(a', b', c', d') = (a, b, c, d);` -* if :math:`x' = x` but :math:`y' \neq y`, then the adversary is able to - introduce a controlled :math:`\oplus`-difference - :math:`a \oplus a' = y \oplus y'`, but the other three pieces +* if :math:`x' = x` but :math:`y' \neq y,` then the adversary is able to + introduce a controlled :math:`\oplus\!`-difference + :math:`a \oplus a' = y \oplus y',` but the other three pieces :math:`(b, c, d)` are all randomized, which is sufficient; -* if :math:`y' = y` but :math:`x' \neq x`, then the adversary is able to - introduce a controlled :math:`\oplus`-difference - :math:`d \oplus d' = x \oplus x'`, but the other three pieces +* if :math:`y' = y` but :math:`x' \neq x,` then the adversary is able to + introduce a controlled :math:`\oplus\!`-difference + :math:`d \oplus d' = x \oplus x',` but the other three pieces :math:`(a, b, c)` are all randomized, which is sufficient; -* if :math:`x' \neq x` and :math:`y' \neq y`, all four pieces are +* if :math:`x' \neq x` and :math:`y' \neq y,` all four pieces are randomized. Note that the size of each piece is at least 24 bytes. @@ -633,23 +634,24 @@ 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 = 4194368` bytes. -A naïve implementation of the :math:`F4Jumble^{-1}` function would require -roughly :math:`\ell_M` bytes plus the size of a BLAKE2b hash state. However, -it is possible to reduce this by streaming the :math:`d` part of the jumbled -encoding three times from a less memory-constrained device. It is essential -that the streamed value of :math:`d` is the same on each pass, which can be -verified using a MAC (with key held only by the Consumer) or +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. +However, it is possible to reduce this by streaming the :math:`d` part of +the jumbled encoding three times from a less memory-constrained device. It +is essential that the streamed value of :math:`d` is the same on each pass, +which can be verified using a MAC (with key held only by the Consumer) or collision-resistant hash function. After the first pass of :math:`d`, the -implementation is able to compute :math:`y`; after the second pass it is -able to compute :math:`a`; and the third allows it to compute and +implementation is able to compute :math:`y;` after the second pass it is +able to compute :math:`a;` and the third allows it to compute and incrementally parse :math:`b.` The maximum memory usage during this process would be 128 bytes (for the cached :math:`c` or :math:`y`), plus two BLAKE2b hash states. -Since this streaming implementation of :math:`F4Jumble^{-1}` is quite -complicated, we do not require all Consumers to support it. If a Consumer -implementation cannot support UAs / UVKs up to the maximum length, it MUST -nevertheless support UAs / UVKs with :math:`\ell_M` of at least 256 bytes. +Since this streaming implementation of :math:`\mathsf{F4Jumble}^{-1}` is +quite complicated, we do not require all Consumers to support it. If a +Consumer implementation cannot support UAs / UVKs up to the maximum length, +it MUST nevertheless support UAs / UVKs with :math:`\ell_M` of at least +:math:`256` bytes. Dependencies