ZIP 224: Security and privacy considerations

This commit is contained in:
Jack Grigg 2021-02-27 18:24:58 +00:00 committed by Daira Hopwood
parent 9fd129ff86
commit 6631754e19
2 changed files with 50 additions and 6 deletions

View File

@ -31,7 +31,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<li>Pallas is used as the "application curve", on which the Orchard protocol itself is implemented (c/f Jubjub).</li>
<li>Vesta is used as the "circuit curve"; its scalar field (being the base field of Pallas) is the "word" type over which the circuit is implemented (c/f BLS12-381).</li>
</ul>
<p>We use (version 10 of) the IETF hash-to-curve Internet Draft <a id="id2" class="footnote_reference" href="#ietf-hash-to-curve">25</a> to implement
<p>We use (version 10 of) the IETF hash-to-curve Internet Draft <a id="id2" class="footnote_reference" href="#ietf-hash-to-curve">26</a> to implement
<span class="math">\(\mathsf{GroupHash}\)</span>
, instead of the BLAKE2s-based mechanism used for Sapling. We specifically use the "simplified SWU" algorithm, which provides an infallible
<span class="math">\(\mathsf{GroupHash}\)</span>
@ -40,7 +40,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<ul>
<li>Curve specifications: <a id="id3" class="footnote_reference" href="#spec-pasta">10</a></li>
<li>Group hash: <a id="id4" class="footnote_reference" href="#spec-pasta-grouphash">11</a></li>
<li>Supporting evidence: <a id="id5" class="footnote_reference" href="#pasta-evidence">26</a></li>
<li>Supporting evidence: <a id="id5" class="footnote_reference" href="#pasta-evidence">27</a></li>
</ul>
</section>
<section id="proving-system"><h3><span class="section-heading">Proving system</span><span class="section-anchor"> <a rel="bookmark" href="#proving-system"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
@ -140,7 +140,20 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<p>TBD</p>
</section>
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>TBD</p>
<p>This ZIP defines a new shielded pool. As with Sapling, the Orchard protocol only supports spending Orchard notes, and moving ZEC into or out of the Orchard pool happens via an Orchard-specific
<span class="math">\(\mathsf{valueBalance}\)</span>
transaction field. This has the following considerations:</p>
<ul>
<li>The Orchard pool forms a separate anonymity set from the Sprout and Sapling pools. The new pool will start with zero notes (as Sapling did at its deployment), but transactions within Orchard will increase the size of the anonymity set more rapidly than Sapling, due to the arity-hiding nature of Orchard actions.</li>
<li>The "transparent turnstile" created by the
<span class="math">\(\mathsf{valueBalance}\)</span>
field, combined with the consensus checks that each pool's balance cannot be negative, together enforce that any potential counterfeiting bugs in the Orchard protocol or implementation are contained within the Orchard pool, and similarly any potential counterfeiting bugs in existing shielded pools cannot cause inflation of the Orchard pool.</li>
<li>Spending funds residing in the Orchard pool to a non-Orchard address will reveal the value of the transaction. This is a necessary side-effect of the transparent turnstile, but can be mitigated by migrating the majority of shielded activity to the Orchard pool and making these transactions a minority. Wallets should convey within their transaction creation UX that amounts are revealed in these situations.
<ul>
<li>Wallets should take steps to migrate their userbases to store funds uniformly within the Orchard pool. Best practices for wallet handling of multiple pools will be covered in a subsequent ZIP. <a id="id27" class="footnote_reference" href="#zip-0315">25</a></li>
</ul>
</li>
</ul>
</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>
<ul>
@ -349,10 +362,18 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
</tr>
</tbody>
</table>
<table id="ietf-hash-to-curve" class="footnote">
<table id="zip-0315" class="footnote">
<tbody>
<tr>
<th>25</th>
<td><a href="zip-0315">ZIP 315: Best Practices for Wallet Handling of Multiple Pools</a></td>
</tr>
</tbody>
</table>
<table id="ietf-hash-to-curve" class="footnote">
<tbody>
<tr>
<th>26</th>
<td><a href="https://www.ietf.org/archive/id/draft-irtf-cfrg-hash-to-curve-10.html">draft-irtf-cfrg-hash-to-curve-10: Hashing to Elliptic Curves</a></td>
</tr>
</tbody>
@ -360,7 +381,7 @@ Discussions-To: &lt;<a href="https://github.com/zcash/zips/issues/435">https://g
<table id="pasta-evidence" class="footnote">
<tbody>
<tr>
<th>26</th>
<th>27</th>
<td><a href="https://github.com/zcash/pasta">Pallas/Vesta supporting evidence</a></td>
</tr>
</tbody>

View File

@ -171,7 +171,29 @@ TBD
Security and Privacy Considerations
===================================
TBD
This ZIP defines a new shielded pool. As with Sapling, the Orchard protocol only supports
spending Orchard notes, and moving ZEC into or out of the Orchard pool happens via an
Orchard-specific :math:`\mathsf{valueBalance}` transaction field. This has the following
considerations:
- The Orchard pool forms a separate anonymity set from the Sprout and Sapling pools. The
new pool will start with zero notes (as Sapling did at its deployment), but transactions
within Orchard will increase the size of the anonymity set more rapidly than Sapling,
due to the arity-hiding nature of Orchard actions.
- The "transparent turnstile" created by the :math:`\mathsf{valueBalance}` field, combined
with the consensus checks that each pool's balance cannot be negative, together enforce
that any potential counterfeiting bugs in the Orchard protocol or implementation are
contained within the Orchard pool, and similarly any potential counterfeiting bugs in
existing shielded pools cannot cause inflation of the Orchard pool.
- Spending funds residing in the Orchard pool to a non-Orchard address will reveal the
value of the transaction. This is a necessary side-effect of the transparent turnstile,
but can be mitigated by migrating the majority of shielded activity to the Orchard pool
and making these transactions a minority. Wallets should convey within their transaction
creation UX that amounts are revealed in these situations.
- Wallets should take steps to migrate their userbases to store funds uniformly within
the Orchard pool. Best practices for wallet handling of multiple pools will be covered
in a subsequent ZIP. [#zip-0315]_
Test Vectors
@ -220,5 +242,6 @@ References
.. [#design-nullifiers] `The Orchard Book: 3.5. Nullifiers <https://zcash.github.io/orchard/design/nullifiers.html>`_
.. [#zip-0032] `ZIP 32: Shielded Hierarchical Deterministic Wallets <zip-0032.rst>`_
.. [#zip-0212] `ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext <zip-0212.rst>`_
.. [#zip-0315] `ZIP 315: Best Practices for Wallet Handling of Multiple Pools <zip-0315.rst>`_
.. [#ietf-hash-to-curve] `draft-irtf-cfrg-hash-to-curve-10: Hashing to Elliptic Curves <https://www.ietf.org/archive/id/draft-irtf-cfrg-hash-to-curve-10.html>`_
.. [#pasta-evidence] `Pallas/Vesta supporting evidence <https://github.com/zcash/pasta>`_