The adversary of this section owns the channel. Every ciphertext passes through her hands, and she attacks on two fronts at once. As an eavesdropper she tries to distinguish: to tell an encryption of one note plaintext from an encryption of another, or to recognise that two ciphertexts hide the same message. As a forger she tries to modify: a stream cipher’s ciphertext is XOR-malleable, so flipping a ciphertext bit flips the corresponding plaintext bit without any key material at all; she can also shift bytes between a packet’s public header and its encrypted body, replay a ciphertext under a different context, or manufacture a wholly new ciphertext that the receiver accepts. She is patient enough to exploit a single reused pad—two ciphertexts under one pad hand her the XOR of the plaintexts—and mathematically literate enough to exploit a key that is merely high-entropy rather than uniform. This section arms the honest parties against all of it, one guarantee at a time: confidentiality from the one-time pad through the nonce-based stream cipher ChaCha20 and the chosen-plaintext game; integrity from message authentication codes through universal hashing and Carter–Wegman; their composition as authenticated encryption with associated data, culminating in the ChaCha20-Poly1305 scheme that Zcash’s note-encryption layer deploys; and finally key derivation, the manufacture of the uniform key that every theorem in between takes as its hypothesis.
Throughout, an adversary is a probabilistic algorithm ; the notation denotes running on input and assigning its output to , and denotes sampling uniformly from the finite set . Every adversary in the computational definitions is probabilistic polynomial time (PPT) in the security parameter , and denotes a negligible function (Math Guide, §“Polynomial, exponential, and negligible functions”; recalled in §1.2).
The information-theoretic baseline is the one-time pad: to encrypt under a uniformly random key used exactly once, output . Since is uniform whatever is, the ciphertext distribution is independent of the message, and even an unbounded eavesdropper learns nothing—Shannon’s perfect secrecy. The price is severe on both counts the name advertises: the key must be as long as the message, and it must never be reused, for two ciphertexts under one pad reveal —the two-time-pad failure, which the adversary of the opening paragraph collects for free. The computational relaxation is EAV security (security against an eavesdropper): an adversary who chooses two equal-length messages and sees a single ciphertext for a hidden uniform bit guesses with advantage at most —the one-ciphertext, no-oracle restriction of the chosen-plaintext game formalised in §6.2. Replacing the truly random pad by the output of a pseudorandom generator stretched from a short seed—the pseudo-one-time pad—achieves EAV security with a fixed-length key, at the cost of resting on a pseudorandomness assumption.
A stream cipher is the practical instantiation of the pseudo-one-time pad: a keyed, seekable generator producing a keystream that XORs into the plaintext. To encrypt many messages under one key without violating the one-time-pad no-reuse rule, modern stream ciphers take an additional public input called a nonce (number used once) and behave like a pseudorandom function of the nonce, in the sense of Section 5.
A nonce-based stream cipher is a deterministic function
producing, for key , nonce , and length , a keystream . Encryption of is with ciphertext ; decryption recomputes the keystream and XORs it off. The security goal is that for distinct nonces the keystreams are jointly indistinguishable from independent uniform strings, provided no nonce repeats under a fixed key.
The stream cipher Zcash deploys—inside the AEAD of §6.5, in the note-encryption layer—is ChaCha20, designed by Bernstein and standardised in RFC 8439. Its core is a reversible mixing of four -bit words built only from modular addition, XOR, and rotation (an “ARX” design), which avoids data-dependent table lookups and hence the timing side channels that table-based ciphers must engineer around.
The ChaCha20 state is a matrix of -bit words, viewed as a vector ; the symbol denotes addition modulo , XOR, and left rotation by bits. The quarter-round updates four words by
The state is initialised from the -bit constant “expand 32-byte k” (words –), a -bit key (–), a -bit block counter (), and a -bit nonce (–). One double round applies to the four columns and then to the four diagonals; the rounds of ChaCha20 are ten double rounds. Writing for the initial state and for the state after the rounds, the -byte keystream block is the feed-forward sum (word-wise, modulo ), serialised in little-endian order.
The rounds form a bijection—each quarter-round is invertible, being a composition of invertible word operations—so without the final addition the block function would be an invertible permutation, and an adversary holding a keystream block could run the rounds backwards. The feed-forward sum destroys invertibility; it is the standard Davies–Meyer-style move for turning a permutation into a one-way mixing function. Incrementing the block counter produces successive -byte keystream blocks, so is the concatenation of the blocks for counters ; this counter mode is what makes the cipher seekable and parallelisable. The security status is a conjecture, in the same heuristic position as every concrete cipher of Section 5: ChaCha20 is conjectured to be a secure PRF of the pair (nonce, counter), and no attack better than brute force over the -bit key is known. Reusing a pair reproduces the same keystream and re-creates the two-time-pad failure; nonce uniqueness is a hard requirement, not a hygiene recommendation.
EAV security models an adversary who sees a single ciphertext. The adversary of this section is stronger: she can influence which messages get encrypted—by triggering payments, injecting plaintext into a session, or simply guessing—and she observes many ciphertexts. The corresponding notion is security against chosen-plaintext attack (CPA), modelled by granting her oracle access to the encryption algorithm, in the game template of Definition 1.15.
For a symmetric encryption scheme with key generator , adversary , and bit , the game runs as follows.
The challenger samples and gives oracle access to .
At some point submits a challenge pair of equal-length messages and receives .
The adversary may continue querying the oracle and finally outputs a bit , which is the output of the game.
The scheme is CPA-secure if for every PPT ,
The first consequence of giving the adversary an encryption oracle is a structural one: encryption cannot be a function of the message alone.
No scheme whose is deterministic and stateless is CPA-secure.
The adversary queries the oracle on two distinct messages , recording and . Decryption correctness forces : a single ciphertext cannot decrypt to both messages. She submits the challenge , receives , and outputs if and otherwise. Since is deterministic, , and since the comparison identifies : the guess is always correct and the advantage is . □
Consequently a CPA-secure scheme must be randomised or nonce-based. A nonce-based stream cipher used with a fresh nonce per encryption—random, or drawn from a counter—attains CPA security under the PRF conjecture for its keystream generator, because each encryption is then effectively a fresh one-time pad. We record the notion here and defer the routine PRF-based proof to the AEAD analysis (Theorem 6.20), where confidentiality and integrity are treated together.
Goldwasser and Micali’s original notion, semantic security, demands that whatever an efficient adversary can compute about the plaintext from the ciphertext, she could have computed without the ciphertext, from the message length alone. Semantic security is provably equivalent to the indistinguishability notions above; we use indistinguishability throughout because it is far easier to manipulate in reductions. The content is the same: the ciphertext is computationally useless for learning anything about the message beyond its length.
CPA security protects confidentiality and says nothing about integrity, and for the XOR-based stream ciphers above the gap is not hypothetical: flipping a bit of the ciphertext flips the corresponding plaintext bit, so the channel-owning adversary can convert a payment of one amount into a payment of another without ever touching the key. Detecting tampering requires a second primitive, keyed like the cipher but aimed at the forger rather than the eavesdropper: the message authentication code. Here we build this symmetric, shared-key form of authentication, the form that the AEAD needs.
A message authentication code (MAC) is a pair with key space : algorithm outputs a tag , and accepts () or rejects (). Correctness requires for all . When is deterministic, canonical verification recomputes the tag and checks equality.
For a MAC and adversary , the game runs as follows.
The challenger samples and gives oracle access to ; let be the set of messages queried.
The adversary outputs a pair ; the game outputs iff and .
The MAC is existentially unforgeable under chosen-message attack (EUF-CMA) if for every PPT ,
A strongly unforgeable (sUF-CMA) MAC additionally forbids producing a new valid tag on an already-queried message: the adversary wins on as long as the oracle never returned that exact pair. We write for the advantage in this variant.
The MAC Zcash uses, Poly1305, is not a pseudorandom-function MAC but a one-time, universal-hash MAC: it provides information-theoretic security per nonce and is extremely fast, at the cost of a key that authenticates only a single message. The enabling abstraction is a hash family whose differences are unpredictable.
Let be a finite abelian group. A family of functions is -almost--universal (-AU) if for all distinct and every ,
Taking recovers ordinary -universality—low collision probability—while the condition controls additive differences, which is what makes the one-time MAC below secure. With under XOR this is the classical almost-XOR-universality; Poly1305 takes under addition modulo .
The Carter–Wegman paradigm turns any AU family into a one-time MAC by masking the hash value with a fresh uniform pad.
Let be -AU into . Define a MAC with key , where and the pad , by . If authenticates at most one message, then any adversary—even a computationally unbounded one—who sees one message–tag pair forges a valid pair with with probability at most .
The adversary observes and must output with and . Subtracting the two tag equations eliminates the pad: the forgery succeeds iff
Condition on the adversary’s view. The pad is uniform and independent of , so given the single observed tag , every value of is equally consistent—each candidate value determines a unique —and the observation therefore leaks nothing about : the posterior on remains uniform on . The adversary’s difference and distinct pair are thus fixed independently of , and the AU property gives . □
The MAC Poly1305 instantiates the paradigm with a polynomial-evaluation hash over the prime field for (prime-field arithmetic as in the Math Guide, §“The prime field and two inversion routes”).
Fix the prime and work in . The key is a pair : is a -bit value subjected to a fixed bit-clamping (the top four bits of bytes and the bottom two bits of bytes are forced to zero), and is a -bit pad. To authenticate a message, split it into blocks of at most bytes; encode each block as an integer in and add , where is the block’s byte length—this sets a bit just above the block’s bytes, making every coefficient nonzero and the block encoding injective in both content and byte length. Interpreting and each as elements of , the hash is the polynomial evaluation
computed by Horner’s rule as . The tag is
the field hash reduced and added to the pad modulo .
Restricted to messages of at most bytes—hence at most blocks—the reduced Poly1305 hash family , read into , is -almost--universal with respect to addition modulo , with
The loss over the ideal accounts for the clamping of —which restricts to a subset of size —and for the final reduction modulo .
Sketch. Fix two distinct messages with block encodings and , padded to a common length by leading zero coefficients without changing their values. The block encoding guarantees that yields distinct coefficient vectors: genuine coefficients are nonzero, so differing block counts set a nonzero coefficient against a zero padding one, while equal block counts leave two blocks differing in content or in final-block byte length, hence in encoding. The difference of hashes is
a nonzero polynomial in of degree at most . Now count the ways a target difference can be hit. The reduced hash values lie in , so their integer difference lies in the interval , which has length ; each residue class modulo therefore contains at most candidate integer differences . For each such , the equation in has at most roots—a polynomial of degree over a field has at most roots (Math Guide, §“Roots and the factor theorem”)—so at most values of produce the difference . The clamped is uniform over a set of values (clamping zeroes of the bits), so it lands on one of those roots with probability at most . □
The bound is comfortably small in practice: for messages of bytes ( blocks) it gives , against the ideal —the clamping and reduction losses cost bits of the margin and leave it enormous. Combining Proposition 6.12 with the Carter–Wegman Theorem 6.10: Poly1305 with a fresh, uniformly random pad per message—uniformity, not mere unpredictability, is what the theorem’s pad-elimination step uses—is a one-time MAC with forgery probability at most per verification attempt. In the AEAD below, ChaCha20 itself generates the one-time key pseudorandomly from the nonce—uniform once the cipher is idealised as a random function—so the per-nonce one-time guarantee is exactly what is needed.
We now combine the two guarantees. The composite goal is authenticated encryption: the adversary should be unable to learn anything about plaintexts (CPA security) and unable to produce any new ciphertext that decrypts to anything other than the distinguished rejection symbol , a value distinct from every message (ciphertext integrity). Real protocols additionally require ciphertexts to bind to public context—packet headers, version bytes, an ephemeral public key—that travels in the clear but must be authenticated; this is the associated data.
An authenticated encryption with associated data (AEAD) scheme is a pair with key space , nonce space , and associated-data space : algorithm returns a ciphertext , and returns a message or . Correctness: for all . The scheme authenticates but does not encrypt the associated data .
For an AEAD scheme and adversary , the game runs as follows.
The challenger samples and gives two oracles: an encryption oracle , recording the set of returned triples , and a verification oracle that on returns if and otherwise. The adversary must never repeat a nonce to the encryption oracle (the nonce-respecting model); verification queries may reuse nonces freely.
The game outputs iff some verification query is answered .
The scheme has ciphertext integrity if for every PPT , .
An AEAD scheme is secure (is an AEAD) if it is both CPA-secure and has ciphertext integrity (Definition 6.14), where the CPA game of Definition 6.4 is run with and extended so that the adversary supplies the nonce and associated data of every oracle query and of the challenge, subject to the nonce-respecting restriction—a restriction on the adversary, not a property of the scheme—that no nonce is used twice across oracle queries and challenge. The restriction is necessary: an AEAD may encrypt deterministically given —ChaCha20-Poly1305 does—and then querying the oracle at and submitting the challenge would identify the bit by comparing ciphertexts.
The standard route from a CPA-secure cipher and a strongly unforgeable MAC to an AEAD is encrypt-then-MAC: encrypt the message, compute a MAC over the ciphertext together with the associated data and nonce, and append the tag; decryption verifies the tag before decrypting, and any tag failure returns . The contrasting orders—MAC-then-encrypt and encrypt-and-MAC—do not generically achieve authenticated encryption; encrypt-then-MAC does.
Let be a CPA-secure encryption scheme and a strongly unforgeable (sUF-CMA) MAC, with independent keys . Define the composite scheme by
with returning unless , in which case it returns . Then is a secure AEAD: it is CPA-secure and has ciphertext integrity.
Ciphertext integrity. Suppose a PPT making at most verification queries wins the game: some fresh query decrypts successfully, i.e. . Each encryption-oracle call on returned and corresponds to one MAC query on the string returning tag . Because the framing parses uniquely (the component lengths are fixed or prepended), the freshness of means the MAC oracle never produced the string–tag pair with : either was never queried, or it was queried and returned a different tag. Either way is a fresh valid pair—a strong forgery against . The reduction runs , answering encryption queries with its own MAC oracle and a self-chosen . Verification queries cannot answer, lacking , so it guesses: it samples a uniform index in advance, answers each fresh verification query before the -th with (queries on triples in are answered , correctly), halts at the -th fresh query, and outputs that query’s as its forgery. On the event that wins and hits her first successful fresh query—the guess is right with probability —every earlier answer was correct, the simulation is perfect, and wins, so
the factor being polynomial.
CPA security. The tag is computed from (together with , and the MAC’s own coins) and so carries no information about the challenge bit beyond what already carries. Formally, the reduction samples itself, forwards ’s oracle and challenge queries to its own oracle to obtain the -components, and appends tags it computes with . This simulates perfectly, so . □
Encrypt-then-MAC lets the receiver reject forged ciphertexts without decrypting, and this is what blocks chosen-ciphertext and padding-oracle attacks: a rejected ciphertext never reaches the decryption logic, so the decryption logic cannot leak. By contrast, MAC-then-encrypt verifies only after decrypting, exposing the decryption routine to attacker-chosen ciphertexts—the historical source of a long line of padding-oracle breaks. Ciphertext integrity is also exactly the property that upgrades CPA security to chosen-ciphertext (CCA) security, the CPA game of Definition 6.4 with a decryption oracle added that refuses only the challenge ciphertext: an authenticated-encryption scheme is automatically CCA-secure, because that oracle is useless to the adversary—every ciphertext she did not legitimately obtain decrypts to except with negligible probability.
We now assemble the concrete scheme of RFC 8439, the AEAD by which Zcash encrypts every shielded note ciphertext and outgoing ciphertext (protocol specification, §“Symmetric Encryption”). It is an encrypt-then-MAC composition of the ChaCha20 stream cipher with the Poly1305 one-time MAC, with one economical twist: the cipher derives both the keystream and the one-time MAC key from the single input.
Fix a -bit key and a -bit nonce . Encryption of a message with associated data proceeds as follows.
One-time MAC key. Run ChaCha20 with key , nonce , and block counter ; take the first bytes of the keystream block as the Poly1305 one-time key —clamp the first bytes to form ; the next are . Discard the rest of this block.
Encrypt. Run ChaCha20 with key and nonce starting at block counter , producing the keystream (the keystream of Remark 6.3 taken from counter onward), and set .
Authenticate. Form the Poly1305 input by concatenating: padded with zeros to a -byte boundary, padded with zeros to a -byte boundary, the -byte little-endian length of , and the -byte little-endian length of . Compute the tag .
The ciphertext is . Decryption recomputes and the tag from , compares it to in constant time, returns on mismatch, and otherwise outputs .
The trailing -byte lengths of and are essential. Without them, the zero-padding that aligns and to -byte boundaries would let an adversary shift bytes between the associated data and the ciphertext, or pad-extend one of them, while leaving the Poly1305 input string unchanged—breaking the binding between and even though every authenticated byte is intact. Appending the explicit lengths makes the MAC input an injective encoding of the pair , the same injectivity that the per-block length encoding supplies within one message in the AU analysis (Proposition 6.12).
Model ChaCha20 as a pseudorandom function from (nonce, block counter) pairs to -byte blocks. In the nonce-respecting model, ChaCha20-Poly1305 is a secure AEAD. Concretely, consider a PPT adversary making encryption queries and verification queries, each of whose Poly1305 inputs—padded associated data, padded ciphertext, and the length block—comprises at most sixteen-byte blocks, . Her CPA advantage is at most twice the best PRF-distinguishing advantage against at comparable cost, and she forges—wins the INT-CTXT game—with probability at most
where is a PRF distinguisher of comparable cost.
Sketch. Replace by a truly random function from (nonce, counter) pairs to -byte blocks. Any noticeable change in the adversary’s success probability yields a PRF distinguisher of comparable cost—it simulates the whole game using its function oracle—so each replacement costs one term; the CPA game is played twice (once per challenge bit), whence the factor two there. We analyse the idealised scheme.
Confidentiality. Since the adversary is nonce-respecting, every encryption query uses a fresh , and the keystream blocks are uniform and independent of everything else in her view; the ciphertext is a genuine one-time pad and reveals nothing about beyond its length. The tag is a deterministic function of and the (independent) key , and adds no information. The idealised CPA advantage is therefore zero.
Integrity. For each nonce , the block is uniform and independent across distinct nonces; clamping its first half samples from Poly1305’s prescribed restricted set, while the second half stays uniform, so the resulting one-time keys are independent across nonces. Because counter is reserved for this key while encryption consumes counters , each one-time key is also independent of the keystream that produced its ciphertext. Per nonce, the setting is exactly the Carter–Wegman one-time MAC of Theorem 6.10 instantiated with the -AU Poly1305 hash of Proposition 6.12, . Consider any single fresh verification query . If was never used for encryption, the pad for is uniform and entirely unknown, so the tag is correct with probability . If equals the nonce of some encryption query—nonce reuse is allowed in verification queries, only encryption is nonce-respecting— then the adversary has seen exactly one tag under that , and freshness of makes this a forgery on a new message under a one-time key, succeeding with probability at most by Theorem 6.10. The union bound over the verification queries (Math Guide, §“The union bound and a birthday calculation”) gives forgery probability at most in the idealised scheme; adding back the PRF-switching cost yields the stated bound. □
The scheme reuses one -bit key for both encryption and authentication, seemingly violating the independent-keys hypothesis of Theorem 6.16. Reserving block counter for the Poly1305 key and counters for the keystream is exactly what restores independence: once the cipher is idealised as a truly random function—the switch the proof of Theorem 6.20 pays for with a PRF-distinguishing term—outputs at distinct counters are independent, so is independent of the keystream and the two-key analysis applies. For the PRF itself the independence is computational, not literal. This is a recurring design pattern—domain separation by a counter or label, the same discipline as §3.5, lets one master key safely play several roles.
The upper volumes consume this AEAD in a trial-decryption pattern: a receiver detects the notes addressed to it by attempting decryption of every ciphertext under each of its keys, relying on decryption under a wrong key to return (protocol specification, §“Symmetric Encryption”). For honestly produced ciphertexts the scheme delivers this. Fix a ciphertext and a key independent of , and idealise the cipher under and under as independent random functions, as in the proof of Theorem 6.20. The one-time key that decryption under derives from block is then uniform and independent of : the pad alone makes the recomputed tag match with probability exactly , and even conditioned on one exposed tag under , Theorem 6.10 bounds acceptance by the AU slack of Proposition 6.12, with as in Theorem 6.20. Decryption under an independent key therefore rejects except with probability at most per attempt, plus two PRF-distinguishing terms for the two idealisations.
The guarantee stops at honest senders, and the boundary deserves care. CPA security and INT-CTXT are single-key notions: nothing in Definition 6.15 constrains a ciphertext crafted by a malicious sender who knows several keys. The scheme is in fact not key-committing—the separate notion demanding that no ciphertext verify under two distinct keys—and a sender who chooses keys herself can craft a single that decrypts validly, to different plaintexts, under both: with the one-time key each derives, the hash of Construction 6.11 is linear in the blocks of , so fixing , leaving two blocks of free, and solving over the two linear equations that pin the hash under to (retrying until both solutions encode valid blocks) makes both keys accept —the multi-key collision of Len, Grubbs, and Ristenpart’s partitioning-oracle attack. The upper volumes’ trial-decryption arguments therefore never rest on the tag alone against adversarial senders: their note-plaintext consistency checks—recomputing the note commitment from the decrypted plaintext and comparing it against the commitment the transaction carries—are what close this gap.
Theorem 6.20 assumes a uniformly random -bit key. In practice keys may come from sources that are high-entropy but not uniform: a Diffie–Hellman shared secret is a structured group encoding, not a uniform bit string, and a hardware noise source may spread its unpredictability unevenly across its bits. (A passphrase is a different, usually low-entropy source, and needs a deliberately costly password KDF rather than the machinery of this subsection.) The adversary is owed nothing here—if the honest parties feed a non-uniform key into a scheme proved secure for uniform keys, the proof simply does not apply, and structure in the key is structure she may exploit. A key-derivation function (KDF) converts an appropriate source secret into one or more pseudorandom keys. The right entropy measure is worst-case, not average-case.
The min-entropy of a random variable is
equivalently, the best chance of guessing in one try is . Given side information , the conditional min-entropy is
so that is the best chance of guessing from . Recall the statistical distance of Definition 1.6 (Math Guide, §“Statistical distance”); we say is -close to uniform on a set if .
A key-derivation function is a function
taking a source secret (a sample of a random variable over ), a non-secret salt , an info or context string , and a desired output length . The security goal must specify the source model. For an arbitrary source of conditional min-entropy at least given the adversary’s side information, an extractor-style guarantee uses a salt sampled uniformly and independently of the source and requires the pair to be computationally indistinguishable from , even given and that side information. No fixed deterministic unsalted function can provide this guarantee for every high-min-entropy source; an unsalted KDF therefore rests on a narrower premise, such as input keying material that is already computationally pseudorandom, or that is hard to query in a random-oracle model.
The notion a KDF targets is that of a seeded randomness extractor whose output need only look uniform.
A keyed function is a strong -computational extractor if for every source over of conditional min-entropy at least given auxiliary information , and a uniformly random salt , the pair is computationally indistinguishable from , even given , with distinguishing advantage at most . “Strong” means the salt is revealed to the distinguisher.
Information theory can realise the notion unconditionally; we state the classical result without proof, since the deployed mechanism below rests on random-oracle modelling instead.
Let be a -universal hash family with a uniform public seed . For any with ,
Thus investing bits of min-entropy buys output bits that are -close to uniform—a strong -extractor in the statistical, not merely computational, sense.
The standardised general-purpose KDF is Krawczyk’s HKDF (RFC 5869), built from HMAC (§5.3) in an extract-then-expand architecture: a salted HMAC call first distils suitable non-uniform input keying material into a short pseudorandom key (the extractor stage, justified along leftover-hash lines), and a counter-chained sequence of HMAC calls then expands that key, under a context string, up to RFC 5869’s limit of hash-output-length blocks (the expander stage, justified by HMAC’s PRF security). The resulting KDF is a standard choice across many protocol source models and output lengths, though its precise guarantee still depends on assumptions about the source and about HMAC. Zcash does not use it—indeed the shielded protocol uses HMAC nowhere: neither the orchard nor the zcash_note_encryption crate carries an HMAC dependency (HMAC enters the wallet stack through the transparent BIP-32 derivation and BIP-39 mnemonic layers and, transitively, through the optional Tor client, never through a shielded crate)—because its requirements are narrower and a single hash call meets them in the random-oracle analysis.
Orchard derives the note-encryption key by one personalised BLAKE2b call:
where is the Diffie–Hellman shared point of the note-encryption key agreement, is the sender’s ephemeral public key, and the quoted string occupies BLAKE2b’s -byte personalisation field (the function kdf_orchard hashes the serialised shared point followed by the ephemeral-key bytes with a -byte output; protocol specification, §“Orchard Key Derivation”). The analysis models this personalised hash as a random oracle: by the domain-separation principle of §3.5 (Proposition 3.17, via the native-personalisation idiom catalogued there), the personalisation makes it an oracle independent of every other hash use in the protocol, and the derived key is uniform in the adversary’s view unless she queries that oracle at the hidden —a query whose argument she must first compute from the two public keys, an instance of the computational Diffie–Hellman problem of §2.2. Folding into the input binds the derived key to this particular ephemeral, the role the context string plays in HKDF. No salt is used because the claim is this narrower Diffie–Hellman-plus-random-oracle one—the unsalted premise anticipated in Definition 6.24—not extraction from every high-min-entropy source.
In the Zcash note-encryption layer, a Diffie–Hellman exchange on the Pallas curve produces a shared group element, and the single BLAKE2b call above condenses that element into the symmetric key fed to ChaCha20-Poly1305. The two halves of this section meet exactly here: key derivation manufactures the uniform key that the AEAD security theorem (Theorem 6.20) takes as its hypothesis, and the chain from a non-uniform shared secret to an authenticated ciphertext is complete. Section 7 assembles that chain end to end as hybrid public-key encryption.