mirror of https://github.com/zcash/zips.git
ZIP 212: Daira's editorial changes.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood
parent
dbfdf2ea00
commit
b1bd2f49a7
198
zip-0212.html
198
zip-0212.html
|
|
@ -3,6 +3,7 @@
|
||||||
<head>
|
<head>
|
||||||
<title>ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext</title>
|
<title>ZIP 212: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext</title>
|
||||||
<meta charset="utf-8" />
|
<meta charset="utf-8" />
|
||||||
|
<script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||||
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
|
||||||
<body>
|
<body>
|
||||||
<section>
|
<section>
|
||||||
|
|
@ -14,51 +15,176 @@ Category: Consensus
|
||||||
Created: 2019-03-31
|
Created: 2019-03-31
|
||||||
License: MIT</pre>
|
License: MIT</pre>
|
||||||
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119.</p>
|
<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
|
||||||
<p>The function <code>ToScalar</code> is defined as in Section 4.4.2 of the Zcash Protocol Specification. <a id="id1" class="footnote_reference" href="#protocol">1</a></p>
|
<p>The function
|
||||||
|
<span class="math">\(\mathsf{ToScalar}\)</span>
|
||||||
|
is defined as in Section 4.4.2 of the Zcash Protocol Specification. <a id="id2" class="footnote_reference" href="#protocol">2</a></p>
|
||||||
</section>
|
</section>
|
||||||
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
<p>This ZIP proposes a new note plaintext format for Sapling Outputs in transactions. The new format allows recipients to check the well-formedness of the emphemeral Diffie-Hellman key in the Output to avoid an assumption on zk-SNARK soundness for preventing diversified address linkability.</p>
|
<p>This ZIP proposes a new note plaintext format for Sapling Outputs in transactions. The new format allows recipients to check the well-formedness of the emphemeral Diffie-Hellman key in the Output to avoid an assumption on zk-SNARK soundness for preventing diversified address linkability.</p>
|
||||||
</section>
|
</section>
|
||||||
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
<p>The Sapling payment protocol contains a feature called "diversified addresses" which allows a single incoming viewing key to receive payments on an enormous number of distinct and unlinkable payment addresses. This feature allows users to maintain many payment addresses without paying additional overhead during blockchain scanning.</p>
|
<p>The Sapling payment protocol contains a feature called "diversified addresses" which allows a single incoming viewing key to receive payments on an enormous number of distinct and unlinkable payment addresses. This feature allows users to maintain many payment addresses without paying additional overhead during blockchain scanning.</p>
|
||||||
<p>The feature works by allowing payment addresses to become a tuple (<code>pk_d</code>, <code>d</code>) of a public key <code>pk_d</code> and 88-bit diversifier <code>d</code> such that <code>pk_d =
|
<p>The feature works by allowing payment addresses to become a tuple
|
||||||
[ivk] GH(d)</code> for some incoming viewing key <code>ivk</code>. The hash function <code>GH(d)</code> maps from a diversifier to prime order elements of the Jubjub elliptic curve. It is possible for a user to choose many <code>d</code> to create several distinct and unlinkable payment addresses of this form.</p>
|
<span class="math">\((\mathsf{pk_d}, \mathsf{d})\)</span>
|
||||||
<p>In order to make a payment to a Sapling address, an ephemeral secret <code>esk</code> is sampled by the sender and an ephemeral public key <code>epk = [esk] GH(d)</code> is included in the Output description. Then, a shared Diffie-Hellman secret is computed by the sender as <code>[esk] [8] pk_d</code>. The recipient can recover this shared secret without knowledge of the particular <code>d</code> by computing <code>[ivk] [8]
|
of a public key
|
||||||
epk</code>. This shared secret is then used as part of Note decryption.</p>
|
<span class="math">\(\mathsf{pk_d}\)</span>
|
||||||
<p>Naively, the recipient cannot know which <code>(pk_d, d)</code> was used to compute the shared secret, but the sender is asked to include the <code>d</code> within the note plaintext to reconstruct the Note. However, if the recipient has more than one known addresses, an attacker could use a different payment address to perform secret exchange and, by observing the behavior of the recipient, link the two diversified addresses together. (This attacker strategy was discovered by Brian Warner earlier in the design of the Sapling protocol.)</p>
|
and
|
||||||
<p>In order to prevent this attack, the protocol currently forces the sender to prove knowledge of the discrete logarithm of <code>epk</code> with respect to the <code>g_d =
|
<span class="math">\(88\)</span>
|
||||||
GH(d)</code> included within the Note commitment. This <code>g_d</code> is determined by <code>d</code> and recomputed during Note decryption, and so the recipient will either be unable to decrypt the note or the sender will be unable to perform the attack.</p>
|
-bit diversifier
|
||||||
<p>However, this check occurs as part of the zero-knowledge proof statement and so relies on the soundness of the underlying zk-SNARK in Sapling, and therefore it relies on relatively strong cryptographic assumptions and a trusted setup. It would be preferable to force the sender to transfer <code>esk</code> within the Note plaintext so that, during note decryption, the recipient can check that <code>epk =
|
<span class="math">\(\mathsf{d}\)</span>
|
||||||
[esk] g_d</code> (for the expected <code>g_d</code>) and ignore the payment as invalid otherwise. This forms a line of defense in the case that soundness of the zk-SNARK does not hold.</p>
|
such that
|
||||||
<p>Merely sending <code>esk</code> to the recipient in the Note plaintext would require us to enlarge the note plaintext, but also would compromise the proof of IND-CCA2 security for in-band secret distribution. We avoid both of these concerns by using a key derivation to obtain both <code>esk</code> and <code>rcm</code>.</p>
|
<span class="math">\(\mathsf{pk_d} = [\mathsf{ivk}] GH(\mathsf{d})\)</span>
|
||||||
|
for some incoming viewing key
|
||||||
|
<span class="math">\(\mathsf{ivk}\)</span>
|
||||||
|
. The hash function
|
||||||
|
<span class="math">\(GH(\mathsf{d})\)</span>
|
||||||
|
maps from a diversifier to prime order elements of the Jubjub elliptic curve. It is possible for a user to choose many
|
||||||
|
<span class="math">\(\mathsf{d}\)</span>
|
||||||
|
to create several distinct and unlinkable payment addresses of this form.</p>
|
||||||
|
<p>In order to make a payment to a Sapling address, an ephemeral secret
|
||||||
|
<span class="math">\(\mathsf{esk}\)</span>
|
||||||
|
is sampled by the sender and an ephemeral public key
|
||||||
|
<span class="math">\(\mathsf{epk} = [\mathsf{esk}] GH(\mathsf{d})\)</span>
|
||||||
|
is included in the Output description. Then, a shared Diffie-Hellman secret is computed by the sender as
|
||||||
|
<span class="math">\([\mathsf{esk}] [8] \mathsf{pk_d}\)</span>
|
||||||
|
. The recipient can recover this shared secret without knowledge of the particular
|
||||||
|
<span class="math">\(\mathsf{d}\)</span>
|
||||||
|
by computing
|
||||||
|
<span class="math">\([\mathsf{ivk}] [8] \mathsf{epk}\)</span>
|
||||||
|
. This shared secret is then used as part of note decryption.</p>
|
||||||
|
<p>Naively, the recipient cannot know which
|
||||||
|
<span class="math">\((\mathsf{pk_d}, \mathsf{d})\)</span>
|
||||||
|
was used to compute the shared secret, but the sender is asked to include the
|
||||||
|
<span class="math">\(\mathsf{d}\)</span>
|
||||||
|
within the note plaintext to reconstruct the note. However, if the recipient has more than one known address, an attacker could use a different payment address to perform secret exchange and, by observing the behavior of the recipient, link the two diversified addresses together. (This attacker strategy was discovered by Brian Warner earlier in the design of the Sapling protocol.)</p>
|
||||||
|
<p>In order to prevent this attack, the protocol currently forces the sender to prove knowledge of the discrete logarithm of
|
||||||
|
<span class="math">\(\mathsf{epk}\)</span>
|
||||||
|
with respect to the
|
||||||
|
<span class="math">\(\mathsf{g_d} = GH(\mathsf{d})\)</span>
|
||||||
|
included within the note commitment. This
|
||||||
|
<span class="math">\(\mathsf{g_d}\)</span>
|
||||||
|
is determined by
|
||||||
|
<span class="math">\(\mathsf{d}\)</span>
|
||||||
|
and recomputed during note decryption, and so the recipient will either be unable to decrypt the note or the sender will be unable to perform the attack.</p>
|
||||||
|
<p>However, this check occurs as part of the zero-knowledge proof statement and so relies on the soundness of the underlying zk-SNARK in Sapling, and therefore it relies on relatively strong cryptographic assumptions and a trusted setup. It would be preferable to force the sender to transfer sufficient information in the note plaintext to allow deriving
|
||||||
|
<span class="math">\(\mathsf{esk}\)</span>
|
||||||
|
, so that, during note decryption, the recipient can check that
|
||||||
|
<span class="math">\(\mathsf{epk} = [\mathsf{esk}] \mathsf{g_d}\)</span>
|
||||||
|
(for the expected
|
||||||
|
<span class="math">\(\mathsf{g_d}\)</span>
|
||||||
|
) and ignore the payment as invalid otherwise. This forms a line of defense in the case that soundness of the zk-SNARK does not hold.</p>
|
||||||
|
<p>Merely sending
|
||||||
|
<span class="math">\(\mathsf{esk}\)</span>
|
||||||
|
to the recipient in the note plaintext would require us to enlarge the note plaintext, but also would compromise the proof of IND-CCA2 security for in-band secret distribution. We avoid both of these concerns by using a key derivation to obtain both
|
||||||
|
<span class="math">\(\mathsf{esk}\)</span>
|
||||||
|
and
|
||||||
|
<span class="math">\(\mathsf{rcm}\)</span>
|
||||||
|
.</p>
|
||||||
</section>
|
</section>
|
||||||
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
<p>Pseudo random functions (PRFs) are defined in section 4.2.1 of the Zcash Protocol Specification. <a id="id2" class="footnote_reference" href="#abstractprfs">3</a> We will be adapting <code>PRF^expand</code> for the purposes of this ZIP. This function is keyed by a 256-bit key <code>sk</code> and takes an arbitrary length byte sequence as input, returning a 64-byte sequence as output.</p>
|
<p>Pseudo random functions (PRFs) are defined in section 4.2.1 of the Zcash Protocol Specification <a id="id3" class="footnote_reference" href="#abstractprfs">4</a>. We will be adapting
|
||||||
|
<span class="math">\(\mathsf{PRF^{expand}}\)</span>
|
||||||
|
for the purposes of this ZIP. This function is keyed by a 256-bit key
|
||||||
|
<span class="math">\(\mathsf{sk}\)</span>
|
||||||
|
and takes an arbitrary length byte sequence as input, returning a
|
||||||
|
<span class="math">\(64\)</span>
|
||||||
|
-byte sequence as output.</p>
|
||||||
<section id="changes-to-sapling-note-plaintexts"><h3><span class="section-heading">Changes to Sapling Note plaintexts</span><span class="section-anchor"> <a href="#changes-to-sapling-note-plaintexts"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
<section id="changes-to-sapling-note-plaintexts"><h3><span class="section-heading">Changes to Sapling Note plaintexts</span><span class="section-anchor"> <a href="#changes-to-sapling-note-plaintexts"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
<p>Note plaintext encodings are specified in section 5.5 of the Zcash Protocol Specification. <a id="id3" class="footnote_reference" href="#notept">4</a> Currently, the encoding of a Sapling note plaintext requires that the first byte take the form <code>0x01</code>, indicating the version of the note plaintext. In addition, a 256-bit <code>rcm</code> field exists within the note plaintext and encoding.</p>
|
<p>Note plaintext encodings are specified in section 5.5 of the Zcash Protocol Specification <a id="id4" class="footnote_reference" href="#notept">5</a>. Currently, the encoding of a Sapling note plaintext requires that the first byte take the form
|
||||||
<p>Following the activation of this ZIP, the first byte of the encoding MUST take the form <code>0x02</code> (representing the new note plaintext version) and the field <code>rcm</code> of the encoding will be renamed to <code>rseed</code>. This field <code>rseed</code> of the Sapling note plaintext will no longer take the type of <cite>NoteCommit^Sapling.Trapdoor</cite> but will instead be a 32-byte sequence. The requirement that <code>rseed</code> (previously, <code>rcm</code>) be a scalar of the Jubjub elliptic curve, when interpreted as a little endian integer, is removed from the decryption of note plaintexts as described in sections 4.17.2 and 4.17.3 of the Zcash Protocol Specification. <a id="id4" class="footnote_reference" href="#saplingdecryptivk">5</a> <a id="id5" class="footnote_reference" href="#saplingdecryptovk">6</a></p>
|
<span class="math">\(\textbf{0x01}\)</span>
|
||||||
|
, indicating the version of the note plaintext. In addition, a
|
||||||
|
<span class="math">\(256\)</span>
|
||||||
|
-bit
|
||||||
|
<span class="math">\(\mathsf{rcm}\)</span>
|
||||||
|
field exists within the note plaintext and encoding.</p>
|
||||||
|
<p>Following the activation of this ZIP, the first byte of the encoding MUST take the form
|
||||||
|
<span class="math">\(\textbf{0x02}\)</span>
|
||||||
|
(representing the new note plaintext version) and the field
|
||||||
|
<span class="math">\(\mathsf{rcm}\)</span>
|
||||||
|
of the encoding will be renamed to
|
||||||
|
<span class="math">\(\mathsf{rseed}\)</span>
|
||||||
|
. This field
|
||||||
|
<span class="math">\(\mathsf{rseed}\)</span>
|
||||||
|
of the Sapling note plaintext will no longer take the type of
|
||||||
|
<span class="math">\(\mathsf{NoteCommit^{Sapling}.Trapdoor}\)</span>
|
||||||
|
but will instead be a
|
||||||
|
<span class="math">\(32\)</span>
|
||||||
|
-byte sequence. The requirement that
|
||||||
|
<span class="math">\(\mathsf{rseed}\)</span>
|
||||||
|
(previously,
|
||||||
|
<span class="math">\(\mathsf{rcm}\)</span>
|
||||||
|
) be a scalar of the Jubjub elliptic curve, when interpreted as a little endian integer, is removed from the decryption of note plaintexts as described in sections 4.17.2 and 4.17.3 of the Zcash Protocol Specification. <a id="id5" class="footnote_reference" href="#saplingdecryptivk">6</a> <a id="id6" class="footnote_reference" href="#saplingdecryptovk">7</a></p>
|
||||||
</section>
|
</section>
|
||||||
<section id="changes-to-the-process-of-sending-sapling-notes"><h3><span class="section-heading">Changes to the process of sending Sapling notes</span><span class="section-anchor"> <a href="#changes-to-the-process-of-sending-sapling-notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
<section id="changes-to-the-process-of-sending-sapling-notes"><h3><span class="section-heading">Changes to the process of sending Sapling notes</span><span class="section-anchor"> <a href="#changes-to-the-process-of-sending-sapling-notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
<p>The process of sending notes in Sapling is described in section 4.6.2 of the Zcash Protocol Specification. <a id="id6" class="footnote_reference" href="#saplingsend">7</a> During this process, the sender samples <code>rcm^new</code> uniformly at random. In addition, the process of encrypting a note is described in section 4.17.1 of the Zcash Protocol Specification. <a id="id7" class="footnote_reference" href="#saplingencrypt">2</a> During this process, the sender also samples the ephemeral private key <code>esk</code> uniformly at random.</p>
|
<p>The process of sending notes in Sapling is described in section 4.6.2 of the Zcash Protocol Specification <a id="id7" class="footnote_reference" href="#saplingsend">8</a>. During this process, the sender samples
|
||||||
<p>After the activation of this ZIP, the sender will sample a uniformly random 32-byte sequence <code>rseed</code>. The note plaintext will take <code>rseed</code> in place of <code>rcm^new</code>.</p>
|
<span class="math">\(\mathsf{rcm^{new}}\)</span>
|
||||||
<p><code>rcm^new</code> is then computed by the sender as the output of <code>ToScalar(PRF^expand_rseed([4]))</code>.</p>
|
uniformly at random. In addition, the process of encrypting a note is described in section 4.17.1 of the Zcash Protocol Specification <a id="id8" class="footnote_reference" href="#saplingencrypt">3</a>. During this process, the sender also samples the ephemeral private key
|
||||||
<p><code>esk</code> is also computed by the sender as the output of <code>ToScalar(PRF^expand_rseed([5]))</code>.</p>
|
<span class="math">\(\mathsf{esk}\)</span>
|
||||||
|
uniformly at random.</p>
|
||||||
|
<p>After the activation of this ZIP, the sender will instead sample a uniformly random
|
||||||
|
<span class="math">\(32\)</span>
|
||||||
|
-byte sequence
|
||||||
|
<span class="math">\(\mathsf{rseed}\)</span>
|
||||||
|
. The note plaintext will take
|
||||||
|
<span class="math">\(\mathsf{rseed}\)</span>
|
||||||
|
in place of
|
||||||
|
<span class="math">\(\mathsf{rcm^{new}}\)</span>
|
||||||
|
.</p>
|
||||||
|
<p>
|
||||||
|
<span class="math">\(\mathsf{rcm^{new}}\)</span>
|
||||||
|
is then computed by the sender as the output of
|
||||||
|
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4]))\)</span>
|
||||||
|
.</p>
|
||||||
|
<p>
|
||||||
|
<span class="math">\(\mathsf{esk}\)</span>
|
||||||
|
is also computed by the sender as the output of
|
||||||
|
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))\)</span>
|
||||||
|
.</p>
|
||||||
</section>
|
</section>
|
||||||
<section id="changes-to-the-process-of-receiving-sapling-notes"><h3><span class="section-heading">Changes to the process of receiving Sapling notes</span><span class="section-anchor"> <a href="#changes-to-the-process-of-receiving-sapling-notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
<section id="changes-to-the-process-of-receiving-sapling-notes"><h3><span class="section-heading">Changes to the process of receiving Sapling notes</span><span class="section-anchor"> <a href="#changes-to-the-process-of-receiving-sapling-notes"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h3>
|
||||||
<p>The process of receiving notes in Sapling is described in sections 4.17.2 and 4.17.3 of the Zcash Protocol Specification. <a id="id8" class="footnote_reference" href="#saplingdecryptivk">5</a> <a id="id9" class="footnote_reference" href="#saplingdecryptovk">6</a></p>
|
<p>The process of receiving notes in Sapling is described in sections 4.17.2 and 4.17.3 of the Zcash Protocol Specification. <a id="id9" class="footnote_reference" href="#saplingdecryptivk">6</a> <a id="id10" class="footnote_reference" href="#saplingdecryptovk">7</a></p>
|
||||||
<p>After the activation of this ZIP, the note plaintext contains a field <code>rseed</code> that is a 32-byte sequence rather than a scalar value <code>rcm</code>. The recipient, during decryption and in any later contexts, will interpret the value <code>rcm</code> as the output of <code>ToScalar(PRF^expand_rseed([4]))</code>. Further, the recipient MUST compute <code>esk</code> as <code>ToScalar(PRF^expand_rseed([5]))</code> and check that <code>epk =
|
<p>After the activation of this ZIP, the note plaintext contains a field
|
||||||
[esk] g_d</code> and fail decryption if this check is not satisfied.</p>
|
<span class="math">\(\mathsf{rseed}\)</span>
|
||||||
|
that is a
|
||||||
|
<span class="math">\(32\)</span>
|
||||||
|
-byte sequence rather than a scalar value
|
||||||
|
<span class="math">\(\mathsf{rcm}\)</span>
|
||||||
|
. The recipient, during decryption and in any later contexts, will interpret the value
|
||||||
|
<span class="math">\(\mathsf{rcm}\)</span>
|
||||||
|
as the output of
|
||||||
|
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4]))\)</span>
|
||||||
|
. Further, the recipient MUST compute
|
||||||
|
<span class="math">\(\mathsf{esk}\)</span>
|
||||||
|
as
|
||||||
|
<span class="math">\(\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))\)</span>
|
||||||
|
and check that
|
||||||
|
<span class="math">\(\mathsf{epk} = [\mathsf{esk}] \mathsf{g_d}\)</span>
|
||||||
|
and fail decryption if this check is not satisfied.</p>
|
||||||
</section>
|
</section>
|
||||||
</section>
|
</section>
|
||||||
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
<p>The attack that this prevents is an interactive attack that requires an adversary to be able to break critical soundness properties of the zk-SNARKs underlying Sapling. It is potentially valid to assume that this cannot occur, due to other damaging effects on the system such as undetectable counterfeiting. However, we have attempted to avoid any instance in the protocol where privacy (even against interactive attacks) depended on strong cryptographic assumptions. Acting differently here would be confusing for users that have previously been told that "privacy does not depend on zk-SNARK soundness" or similar claims.</p>
|
<p>The attack that this prevents is an interactive attack that requires an adversary to be able to break critical soundness properties of the zk-SNARKs underlying Sapling. It is potentially valid to assume that this cannot occur, due to other damaging effects on the system such as undetectable counterfeiting. However, we have attempted to avoid any instance in the protocol where privacy (even against interactive attacks) depended on strong cryptographic assumptions. Acting differently here would be confusing for users that have previously been told that "privacy does not depend on zk-SNARK soundness" or similar claims.</p>
|
||||||
<p>It is possible for us to infringe on the length of the <code>memo</code> field and ask the sender to provide <code>esk</code> within the existing note plaintext without modifying the transaction format, but this would harm users that have come to expect a 512-byte memo field to be available to them. Changes to the memo field length should be considered in a broader context than changes made for cryptographic purposes.</p>
|
<p>It is possible for us to infringe on the length of the <code>memo</code> field and ask the sender to provide
|
||||||
<p>It is possible to transmit a signature of knowledge of a correct <code>esk</code> rather than <code>esk</code> itself, but this appears to be an unnecessary complication and is likely slower than just supplying <code>esk</code>.</p>
|
<span class="math">\(\mathsf{esk}\)</span>
|
||||||
|
within the existing note plaintext without modifying the transaction format, but this would harm users who have come to expect a
|
||||||
|
<span class="math">\(512\)</span>
|
||||||
|
-byte memo field to be available to them. Changes to the memo field length should be considered in a broader context than changes made for cryptographic purposes.</p>
|
||||||
|
<p>It is possible to transmit a signature of knowledge of a correct
|
||||||
|
<span class="math">\(\mathsf{esk}\)</span>
|
||||||
|
rather than
|
||||||
|
<span class="math">\(\mathsf{esk}\)</span>
|
||||||
|
itself, but this appears to be an unnecessary complication and is likely slower than just supplying
|
||||||
|
<span class="math">\(\mathsf{esk}\)</span>
|
||||||
|
.</p>
|
||||||
</section>
|
</section>
|
||||||
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
<p>The changes made in this proposal prevent an interactive attack that could link together diversified addresses by only breaking the knowledge soundness assumption of the zk-SNARK. It is already assumed that the adversary cannot defeat the EC-DDH assumption of the Jubjub elliptic curve, for it could perform a linkability attack trivially in that case.</p>
|
<p>The changes made in this proposal prevent an interactive attack that could link together diversified addresses by only breaking the knowledge soundness assumption of the zk-SNARK. It is already assumed that the adversary cannot defeat the EC-DDH assumption of the Jubjub elliptic curve, for it could perform a linkability attack trivially in that case.</p>
|
||||||
<p>In the naive case where the protocol is modified so that <code>esk</code> is supplied directly to the recipient (rather than derived through <code>rseed</code>) this would lead to an instance of key-dependent encryption, which is difficult or perhaps impossible to prove secure using existing security notions. Our approach of using a key derivation, which ultimately queries an oracle, allows a proof for IND-CCA2 security to be written by reprogramming the oracle to return bogus keys when necessary.</p>
|
<p>In the naive case where the protocol is modified so that
|
||||||
|
<span class="math">\(\mathsf{esk}\)</span>
|
||||||
|
is supplied directly to the recipient (rather than derived through
|
||||||
|
<span class="math">\(\mathsf{rseed}\)</span>
|
||||||
|
) this would lead to an instance of key-dependent encryption, which is difficult or perhaps impossible to prove secure using existing security notions. Our approach of using a key derivation, which ultimately queries an oracle, allows a proof for IND-CCA2 security to be written by reprogramming the oracle to return bogus keys when necessary.</p>
|
||||||
</section>
|
</section>
|
||||||
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
<section id="reference-implementation"><h2><span class="section-heading">Reference Implementation</span><span class="section-anchor"> <a href="#reference-implementation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
<p>TBD</p>
|
<p>TBD</p>
|
||||||
|
|
@ -67,10 +193,18 @@ GH(d)</code> included within the Note commitment. This <code>g_d</code> is deter
|
||||||
<p>The discovery that diversified address unlinkability depended on the zk-SNARK knowledge assumption was made by Sean Bowe and Zooko Wilcox.</p>
|
<p>The discovery that diversified address unlinkability depended on the zk-SNARK knowledge assumption was made by Sean Bowe and Zooko Wilcox.</p>
|
||||||
</section>
|
</section>
|
||||||
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
|
||||||
<table id="protocol" class="footnote">
|
<table id="rfc2119" class="footnote">
|
||||||
<tbody>
|
<tbody>
|
||||||
<tr>
|
<tr>
|
||||||
<th>1</th>
|
<th>1</th>
|
||||||
|
<td><a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a></td>
|
||||||
|
</tr>
|
||||||
|
</tbody>
|
||||||
|
</table>
|
||||||
|
<table id="protocol" class="footnote">
|
||||||
|
<tbody>
|
||||||
|
<tr>
|
||||||
|
<th>2</th>
|
||||||
<td><a href="https://zips.z.cash/protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later</a></td>
|
<td><a href="https://zips.z.cash/protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later</a></td>
|
||||||
</tr>
|
</tr>
|
||||||
</tbody>
|
</tbody>
|
||||||
|
|
@ -78,7 +212,7 @@ GH(d)</code> included within the Note commitment. This <code>g_d</code> is deter
|
||||||
<table id="saplingencrypt" class="footnote">
|
<table id="saplingencrypt" class="footnote">
|
||||||
<tbody>
|
<tbody>
|
||||||
<tr>
|
<tr>
|
||||||
<th>2</th>
|
<th>3</th>
|
||||||
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingencrypt">Section 4.17.1: Encryption (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later</a></td>
|
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingencrypt">Section 4.17.1: Encryption (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later</a></td>
|
||||||
</tr>
|
</tr>
|
||||||
</tbody>
|
</tbody>
|
||||||
|
|
@ -86,7 +220,7 @@ GH(d)</code> included within the Note commitment. This <code>g_d</code> is deter
|
||||||
<table id="abstractprfs" class="footnote">
|
<table id="abstractprfs" class="footnote">
|
||||||
<tbody>
|
<tbody>
|
||||||
<tr>
|
<tr>
|
||||||
<th>3</th>
|
<th>4</th>
|
||||||
<td><a href="https://zips.z.cash/protocol/protocol.pdf#abstractprfs">Section 4.1.2: Pseudo Random Functions. Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later</a></td>
|
<td><a href="https://zips.z.cash/protocol/protocol.pdf#abstractprfs">Section 4.1.2: Pseudo Random Functions. Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later</a></td>
|
||||||
</tr>
|
</tr>
|
||||||
</tbody>
|
</tbody>
|
||||||
|
|
@ -94,7 +228,7 @@ GH(d)</code> included within the Note commitment. This <code>g_d</code> is deter
|
||||||
<table id="notept" class="footnote">
|
<table id="notept" class="footnote">
|
||||||
<tbody>
|
<tbody>
|
||||||
<tr>
|
<tr>
|
||||||
<th>4</th>
|
<th>5</th>
|
||||||
<td><a href="https://zips.z.cash/protocol/protocol.pdf#notept">Section 5.5: Encodings of Note Plaintexts and Memo Fields. Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later</a></td>
|
<td><a href="https://zips.z.cash/protocol/protocol.pdf#notept">Section 5.5: Encodings of Note Plaintexts and Memo Fields. Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later</a></td>
|
||||||
</tr>
|
</tr>
|
||||||
</tbody>
|
</tbody>
|
||||||
|
|
@ -102,7 +236,7 @@ GH(d)</code> included within the Note commitment. This <code>g_d</code> is deter
|
||||||
<table id="saplingdecryptivk" class="footnote">
|
<table id="saplingdecryptivk" class="footnote">
|
||||||
<tbody>
|
<tbody>
|
||||||
<tr>
|
<tr>
|
||||||
<th>5</th>
|
<th>6</th>
|
||||||
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingdecryptivk">Section 4.17.2: Decryption using an Incoming Viewing Key (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later</a></td>
|
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingdecryptivk">Section 4.17.2: Decryption using an Incoming Viewing Key (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later</a></td>
|
||||||
</tr>
|
</tr>
|
||||||
</tbody>
|
</tbody>
|
||||||
|
|
@ -110,7 +244,7 @@ GH(d)</code> included within the Note commitment. This <code>g_d</code> is deter
|
||||||
<table id="saplingdecryptovk" class="footnote">
|
<table id="saplingdecryptovk" class="footnote">
|
||||||
<tbody>
|
<tbody>
|
||||||
<tr>
|
<tr>
|
||||||
<th>6</th>
|
<th>7</th>
|
||||||
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingdecryptovk">Section 4.17.3: Decryption using a Full Viewing Key (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later</a></td>
|
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingdecryptovk">Section 4.17.3: Decryption using a Full Viewing Key (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later</a></td>
|
||||||
</tr>
|
</tr>
|
||||||
</tbody>
|
</tbody>
|
||||||
|
|
@ -118,7 +252,7 @@ GH(d)</code> included within the Note commitment. This <code>g_d</code> is deter
|
||||||
<table id="saplingsend" class="footnote">
|
<table id="saplingsend" class="footnote">
|
||||||
<tbody>
|
<tbody>
|
||||||
<tr>
|
<tr>
|
||||||
<th>7</th>
|
<th>8</th>
|
||||||
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingsend">Section 4.6.2: Sending Notes (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later</a></td>
|
<td><a href="https://zips.z.cash/protocol/protocol.pdf#saplingsend">Section 4.6.2: Sending Notes (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later</a></td>
|
||||||
</tr>
|
</tr>
|
||||||
</tbody>
|
</tbody>
|
||||||
|
|
|
||||||
177
zip-0212.rst
177
zip-0212.rst
|
|
@ -12,9 +12,11 @@
|
||||||
Terminology
|
Terminology
|
||||||
===========
|
===========
|
||||||
|
|
||||||
The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119.
|
The key words "MUST" and "MUST NOT" in this document are to be interpreted as
|
||||||
|
described in RFC 2119. [#RFC2119]_
|
||||||
|
|
||||||
The function ``ToScalar`` is defined as in Section 4.4.2 of the Zcash Protocol Specification. [#protocol]_
|
The function :math:`\mathsf{ToScalar}` is defined as in Section 4.4.2 of the
|
||||||
|
Zcash Protocol Specification. [#protocol]_
|
||||||
|
|
||||||
Abstract
|
Abstract
|
||||||
========
|
========
|
||||||
|
|
@ -33,95 +35,104 @@ number of distinct and unlinkable payment addresses. This feature allows users
|
||||||
to maintain many payment addresses without paying additional overhead during
|
to maintain many payment addresses without paying additional overhead during
|
||||||
blockchain scanning.
|
blockchain scanning.
|
||||||
|
|
||||||
The feature works by allowing payment addresses to become a tuple (``pk_d``,
|
The feature works by allowing payment addresses to become a tuple
|
||||||
``d``) of a public key ``pk_d`` and 88-bit diversifier ``d`` such that ``pk_d =
|
:math:`(\mathsf{pk_d}, \mathsf{d})` of a public key :math:`\mathsf{pk_d}` and
|
||||||
[ivk] GH(d)`` for some incoming viewing key ``ivk``. The hash function ``GH(d)``
|
:math:`88`-bit diversifier :math:`\mathsf{d}` such that
|
||||||
maps from a diversifier to prime order elements of the Jubjub elliptic curve. It
|
:math:`\mathsf{pk_d} = [\mathsf{ivk}] GH(\mathsf{d})` for some incoming viewing key
|
||||||
is possible for a user to choose many ``d`` to create several distinct and
|
:math:`\mathsf{ivk}`. The hash function :math:`GH(\mathsf{d})` maps from a
|
||||||
unlinkable payment addresses of this form.
|
diversifier to prime order elements of the Jubjub elliptic curve. It
|
||||||
|
is possible for a user to choose many :math:`\mathsf{d}` to create several
|
||||||
|
distinct and unlinkable payment addresses of this form.
|
||||||
|
|
||||||
In order to make a payment to a Sapling address, an ephemeral secret ``esk`` is
|
In order to make a payment to a Sapling address, an ephemeral secret
|
||||||
sampled by the sender and an ephemeral public key ``epk = [esk] GH(d)`` is
|
:math:`\mathsf{esk}` is sampled by the sender and an ephemeral public key
|
||||||
included in the Output description. Then, a shared Diffie-Hellman secret is
|
:math:`\mathsf{epk} = [\mathsf{esk}] GH(\mathsf{d})` is included in the
|
||||||
computed by the sender as ``[esk] [8] pk_d``. The recipient can recover this
|
Output description. Then, a shared Diffie-Hellman secret is computed by the
|
||||||
shared secret without knowledge of the particular ``d`` by computing ``[ivk] [8]
|
sender as :math:`[\mathsf{esk}] [8] \mathsf{pk_d}`. The recipient can recover
|
||||||
epk``. This shared secret is then used as part of Note decryption.
|
this shared secret without knowledge of the particular :math:`\mathsf{d}` by
|
||||||
|
computing :math:`[\mathsf{ivk}] [8] \mathsf{epk}`. This shared secret is then
|
||||||
|
used as part of note decryption.
|
||||||
|
|
||||||
Naively, the recipient cannot know which ``(pk_d, d)`` was used to compute the
|
Naively, the recipient cannot know which :math:`(\mathsf{pk_d}, \mathsf{d})`
|
||||||
shared secret, but the sender is asked to include the ``d`` within the note
|
was used to compute the shared secret, but the sender is asked to include the
|
||||||
plaintext to reconstruct the Note. However, if the recipient has more than one
|
:math:`\mathsf{d}` within the note plaintext to reconstruct the note. However,
|
||||||
known addresses, an attacker could use a different payment address to perform
|
if the recipient has more than one known address, an attacker could use a
|
||||||
secret exchange and, by observing the behavior of the recipient, link the two
|
different payment address to perform secret exchange and, by observing the
|
||||||
diversified addresses together. (This attacker strategy was discovered by Brian
|
behavior of the recipient, link the two diversified addresses together. (This
|
||||||
Warner earlier in the design of the Sapling protocol.)
|
attacker strategy was discovered by Brian Warner earlier in the design of the
|
||||||
|
Sapling protocol.)
|
||||||
|
|
||||||
In order to prevent this attack, the protocol currently forces the sender to
|
In order to prevent this attack, the protocol currently forces the sender to
|
||||||
prove knowledge of the discrete logarithm of ``epk`` with respect to the ``g_d =
|
prove knowledge of the discrete logarithm of :math:`\mathsf{epk}` with respect
|
||||||
GH(d)`` included within the Note commitment. This ``g_d`` is determined by ``d``
|
to the :math:`\mathsf{g_d} = GH(\mathsf{d})` included within the note
|
||||||
and recomputed during Note decryption, and so the recipient will either be
|
commitment. This :math:`\mathsf{g_d}` is determined by :math:`\mathsf{d}`
|
||||||
|
and recomputed during note decryption, and so the recipient will either be
|
||||||
unable to decrypt the note or the sender will be unable to perform the attack.
|
unable to decrypt the note or the sender will be unable to perform the attack.
|
||||||
|
|
||||||
However, this check occurs as part of the zero-knowledge proof statement and so
|
However, this check occurs as part of the zero-knowledge proof statement and so
|
||||||
relies on the soundness of the underlying zk-SNARK in Sapling, and therefore it
|
relies on the soundness of the underlying zk-SNARK in Sapling, and therefore it
|
||||||
relies on relatively strong cryptographic assumptions and a trusted setup. It
|
relies on relatively strong cryptographic assumptions and a trusted setup. It
|
||||||
would be preferable to force the sender to transfer ``esk`` within the Note
|
would be preferable to force the sender to transfer sufficient information in
|
||||||
plaintext so that, during note decryption, the recipient can check that ``epk =
|
the note plaintext to allow deriving :math:`\mathsf{esk}`, so that, during note
|
||||||
[esk] g_d`` (for the expected ``g_d``) and ignore the payment as invalid
|
decryption, the recipient can check that :math:`\mathsf{epk} = [\mathsf{esk}] \mathsf{g_d}`
|
||||||
|
(for the expected :math:`\mathsf{g_d}`) and ignore the payment as invalid
|
||||||
otherwise. This forms a line of defense in the case that soundness of the
|
otherwise. This forms a line of defense in the case that soundness of the
|
||||||
zk-SNARK does not hold.
|
zk-SNARK does not hold.
|
||||||
|
|
||||||
Merely sending ``esk`` to the recipient in the Note plaintext would require us
|
Merely sending :math:`\mathsf{esk}` to the recipient in the note plaintext would
|
||||||
to enlarge the note plaintext, but also would compromise the proof of IND-CCA2
|
require us to enlarge the note plaintext, but also would compromise the proof
|
||||||
security for in-band secret distribution. We avoid both of these concerns by
|
of IND-CCA2 security for in-band secret distribution. We avoid both of these
|
||||||
using a key derivation to obtain both ``esk`` and ``rcm``.
|
concerns by using a key derivation to obtain both :math:`\mathsf{esk}` and
|
||||||
|
:math:`\mathsf{rcm}`.
|
||||||
|
|
||||||
Specification
|
Specification
|
||||||
=============
|
=============
|
||||||
|
|
||||||
Pseudo random functions (PRFs) are defined in section 4.2.1 of the Zcash
|
Pseudo random functions (PRFs) are defined in section 4.2.1 of the Zcash
|
||||||
Protocol Specification. [#abstractprfs]_ We will be adapting ``PRF^expand`` for
|
Protocol Specification [#abstractprfs]_. We will be adapting
|
||||||
the purposes of this ZIP. This function is keyed by a 256-bit key ``sk`` and
|
:math:`\mathsf{PRF^{expand}}` for the purposes of this ZIP. This function is
|
||||||
takes an arbitrary length byte sequence as input, returning a 64-byte sequence
|
keyed by a 256-bit key :math:`\mathsf{sk}` and takes an arbitrary length byte
|
||||||
as output.
|
sequence as input, returning a :math:`64`-byte sequence as output.
|
||||||
|
|
||||||
Changes to Sapling Note plaintexts
|
Changes to Sapling Note plaintexts
|
||||||
----------------------------------
|
----------------------------------
|
||||||
|
|
||||||
Note plaintext encodings are specified in section 5.5 of the Zcash Protocol
|
Note plaintext encodings are specified in section 5.5 of the Zcash Protocol
|
||||||
Specification. [#notept]_ Currently, the encoding of a Sapling note plaintext
|
Specification [#notept]_. Currently, the encoding of a Sapling note plaintext
|
||||||
requires that the first byte take the form ``0x01``, indicating the version of
|
requires that the first byte take the form :math:`\textbf{0x01}`, indicating
|
||||||
the note plaintext. In addition, a 256-bit ``rcm`` field exists within the note
|
the version of the note plaintext. In addition, a :math:`256`-bit
|
||||||
plaintext and encoding.
|
:math:`\mathsf{rcm}` field exists within the note plaintext and encoding.
|
||||||
|
|
||||||
Following the activation of this ZIP, the first byte of the encoding MUST take
|
Following the activation of this ZIP, the first byte of the encoding MUST take
|
||||||
the form ``0x02`` (representing the new note plaintext version) and the field
|
the form :math:`\textbf{0x02}` (representing the new note plaintext version)
|
||||||
``rcm`` of the encoding will be renamed to ``rseed``. This field ``rseed`` of
|
and the field :math:`\mathsf{rcm}` of the encoding will be renamed to
|
||||||
the Sapling note plaintext will no longer take the type of
|
:math:`\mathsf{rseed}`. This field :math:`\mathsf{rseed}` of the Sapling note
|
||||||
`NoteCommit^Sapling.Trapdoor` but will instead be a 32-byte sequence. The
|
plaintext will no longer take the type of :math:`\mathsf{NoteCommit^{Sapling}.Trapdoor}`
|
||||||
requirement that ``rseed`` (previously, ``rcm``) be a scalar of the Jubjub
|
but will instead be a :math:`32`-byte sequence. The requirement that
|
||||||
elliptic curve, when interpreted as a little endian integer, is removed from the
|
:math:`\mathsf{rseed}` (previously, :math:`\mathsf{rcm}`) be a scalar of the
|
||||||
decryption of note plaintexts as described in sections 4.17.2 and 4.17.3 of the
|
Jubjub elliptic curve, when interpreted as a little endian integer, is removed
|
||||||
Zcash Protocol Specification. [#saplingdecryptivk]_ [#saplingdecryptovk]_
|
from the decryption of note plaintexts as described in sections 4.17.2 and 4.17.3
|
||||||
|
of the Zcash Protocol Specification. [#saplingdecryptivk]_ [#saplingdecryptovk]_
|
||||||
|
|
||||||
Changes to the process of sending Sapling notes
|
Changes to the process of sending Sapling notes
|
||||||
-----------------------------------------------
|
-----------------------------------------------
|
||||||
|
|
||||||
The process of sending notes in Sapling is described in section 4.6.2 of the
|
The process of sending notes in Sapling is described in section 4.6.2 of the
|
||||||
Zcash Protocol Specification. [#saplingsend]_ During this process, the sender
|
Zcash Protocol Specification [#saplingsend]_. During this process, the sender
|
||||||
samples ``rcm^new`` uniformly at random. In addition, the process of encrypting
|
samples :math:`\mathsf{rcm^{new}}` uniformly at random. In addition, the
|
||||||
a note is described in section 4.17.1 of the Zcash Protocol Specification.
|
process of encrypting a note is described in section 4.17.1 of the Zcash Protocol
|
||||||
[#saplingencrypt]_ During this process, the sender also samples the ephemeral
|
Specification [#saplingencrypt]_. During this process, the sender also samples
|
||||||
private key ``esk`` uniformly at random.
|
the ephemeral private key :math:`\mathsf{esk}` uniformly at random.
|
||||||
|
|
||||||
After the activation of this ZIP, the sender will sample a uniformly random
|
After the activation of this ZIP, the sender will instead sample a uniformly
|
||||||
32-byte sequence ``rseed``. The note plaintext will take ``rseed`` in place of
|
random :math:`32`-byte sequence :math:`\mathsf{rseed}`. The note plaintext will
|
||||||
``rcm^new``.
|
take :math:`\mathsf{rseed}` in place of :math:`\mathsf{rcm^{new}}`.
|
||||||
|
|
||||||
``rcm^new`` is then computed by the sender as the output of
|
:math:`\mathsf{rcm^{new}}` is then computed by the sender as the output of
|
||||||
``ToScalar(PRF^expand_rseed([4]))``.
|
:math:`\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4]))`.
|
||||||
|
|
||||||
``esk`` is also computed by the sender as the output of
|
:math:`\mathsf{esk}` is also computed by the sender as the output of
|
||||||
``ToScalar(PRF^expand_rseed([5]))``.
|
:math:`\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))`.
|
||||||
|
|
||||||
Changes to the process of receiving Sapling notes
|
Changes to the process of receiving Sapling notes
|
||||||
-------------------------------------------------
|
-------------------------------------------------
|
||||||
|
|
@ -130,12 +141,15 @@ The process of receiving notes in Sapling is described in sections 4.17.2 and
|
||||||
4.17.3 of the Zcash Protocol Specification. [#saplingdecryptivk]_
|
4.17.3 of the Zcash Protocol Specification. [#saplingdecryptivk]_
|
||||||
[#saplingdecryptovk]_
|
[#saplingdecryptovk]_
|
||||||
|
|
||||||
After the activation of this ZIP, the note plaintext contains a field ``rseed``
|
After the activation of this ZIP, the note plaintext contains a field
|
||||||
that is a 32-byte sequence rather than a scalar value ``rcm``. The recipient,
|
:math:`\mathsf{rseed}` that is a :math:`32`-byte sequence rather than a
|
||||||
during decryption and in any later contexts, will interpret the value ``rcm`` as
|
scalar value :math:`\mathsf{rcm}`. The recipient, during decryption and in
|
||||||
the output of ``ToScalar(PRF^expand_rseed([4]))``. Further, the recipient MUST
|
any later contexts, will interpret the value :math:`\mathsf{rcm}` as the
|
||||||
compute ``esk`` as ``ToScalar(PRF^expand_rseed([5]))`` and check that ``epk =
|
output of :math:`\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([4]))`.
|
||||||
[esk] g_d`` and fail decryption if this check is not satisfied.
|
Further, the recipient MUST compute :math:`\mathsf{esk}` as
|
||||||
|
:math:`\mathsf{ToScalar}(\mathsf{PRF^{expand}_{rseed}}([5]))` and check
|
||||||
|
that :math:`\mathsf{epk} = [\mathsf{esk}] \mathsf{g_d}` and fail decryption
|
||||||
|
if this check is not satisfied.
|
||||||
|
|
||||||
Rationale
|
Rationale
|
||||||
=========
|
=========
|
||||||
|
|
@ -150,15 +164,16 @@ Acting differently here would be confusing for users that have previously been
|
||||||
told that "privacy does not depend on zk-SNARK soundness" or similar claims.
|
told that "privacy does not depend on zk-SNARK soundness" or similar claims.
|
||||||
|
|
||||||
It is possible for us to infringe on the length of the ``memo`` field and ask
|
It is possible for us to infringe on the length of the ``memo`` field and ask
|
||||||
the sender to provide ``esk`` within the existing note plaintext without
|
the sender to provide :math:`\mathsf{esk}` within the existing note plaintext
|
||||||
modifying the transaction format, but this would harm users that have come to
|
without modifying the transaction format, but this would harm users who have
|
||||||
expect a 512-byte memo field to be available to them. Changes to the memo field
|
come to expect a :math:`512`-byte memo field to be available to them. Changes
|
||||||
length should be considered in a broader context than changes made for
|
to the memo field length should be considered in a broader context than changes
|
||||||
cryptographic purposes.
|
made for cryptographic purposes.
|
||||||
|
|
||||||
It is possible to transmit a signature of knowledge of a correct ``esk`` rather
|
It is possible to transmit a signature of knowledge of a correct
|
||||||
than ``esk`` itself, but this appears to be an unnecessary complication and is
|
:math:`\mathsf{esk}` rather than :math:`\mathsf{esk}` itself, but this appears
|
||||||
likely slower than just supplying ``esk``.
|
to be an unnecessary complication and is likely slower than just supplying
|
||||||
|
:math:`\mathsf{esk}`.
|
||||||
|
|
||||||
Security and Privacy Considerations
|
Security and Privacy Considerations
|
||||||
===================================
|
===================================
|
||||||
|
|
@ -169,13 +184,13 @@ assumption of the zk-SNARK. It is already assumed that the adversary cannot
|
||||||
defeat the EC-DDH assumption of the Jubjub elliptic curve, for it could perform
|
defeat the EC-DDH assumption of the Jubjub elliptic curve, for it could perform
|
||||||
a linkability attack trivially in that case.
|
a linkability attack trivially in that case.
|
||||||
|
|
||||||
In the naive case where the protocol is modified so that ``esk`` is supplied
|
In the naive case where the protocol is modified so that :math:`\mathsf{esk}`
|
||||||
directly to the recipient (rather than derived through ``rseed``) this would
|
is supplied directly to the recipient (rather than derived through
|
||||||
lead to an instance of key-dependent encryption, which is difficult or perhaps
|
:math:`\mathsf{rseed}`) this would lead to an instance of key-dependent
|
||||||
impossible to prove secure using existing security notions. Our approach of
|
encryption, which is difficult or perhaps impossible to prove secure using
|
||||||
using a key derivation, which ultimately queries an oracle, allows a proof for
|
existing security notions. Our approach of using a key derivation, which
|
||||||
IND-CCA2 security to be written by reprogramming the oracle to return bogus keys
|
ultimately queries an oracle, allows a proof for IND-CCA2 security to be
|
||||||
when necessary.
|
written by reprogramming the oracle to return bogus keys when necessary.
|
||||||
|
|
||||||
Reference Implementation
|
Reference Implementation
|
||||||
========================
|
========================
|
||||||
|
|
@ -190,6 +205,8 @@ knowledge assumption was made by Sean Bowe and Zooko Wilcox.
|
||||||
|
|
||||||
References
|
References
|
||||||
==========
|
==========
|
||||||
|
|
||||||
|
.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>`_
|
||||||
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later <https://zips.z.cash/protocol/protocol.pdf>`_
|
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later <https://zips.z.cash/protocol/protocol.pdf>`_
|
||||||
.. [#saplingencrypt] `Section 4.17.1: Encryption (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later <https://zips.z.cash/protocol/protocol.pdf#saplingencrypt>`_
|
.. [#saplingencrypt] `Section 4.17.1: Encryption (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later <https://zips.z.cash/protocol/protocol.pdf#saplingencrypt>`_
|
||||||
.. [#abstractprfs] `Section 4.1.2: Pseudo Random Functions. Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later <https://zips.z.cash/protocol/protocol.pdf#abstractprfs>`_
|
.. [#abstractprfs] `Section 4.1.2: Pseudo Random Functions. Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later <https://zips.z.cash/protocol/protocol.pdf#abstractprfs>`_
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue