ZIP 32: fix a type error in dk derivation for Orchard.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-03-03 22:48:38 +00:00
parent 81136fe7ab
commit 45e175512e
2 changed files with 21 additions and 16 deletions

View File

@ -625,12 +625,17 @@ License: MIT</pre>
:</p>
<ul>
<li>Let
<span class="math">\(\mathit{FVK}_i\)</span>
be the raw encoding of the Orchard full viewing key for
<span class="math">\((\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})\)</span>
be the Orchard full viewing key for
<span class="math">\(\mathsf{sk}_i\)</span>
(as specified in <a id="id20" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">18</a>).</li>
.</li>
<li>Let
<span class="math">\(\mathsf{K} = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})\)</span>
and let
<span class="math">\(\mathsf{B} = \mathsf{repr}_{\mathbb{P}}(\mathsf{ak})\,||\,\mathsf{I2LEBSP}_{256}(\mathsf{nk})\)</span>
.</li>
<li>
<span class="math">\(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathit{FVK}_i, [\texttt{0x82}]))\)</span>
<span class="math">\(\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{K}, [\texttt{0x82}]\,||\,\mathsf{LEBS2OSP}_{512}(\mathsf{B})))\)</span>
.</li>
<li>Let
<span class="math">\(j\)</span>
@ -652,7 +657,7 @@ License: MIT</pre>
</section>
</section>
<section id="specification-wallet-usage"><h2><span class="section-heading">Specification: Wallet usage</span><span class="section-anchor"> <a rel="bookmark" href="#specification-wallet-usage"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="id21" class="footnote_reference" href="#bip-0044">5</a> to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.</p>
<p>Existing Zcash-supporting HD wallets all use BIP 44 <a id="id20" class="footnote_reference" href="#bip-0044">5</a> to organize their derived keys. In order to more easily mesh with existing user experiences, we broadly follow BIP 44's design here. However, we have altered the design where it makes sense to leverage features of shielded addresses.</p>
<section id="key-path-levels"><h3><span class="section-heading">Key path levels</span><span class="section-anchor"> <a rel="bookmark" href="#key-path-levels"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>Sprout, Sapling, and Orchard key paths have the following three path levels at the top, all of which use hardened derivation:</p>
<ul>
@ -665,7 +670,7 @@ License: MIT</pre>
) following the BIP 43 recommendation. It indicates that the subtree of this node is used according to this specification.</li>
<li>
<span class="math">\(coin\_type\)</span>
: a constant identifying the cybercoin that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 <a id="id22" class="footnote_reference" href="#slip-0044">6</a>. Note that in keeping with that document, all cybercoin testnets share
: a constant identifying the cybercoin that this subtree's keys are used with. For compatibility with existing BIP 44 implementations, we use the same constants as defined in SLIP 44 <a id="id21" class="footnote_reference" href="#slip-0044">6</a>. Note that in keeping with that document, all cybercoin testnets share
<span class="math">\(coin\_type\)</span>
index
<span class="math">\(1\)</span>
@ -674,7 +679,7 @@ License: MIT</pre>
<span class="math">\(account\)</span>
: numbered from index
<span class="math">\(0\)</span>
in sequentially increasing manner. Defined as in BIP 44 <a id="id23" class="footnote_reference" href="#bip-0044">5</a>.</li>
in sequentially increasing manner. Defined as in BIP 44 <a id="id22" class="footnote_reference" href="#bip-0044">5</a>.</li>
</ul>
<p>Unlike BIP 44, none of the shielded key paths have a
<span class="math">\(change\)</span>
@ -696,7 +701,7 @@ License: MIT</pre>
payment addresses, because each diversifier has around a 50% chance of being invalid.</p>
<p>If in certain circumstances a wallet needs to derive independent spend authorities within a single account, they MAY additionally support a non-hardened
<span class="math">\(address\_index\)</span>
path level as in <a id="id24" class="footnote_reference" href="#bip-0044">5</a>:</p>
path level as in <a id="id23" class="footnote_reference" href="#bip-0044">5</a>:</p>
<ul>
<li>
<span class="math">\(m_\mathsf{Sapling} / purpose' / coin\_type' / account' / address\_index\)</span>
@ -731,7 +736,7 @@ License: MIT</pre>
<section id="sapling-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Sapling Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A "Sapling full viewing key fingerprint" of a full viewing key with raw encoding
<span class="math">\(\mathit{FVK}\)</span>
(as specified in <a id="id25" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">16</a>) is given by:</p>
(as specified in <a id="id24" class="footnote_reference" href="#protocol-saplingfullviewingkeyencoding">16</a>) is given by:</p>
<ul>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashSaplingFVFP”}, \mathit{FVK})\)</span>
@ -743,7 +748,7 @@ License: MIT</pre>
<section id="sprout-address-fingerprints-and-tags"><h3><span class="section-heading">Sprout Address Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#sprout-address-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A "Sprout address fingerprint" of a Sprout payment address with raw encoding
<span class="math">\(\mathit{ADDR}\)</span>
(as specified in <a id="id26" class="footnote_reference" href="#protocol-sproutpaymentaddrencoding">14</a>, including the lead bytes) is given by:</p>
(as specified in <a id="id25" class="footnote_reference" href="#protocol-sproutpaymentaddrencoding">14</a>, including the lead bytes) is given by:</p>
<ul>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“Zcash_Sprout_AFP”}, \mathit{ADDR})\)</span>
@ -755,7 +760,7 @@ License: MIT</pre>
<section id="orchard-full-viewing-key-fingerprints-and-tags"><h3><span class="section-heading">Orchard Full Viewing Key Fingerprints and Tags</span><span class="section-anchor"> <a rel="bookmark" href="#orchard-full-viewing-key-fingerprints-and-tags"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>An "Orchard full viewing key fingerprint" of a full viewing key with raw encoding
<span class="math">\(\mathit{FVK}\)</span>
(as specified in <a id="id27" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">18</a>) is given by:</p>
(as specified in <a id="id26" class="footnote_reference" href="#protocol-orchardfullviewingkeyencoding">18</a>) is given by:</p>
<ul>
<li>
<span class="math">\(\mathsf{BLAKE2b}\text{-}\mathsf{256}(\texttt{“ZcashOrchardFVFP”}, \mathit{FVK})\)</span>
@ -780,7 +785,7 @@ License: MIT</pre>
</section>
</section>
<section id="specification-key-encodings"><h2><span class="section-heading">Specification: Key Encodings</span><span class="section-anchor"> <a rel="bookmark" href="#specification-key-encodings"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The following encodings are analogous to the <code>xprv</code> and <code>xpub</code> encodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 <a id="id28" class="footnote_reference" href="#bip-0173">7</a> encoding.</p>
<p>The following encodings are analogous to the <code>xprv</code> and <code>xpub</code> encodings defined in BIP 32 for transparent keys and addresses. Each key type has a raw representation and a Bech32 <a id="id27" class="footnote_reference" href="#bip-0173">7</a> encoding.</p>
<section id="sapling-extended-spending-keys"><h3><span class="section-heading">Sapling extended spending keys</span><span class="section-anchor"> <a rel="bookmark" href="#sapling-extended-spending-keys"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
<p>A Sapling extended spending key
<span class="math">\((\mathsf{ask, nsk, ovk, dk, c})\)</span>
@ -904,7 +909,7 @@ License: MIT</pre>
<span class="math">\(0\)</span>
.</p>
<p>When encoded as Bech32, the Human-Readable Part is <code>secret-orchard-extsk-main</code> for Mainnet, or <code>secret-orchard-extsk-test</code> for Testnet.</p>
<p>We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users <a id="id29" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">19</a>.</p>
<p>We define this encoding for completeness, however given that it includes the capability to derive child spending keys, we expect that most wallets will only expose the regular Orchard spending key encoding to users <a id="id28" class="footnote_reference" href="#protocol-orchardspendingkeyencoding">19</a>.</p>
</section>
</section>
<section id="test-vectors"><h2><span class="section-heading">Test Vectors</span><span class="section-anchor"> <a rel="bookmark" href="#test-vectors"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>

View File

@ -373,9 +373,9 @@ key structure.
Given an Orchard extended spending key :math:`(\mathsf{sk}_i, \mathsf{c}_i)`:
- Let :math:`\mathit{FVK}_i` be the raw encoding of the Orchard full viewing key for :math:`\mathsf{sk}_i`
(as specified in [#protocol-orchardfullviewingkeyencoding]_).
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathit{FVK}_i, [\texttt{0x82}]))`.
- Let :math:`(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})` be the Orchard full viewing key for :math:`\mathsf{sk}_i`.
- Let :math:`\mathsf{K} = \mathsf{I2LEBSP}_{256}(\mathsf{rivk})` and let :math:`\mathsf{B} = \mathsf{repr}_{\mathbb{P}}(\mathsf{ak})\,||\,\mathsf{I2LEBSP}_{256}(\mathsf{nk})`.
- :math:`\mathsf{dk}_i = \mathsf{truncate}_{32}(\mathsf{PRF^{expand}}(\mathsf{K}, [\texttt{0x82}]\,||\,\mathsf{LEBS2OSP}_{512}(\mathsf{B})))`.
- Let :math:`j` be the index of the desired diversifier, in the range :math:`0\,.\!. 2^{88} - 1`.
- :math:`d_{i,j} = \mathsf{FF1}\text{-}\mathsf{AES256.Encrypt}(\mathsf{dk}_i, \texttt{“”}, \mathsf{I2LEBSP}_{88}(j))`.