This section instantiates RedDSA, the re-randomisable Schnorr signature scheme of the Crypto Guide, on the Pallas group; constructs the randomised validating key and the spend-authorisation signature of an Action; and proves two properties of them: the published key is, with the signature scheme’s hash modelled as a random oracle, within negligible statistical distance of a key independent of the spend validating key; and a new valid signature under a randomised key yields the key’s discrete logarithm. The signed message is a parameter throughout; “Transaction digests and signatures” (§11.3) fixes it.
Requirement R5 of “Requirements on a shielded payment” (§1.4) admits only the holder of a note’s spending authority as a party that consumes the note. For keys generated with , the spending authority over the notes of every address derived from a spending key is knowledge of its spend authorising key of “The spending key and the spend-side secrets” (§3.1), the discrete logarithm of to the base . No lower key tier yields , since every lower tier is computed from the full viewing key (Proposition 3.18(a)). Each Action therefore carries a signature that only a holder of can produce, under a validating key that does not link Actions consuming notes of the same key: a fresh re-randomisation of (§7.2), never itself. Theorem 12.9, in “Authorisation of spends” (§12.3), proves for keys with that no efficient party without produces an accepted Action that consumes a note of an honestly generated address and whose spend-authorisation signature is on a digest that the key holder did not sign under the Action’s randomised key, except with negligible probability.
The RedPallas hash is the map from byte strings to -byte strings
with the notation of the expansion function (§2.3) and the -byte personalisation Zcash_RedPallasH. Its reduction to scalars is
(protocol specification, §“RedDSA, RedJubjub, and RedPallas” and §“BLAKE2 Hash Functions”). The symbol is that of the specification and of the Crypto Guide’s Remark “RedDSA as deployed” (§“RedDSA: re-randomisable Schnorr for Orchard”); it is distinct from the star encoding of a point.
In security arguments the RedPallas hash is modelled as a random oracle with output length , that is, with range the -byte strings, queried by every party (Crypto Guide, §“The random oracle model”, Definition “Random oracle”). Consequently is a random function into : its values at distinct inputs are independent, and each is distributed as for uniform on the -byte strings. That distribution is at statistical distance at most
from the uniform distribution on (Math Guide, §“Uniform sampling and the bias of modular reduction”, Proposition “Bias of modular reduction”, with ), and it gives each scalar probability at most , since each residue has at most preimages among the strings. The assumption is a heuristic about BLAKE2b, not a theorem. Every later result on RedPallas signatures or on the randomiser generator below names it.
RedPallas is the Crypto Guide’s Construction “RedDSA” (§“RedDSA: re-randomisable Schnorr for Orchard”) on the Pallas group , of prime order , with both hashes and with a base point as parameter; the group having prime order, generates it. For a point let , its -byte encoding; the map is injective, as the star encoding is (§2.1) and is a bijection onto the -byte strings. Messages are byte strings.
Keys. A signing key is a scalar ; its validating key is .
Signing a message under : draw uniformly from the -byte strings, where is the specification’s randomness length for a -bit hash; let
and output the -byte signature .
Validation of a -byte string under a point on : let be the first bytes of and the last ; let , and . Accept if and only if , and
| (4) |
(Protocol specification, §“RedDSA, RedJubjub, and RedPallas”; its validation equation carries the cofactor, which is on Pallas.)
The partial inverse returns on every -bit string that is not the star encoding of a point (§2.1); validation therefore rejects a non-canonical , and an accepted signature has . An honest signature is accepted: its first half decodes to , its is an integer representative below , the verifier recomputes the signer’s , and (Crypto Guide, §“From identification to signature via the Fiat–Shamir transform”, Proposition “Perfect correctness”). Both the nonce hash and the challenge hash take the encoded validating key : the scheme is key-prefixed. The message is a parameter: the message of every RedPallas signature in this volume is the signature digest constructed in “Transaction digests and signatures” (§11.3), and no argument before that subsection depends on its value.
The volume uses two instances of RedPallas, which share the signing and validation algorithms and differ in the base and in the use of key re-randomisation (protocol specification, §“Spend Authorization Signature (Sapling and Orchard)” and §“Binding Signature (Sapling and Orchard)”):
the spend-authorisation instance, with key re-randomisation (§7.2) and base
the binding-signature instance, without re-randomisation, used in “The binding signature” (§8.3), with base the value-commitment randomness base
Both bases are rows of Table 2 (§2.2); the specification takes each as the generator parameter of RedDSA.
The randomiser generator draws uniformly from the -byte strings and returns (protocol specification, §“RedDSA, RedJubjub, and RedPallas”); its distance from uniform is bounded in §7.2. Re-randomisation by a randomiser maps a key pair to (Crypto Guide, §“Key re-randomisation and unlinkability”, Definition “Key re-randomisation”).
Let be valid under on , with decoded components and and challenge , and let for a scalar . The shifted string satisfies . Validation of under , however, recomputes the challenge as , the value of the oracle at an input other than that of , since ; and (4) holds for under only if , that is, only if . Under Assumption 7.3, for each the value is independent of and equals it with probability at most . A signature is therefore not transported from one key to a related key by shifting its response. With a challenge that omitted the key, always, and the shift would turn every signature under into one under (Crypto Guide, §“From identification to signature via the Fiat–Shamir transform”, Remark “Two conventions”; §“Key re-randomisation and unlinkability”, Remark “Unforgeability under re-randomised keys, and the key-prefixing subtlety”). The proof of Proposition 7.12, which admits randomisers chosen by the adversary, uses key prefixing in its steps (3) and (5).
For each Action the spender draws a spend-authorisation randomiser , independently of every other draw, and sets
with the sign-normalised spend authorising key of the spending key of the consumed note and its spend validating key (§3.1). Since , it follows that (Crypto Guide, §“Key re-randomisation and unlinkability”, Proposition “Re-randomisation consistency”), so is a key pair of the spend-authorisation instance. The Action publishes the randomised validating key and its spend-authorisation signature, the RedPallas signature under on the signature digest constructed in “Transaction digests and signatures” (§11.3); it publishes none of , , , and (protocol specification, §“Spend Authorization Signature (Sapling and Orchard)”).
Under Assumption 7.3, let an algorithm, the observer, make at most queries to and, at one point, choose a byte string and receive , for uniform on the -byte strings and independent of all else. The pair formed by the observer’s view and is within statistical distance
| (5) |
of the pair obtained when is replaced by a uniform element of independent of all else. A randomiser from is the case ; the nonce of a RedPallas signature under on is the case . The first term of (5) is set by the -bit output of , not by the -bit length of ; the length of enters only the second term.
Let be the event that the observer queries at . In a second experiment, is replaced, in the computation of only, by a uniform -byte string independent of all else. In the lazy realisation of the random oracle (Crypto Guide, §“The random oracle model”, Definition “Random oracle”) the answers at inputs other than are independent of , so the two experiments are identical until occurs; has the same probability in both, and their outputs are within statistical distance (Crypto Guide, §“Security as a game”, Remark “Game-hopping”). In the second experiment the observer’s view is independent of , so each query agrees with in its first bytes with probability at most , and by the union bound. There is independent of , of and of the observer’s coins, and the pair of view and is a function of and of them. Replacing by a uniform scalar changes the pair by at most (Assumption 7.3; Math Guide, §“Statistical distance”, Theorem “Properties of statistical distance”, part (4)). The triangle inequality, part (2) of the same theorem, gives (5). □
Two consensus rules of the protocol specification, §“Action Descriptions”, concern spend authorisation:
the randomised validating key of an Action must not be the identity ;
the spend-authorisation signature of the Action must be valid under on the signature digest of “Transaction digests and signatures” (§11.3).
Validation rejects a non-canonical encoding of the signature’s point component (§7.1). An honestly computed equals only if ; for fixed before is drawn, this event has probability at most (Assumption 7.3).
Let be points of the Pallas group, equal or distinct, and let for randomisers independent of each other and of the points.
If each is uniform on , the tuple is uniform on , whatever the points , and hence independent of them. For each and the scalar with , the pair is distributed exactly as a fresh key pair with uniform, independently of . The distribution of the tuple is thus the same for every assignment of the points, and no observer, whatever its running time, distinguishes two assignments, for instance one in which two Actions share a key from one in which they do not, with non-zero advantage.
If each is drawn by , then under Assumption 7.3, for an observer that receives the tuple and makes at most queries to , the pair of its view and the tuple is within statistical distance
of the pair obtained from a uniform tuple independent of ; the pairs arising from two assignments of the points are therefore within statistical distance .
(i) For each this is the Crypto Guide’s Theorem “Perfect unlinkability of re-randomised keys” (§“Key re-randomisation and unlinkability”). The base generates the Pallas group, of prime order (§7.1), so is a bijection from onto the group, and translation by is a bijection of the group; hence is uniform whatever is, and the independence of the gives the product distribution. The scalar is uniform for every fixed because is, and . Equal distributions give every distinguisher advantage zero (Math Guide, §“Statistical distance”, Theorem “Properties of statistical distance”, part (3)).
(ii) The randomisers are replaced by independent uniform scalars one at a time, for . At step the lemma on the distance of from uniform applies, with , to the observer extended by the rest of the experiment: it holds the points and , already uniform; it draws itself and queries at them; it receives , computes the tuple and runs the given observer. It makes at most queries, and the given observer’s view and the tuple are a function of its view and . By (5) and part (4) of the same theorem, step changes the pair of view and tuple by at most . By the triangle inequality, the steps together change it by at most
After the last step the are uniform, independent and independent of , so by (i) the tuple is uniform and independent of , for every assignment of the points. The triangle inequality through that common distribution gives the factor for two assignments. □
The proposition concerns alone, for randomisers drawn by the honest spender; a randomiser chosen by an adversary is the subject of Proposition 7.12 (§7.3). The spend-authorisation signature published with adds no information about : under Assumption 7.3 it is simulated from and the message alone by programming (Crypto Guide, §“Security in the random oracle model and the forking lemma”, Lemma “Signature simulation”). The simulator draws uniform on the -byte strings and uniform on , sets and , programs at to , and outputs . Beyond the abort probability of the lemma, a real signature differs from the simulated one only through its nonce: for a uniform nonce the two are identically distributed, since is then uniform given and . The difference is therefore at most the bound (5) per signature, with there the number of all other queries to in the experiment. The remaining public fields of an Action are treated in Theorem 12.12, in “Privacy” (§12.4).
Assume that discrete logarithms on Pallas are hard (Assumption 2.22) and that is a random oracle (Assumption 7.3). Let be uniform on and . An adversary receives , makes at most queries to and at most queries to a signing oracle that answers a pair of its choice, and a byte string, with the spend-authorisation signature under on , whose validating key is ; it outputs a triple with a point. It forges if is valid under on and is not the triple of validating key, message and signature of an oracle answer. Let be its forging probability, and
Extraction. There is an algorithm that receives but not , runs twice on shared coins, answers its signing queries without , and outputs a scalar with , for the of the first run, with probability at least
the bound of the Crypto Guide’s Theorem “EUF-CMA security of Schnorr signatures in the ROM” (§“Security in the random oracle model and the forking lemma”) with replaced by and the group order by .
Unforgeability under re-randomisation. If also outputs with , of its own choice and possibly dependent on , then outputs , the discrete logarithm of , with the same probability. By Assumption 2.22, is then negligible for every efficient .
With every randomiser zero, part (ii) is the existential unforgeability of RedPallas under chosen-message attack (Crypto Guide, §“Syntax and security goal”, Definition “Existential unforgeability under chosen-message attack”) in its strong form (Definition “Strong unforgeability” there), since freshness is required of the triple rather than of the message. Part (ii) implies the SURK-CMA requirement of the protocol specification, §“Signature with Re-Randomizable Keys”, whose forgery is a message–signature pair not returned by the oracle, hence a triple not returned by it.
The argument is route (ii) of the Crypto Guide’s Remark “Unforgeability under re-randomised keys, and the key-prefixing subtlety” (§“Key re-randomisation and unlinkability”), with the bound of its Theorem “EUF-CMA security of Schnorr signatures in the ROM” (§“Security in the random oracle model and the forking lemma”), which applies to RedPallas with the generator replaced by the base (Construction “RedDSA”). The Orchard steps are made in place; write .
(1) Idealisation. First, the nonce of each oracle answer is replaced by a uniform scalar. By the lemma on the distance of from uniform, with and the rest of the experiment as observer, each of the at most replacements costs at most : apart from this nonce query, the experiment queries at most times for , times for other nonces, times for challenges and once for validating the forgery. Second, the answers of to the queries of and to the validation query are replaced by uniform preimages, under , of uniform scalars, so that their values under are uniform on . Each of these at most replacements costs at most , because in both distributions an answer, conditioned on its reduction, is uniform on the preimages of that reduction. The forging probability thus drops by at most (Math Guide, §“Statistical distance”, Theorem “Properties of statistical distance”, part (3)).
(2) Embedding. The reduction receives a discrete-logarithm challenge with uniform and gives the key .
(3) Signing. It answers the -th query without , under , by the simulator of the Crypto Guide’s Lemma “Signature simulation” (§“Security in the random oracle model and the forking lemma”): it draws uniform on the -byte strings and uniform on , sets and , programs at to , aborting if that entry is already defined, and returns . After step (1) a real answer has a uniform nonce and, at a fresh input, the challenge for a uniform ; then is uniform given , and , which is the simulated distribution (Crypto Guide, §“The Schnorr identification protocol”, Theorem “Special honest-verifier zero knowledge”). The point is uniform, so the reduction aborts with probability at most , as in the lemma. Key prefixing places in every programmed input: entries programmed under distinct keys have distinct inputs, and the simulation needs no relation among the .
(4) Critical query. Let be a forgery, with decoding to and . If , the scalar satisfies (i), and in (ii) ; the reduction outputs these. Let . The validation input is not a programmed entry. Its first bytes, its next bytes and its remainder would otherwise give , and for some , the second by injectivity of , and the challenge would be . Then , and (4) gives . Since generates the group, of prime order , and , this forces , so and the triple is an oracle answer. The input was queried by , except with probability at most : otherwise its value under is a uniform scalar drawn at validation, and, since generates the group, at most one scalar satisfies (4). This guessing term is part of the term of the cited theorem.
(5) Fork. The reduction wraps as the algorithm of the Crypto Guide’s Theorem “General forking lemma” (§“Security in the random oracle model and the forking lemma”), with challenge set , prepared challenges , and coins that include those of and of the simulator. The wrapper answers the -th distinct unprogrammed query to , of or of validation, with a uniform preimage of under , and returns the index of the critical query with ’s output. The two runs of the forking algorithm share the coins and the challenges before that index, so makes the same critical query in both, with the same , the same , since key prefixing makes part of the critical input, and the same . In (ii) they also share , which determines because generates the group. The runs receive distinct challenges at the critical index and return responses and .
(6) Extraction. The transcripts and are accepting for with , so the Crypto Guide’s Theorem “2-special soundness” (§“The Schnorr identification protocol”) gives
the discrete logarithm of , which is (i). For (ii) the reduction outputs . The probability bound follows as in the cited theorem, from the forking bound
with at least less the abort and guessing terms of steps (3) and (4). □