V Ironwood Guide: The Zcash Orchard protocol and its Ironwood pool 9 The Action statement and its proof 11 Transactions and consensus rules

10 Note encryption

This section constructs the in-band delivery of a created note: its plaintext, its encryption to the recipient by one-shot Diffie–Hellman on the diversified base, the outgoing ciphertext keyed from $\mathsf{ovk}$ and the Action’s own public fields, and the trial decryption and acceptance checks by which a recipient obtains a note consistent with the published $\mathsf{cmx}$ . It states the two assumptions that note encryption adds, proves decryption correctness, confidentiality and key privacy of the encryption to the recipient, confidentiality of the outgoing ciphertext, and the consistency of accepted notes, and states what each key tier can decrypt.

10.1 The note plaintext

Every Action carries, beside the extracted commitment $\mathsf{cmx}$ of its created note, a note ciphertext $(\mathsf{epk}^{\star},C_{\mathsf{enc}},C_{\mathsf{out}})$ . The component $C_{\mathsf{enc}}$ encrypts the plaintext of the created note so that the holder of the recipient’s incoming viewing key $\mathsf{ivk}$ recovers the note and its memo from the chain alone (protocol specification, §“In-band secret distribution (Sapling and Orchard)” and §“Action Descriptions”). The component $C_{\mathsf{out}}$ lets the sender, or any party that holds the outgoing viewing key $\mathsf{ovk}$ under which it was formed, recover the same plaintext (§10.3). The fields $\mathsf{epk}^{\star}$ , $C_{\mathsf{enc}}$ and $C_{\mathsf{out}}$ are not inputs of the Action statement (Definition 9.2), which therefore does not constrain them; the checks that make a decrypted note consistent with $\mathsf{cmx}$ are made by the recipient (§10.4).

Definition 10.1 (Note plaintext).

Let a created note have recipient address $(d,\mathsf{pk_{d}})$ and value $v\in\{0,\dots,2^{64}-1\}$ . Its note plaintext is the tuple $\mathsf{np}:=(\mathsf{leadByte},d,v,\mathsf{rseed},\mathsf{memo})$ , encoded as the byte string

\mathsf{leadByte}\,\|\,\mathsf{LEBS2OSP}_{88}(d)\,\|\,\mathsf{I2LEOSP}_{64}(v)% \,\|\,\mathsf{rseed}\,\|\,\mathsf{memo},

where $\mathsf{leadByte}$ is one byte, the format version of “The note seed” (§4.3), equal to $\mathtt{0x03}$ for an Ironwood-pool output; $d$ is the $88$ -bit diversifier of the address ( $11$ bytes); $v$ occupies $8$ bytes; $\mathsf{rseed}$ is the $32$ -byte note seed; and $\mathsf{memo}$ is a $512$ -byte string chosen by the sender, whose use is by agreement between sender and recipient (protocol specification, §“Note Plaintexts and Memo Fields” and §“Encodings of Note Plaintexts and Memo Fields”). The encoding has the fixed length $1+11+8+32+512=564$ bytes, so the length of a ciphertext carries no information about the plaintext.

The plaintext omits $\mathsf{pk_{d}}$ , $\rho$ , $\psi$ and $\mathsf{rcm}$ . The recipient computes $\mathsf{pk_{d}}=[\mathsf{ivk}]\,\mathsf{g_{d}}$ , takes $\rho=\mathsf{nf}^{\mathsf{old}}$ from the same Action (“Nullifier chaining”, §6.3), and derives $\psi$ and $\mathsf{rcm}$ from $\mathsf{rseed}$ (§4.3).

For each output the sender draws $\mathsf{rseed}$ uniformly from the $32$ -byte strings, independently of every other output. The ephemeral secret key of this section is

\mathsf{esk}=\mathrm{ToScalar}\bigl{(}\mathsf{PRFexpand}_{\mathsf{rseed}}([% \mathtt{0x04}]\,\|\,\mathsf{I2LEOSP}_{256}(\mathsf{nf}^{\mathsf{old}}))\bigr{)},

derived in “The note seed” (§4.3) together with $\psi$ and $\mathsf{rcm}$ . The sender redraws $\mathsf{rseed}$ when $\mathsf{esk}=0$ or $\mathsf{cmx}=\bot$ , so $\mathsf{esk}\in\mathbb{F}_{p_{\mathsf{Vesta}}}^{*}$ (protocol specification, §“Sending Notes (Orchard)”; ZIP 2005, “Changes to the Protocol Specification”, §4.7.3).

10.2 Encryption to the recipient

Construction 10.2 (Encryption to the recipient).

Let $(d,\mathsf{pk_{d}})$ be the recipient’s address, $\mathsf{g_{d}}=\mathsf{DiversifyHash}(d)$ its diversified base (“Diversified addresses”, §3.3), and $\mathsf{esk}$ as in §10.1. A star encoding $P^{\star}$ enters a byte string as the $32$ bytes $\mathsf{LEBS2OSP}_{256}(P^{\star})$ (§2.1), with which it is identified below. The sender computes the ephemeral public key, the shared secret and the encryption key

	$\displaystyle\mathsf{epk}$	$\displaystyle:=[\mathsf{esk}]\,\mathsf{g_{d}},\qquad s:=[\mathsf{esk}]\,% \mathsf{pk_{d}},$
	$\displaystyle K_{\mathsf{enc}}$	$\displaystyle:=\mathsf{KDF}(s,\mathsf{epk}):=\mathrm{BLAKE2b\text{-}256}\bigl{% (}\texttt{Zcash\_OrchardKDF},\ s^{\star}\,\\|\,\mathsf{epk}^{\star}\bigr{)},$

with $\mathrm{BLAKE2b\text{-}256}(P,x)$ unkeyed BLAKE2b with a $32$ -byte output and the $16$ -byte personalisation $P$ , and the ciphertext $C_{\mathsf{enc}}:=\mathsf{Enc}_{K_{\mathsf{enc}}}(\mathsf{np})$ . The pair $\mathsf{Enc}_{K}$ , $\mathsf{Dec}_{K}$ denotes ChaCha20-Poly1305 encryption and decryption under the $256$ -bit key $K$ with the all-zero $96$ -bit nonce and empty associated data; decryption returns $\bot$ when the tag does not verify (Crypto Guide, §“The ChaCha20-Poly1305 AEAD”, Construction “ChaCha20-Poly1305”). The Action publishes the $32$ -byte field $\mathsf{epk}^{\star}$ and $C_{\mathsf{enc}}$ , of $564+16=580$ bytes, the plaintext and the $16$ -byte tag (protocol specification, §“Encryption (Sapling and Orchard)”, §“Orchard Key Agreement”, §“Orchard Key Derivation” and §“Symmetric Encryption”).

The key agreement is Diffie–Hellman on Pallas: public keys are non-identity points, private keys lie in $\mathbb{F}_{p_{\mathsf{Vesta}}}^{*}$ , and both the derivation of a public key from a base and the agreement are scalar multiplication (protocol specification, §“Orchard Key Agreement”). A consensus rule requires $\mathsf{epk}^{\star}$ to be the canonical encoding of a non-identity Pallas point (protocol specification, §“Action Descriptions”). The fixed nonce is safe because every key encrypts once: $K_{\mathsf{enc}}$ depends on the fresh $\mathsf{esk}$ of its output, and the key of $C_{\mathsf{out}}$ is derived separately (§10.3). The scheme is the Crypto Guide’s Construction “DH-based hybrid public-key encryption” (§“Hybrid public-key encryption”) over the per-address base $\mathsf{g_{d}}$ in place of a fixed generator, as the same volume records for deployed note delivery (§“Shielded-note delivery as deployed hybrid encryption”).

Proposition 10.3 (Decryption correctness).

Let $(d,\mathsf{pk_{d}})$ be an address of the incoming viewing key $\mathsf{ivk}$ , so $\mathsf{pk_{d}}=[\mathsf{ivk}]\,\mathsf{g_{d}}$ (§3.3), and let $\mathsf{epk}=[\mathsf{esk}]\,\mathsf{g_{d}}$ with $\mathsf{esk}\in\mathbb{F}_{p_{\mathsf{Vesta}}}^{*}$ . Then

[\mathsf{ivk}]\,\mathsf{epk}=[\mathsf{esk}]\,\mathsf{pk_{d}}=s.

Hence the holder of $\mathsf{ivk}$ computes $K_{\mathsf{enc}}=\mathsf{KDF}([\mathsf{ivk}]\,\mathsf{epk},\mathsf{epk})$ from the published $\mathsf{epk}^{\star}$ and obtains $\mathsf{Dec}_{K_{\mathsf{enc}}}(C_{\mathsf{enc}})=\mathsf{np}$ , and a party that knows $(\mathsf{pk_{d}},\mathsf{esk})$ obtains the same shared secret as $[\mathsf{esk}]\,\mathsf{pk_{d}}$ .

Proof.

In the cyclic Pallas group $[a]([b]\,P)=[ab]\,P=[b]([a]\,P)$ , so $[\mathsf{ivk}]([\mathsf{esk}]\,\mathsf{g_{d}})=[\mathsf{esk}]([\mathsf{ivk}]\,% \mathsf{g_{d}})=[\mathsf{esk}]\,\mathsf{pk_{d}}$ . The recipient decodes $\mathsf{epk}=\mathsf{abst}_{\mathbb{P}}(\mathsf{epk}^{\star})$ , and because the star encoding is canonical (§2.1) it re-encodes to the published bytes. The function $\mathsf{KDF}$ is deterministic and both parties apply it to $(s^{\star},\mathsf{epk}^{\star})$ , so they derive the same $K_{\mathsf{enc}}$ ; correctness of ChaCha20-Poly1305 gives $\mathsf{Dec}_{K_{\mathsf{enc}}}(\mathsf{Enc}_{K_{\mathsf{enc}}}(\mathsf{np}))=% \mathsf{np}$ . This is the Crypto Guide’s Theorem “Correctness of hybrid encryption” (§“Hybrid public-key encryption”) over the base $\mathsf{g_{d}}$ . □

Assumption 10.4 (The note-encryption hashes as random oracles).

In security arguments the key-derivation function $\mathsf{KDF}$ (BLAKE2b-256 personalised Zcash_OrchardKDF), the function $\mathsf{PRF}^{\mathsf{ock}}$ (BLAKE2b-256 personalised Zcash_Orchardock, constructed in §10.3), and $\mathsf{PRFexpand}$ on inputs with leading byte $\mathtt{0x04}$ , the derivation of $\mathsf{esk}$ from $\mathsf{rseed}$ , are modelled as independent random oracles (Crypto Guide, §“The random oracle model”, Definition “Random oracle”). The PRF assumption (Assumption 2.12) does not suffice for the last: it requires a key unknown to the adversary, whereas the plaintext that $K_{\mathsf{enc}}$ encrypts contains $\mathsf{rseed}$ , the key from which $\mathsf{esk}$ , and hence $K_{\mathsf{enc}}$ , is derived. On its other inputs $\mathsf{PRFexpand}$ is used only under Assumption 2.12. The assumption is a heuristic about BLAKE2b, not a theorem; every result that uses $\mathsf{KDF}$ , $\mathsf{PRF}^{\mathsf{ock}}$ or the derivation of $\mathsf{esk}$ names it.

Assumption 10.5 (Confidentiality and integrity of ChaCha20-Poly1305).

For a uniform $256$ -bit key that encrypts a single plaintext, ChaCha20-Poly1305 with the all-zero nonce and empty associated data is

(a)

confidential: the encryptions of any two plaintexts of equal length are computationally indistinguishable; and
(b)

integral: no efficient adversary without the key outputs a ciphertext, other than one it was given, that decrypts to a value other than $\bot$ .

The Crypto Guide’s Theorem “Security of ChaCha20-Poly1305” (§“The ChaCha20-Poly1305 AEAD”) derives both, with explicit bounds, from the pseudorandomness of ChaCha20. The protocol specification requires one-time INT-CTXT and IND-CPA security of the scheme, properties (b) and (a) above (Crypto Guide, Definitions “Ciphertext integrity, INT-CTXT” and “CPA security”, §“Authenticated encryption with associated data” and §“Chosen-plaintext security”; protocol specification, §“Symmetric Encryption”). The scheme is not key-committing: a party that chooses two keys can construct one ciphertext that decrypts validly under both (Crypto Guide, §“The ChaCha20-Poly1305 AEAD”, Remark “Wrong-key rejection and key commitment”). No result of this volume relies on the tag against a sender who chooses the key.

Proposition 10.6 (Confidentiality and key privacy of note encryption).

Let a key be generated honestly with $\mathsf{use\_qsk}=\mathsf{false}$ . An efficient adversary receives the address $(d,\mathsf{pk_{d}})$ of the key at an index of its choice and data $z$ that an efficient algorithm computes independently of the key and of $\mathsf{rseed}$ ; it chooses a value $v$ , a memo and $\rho\in\mathbb{F}_{p_{\mathsf{Pallas}}}$ . An output to $(d,\mathsf{pk_{d}})$ with these values and $\rho=\mathsf{nf}^{\mathsf{old}}$ is formed as in §10.1 and the construction above, with $\mathsf{rseed}$ uniform, and $\mathsf{cmx}$ is the extracted commitment of its note. Then the triple $(\mathsf{epk}^{\star},C_{\mathsf{enc}},\mathsf{cmx})$ is computationally indistinguishable from $(E^{\star},C^{\prime},\mathsf{cmx})$ , where $E$ is a uniform non-identity Pallas point and $C^{\prime}$ is the encryption of a fixed $564$ -byte string under an independent uniform key. The hypotheses are Assumptions 3.16, 10.4, 10.5, 2.8 (for $\mathsf{g_{d}}$ ), 3.13 (for the joint distribution of $\mathsf{ivk}$ and $d$ ) and 2.12 (for the dependence of $\mathsf{cmx}$ on $\mathsf{rseed}$ ), together with Assumption 2.22 for Lemma “Rejection in key generation” (§3.2).

Since $E$ and $C^{\prime}$ are computed from neither the plaintext nor the address, the pair $(\mathsf{epk}^{\star},C_{\mathsf{enc}})$ reveals neither the plaintext, $\mathsf{rseed}$ included, nor the recipient’s address: given two addresses of independent keys, the data $z$ may contain the second, and the ciphertext is indistinguishable from one independent of both. The value $\mathsf{cmx}$ is included so that the result applies within an Action. Of the hypotheses only Assumption 3.16, used through the computational Diffie–Hellman problem that it implies, concerns the one-shot key agreement between $\mathsf{esk}$ and $\mathsf{pk_{d}}$ ; Assumptions 10.4 and 10.5 concern the hash functions and the cipher. The adversary is passive: the volume does not claim indistinguishability of encryptions against an adversary that may also obtain decryptions of ciphertexts of its choice other than the challenge, before and after receiving it (IND-CCA2), which the protocol specification, §“Key Derivation”, requires of the scheme.

Proof.

The proof is a sequence of games (Crypto Guide, §“Security as a game”, Remark “Game-hopping”); each reduction below runs the adversary and the rest of the game. Let $Q$ be the event that the adversary queries the oracle of Assumption 10.4 for $\mathsf{PRFexpand}$ at an input keyed by $\mathsf{rseed}$ .

Preliminary step. As in the proof of Proposition 3.18, the key is replaced by a single draw without rejection and its triple $(\mathsf{ask},\mathsf{nk},\mathsf{r_{ivk}})$ by independent uniform elements (Lemma 2.15, Assumption 2.12; Lemma “Rejection in key generation”, §3.2, Assumptions 2.22 and 2.8). Then $(\mathsf{ivk},\mathsf{dk})$ is replaced by $(\mathsf{Commit}^{\mathsf{ivk}}_{\mathsf{r_{ivk}}^{\prime}}(\mathsf{ak},% \mathsf{nk}),u_{1})$ (Assumption 3.13; the reduction draws $\mathsf{ask}$ and $\mathsf{nk}$ itself). Now $d=\mathsf{FF1\text{-}AES256}_{u_{1}}(\mathrm{LE}_{88}(j))$ , and $\mathsf{ivk}$ is, independently of $d$ , $0$ with probability $1/p_{\mathsf{Vesta}}$ and otherwise uniform on the set $X_{\mathsf{Pallas}}$ of $x$ -coordinates of non-identity points, of $(p_{\mathsf{Vesta}}-1)/2$ elements, except on the negligible event $\hat{M}=\bot$ (Lemma “Distribution of $\mathsf{ivk}$ ”, §3.2). The redraw of $\mathsf{rseed}$ is replaced by a single trial, at the cost of the redraw probability, negligible as in the proof of Proposition 4.8.

(1) By Assumption 10.4, $\mathsf{esk}$ is $\mathrm{ToScalar}$ of a random-oracle output at an input keyed by $\mathsf{rseed}$ . It is replaced by an independent uniform element of $\mathbb{F}_{p_{\mathsf{Vesta}}}^{*}$ . The oracle’s value at that input is used nowhere else, so the games are identical until $Q$ occurs; they differ by at most $\mathrm{Pr}[Q]$ in the new game plus the reduction distance of $\mathrm{ToScalar}$ , below $2^{-257}$ , and $1/p_{\mathsf{Vesta}}$ for the value $0$ (Crypto Guide, §“Security as a game”, Remark “Game-hopping”; §2.3).

(2) The key $K_{\mathsf{enc}}$ is replaced by an independent uniform key. The games differ only on the event $C$ that the adversary queries the $\mathsf{KDF}$ oracle at $s^{\star}\,\|\,\mathsf{epk}^{\star}$ , and $s=[\mathsf{esk}]\,\mathsf{pk_{d}}$ solves the computational Diffie–Hellman instance $(\mathsf{g_{d}},\mathsf{pk_{d}},\mathsf{epk})$ . This is the game hop of the Crypto Guide’s Theorem “Passive security of hybrid encryption” (§“Hybrid public-key encryption”), with loss factor the number $q_{K}$ of $\mathsf{KDF}$ queries, run over $\mathsf{g_{d}}$ . A distinguisher $\mathcal{D}$ for Assumption 3.16 receives $([a]\,P,[b]\,P,[c]\,P)$ with $a$ uniform on $X_{\mathsf{Pallas}}$ and $b, c$ uniform. It answers each new query of $\mathsf{GroupHash}$ under the domain z.cash:Orchard-gd with $[t]\,P$ for a fresh uniform $t$ , recorded, a uniform point as in the model of Assumption 2.8, so that $\mathsf{g_{d}}=[t]\,P$ with $t$ known. It sets $\mathsf{pk_{d}}:=[t]([a]\,P)=[a]\,\mathsf{g_{d}}$ , which embeds $a$ as $\mathsf{ivk}$ , and $\mathsf{epk}:=[t]([b]\,P)=[b]\,\mathsf{g_{d}}$ , which embeds $b$ as $\mathsf{esk}$ ; it draws $u_{1}$ and $\mathsf{rseed}$ , computes $d$ , $\mathsf{cmx}$ and $C_{\mathsf{enc}}$ under a uniform key itself, and answers the other oracles lazily. It then decodes the first $32$ bytes of a uniformly chosen $\mathsf{KDF}$ query to a point $S$ and outputs $1$ exactly when $S=[t]([c]\,P)$ . The simulation differs from the game only when $\mathsf{ivk}=0$ in the game, or $b=0$ or $t=0$ in the simulation, of total probability at most $3/p_{\mathsf{Vesta}}$ . On a Diffie–Hellman triple $\mathcal{D}$ therefore outputs $1$ with probability at least $\mathrm{Pr}[C]/q_{K}-3/p_{\mathsf{Vesta}}$ ; on a random triple the point $[t]([c]\,P)$ is, for $t\neq 0$ , uniform and independent of the view, and $\mathcal{D}$ outputs $1$ with probability at most $4/p_{\mathsf{Vesta}}$ . An algorithm that computes Diffie–Hellman secrets on Pallas thus decides DDH, and $\mathrm{Pr}[C]\leq q_{K}\,(\epsilon_{\mathcal{D}}+7/p_{\mathsf{Vesta}})$ for the advantage $\epsilon_{\mathcal{D}}$ of $\mathcal{D}$ . The exponent embedded as $\mathsf{ivk}$ is uniform on $X_{\mathsf{Pallas}}$ in Assumption 3.16. Against the computational Diffie–Hellman problem with a uniform exponent on $\mathbb{F}_{p_{\mathsf{Vesta}}}$ , which lies in $X_{\mathsf{Pallas}}$ with probability $(p_{\mathsf{Vesta}}-1)/(2p_{\mathsf{Vesta}})$ and on those instances gives an exact simulation, the same reduction loses a factor $2p_{\mathsf{Vesta}}/(p_{\mathsf{Vesta}}-1)$ , about $2$ (proof of Proposition 3.18, part (d)).

(3) Now $\mathsf{epk}=[\mathsf{esk}]\,\mathsf{g_{d}}$ with $\mathsf{esk}$ uniform on $\mathbb{F}_{p_{\mathsf{Vesta}}}^{*}$ is a uniform non-identity point for every generator $\mathsf{g_{d}}$ , and the $\mathsf{KDF}$ context contains no key of the recipient (Crypto Guide, §“Key privacy”, Remark “What key privacy buys upstairs”). The ciphertext $C_{\mathsf{enc}}$ is an encryption under a uniform key used once, and Assumption 10.5(a) replaces $\mathsf{np}$ by the fixed string; the reduction obtains $C_{\mathsf{enc}}$ from its challenger and computes the rest. The last game outputs $(E^{\star},C^{\prime},\mathsf{cmx})$ .

(4) In the last game $\mathsf{rseed}$ enters the view only through $\mathsf{cmx}$ , that is through $\mathsf{PRFexpand}_{\mathsf{rseed}}$ under the leading bytes $\mathtt{0x09}$ and $\mathtt{0x0B}$ . A distinguisher with oracle access to $\mathsf{PRFexpand}_{\mathsf{rseed}}$ or to a random function computes $\mathsf{cmx}$ from its oracle, runs the adversary, and outputs $1$ when some key $k$ of a query at a leading byte $\mathtt{0x04}$ satisfies $\mathsf{PRFexpand}_{k}([\mathtt{0x09}]\,\|\,\mathsf{I2LEOSP}_{256}(\rho))$ equal to its oracle’s answer at that input. It outputs $1$ with probability at least $\mathrm{Pr}[Q]$ in the first case. In the second the view depends on that answer only through $\mathsf{cmx}$ , and the trapdoor $\mathsf{rcm}$ , $\mathrm{ToScalar}$ of the independent answer at the $\mathtt{0x0B}$ input, is within $2^{-257}$ of uniform; by Proposition 4.5(a), $\mathsf{cmx}$ is therefore independent of that answer up to $2^{-257}+\epsilon_{\bot}$ , for $\epsilon_{\bot}$ the probability that the hash point of $M(n)$ is $\bot$ , negligible as in the proof of Proposition 4.8. The distinguisher thus outputs $1$ with probability at most $q\cdot 2^{-512}+2^{-257}+\epsilon_{\bot}$ , for $q$ such queries, and $\mathrm{Pr}[Q]$ in the last game is negligible under Assumption 2.12 (with Lemma 2.15). Every reduction of hops (2) and (3) draws $\mathsf{rseed}$ itself and detects $Q$ , so each hop changes the probability of $Q$ by at most its own cost. Hence $\mathrm{Pr}[Q]$ is negligible in the game of hop (1) as well, and the sum of the costs of all hops is negligible.

The DDH hybrid of the Crypto Guide’s Theorem “ElGamal is key-private under DDH” (§“Key privacy”) is not used: as stated it embeds a uniform exponent of $\mathbb{F}_{p_{\mathsf{Vesta}}}$ as the recipient’s key, whereas $\mathsf{ivk}$ is not uniform on $\mathbb{F}_{p_{\mathsf{Vesta}}}$ ; and the factor- $2$ argument above transfers a search problem such as computational Diffie–Hellman, not a decision problem, since on instances outside $X_{\mathsf{Pallas}}$ a distinguisher’s output is unconstrained. □

10.3 The outgoing ciphertext

Construction 10.7 (Outgoing ciphertext).

The sender chooses an outgoing viewing key $\mathsf{ovk}$ of its own, such as that of the address whose note the Action consumes (“Viewing keys”, §3.2), or $\mathsf{ovk}=\bot$ . If $\mathsf{ovk}\neq\bot$ , the outgoing cipher key is

	$\displaystyle\mathsf{ock}$	$\displaystyle:=\mathsf{PRF}^{\mathsf{ock}}_{\mathsf{ovk}}(\mathsf{cv}^{\mathsf% {net}},\mathsf{cmx},\mathsf{epk})$
		$\displaystyle:=\mathrm{BLAKE2b\text{-}256}\bigl{(}\texttt{Zcash\_Orchardock},% \ \mathsf{ovk}\,\\|\,(\mathsf{cv}^{\mathsf{net}})^{\star}\,\\|\,\mathsf{I2LEOSP}% _{256}(\mathsf{cmx})\,\\|\,\mathsf{epk}^{\star}\bigr{)},$

where $\mathsf{cv}^{\mathsf{net}}$ is the Action’s net value commitment (Definition 8.2) and $\mathsf{cmx}$ its extracted note commitment (Definition 4.4), and the outgoing plaintext is the $32+32=64$ -byte string $\mathsf{op}:=\mathsf{pk_{d}}^{\star}\,\|\,\mathsf{I2LEOSP}_{256}(\mathsf{esk})$ . If $\mathsf{ovk}=\bot$ , the sender draws $\mathsf{ock}$ uniformly from the $256$ -bit strings and $\mathsf{op}$ uniformly from the $64$ -byte strings. In both cases $C_{\mathsf{out}}:=\mathsf{Enc}_{\mathsf{ock}}(\mathsf{op})$ , of $64+16=80$ bytes, and the Action publishes it; with $\mathsf{ovk}=\bot$ no outgoing viewing key recovers it (protocol specification, §“Encryption (Sapling and Orchard)”, §“Sending Notes (Orchard)” and §“Pseudo Random Functions”).

Construction 10.8 (Recovery with $\mathsf{ovk}$ ).

For an Ironwood-pool output, the holder of $\mathsf{ovk}$

(i)

computes $\mathsf{ock}$ from $\mathsf{ovk}$ and the Action’s public $\mathsf{cv}^{\mathsf{net}}$ , $\mathsf{cmx}$ and $\mathsf{epk}^{\star}$ , and decrypts $C_{\mathsf{out}}$ under $\mathsf{ock}$ to the outgoing plaintext $\mathsf{op}$ , rejecting $\bot$ ;
(ii)

parses $\mathsf{op}$ as a $32$ -byte string $b_{1}$ followed by a $32$ -byte string $b_{2}$ , and reads $\mathsf{esk}$ as the integer $\mathsf{LEOS2IP}_{256}(b_{2})$ , rejecting $\mathsf{esk}\geq p_{\mathsf{Vesta}}$ , and $\mathsf{pk_{d}}$ as the point $\mathsf{abst}_{\mathbb{P}}(b_{1})$ , rejecting $\bot$ and $\mathcal{O}$ ;
(iii)

computes $s:=[\mathsf{esk}]\,\mathsf{pk_{d}}$ , $K_{\mathsf{enc}}:=\mathsf{KDF}(s,\mathsf{epk})$ and $\mathsf{np}:=\mathsf{Dec}_{K_{\mathsf{enc}}}(C_{\mathsf{enc}})$ , rejecting $\bot$ ;
(iv)

rejects unless $\mathsf{leadByte}=\mathtt{0x03}$ ;
(v)

with $\rho:=\mathsf{nf}^{\mathsf{old}}$ of the same Action, rejects unless

$\mathsf{esk}=\mathrm{ToScalar}\bigl{(}\mathsf{PRFexpand}_{\mathsf{rseed}}([% \mathtt{0x04}]\,\|\,\mathsf{I2LEOSP}_{256}(\rho))\bigr{)};$
(vi)

computes $\mathsf{g_{d}}:=\mathsf{DiversifyHash}(d)$ , then $\psi$ , then $\mathsf{rcm}$ under $\mathtt{0x03}$ from $\mathsf{g_{d}}$ , $\mathsf{pk_{d}}$ , $v$ , $\rho$ and $\psi$ , by steps (iv) and (v) of the derivation of §4.3;
(vii)

rejects if the note commitment of $((d,\mathsf{pk_{d}}),v,\rho,\psi,\mathsf{rcm})$ (Definition 4.4) is $\bot$ or its $x$ -coordinate differs from $\mathsf{cmx}$ , or if $([\mathsf{esk}]\,\mathsf{g_{d}})^{\star}\neq\mathsf{epk}^{\star}$ ;
(viii)

otherwise returns the note $((d,\mathsf{pk_{d}}),v,\rho,\psi,\mathsf{rcm})$ and $\mathsf{memo}$ .

The order $\mathsf{g_{d}}$ and $\mathsf{pk_{d}}$ , then $\psi$ , then $\mathsf{rcm}$ is forced because $\mathsf{rcm}$ depends on all three. The specification’s decryption sections still use the legacy derivation of $\mathsf{rcm}$ ; ZIP 2005 specifies the reordered procedure (protocol specification, §“Decryption using an Outgoing Viewing Key (Sapling and Orchard)”; ZIP 2005, “Changes to the Protocol Specification”, §4.20.2 and §4.20.3). The specification’s further check that $b_{1}$ re-encodes $\mathsf{pk_{d}}$ holds for every string that $\mathsf{abst}_{\mathbb{P}}$ decodes, the star encoding being canonical (§2.1). For $\mathsf{pk_{d}}$ the specification’s procedure rejects only $\bot$ ; the rejection of $\mathcal{O}$ in step (ii) makes the returned $\mathsf{pk_{d}}$ a transmission key of Definition “Note” (§4.1).

Remark 10.9 (Transplant resistance).

The key $\mathsf{ock}$ is a function of the Action’s own $\mathsf{cv}^{\mathsf{net}}$ , $\mathsf{cmx}$ and $\mathsf{epk}$ . A ciphertext $C_{\mathsf{out}}$ that a party without $\mathsf{ovk}$ copies into an Action whose $(\mathsf{cv}^{\mathsf{net}},\mathsf{cmx},\mathsf{epk})$ differ is decrypted by the holder of $\mathsf{ovk}$ under a key that, by Assumption 10.4, is uniform and independent of the copied ciphertext; by Assumption 10.5(b) that decryption returns $\bot$ except with negligible probability. A copied $C_{\mathsf{out}}$ is therefore rejected, not attributed to the other Action.

Proposition 10.10 (Confidentiality of the outgoing ciphertext).

Let the sending key be generated honestly with $\mathsf{use\_qsk}=\mathsf{false}$ . To an efficient party that holds neither its $\mathsf{ovk}$ nor its $\mathsf{r_{ivk}}$ , and may hold its $\mathsf{ak}$ , $\mathsf{nk}$ , $\mathsf{ivk}$ and $\mathsf{dk}$ , each ciphertext $C_{\mathsf{out}}$ that the holder of the key forms is computationally indistinguishable, jointly with every other public field of its Action, from the encryption of a fixed $64$ -byte string under an independent uniform key. The hypotheses are Assumptions 2.12, 3.13, 10.4, 10.5, 9.14, 2.22 and 2.8.

Proof.

As in the preliminary step of the proof of Proposition 10.6, the key is replaced by a single draw without rejection and its triple $(\mathsf{ask},\mathsf{nk},\mathsf{r_{ivk}})$ by independent uniform elements (Lemma 2.15, Assumption 2.12; Lemma “Rejection in key generation”, §3.2, Assumptions 2.22 and 2.8). After this step, Assumption 3.13 makes $\mathsf{ovk}$ indistinguishable from a uniform $32$ -byte string independent of $\mathsf{ivk}$ and $\mathsf{dk}$ ; the reduction draws $\mathsf{ask}$ and $\mathsf{nk}$ itself, obtains $(\mathsf{ivk},\mathsf{dk},\mathsf{ovk})$ from its challenger, computes every other field, and simulates the Action proof, whose witness contains $\mathsf{r_{ivk}}$ , under Assumption 9.14. Then $\mathsf{ock}$ is a random-oracle output (Assumption 10.4) at an input that the party queries with negligible probability, hence uniform, and distinct Actions give distinct inputs, their $\mathsf{epk}$ differing except with negligible probability, so each $\mathsf{ock}$ encrypts once; Assumption 10.5(a) then applies. With $\mathsf{ovk}=\bot$ , $\mathsf{ock}$ is uniform by construction. The ciphertext $C_{\mathsf{out}}$ thus reveals nothing about $(\mathsf{pk_{d}},\mathsf{esk})$ . □

A holder of $\mathsf{ovk}$ recovers, for every output sent under that $\mathsf{ovk}$ , the pair $(\mathsf{pk_{d}},\mathsf{esk})$ , hence the shared secret $[\mathsf{esk}]\,\mathsf{pk_{d}}$ (Proposition 10.3), $K_{\mathsf{enc}}$ , the note plaintext and the recipient’s address $(d,\mathsf{pk_{d}})$ ; in this way the sender, or a party to whom the sender discloses $\mathsf{ovk}$ , reads outgoing notes (protocol specification, §“Decryption using an Outgoing Viewing Key (Sapling and Orchard)”). By this route it reads only outputs sent under that $\mathsf{ovk}$ . Detecting the notes sent to the key’s own addresses by trial decryption requires $\mathsf{ivk}$ (§10.4), and $\mathsf{ovk}$ yields no $\mathsf{ivk}$ (Proposition 3.18, “Capability separation”, part (c), for keys generated with $\mathsf{use\_qsk}=\mathsf{false}$ ).

10.4 Trial decryption and note acceptance

Construction 10.11 (Trial decryption).

No public field of an Action names its recipient, so the holder of an incoming viewing key attempts every output: it computes $\mathsf{epk}:=\mathsf{abst}_{\mathbb{P}}(\mathsf{epk}^{\star})$ , rejecting $\bot$ , which consensus excludes, then $s:=[\mathsf{ivk}]\,\mathsf{epk}$ , $K_{\mathsf{enc}}:=\mathsf{KDF}(s,\mathsf{epk})$ and $\mathsf{np}:=\mathsf{Dec}_{K_{\mathsf{enc}}}(C_{\mathsf{enc}})$ (protocol specification, §“Decryption using an Incoming Viewing Key (Sapling and Orchard)”). A result other than $\bot$ is a candidate, not an accepted note.

The same $\mathsf{ivk}$ serves the outputs of both pools, since keys and addresses are defined for the Orchard protocol, not for a pool (§3.4), and an address does not name a pool (ZIP 326, “Scanning for Ironwood-pool and Orchard-pool notes”); the pool of an output is that of the bundle that carries it. For an honestly produced ciphertext under a key independent of the trial key, decryption returns $\bot$ except with negligible probability (Assumption 10.5(b); Crypto Guide, §“The ChaCha20-Poly1305 AEAD”, Remark “Wrong-key rejection and key commitment”); against a sender who chooses the keys the tag gives no such guarantee.

Construction 10.12 (Acceptance of an Ironwood-pool output).

Given a candidate $\mathsf{np}=(\mathsf{leadByte},d,v,\mathsf{rseed},\mathsf{memo})$ of an Ironwood-pool output, the recipient accepts only if every check passes:

(i)

$\mathsf{leadByte}=\mathtt{0x03}$ , the recipient’s enforcement of the lead-byte rule of “The note seed” (§4.3);

(ii)

with $\rho:=\mathsf{nf}^{\mathsf{old}}$ of the same Action and $\underline{\rho}:=\mathsf{I2LEOSP}_{256}(\rho)$ , the note is re-derived in the order

	$\displaystyle\mathsf{g_{d}}$	$\displaystyle:=\mathsf{DiversifyHash}(d),\qquad\mathsf{pk_{d}}:=[\mathsf{ivk}]% \,\mathsf{g_{d}},$
	$\displaystyle\psi$	$\displaystyle:=\mathrm{ToBase}\bigl{(}\mathsf{PRFexpand}_{\mathsf{rseed}}([% \mathtt{0x09}]\,\\|\,\underline{\rho})\bigr{)},$
	$\displaystyle\mathsf{rcm}$	$\displaystyle:=\mathrm{ToScalar}\bigl{(}\mathsf{PRFexpand}_{\mathsf{rseed}}(% \mathsf{pre\_rcm})\bigr{)},$

with the $137$ -byte string $\mathsf{pre\_rcm}$ of §4.3 formed from $\mathsf{g_{d}}$ , $\mathsf{pk_{d}}$ , $v$ , $\rho$ and $\psi$ ;

(iii)

$([\mathsf{esk}]\,\mathsf{g_{d}})^{\star}=\mathsf{epk}^{\star}$ for

$\mathsf{esk}:=\mathrm{ToScalar}\bigl{(}\mathsf{PRFexpand}_{\mathsf{rseed}}([% \mathtt{0x04}]\,\|\,\underline{\rho})\bigr{)},$

a check that ZIP 2005 places directly after the computation of $\mathsf{g_{d}}$ ;
(iv)

the note commitment $\mathsf{cm}^{\prime}$ of the re-derived note (Definition 4.4) is not $\bot$ and $\mathsf{Extract}_{\mathbb{P}}(\mathsf{cm}^{\prime})=\mathsf{cmx}$ .

The accepted note is $n=((d,\mathsf{pk_{d}}),v,\rho,\psi,\mathsf{rcm})$ , with $\mathsf{memo}$ (ZIP 2005, “Changes to the Protocol Specification”, §4.20.2 and §4.20.3; protocol specification, §“Decryption using an Incoming Viewing Key (Sapling and Orchard)” and §“Note Plaintexts and Memo Fields”).

The order in (ii) is forced because $\mathsf{rcm}$ depends on $\mathsf{g_{d}}$ , $\mathsf{pk_{d}}$ and $\psi$ ; the recovery with $\mathsf{ovk}$ of §10.3 follows the same order. The specification’s decryption sections still use the legacy derivation of $\mathsf{rcm}$ ; ZIP 2005 specifies both reordered procedures. The specification’s check $\mathsf{rcm}<p_{\mathsf{Vesta}}$ holds for every output of $\mathrm{ToScalar}$ .

Remark 10.13 (Role of check (iii)).

The Action statement (Definition 9.2) does not constrain $\mathsf{epk}$ . Check (iii) makes the recipient accept only an $\mathsf{epk}$ formed on the base $\mathsf{g_{d}}$ of the diversifier in the plaintext. Without it a sender could agree the key with one address of a recipient while naming the diversifier of another, and link the two addresses by observing whether the recipient accepts (ZIP 212, “Motivation”).

Remark 10.14 (Where the Ironwood derivation is checked).

The Action statement takes $\psi$ and $\mathsf{rcm}$ as witnesses and does not check their derivation from $\mathsf{rseed}$ (Definition 9.2). An accepted Ironwood-pool note has, by checks (i), (ii) and (iv), $\psi$ and $\mathsf{rcm}$ derived under $\mathtt{0x03}$ and the commitment $\mathsf{cmx}$ . For a coinbase output, consensus runs the recovery with $\mathsf{ovk}$ of §10.3 under the all-zero $\mathsf{ovk}$ (“Chain state and pool rules”, §11.4), which checks the lead byte and the whole $\mathtt{0x03}$ derivation. For every other output, these recipient checks are the only check of the $\mathtt{0x03}$ note format.

Orchard-pool outputs carry lead byte $\mathtt{0x02}$ and use the legacy trapdoor derivation of the protocol specification, §“Sending Notes (Orchard)”; the recipient decrypts them with the same $\mathsf{ivk}$ under that byte and derivation (§“Note Plaintexts and Memo Fields”), on which this volume does not rely.

Proposition 10.15 (Consistency of accepted notes).

Let the acceptance procedure accept an Ironwood-pool output with note $n=((d,\mathsf{pk_{d}}),v,\rho,\psi,\mathsf{rcm})$ .

(a)

The note $n$ is addressed to $(d,[\mathsf{ivk}]\,\mathsf{g_{d}})$ , an address of the recipient’s key; it has $\rho=\mathsf{nf}^{\mathsf{old}}$ of the same Action; and its $\psi$ and $\mathsf{rcm}$ are derived from its $\mathsf{rseed}$ under $\mathtt{0x03}$ .
(b)

The extracted commitment of $n$ satisfies $\mathsf{Extract}_{\mathbb{P}}(\mathsf{NoteCommit}_{\mathsf{rcm}}(M(n)))=% \mathsf{cmx}$ .
(c)

For every efficient sender, which may choose $\mathsf{epk}^{\star}$ , $C_{\mathsf{enc}}$ , $C_{\mathsf{out}}$ and the keys under which they are formed, the probability that the recipient accepts $n$ while the sender outputs a note $n^{\prime}\neq n$ with $\mathsf{cmx}(n^{\prime})=\mathsf{cmx}$ is negligible, under the binding of note commitments (Proposition 4.5), hence under Assumptions 2.22 and 2.8. In particular, under Assumption 9.11, the committed values and the trapdoor of the created note that an extractor recovers from the Action proof, which satisfy condition A2 of the Action statement (Definition 9.2), are $(\mathsf{g_{d}},\mathsf{pk_{d}},v,\rho,\psi)$ and $\mathsf{rcm}$ modulo $p_{\mathsf{Vesta}}$ , those of $n$ , except with negligible probability.

Proof.

Parts (a) and (b) hold by construction: acceptance requires checks (i), (ii) and (iv), and check (iv) recomputes the commitment of $n$ deterministically and compares its $x$ -coordinate with $\mathsf{cmx}$ , whatever the ciphertext and whichever key decrypted it. The address $(d,[\mathsf{ivk}]\,\mathsf{g_{d}})$ is an address of the key because $\mathsf{FF1\text{-}AES256}_{\mathsf{dk}}$ is a permutation of the $88$ -bit strings, so every $d$ is the diversifier of one index (§3.3).

(c) Consider the algorithm that generates the recipient’s key, runs the sender, runs the acceptance procedure on its output, and outputs $n$ and the sender’s $n^{\prime}$ . When the recipient accepts, $n$ opens $\mathsf{cmx}\neq\bot$ by (b), so an $n^{\prime}\neq n$ with $\mathsf{cmx}(n^{\prime})=\mathsf{cmx}$ gives two distinct notes with equal extracted commitments other than $\bot$ , which Proposition 4.5(b) excludes except with negligible probability. For the particular case, the extractor of Assumption 9.11 run on the sender is such a sender-side algorithm, with an opening of the committed values and a trapdoor in place of a note. Outside the negligible $\bot$ -weakened case of condition A2, which yields an input on which $\mathsf{NoteCommit}$ returns $\bot$ (Proposition 2.24(iii)), its opening $(M^{\prime},\mathsf{rcm}^{\prime})$ satisfies $\mathsf{Extract}_{\mathbb{P}}(\mathsf{NoteCommit}_{\mathsf{rcm}^{\prime}}(M^{% \prime}))=\mathsf{cmx}$ . Step 2 of the proof of Proposition 4.5(b), which uses Proposition 2.24(ii) and the fact that $H_{D}\neq\mathcal{O}$ , then gives $M^{\prime}=M(n)$ and $\mathsf{rcm}^{\prime}\equiv\mathsf{rcm}\pmod{p_{\mathsf{Vesta}}}$ except with negligible probability, and $M(n)$ determines $(\mathsf{g_{d}},\mathsf{pk_{d}},v,\rho,\psi)$ because the encoding is injective. The proof uses neither the integrity of ChaCha20-Poly1305 nor key commitment, which the scheme lacks (Assumption 10.5): a ciphertext valid under two keys yields under each a candidate that must still pass check (iv). □

On acceptance the recipient records $n$ with its note position, the index of $\mathsf{cmx}$ among the leaves of the note commitment tree of the output’s pool, fixed by the order in which the chain appends extracted commitments (“The Merkle hash and the tree”, §5.1; protocol specification, §“Note Commitment Trees”). The position determines the authentication path, which the recipient computes from public data (Lemma 5.15) and which, with the opening $n$ of the leaf $\mathsf{cmx}$ (Proposition 10.15), a later Action consuming $n$ requires (conditions A1 and A3 of Definition 9.2).

The key tiers of Proposition 3.18 (“Capability separation”) have the following powers over note ciphertexts, for keys generated with $\mathsf{use\_qsk}=\mathsf{false}$ .

Incoming tier. A holder of the incoming viewing key $(\mathsf{dk},\mathsf{ivk})$ , of which trial decryption and acceptance use only $\mathsf{ivk}$ , detects and reads every note sent to any address of the key, value and memo included. It cannot compute the nullifiers of these notes, which require $\mathsf{nk}$ , and $(\mathsf{dk},\mathsf{ivk})$ yields neither $\mathsf{nk}$ nor $\mathsf{ask}$ (Proposition 3.18(b)). It cannot link a published nullifier to one of them, for notes with pairwise distinct $\rho$ (Proposition 6.10), so the nullifier sets alone do not show it which are consumed; and it cannot authorise a spend.

Full-viewing tier. A holder of the full viewing key $(\mathsf{ak},\mathsf{nk},\mathsf{r_{ivk}})$ derives $(\mathsf{dk},\mathsf{ivk})$ and $\mathsf{ovk}$ (“Viewing keys”, §3.2). It detects and reads incoming notes as above, and reads the outputs sent under its $\mathsf{ovk}$ (§10.3), not those sent under $\mathsf{ovk}=\bot$ or another outgoing viewing key. With $\mathsf{nk}$ it computes the nullifier $\mathsf{nf}=\mathsf{DeriveNullifier}_{\mathsf{nk}}(\rho,\psi,\mathsf{cm})$ of each accepted note (Definition 6.3) and detects its consumption by the membership of $\mathsf{nf}$ in the nullifier set of the note’s pool (“Nullifier sets”, §6.2; protocol specification, §“Decryption using an Incoming Viewing Key (Sapling and Orchard)”, notes). It cannot spend, since it yields no $\mathsf{ask}$ (Proposition 3.18(a)). For each unspent note the owner thus holds the note, its position, its authentication path and its nullifier, the consumed-note inputs of an Action (Definition 9.2); spending authority is $\mathsf{ask}$ .