The Zcash ArboretumIronwood Guide PDF

7 Spend authorisation

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.

7.1 The RedPallas signature scheme

Remark 7.1 (Spending authority and its signature).

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 𝖺𝗄ℙ=[𝖺𝗌𝗄]⁢G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁 to the base G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁. 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.

Definition 7.2 (RedPallas hash).

The RedPallas hash is the map 𝖧 from byte strings to 64-byte strings

𝖧⁢(z):=BLAKE2b⁢-⁢512⁢(Zcash_RedPallasH,z),

with the notation of the expansion function (§2.3) and the 16-byte personalisation Zcash_RedPallasH. Its reduction to scalars is

𝖧⊛⁢(z):=𝖫𝖤𝖮𝖲𝟤𝖨𝖯512⁢(𝖧⁢(z))modp𝖵𝖾𝗌𝗍𝖺=ToScalar⁢(𝖧⁢(z))∈𝔽p𝖵𝖾𝗌𝗍𝖺

(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 P⋆ of a point.

Assumption 7.3 (The RedPallas hash as a random oracle).

In security arguments the RedPallas hash 𝖧 is modelled as a random oracle with output length 512, that is, with range the 64-byte strings, queried by every party (Crypto Guide, §“The random oracle model”, Definition “Random oracle”). Consequently 𝖧⊛ is a random function into 𝔽p𝖵𝖾𝗌𝗍𝖺: its values at distinct inputs are independent, and each is distributed as ToScalar⁢(U) for U uniform on the 64-byte strings. That distribution is at statistical distance at most

δ512:=p𝖵𝖾𝗌𝗍𝖺/2512<2−257

from the uniform distribution on 𝔽p𝖵𝖾𝗌𝗍𝖺 (Math Guide, §“Uniform sampling and the bias of modular reduction”, Proposition “Bias of modular reduction”, with L=512), and it gives each scalar probability at most 1/p𝖵𝖾𝗌𝗍𝖺+2−512, since each residue has at most ⌊2512/p𝖵𝖾𝗌𝗍𝖺⌋+1 preimages among the 2512 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.

Construction 7.4 (RedPallas).

RedPallas is the Crypto Guide’s Construction “RedDSA” (§“RedDSA: re-randomisable Schnorr for Orchard”) on the Pallas group ℰ⁢(𝔽p𝖯𝖺𝗅𝗅𝖺𝗌), of prime order p𝖵𝖾𝗌𝗍𝖺, with both hashes 𝖧⊛ and with a base point B≠𝒪 as parameter; the group having prime order, B generates it. For a point P let P¯:=𝖫𝖤𝖡𝖲𝟤𝖮𝖲𝖯256⁢(P⋆), its 32-byte encoding; the map P↦P¯ is injective, as the star encoding is (§2.1) and 𝖫𝖤𝖡𝖲𝟤𝖮𝖲𝖯256 is a bijection onto the 32-byte strings. Messages are byte strings.

  1. 1.

    Keys. A signing key is a scalar x∈𝔽p𝖵𝖾𝗌𝗍𝖺; its validating key is X:=[x]⁢B.

  2. 2.

    Signing a message M under x: draw T uniformly from the 80-byte strings, where 80=(512+128)/8 is the specification’s randomness length for a 512-bit hash; let

    r :=𝖧⊛⁢(T⁢‖X¯‖⁢M), R :=[r]⁢B,
    c :=𝖧⊛⁢(R¯⁢‖X¯‖⁢M), S :=r+c⋅x∈𝔽p𝖵𝖾𝗌𝗍𝖺,

    and output the 64-byte signature σ:=R¯∥𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(S).

  3. 3.

    Validation of a 64-byte string σ under a point X on M: let R¯ be the first 32 bytes of σ and S¯ the last 32; let R:=𝖺𝖻𝗌𝗍ℙ⁢(𝖫𝖤𝖡𝖲𝟤𝖮𝖲𝖯256−1⁢(R¯)), S:=𝖫𝖤𝖮𝖲𝟤𝖨𝖯256⁢(S¯) and c:=𝖧⊛⁢(R¯⁢‖X¯‖⁢M). Accept if and only if R≠⊥, S<p𝖵𝖾𝗌𝗍𝖺 and

    [S]⁢B=R+[c]⁢X. (4)

(Protocol specification, §“RedDSA, RedJubjub, and RedPallas”; its validation equation carries the cofactor, which is 1 on Pallas.)

The partial inverse 𝖺𝖻𝗌𝗍ℙ returns ⊥ on every 256-bit string that is not the star encoding of a point (§2.1); validation therefore rejects a non-canonical R¯, and an accepted signature has R¯=R¯. An honest signature is accepted: its first half R¯ decodes to R, its S is an integer representative below p𝖵𝖾𝗌𝗍𝖺, the verifier recomputes the signer’s c, and [S]⁢B=[r]⁢B+[c⋅x]⁢B=R+[c]⁢X (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 X¯: the scheme is key-prefixed. The message M 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.

Definition 7.5 (Spend-authorisation and binding-signature instances).

The volume uses two instances of RedPallas, which share the signing and validation algorithms and differ in the base B and in the use of key re-randomisation (protocol specification, §“Spend Authorization Signature (Sapling and Orchard)” and §“Binding Signature (Sapling and Orchard)”):

  1. 1.

    the spend-authorisation instance, with key re-randomisation (§7.2) and base

    B=G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁=𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁⁢(z.cash:Orchard,G);
  2. 2.

    the binding-signature instance, without re-randomisation, used in “The binding signature” (§8.3), with base the value-commitment randomness base

    B=R𝖮𝗋𝖼𝗁𝖺𝗋𝖽=𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁⁢(z.cash:Orchard-cv,r).

Both bases are rows of Table 2 (§2.2); the specification takes each as the generator parameter of RedDSA.

Definition 7.6 (Randomiser generator and key re-randomisation).

The randomiser generator 𝖦𝖾𝗇𝖱𝖺𝗇𝖽𝗈𝗆 draws T uniformly from the 80-byte strings and returns 𝖧⊛⁢(T)∈𝔽p𝖵𝖾𝗌𝗍𝖺 (protocol specification, §“RedDSA, RedJubjub, and RedPallas”); its distance from uniform is bounded in §7.2. Re-randomisation by a randomiser α∈𝔽p𝖵𝖾𝗌𝗍𝖺 maps a key pair (x,X) to (x+α,X+[α]⁢B) (Crypto Guide, §“Key re-randomisation and unlinkability”, Definition “Key re-randomisation”).

Remark 7.7 (Key prefixing).

Let σ be valid under X on M, with decoded components R and S and challenge c=𝖧⊛⁢(R¯⁢‖X¯‖⁢M), and let X′:=X+[β]⁢B≠𝒪 for a scalar β≠0. The shifted string σ′:=R¯∥𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(S+c⁢β) satisfies [S+c⁢β]⁢B=R+[c]⁢X′. Validation of σ′ under X′, however, recomputes the challenge as c′:=𝖧⊛⁢(R¯⁢‖X′¯‖⁢M), the value of the oracle at an input other than that of c, since X′¯≠X¯; and (4) holds for σ′ under X′ only if [c−c′]⁢X′=𝒪, that is, only if c′=c. Under Assumption 7.3, for each β the value c′ is independent of c and equals it with probability at most 1/p𝖵𝖾𝗌𝗍𝖺+2−512. A signature is therefore not transported from one key to a related key by shifting its response. With a challenge that omitted the key, c′=c always, and the shift would turn every signature under X into one under X′ (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).

7.2 Randomised validating keys

Construction 7.8 (Randomised validating key).

For each Action the spender draws a spend-authorisation randomiser α:=𝖦𝖾𝗇𝖱𝖺𝗇𝖽𝗈𝗆⁢(), independently of every other draw, and sets

𝗋𝗌𝗄:=𝖺𝗌𝗄+α∈𝔽p𝖵𝖾𝗌𝗍𝖺,𝗋𝗄:=𝖺𝗄ℙ+[α]⁢G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁∈ℰ⁢(𝔽p𝖯𝖺𝗅𝗅𝖺𝗌),

with 𝖺𝗌𝗄 the sign-normalised spend authorising key of the spending key of the consumed note and 𝖺𝗄ℙ its spend validating key (§3.1). Since 𝖺𝗄ℙ=[𝖺𝗌𝗄]⁢G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁, it follows that 𝗋𝗄=[𝗋𝗌𝗄]⁢G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁 (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)”).

Lemma 7.9 (Distance of GenRandom from uniform).

Under Assumption 7.3, let an algorithm, the observer, make at most qh queries to 𝖧 and, at one point, choose a byte string w and receive α:=𝖧⊛⁢(T∥w), for T uniform on the 80-byte strings and independent of all else. The pair formed by the observer’s view and α is within statistical distance

δ512+qh⋅2−640 (5)

of the pair obtained when α is replaced by a uniform element of 𝔽p𝖵𝖾𝗌𝗍𝖺 independent of all else. A randomiser from 𝖦𝖾𝗇𝖱𝖺𝗇𝖽𝗈𝗆 is the case w=ε; the nonce of a RedPallas signature under X on M is the case w=X¯∥M. The first term of (5) is set by the 512-bit output of 𝖧, not by the 640-bit length of T; the length of T enters only the second term.

Proof.

Let E be the event that the observer queries 𝖧 at T∥w. In a second experiment, 𝖧⁢(T∥w) is replaced, in the computation of α only, by a uniform 64-byte string U 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 T∥w are independent of 𝖧⁢(T∥w), so the two experiments are identical until E occurs; E has the same probability in both, and their outputs are within statistical distance Pr⁢[E] (Crypto Guide, §“Security as a game”, Remark “Game-hopping”). In the second experiment the observer’s view is independent of T, so each query agrees with T∥w in its first 80 bytes with probability at most 2−640, and Pr⁢[E]≤qh⋅2−640 by the union bound. There U is independent of 𝖧, of T and of the observer’s coins, and the pair of view and α is a function of α=ToScalar⁢(U) and of them. Replacing α by a uniform scalar changes the pair by at most δ512 (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:

  1. 1.

    the randomised validating key 𝗋𝗄 of an Action must not be the identity 𝒪;

  2. 2.

    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 1/p𝖵𝖾𝗌𝗍𝖺+2−512 (Assumption 7.3).

Proposition 7.10 (Unlinkability of randomised validating keys).

Let 𝖺𝗄1ℙ,…,𝖺𝗄nℙ be points of the Pallas group, equal or distinct, and let 𝗋𝗄i:=𝖺𝗄iℙ+[αi]⁢G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁 for randomisers α1,…,αn independent of each other and of the points.

  1. (i)

    If each αi is uniform on 𝔽p𝖵𝖾𝗌𝗍𝖺, the tuple (𝗋𝗄1,…,𝗋𝗄n) is uniform on ℰ⁢(𝔽p𝖯𝖺𝗅𝗅𝖺𝗌)n, whatever the points 𝖺𝗄iℙ, and hence independent of them. For each i and the scalar 𝖺𝗌𝗄i with 𝖺𝗄iℙ=[𝖺𝗌𝗄i]⁢G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁, the pair (𝖺𝗌𝗄i+αi,𝗋𝗄i) is distributed exactly as a fresh key pair (y,[y]⁢G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁) with y uniform, independently of 𝖺𝗌𝗄i. 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.

  2. (ii)

    If each αi is drawn by 𝖦𝖾𝗇𝖱𝖺𝗇𝖽𝗈𝗆, then under Assumption 7.3, for an observer that receives the tuple and makes at most qh queries to 𝖧, the pair of its view and the tuple is within statistical distance

    n⁢(δ512+(qh+n)⋅2−640)

    of the pair obtained from a uniform tuple independent of 𝖧; the pairs arising from two assignments of the points are therefore within statistical distance 2⁢n⁢(δ512+(qh+n)⋅2−640).

Proof.

(i) For each i this is the Crypto Guide’s Theorem “Perfect unlinkability of re-randomised keys” (§“Key re-randomisation and unlinkability”). The base G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁 generates the Pallas group, of prime order p𝖵𝖾𝗌𝗍𝖺 (§7.1), so α↦[α]⁢G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁 is a bijection from 𝔽p𝖵𝖾𝗌𝗍𝖺 onto the group, and translation by 𝖺𝗄iℙ is a bijection of the group; hence 𝗋𝗄i is uniform whatever 𝖺𝗄iℙ is, and the independence of the αi gives the product distribution. The scalar 𝖺𝗌𝗄i+αi is uniform for every fixed 𝖺𝗌𝗄i because αi is, and 𝗋𝗄i=[𝖺𝗌𝗄i+αi]⁢G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁. 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 i=1,…,n. At step i the lemma on the distance of 𝖦𝖾𝗇𝖱𝖺𝗇𝖽𝗈𝗆 from uniform applies, with w=ε, to the observer extended by the rest of the experiment: it holds the points and α1,…,αi−1, already uniform; it draws Ti+1,…,Tn itself and queries 𝖧 at them; it receives αi, computes the tuple and runs the given observer. It makes at most qh+n−i queries, and the given observer’s view and the tuple are a function of its view and αi. By (5) and part (4) of the same theorem, step i changes the pair of view and tuple by at most δ512+(qh+n−i)⋅2−640. By the triangle inequality, the n steps together change it by at most

n⁢δ512+(n⁢qh+n⁢(n−1)2)⁢2−640≤n⁢(δ512+(qh+n)⋅2−640).

After the last step the αi 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 2 for two assignments. □

Remark 7.11 (Scope of Proposition 7.10). #

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 M alone by programming 𝖧 (Crypto Guide, §“Security in the random oracle model and the forking lemma”, Lemma “Signature simulation”). The simulator draws u uniform on the 64-byte strings and S uniform on 𝔽p𝖵𝖾𝗌𝗍𝖺, sets c:=ToScalar⁢(u) and R:=[S]⁢G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁−[c]⁢𝗋𝗄, programs 𝖧 at R¯⁢‖𝗋𝗄¯‖⁢M to u, and outputs R¯∥𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(S). 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 S=r+c⋅𝗋𝗌𝗄 is then uniform given u and R=[S]⁢G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁−[c]⁢𝗋𝗄. The difference is therefore at most the bound (5) per signature, with qh 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).

7.3 RedPallas unforgeability

Proposition 7.12 (Unforgeability under re-randomisation).

Assume that discrete logarithms on Pallas are hard (Assumption 2.22) and that 𝖧 is a random oracle (Assumption 7.3). Let x be uniform on 𝔽p𝖵𝖾𝗌𝗍𝖺 and 𝖺𝗄ℙ:=[x]⁢G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁. An adversary 𝒜 receives 𝖺𝗄ℙ, makes at most qh queries to 𝖧 and at most qs queries to a signing oracle that answers a pair (α,M) of its choice, α∈𝔽p𝖵𝖾𝗌𝗍𝖺 and M a byte string, with the spend-authorisation signature under x+α on M, whose validating key is 𝖺𝗄ℙ+[α]⁢G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁; it outputs a triple (𝗋𝗄∗,M∗,σ∗) with 𝗋𝗄∗ a point. It forges if σ∗ is valid under 𝗋𝗄∗ on M∗ and (𝗋𝗄∗,M∗,σ∗) is not the triple of validating key, message and signature of an oracle answer. Let ϵ be its forging probability, Q:=qh+qs+1 and

η:=Q⁢δ512+qs⁢(qh+2⁢qs)⋅2−640.
  1. (i)

    Extraction. There is an algorithm 𝒟 that receives 𝖺𝗄ℙ but not x, runs 𝒜 twice on shared coins, answers its signing queries without x, and outputs a scalar 𝗋𝗌𝗄∗ with 𝗋𝗄∗=[𝗋𝗌𝗄∗]⁢G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁, for the 𝗋𝗄∗ of the first run, with probability at least

    (ϵ−η)2Q−Qp𝖵𝖾𝗌𝗍𝖺−qs⁢(qh+qs)p𝖵𝖾𝗌𝗍𝖺(ϵ≥η),

    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 p𝖵𝖾𝗌𝗍𝖺.

  2. (ii)

    Unforgeability under re-randomisation. If 𝒜 also outputs α∗∈𝔽p𝖵𝖾𝗌𝗍𝖺 with 𝗋𝗄∗=𝖺𝗄ℙ+[α∗]⁢G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁, of its own choice and possibly dependent on 𝖺𝗄ℙ, then 𝒟 outputs x=𝗋𝗌𝗄∗−α∗, 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.

Proof.

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 G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁 (Construction “RedDSA”). The Orchard steps are made in place; write G:=G𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁.

(1) Idealisation. First, the nonce ri of each oracle answer is replaced by a uniform scalar. By the lemma on the distance of 𝖦𝖾𝗇𝖱𝖺𝗇𝖽𝗈𝗆 from uniform, with w=𝗋𝗄i¯∥Mi and the rest of the experiment as observer, each of the at most qs replacements costs at most δ512+(qh+2⁢qs)⋅2−640: apart from this nonce query, the experiment queries 𝖧 at most qh times for 𝒜, qs−1 times for other nonces, qs 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 ToScalar, of uniform scalars, so that their values under 𝖧⊛ are uniform on 𝔽p𝖵𝖾𝗌𝗍𝖺. Each of these at most qh+1 replacements costs at most δ512, 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 Y=[x]⁢G with x uniform and gives 𝒜 the key 𝖺𝗄ℙ:=Y.

(3) Signing. It answers the i-th query (αi,Mi) without x, under 𝗋𝗄i:=𝖺𝗄ℙ+[αi]⁢G, by the simulator of the Crypto Guide’s Lemma “Signature simulation” (§“Security in the random oracle model and the forking lemma”): it draws ui uniform on the 64-byte strings and Si uniform on 𝔽p𝖵𝖾𝗌𝗍𝖺, sets ci:=ToScalar⁢(ui) and Ri:=[Si]⁢G−[ci]⁢𝗋𝗄i, programs 𝖧 at Ri¯⁢‖𝗋𝗄i¯‖⁢Mi to ui, aborting if that entry is already defined, and returns σi:=Ri¯∥𝖨𝟤𝖫𝖤𝖮𝖲𝖯256⁢(Si). After step (1) a real answer has a uniform nonce ri and, at a fresh input, the challenge ci=ToScalar⁢(ui) for a uniform ui; then Si=ri+ci⁢(x+αi) is uniform given ui, and Ri=[Si]⁢G−[ci]⁢𝗋𝗄i, which is the simulated distribution (Crypto Guide, §“The Schnorr identification protocol”, Theorem “Special honest-verifier zero knowledge”). The point Ri is uniform, so the reduction aborts with probability at most qs⁢(qh+qs)/p𝖵𝖾𝗌𝗍𝖺, as in the lemma. Key prefixing places 𝗋𝗄i¯ in every programmed input: entries programmed under distinct keys have distinct inputs, and the simulation needs no relation among the 𝗋𝗄i.

(4) Critical query. Let (𝗋𝗄∗,M∗,σ∗) be a forgery, with σ∗=R¯∗∥S¯∗ decoding to R∗≠⊥ and S∗<p𝖵𝖾𝗌𝗍𝖺. If 𝗋𝗄∗=𝒪, the scalar 𝗋𝗌𝗄∗:=0 satisfies (i), and in (ii) x=−α∗; the reduction outputs these. Let 𝗋𝗄∗≠𝒪. The validation input R¯∗⁢‖𝗋𝗄∗¯‖⁢M∗ is not a programmed entry. Its first 32 bytes, its next 32 bytes and its remainder would otherwise give R¯∗=Ri¯, 𝗋𝗄∗=𝗋𝗄i and M∗=Mi for some i, the second by injectivity of P↦P¯, and the challenge would be ci. Then R∗=Ri, and (4) gives [S∗]⁢G=Ri+[ci]⁢𝗋𝗄i=[Si]⁢G. Since G generates the group, of prime order p𝖵𝖾𝗌𝗍𝖺, and S∗,Si<p𝖵𝖾𝗌𝗍𝖺, this forces S∗=Si, so σ∗=σi and the triple is an oracle answer. The input was queried by 𝒜, except with probability at most 1/p𝖵𝖾𝗌𝗍𝖺: 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 Q/p𝖵𝖾𝗌𝗍𝖺 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 𝔽p𝖵𝖾𝗌𝗍𝖺, Q prepared challenges c1,…,cQ, and coins that include those of 𝒜 and of the simulator. The wrapper answers the j-th distinct unprogrammed query to 𝖧, of 𝒜 or of validation, with a uniform preimage of cj under ToScalar, 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 R¯∗, the same 𝗋𝗄∗, since key prefixing makes 𝗋𝗄∗ part of the critical input, and the same M∗. In (ii) they also share α∗, which 𝗋𝗄∗ determines because G generates the group. The runs receive distinct challenges c≠c′ at the critical index and return responses S∗ and S′⁣∗.

(6) Extraction. The transcripts (R∗,c,S∗) and (R∗,c′,S′⁣∗) are accepting for 𝗋𝗄∗ with c≠c′, so the Crypto Guide’s Theorem “2-special soundness” (§“The Schnorr identification protocol”) gives

𝗋𝗌𝗄∗=(S∗−S′⁣∗)⁢(c−c′)−1,

the discrete logarithm of 𝗋𝗄∗, which is (i). For (ii) the reduction outputs 𝗋𝗌𝗄∗−α∗=x. The probability bound follows as in the cited theorem, from the forking bound

𝑓𝑟𝑘≥𝑎𝑐𝑐⁢(𝑎𝑐𝑐Q−1p𝖵𝖾𝗌𝗍𝖺),

with 𝑎𝑐𝑐 at least ϵ−η less the abort and guessing terms of steps (3) and (4). □

Remark 7.13 (Uses of Proposition 7.12). #

Proposition 7.12 holds for every message: it places no condition on M∗ beyond the freshness of the triple. Theorem 12.9 applies part (i), and Proposition 11.10 applies part (ii) to a signature on a new digest.