<p>The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119. <aid="id1"class="footnote_reference"href="#rfc2119">1</a></p>
<p>The function
<spanclass="math">\(\mathsf{ToScalar}\)</span>
is defined as in Section 4.4.2 of the Zcash Protocol Specification. <aid="id2"class="footnote_reference"href="#protocol">2</a></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 ephemeral Diffie-Hellman key in the Output to avoid an assumption on zk-SNARK soundness for preventing diversified address linkability.</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>
was used to compute the shared secret, but the sender is asked to include the
<spanclass="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
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
<spanclass="math">\(\mathsf{esk}\)</span>
, so that, during note decryption, the recipient can check that
) 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
<spanclass="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
<p>Pseudo random functions (PRFs) are defined in section 4.2.1 of the Zcash Protocol Specification <aid="id3"class="footnote_reference"href="#abstractprfs">4</a>. We will be adapting
<sectionid="changes-to-sapling-note-plaintexts"><h3><spanclass="section-heading">Changes to Sapling Note plaintexts</span><spanclass="section-anchor"><arel="bookmark"href="#changes-to-sapling-note-plaintexts"><imgwidth="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 <aid="id4"class="footnote_reference"href="#notept">5</a>. Currently, the encoding of a Sapling note plaintext requires that the first byte take the form
<spanclass="math">\(\textbf{0x01}\)</span>
, indicating the version of the note plaintext. In addition, a
<spanclass="math">\(256\)</span>
-bit
<spanclass="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
<spanclass="math">\(\textbf{0x02}\)</span>
(representing the new note plaintext version) and the field
<spanclass="math">\(\mathsf{rcm}\)</span>
of the encoding will be renamed to
<spanclass="math">\(\mathsf{rseed}\)</span>
. This field
<spanclass="math">\(\mathsf{rseed}\)</span>
of the Sapling note plaintext will no longer take the type of
) be a scalar of the Jubjub elliptic curve, when interpreted as a little endian integer, is removed from the description of note plaintexts in sections 4.17.2 and 4.17.3 of the Zcash Protocol Specification. <aid="id5"class="footnote_reference"href="#saplingdecryptivk">6</a><aid="id6"class="footnote_reference"href="#saplingdecryptovk">7</a></p>
<sectionid="changes-to-the-process-of-sending-sapling-notes"><h3><spanclass="section-heading">Changes to the process of sending Sapling notes</span><spanclass="section-anchor"><arel="bookmark"href="#changes-to-the-process-of-sending-sapling-notes"><imgwidth="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 <aid="id7"class="footnote_reference"href="#saplingsend">8</a>. During this process, the sender samples
<spanclass="math">\(\mathsf{rcm^{new}}\)</span>
uniformly at random. In addition, the process of encrypting a note is described in section 4.17.1 of the Zcash Protocol Specification <aid="id8"class="footnote_reference"href="#saplingencrypt">3</a>. During this process, the sender also samples the ephemeral private key
<spanclass="math">\(\mathsf{esk}\)</span>
uniformly at random.</p>
<p>After the activation of this ZIP, the sender will instead sample a uniformly random
<sectionid="changes-to-the-process-of-receiving-sapling-notes"><h3><spanclass="section-heading">Changes to the process of receiving Sapling notes</span><spanclass="section-anchor"><arel="bookmark"href="#changes-to-the-process-of-receiving-sapling-notes"><imgwidth="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. <aid="id9"class="footnote_reference"href="#saplingdecryptivk">6</a><aid="id10"class="footnote_reference"href="#saplingdecryptovk">7</a></p>
<p>After the activation of this ZIP, the note plaintext contains a field
<spanclass="math">\(\mathsf{rseed}\)</span>
that is a
<spanclass="math">\(32\)</span>
-byte sequence rather than a scalar value
<spanclass="math">\(\mathsf{rcm}\)</span>
. The recipient, during decryption and in any later contexts, will interpret the value
<sectionid="consensus-rule-change-for-coinbase-transactions"><h3><spanclass="section-heading">Consensus rule change for coinbase transactions</span><spanclass="section-anchor"><arel="bookmark"href="#consensus-rule-change-for-coinbase-transactions"><imgwidth="24"height="24"src="assets/images/section-anchor.png"alt=""></a></span></h3>
<p>After the activation of this ZIP, any Sapling output of a coinbase transaction that is decrypted to a note plaintext as specified in <aid="id11"class="footnote_reference"href="#zip-0213">10</a>, MUST have note plaintext lead byte equal to 0x02.</p>
<p>This applies even during the “grace period”, and also applies to funding stream outputs <aid="id12"class="footnote_reference"href="#zip-0207">9</a> sent to shielded payment addresses, if there are any.</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
<spanclass="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
<spanclass="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
<spanclass="math">\(\mathsf{esk}\)</span>
rather than
<spanclass="math">\(\mathsf{esk}\)</span>
itself, but this appears to be an unnecessary complication and is likely slower than just supplying
<sectionid="security-and-privacy-considerations"><h2><spanclass="section-heading">Security and Privacy Considerations</span><spanclass="section-anchor"><arel="bookmark"href="#security-and-privacy-considerations"><imgwidth="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>In the naive case where the protocol is modified so that
<spanclass="math">\(\mathsf{esk}\)</span>
is supplied directly to the recipient (rather than derived through
<spanclass="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>
<td><ahref="https://zips.z.cash/protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later</a></td>
<td><ahref="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><ahref="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><ahref="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><ahref="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>