mirror of https://github.com/zcash/zips.git
ZIP 224: Security and privacy considerations
This commit is contained in:
Jack Grigg
Daira Hopwood
parent
9fd129ff86
commit
6631754e19
|
|
@ -31,7 +31,7 @@ Discussions-To: <<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: <<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: <<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: <<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: <<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>
|
||||
|
|
|
|||
25
zip-0224.rst
25
zip-0224.rst
|
|
@ -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>`_
|
||||
|
|
|
|||
Loading…
Reference in New Issue