]> Google LLC

sgschlesinger@gmail.com

Google LLC

jkcrypto@google.com

Cloudflare, Inc.

armfazh@cloudflare.com

moderation credential credits unlinkability privacy This document specifies EC-ACT, a keyed-verification anonymous credential scheme with a hidden credit balance. A Client spends a public amount and receives a fresh Credential for the remaining balance and a return amount chosen by the Moderator. The Moderator verifies each spend without learning the balance or linking it to issuance or to other spends. EC-ACT uses a pairing-free BBS-style signature and proofs over linear relations. This document defines its cryptographic operations, encodings, and security requirements. The MOLE protocols use EC-ACT as a Credential scheme. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Applications such as MOLE require an updateable state managed by a client but authenticated by a server, with stringent requirements on unlinkability of updates and tests. EC-ACT provides such functionality: a Client holds a balance that is authenticated via signature issued by a Moderator, and can be told to update the balance in a verifiable manner.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The capitalized terms Client, Moderator, and Credential are used as defined in ; a lowercase credential is the generic cryptographic notion. The message-encoding conventions, Python notation, and helpers I2OSP, U16Prefixed, random, and Seed are those of Section 2 of . The algorithms use bytes for byte strings, int for integers, and Sequence and NamedTuple from Python's typing module. Record fields appear in the same order as their tuple representation. The group G, protocol context ctx_proto, seed length Nseed, generators, and balance width L are globals fixed by the EC-ACT configuration (). Shared group methods from use the EC-ACT group instance G, which stores ctx_proto and applies EC-ACT domain separation. Both schemes use Nseed = 48. Public byte-string inputs retain the length bounds specified by the operation that uses them.

Preliminaries This document contains executable Python code to specify much of the protocol. EC-ACT uses three dependencies:

Group:

A prime-order group implementing the interface in . gives concrete instances.

Hash:

A cryptographic hash function, used by the HashToGroup, HashToScalar, and derivation algorithms that the group of provides.

Sigma protocol:

The compact non-interactive Sigma protocol of , instantiated in .

Prime-Order Group EC-ACT uses the prime-order group interface and the Element and Scalar types of Section 3.1 of , instantiated as in . The prime p = G.Order() is the group order and the scalar-field modulus. The Python interface provides G.scalar(x) for an integer x in [0, G.Order()), s.isZero() for a scalar, and A.isIdentity() for an element. Arithmetic combines values of the same type: integer constants are converted with G.scalar before scalar arithmetic. The negative of an element A is G.Identity() - A.

Errors DeserializeError, VerifyError, DeriveError, and ValueError have the meanings given in Section 3.2 of . EC-ACT additionally uses AmountError when a balance or amount is outside the range admitted by : An implementation that raises an error MUST abort the affected protocol run.

Deriving Scalars Use G.DeriveScalars(rand: bytes, info: bytes, count: int) -> list[Scalar] from Section 4.2 of , using the EC-ACT group instance initialized with ctx_proto. It rejects rand whose length is not Nseed with ValueError, and raises DeriveError in the negligible event that a derived scalar is zero. EC-ACT applies the following requirements to this shared algorithm. rand MUST be Nseed bytes of output of random and MUST NOT be used for more than one derivation. An algorithm derives all of its scalars with one call, under an info string that names it. See . For the P256-SHA256 ciphersuite, Ns = 32 bytes is the scalar encoding length, while Nseed = 48 bytes is the seed length. The group order p is a 256-bit prime (2^255 < p < 2^256). The hash-to-scalar method reduces an Ns + 16 = 48-byte string modulo p. If the input string is uniform, the resulting scalar, conditioned on being nonzero, has statistical distance at most 2^-128 from uniform over the nonzero scalars. The 16-byte margin follows the hash-to-field method for a 128-bit security target (). This is a sampling bound for a uniform byte string. It does not establish that the deterministic hash-derived scalars or nonces are uniform. describes their analysis and the remaining proof gaps.

Key Generation Use G.DeriveKeyPair(seed, info) and G.GenerateKeyPair() from Section 4.4 of , with the EC-ACT group instance of . Both return tuple[Scalar, Element]; EC-ACT names the returned keys (skM, pkM) because the Moderator is the issuer. The Moderator publishes G.SerializeElement(pkM) in its configuration.

The Credential Scheme An Anonymous Credit Token is a keyed-verification anonymous credential over a privately verifiable, pairing-free BBS-style signature , whose hidden state is a balance c: a nonnegative integer number of credits. A Moderator issues a Credential with an initial balance of its choosing, and the Client later spends from it. A spend reveals a public amount s and proves, in zero knowledge, that the Credential holds at least s credits. It also reveals a nullifier, which the Moderator checks against its record of accepted spends to enforce single use. In the same exchange the Moderator issues a refund: a message containing a signature, a public return amount t, and a proof of correct signing. The Client combines this message with its saved spend state to finalize a fresh Credential with balance c - s + t. Every spend declares a public top-up allowance a, the maximum permitted increase in the balance. When no top-up is allowed, the spend sets a = 0. The Moderator chooses t with 0 <= t <= s + a, so the balance increases exactly when t > s, by at most a. With a = 0, the return amount is at most s. A presentation hides its Credential's balance beyond the public amounts and the predicates they establish. It is intended to be unlinkable to the issuance or refund that produced that Credential and to other presentations, subject to the assumptions and anonymity-set requirements of . The scheme is a two-party protocol between a Client and a Moderator. The Moderator holds a key pair (skM, pkM) and both issues and verifies Credentials: they are not publicly verifiable, and only the Moderator can check a spend. Each of the two flows, issuance and spending, is a single request/response exchange followed by a Client-local finalization. For spending, both parties know s, the spend amount, a, the top-up allowance, and a spend context ctx_spend that binds the proof to the Moderator's challenge (), typically a collision-resistant digest of the encoded challenge.

Credential issuance and spending overview response = IssueResponse(skM, ctx_cred, c, request) response <-------- credential = FinalizeIssue(pkM, ctx_cred, state, response) Spending inputs at both parties: s, a, ctx_spend state, proof = ProveSpend(credential, ctx_cred, s, a, ctx_spend) proof (includes nullifier k) --------> VerifySpend(skM, ctx_cred, ctx_spend, proof) refund = IssueRefund(skM, ctx_cred, proof, t) Record proof.k atomically, failing if present refund <-------- credential = FinalizeRefund(pkM, ctx_cred, state, refund) ]]>

The Moderator chooses the initial balance c and the return amount t according to its policy; both are outside the scope of this document, as is the nullifier store the Moderator keeps to reject a second spend of the same Credential.

Configuration A ciphersuite () is identified by an ASCII byte string identifier, and both parties MUST agree on it before running the protocol. The Credential scheme is specified for the P-256 ciphersuite of ; its protocol context is bytes: return b"EC-ACTv1-" + identifier ]]> Throughout this section and wherever the algorithms of this section are invoked, ctx_proto denotes this value, and HashToGroup, HashToScalar, G.DeriveScalars, G.DeriveNonces, and the key generation of are parameterized by it. The scheme has one further parameter, the balance width L. Balances and amounts are integers in [0, 2^L). L MUST satisfy 1 <= L <= MAX_BIT_LENGTH, where MAX_BIT_LENGTH is fixed by the ciphersuite. The size of a spend proof and the cost of producing and verifying it grow linearly in L, so a deployment SHOULD choose the smallest L that accommodates its largest balance. The Moderator publishes L together with its public key; a Client MUST use the published value. L is fixed for the lifetime of a key and credential context. shows by induction over issuances and refunds that every balance the Moderator has signed lies below 2^L, assuming one value of L per key and context. A Moderator that changes L MUST also change the credential context or the key. Deployments are RECOMMENDED to include L in the credential context, for instance by appending I2OSP(L, 1) to it, so that changing L changes the context.

Generators The scheme uses the group generator B = G.Generator() and four further elements H1, H2, H3, H4, fixed by the ciphersuite: tuple[Element, Element, Element, Element]: return ( G.HashToGroup(b"GenH1"), G.HashToGroup(b"GenH2"), G.HashToGroup(b"GenH3"), G.HashToGroup(b"GenH4"), ) ]]> H1 commits to the balance, H2 to the nullifier, H3 is the blinding base, and H4 binds the credential context (). The discrete logarithm of any of these elements with respect to any other, or to B, MUST NOT be known to any party; deriving them by hashing fixed labels ensures this. The five elements are pairwise distinct except with negligible probability; an implementation MAY verify this once when instantiating a ciphersuite.

Key Generation A Moderator holds a key pair (skM, pkM), generated with G.GenerateKeyPair of under the protocol context of this section, or derived from a seed with G.DeriveKeyPair. The Moderator publishes SerializeElement(pkM) in its configuration. The signing key skM is also the verification key: VerifySpend requires it.

Credential Context Every Credential is bound at issuance to a credential context ctx_cred, an opaque byte string of at most 2^16 - 1 bytes chosen by the Moderator and agreed with the Client out of band. It restricts when, or under which policy, a Credential may be spent, so that a Moderator can for instance expire all Credentials of an epoch at once without rotating its key. The context is bound as a signed attribute. It is mapped to a scalar and carried under H4: Scalar: return G.HashToScalar( U16Prefixed(ctx_cred) + b"CredentialContext" ) ]]> No message of this document carries the context. Each party supplies it to every algorithm of this section that computes or checks a signature, so a spend verifies only under the context the Credential was issued under. A Client keeps its own copy of the context for as long as it holds the Credential. A Credential presented under a context other than the one it was issued under fails verification; the mismatch is not otherwise signalled. The set of Clients sharing a credential context MUST be coarse; see .

Amounts Balances and amounts are nonnegative integers below 2^L. On the wire they are uint64 values; in the algebra they enter as scalars. G.scalar(x) denotes the Scalar whose integer value is x. The spend range proof shows that a hidden value lies in [0, m] for a public bound m < 2^L. It decomposes the value into bits with the weights returned by RangeWeights(m): the powers of two below the leading power of m, followed by a top weight chosen so that all weights sum to m. Every weight is positive, so a sum of weighted bits lies in [0, m], and every integer in [0, m] is such a sum. Bits(x, weights) returns the bits of x for these weights, least significant first, as scalars each equal to 0 or 1: list[int]: if not 0 <= m < 2**L: raise AmountError n = m.bit_length() if n == 0: return [] return [2**j for j in range(n - 1)] + [m - 2 ** (n - 1) + 1] def Bits(x: int, weights: Sequence[int]) -> list[Scalar]: n = len(weights) if n == 0: return [] top = (x >> (n - 1)) & 1 rest = x - top * weights[n - 1] return [G.scalar((rest >> j) & 1) for j in range(n - 1)] + [ G.scalar(top) ] ]]> For x in [0, m] with m >= 1, x < 2^n where n is the bit length of m, so top is set exactly when x >= 2^(n-1), which is at least the top weight; rest then lies in [0, 2^(n-1)). When m is a power of two minus one, the weights are the powers of two and Bits is the binary decomposition. When m = 0, there are no weights and the value is zero. An implementation MUST compute Bits in constant time with respect to x, which is derived from the Client's hidden balance. The number of weights depends only on m, which is public. A party that receives an amount MUST check that it is below 2^L before using it, and MUST raise an AmountError otherwise. The spend range proof bounds a difference of amounts. The bounds on each amount are needed to interpret this difference over the integers (). The comparisons s <= c and c + a < 2^L in ProveSpend, s + a < 2^L in VerifySpend, t <= s + a in IssueRefund, and t <= s + a and v1 + t < 2^L in FinalizeRefund are integer comparisons. The condition s + a < 2^L is equivalent to 0 <= 2^L - 1 - (s + a); in ProveSpend it follows from the first two comparisons rather than a separate check. Each sum can reach 2^(L+1) - 2, which does not fit in a uint64 when L = 64, and an implementation MUST compute them without overflow.

Zero-Knowledge Proofs Each proof of this document is a compact NARG string () for a linear relation declared where it is used, in the notation of . In a Relation block, the reserved name G denotes the generator B at element index zero. Compact proofs carry a single challenge scalar in place of all per-equation commitments, reducing the size of the spend message. The ciphersuite is sigma-proofs_Shake128_P256 of . Its group is the group of with the same element and scalar encodings, so statement elements are encoded identically in both documents.

Tags Every proof is bound to a tag () built by Tag from a label naming the operation and a possibly empty list of bindings: public byte strings to which the proof must be bound that do not appear in the relation. bytes: tag = ctx_proto + b"-" + label + b"-CMPT-with-" + SIGMA_SUITE for binding in bindings: tag += U16Prefixed(binding) return tag ]]> SIGMA_SUITE is the ciphersuite identifier "sigma-proofs_Shake128_P256". The labels are a fixed set, and each binding is length-prefixed, so distinct inputs yield distinct tags (). Bindings are arbitrary byte strings, not the US-ASCII text that section recommends; the length prefixes keep the tag unambiguous.

Prover Nonces ProveCompact draws one nonce per witness scalar from its rng, in scalar-index order. The rng MUST return, on its i-th call, the value that ProverNonces.random_scalar computes below. The nonces are derived together with G.DeriveNonces (Section 4.3 of ) from the witness, the session, the relation, and fresh randomness; see "Derived prover nonces" in . None: self.nonces = G.DeriveNonces( b"".join(G.SerializeScalar(w) for w in witness), b"nonce", session_id + I2OSP(len(instance), 4) + instance, random(Nseed), len(witness), ) self.count = 0 def random_scalar(self) -> int: i = self.count self.count = i + 1 return int(self.nonces[i]) ]]> witness is the prover's whole witness in scalar-index order; session_id is the 32-byte DeriveSessionID(tag) of ; and instance is the SerializeLinearRelation of the relation (). This rule binds only the prover; a verifier following accepts these proofs unchanged. The derivation is deterministic in the witness, the tag, the relation, and rand: replaying the bytes of random reproduces a proof byte for byte, which the test vectors of rely on, and a random source that repeats all of rand reproduces the same proof. A retried operation draws fresh rand and produces a different proof.

Proving and Verifying A relation is proven and verified as follows, where relation is the declared relation compiled as in , and DeriveSessionID, SerializeLinearRelation, ProveCompact, and VerifyCompact are those of and . bytes: nonces = ProverNonces( witness, DeriveSessionID(tag), SerializeLinearRelation(relation), ) return ProveCompact(tag, relation, witness, nonces) def Verify( tag: bytes, relation: LinearRelation, proof: bytes ) -> bool: return VerifyCompact(tag, relation, proof) ]]>

Issuance Issuance produces a signature on the attributes (c, k, r, ctx), whose group-element encoding is B + c * H1 + k * H2 + r * H3 + ctx * H4. Here c is the balance chosen by the Moderator, ctx is the context scalar, and k and r are chosen by the Client and hidden from the Moderator: IssueResponse -> FinalizeIssue ]]> IssueRequest and FinalizeIssue are run by the Client, and IssueResponse by the Moderator. The Python records are:

Signing Exponent IssueResponse here and IssueRefund () choose the exponent e of the signature (A, e). It is derived with G.DeriveNonces (Section 4.3 of ) from the signing key, the group-element encoding of the signed attributes, and fresh randomness. Repeating these inputs reproduces the same signature. Changing the signed encoding changes the derivation input even when the random source repeats (). Scalar: instance = U16Prefixed(label) + U16Prefixed( G.SerializeElement(X_A) ) (e,) = G.DeriveNonces( G.SerializeScalar(skM), b"e", instance, random(Nseed), 1 ) if (e + skM).isZero(): raise DeriveError return e ]]> label is IssueResponse or Refund, the tag label of the accompanying proof, and X_A is the group-element encoding being signed. The abort when e + skM is zero has probability about 1/p; a caller that retries draws fresh randomness.

Issuance Request The Client commits to a fresh nullifier k and blinding factor r, and proves that it knows the opening: ( tuple[ClientIssuanceState, IssueRequestMessage] ): rand = random(Nseed) (k, r) = G.DeriveScalars(rand, b"IssueRequest", 2) K = k * H2 + r * H3 tag = Tag(b"IssueRequest", []) pok = Prove(tag, CommitmentRelation(K), [k, r]) return ClientIssuanceState(k, r, K), IssueRequestMessage(K, pok) ]]> The nullifier k is revealed when the Credential is spent, and the Moderator uses it to reject a second spend. A Client MUST NOT reuse it across Credentials, and MUST NOT finalize one state against two responses: the two Credentials would share k, and at most one of them can be spent ().

Issuance Response The Moderator checks the request, chooses the balance c, and signs the encoding X_A = B + c * H1 + ctx * H4 + K as A = X_A / (e + skM). It proves that A is such a signature under pkM without revealing skM, with the witness x = e + skM and X_G = x * B, which the Client computes as e * B + pkM: IssueResponseMessage: K, pok = request if not 0 <= c < 2**L: raise AmountError tag = Tag(b"IssueRequest", []) if not Verify(tag, CommitmentRelation(K), pok): raise VerifyError ctx = CreateContextScalar(ctx_cred) X_A = B + G.scalar(c) * H1 + ctx * H4 + K e = SigningExponent(skM, b"IssueResponse", X_A) x = e + skM A = G.ScalarInverse(x) * X_A X_G = G.ScalarMultGen(x) tag = Tag(b"IssueResponse", []) pok = Prove(tag, SignatureRelation(A, X_A, X_G), [x]) return IssueResponseMessage(A, e, c, pok) ]]> The check c < 2^L bounds every issued balance; the soundness of spending relies on it ().

Issuance Finalization The Client checks the response and assembles the Credential. Credential: k, r, K = state A, e, c, pok = response if not 0 <= c < 2**L: raise AmountError ctx = CreateContextScalar(ctx_cred) X_A = B + G.scalar(c) * H1 + ctx * H4 + K X_G = G.ScalarMultGen(e) + pkM tag = Tag(b"IssueResponse", []) if not Verify(tag, SignatureRelation(A, X_A, X_G), pok): raise VerifyError return Credential(k, c, r, A, e) ]]> A Credential is the tuple (k, c, r, A, e); its encoding, for storage, is given in . It is never sent. The Client also retains ctx_cred, which is not part of the Credential but is needed to spend it.

Spending Spending consumes a Credential with balance c and produces one with balance c - s + t. The amount s and the top-up allowance a are chosen by the Client to match the Moderator's challenge; the return amount t, with 0 <= t <= s + a, is chosen by the Moderator. With s = a = 0 a spend changes nothing but the nullifier and refreshes the Credential. Spending consists of four algorithms: VerifySpend -> IssueRefund -> FinalizeRefund ]]> ProveSpend and FinalizeRefund are run by the Client; VerifySpend and IssueRefund by the Moderator, in that order and only if VerifySpend succeeds. A spend is bound to a spend context ctx_spend, an opaque byte string of at most 2^16 - 1 bytes supplied by the verifier and known to the Client. The spend proof uses Tag(b"Spend", [ctx_spend]), with ctx_spend as its sole binding (). ctx_spend is typically a collision-resistant digest, such as SHA-256, of the challenge that triggered the presentation, so that a spend proof produced for one challenge does not verify under another. The top-up allowance is bound by the relation: a proof produced for one value of a does not verify under another, so a Moderator authorizes a top-up by verifying the proof with the value it accepts, and a Moderator that offers none MUST reject a spend with a != 0. The Python records for spending are: An absent Com_c is None.

The Spend Relation A spend shows that the remainder v1 = c - s of the hidden balance c satisfies The lower bound shows that the Credential covers the spend, and the upper bound that the topped-up balance c + a = s + v1 + a is below 2^L, so the Moderator may choose a return amount t <= s + a without the resulting balance exceeding 2^L - 1. A single range proof over the bits of v1, weighted by w = RangeWeights(m) (), shows both. A spend with s + a >= 2^L cannot satisfy them and is rejected with an AmountError. The number n = len(w) of bit commitments is the bit length of m and is fixed by the public amounts. A refresh, with s = a = 0, needs no range proof: the remainder is the balance c, whose range follows from issuance and prior refunds (). It commits to c in a single commitment Com_c instead. The relation therefore has two shapes, selected by whether s + a is zero; a group marked with a condition below is present exactly when it holds. 0) Com1[0], ..., Com1[n-1], (s + a > 0) Com_c): (s + a = 0) Witness: e, r2, r3, c, r, kstar, rn, b1[0], ..., b1[n-1], s1[0], ..., s1[n-1], u1[0], ..., u1[n-1], (s + a > 0) rc (s + a = 0) Equations: A_bar = -e * A_prime + r2 * B_bar H1_prime = r3 * B_bar - c * H1 - r * H3 K_n = kstar * H2 + rn * H3 for j in 0, ..., n-1: (s + a > 0) Com1[j] = b1[j] * H1 + s1[j] * H3 Com1[j] = b1[j] * Com1[j] + u1[j] * H3 K_n + s * H1 + sum_j w[j] * Com1[j] = c * H1 + kstar * H2 + rn * H3 + sum_j w[j] * s1[j] * H3 (s + a > 0) Com_c = c * H1 + rc * H3 (s + a = 0) ]]> The first equation states that A_prime is a rerandomization of a signature under skM, since the verifier computes A_bar = skM * A_prime. The second opens the signed encoding to the hidden balance c and blinding factor r, relative to the public H1_prime, which fixes the nullifier k and the context. The third opens K_n to the next nullifier and so shows that K_n has no H1 component, which would otherwise raise the balance the refund signs. Each pair of bit equations is the Bit relation of , with u1[j] = (1 - b1[j]) * s1[j] for an honest prover. The sum equation ties the committed bits to the balance: given the third equation, its left-hand side opens under H1 to s + v1 with v1 = sum_j w[j] * b1[j], so c = s + v1 with 0 <= v1 <= m. Its left-hand side is s * H1 + K_prime, with K_prime the commitment the refund signs (); including K_n keeps it from being the identity element when s = 0 and m = 0, which would reject. The weights are public scalars of the relation, computed by both parties from s and a. In a refresh, Com_c opens to c directly. The witness scalars are supplied in the order listed.

Spend Proof Generation The Client rerandomizes its signature, commits to the next nullifier and to the remainder, and proves the spend relation. tuple[ClientSpendState, SpendMessage]: k, c, r, A, e = credential if not (0 <= s < 2**L and 0 <= a < 2**L): raise AmountError if s > c or c + a >= 2**L: raise AmountError v1 = c - s w = RangeWeights(2**L - 1 - (s + a)) if s + a > 0 else [] n = len(w) ctx = CreateContextScalar(ctx_cred) # Four fixed scalars, then one for each bit of the remainder or # one for the commitment of a refresh. count = 4 + (n if s + a > 0 else 1) derived = G.DeriveScalars(random(Nseed), b"ProveSpend", count) (r1, r2, kstar, rn) = derived[:4] # Rerandomize the signature. B_msg = B + G.scalar(c) * H1 + k * H2 + r * H3 + ctx * H4 A_prime = (r1 * r2) * A B_bar = r1 * B_msg r3 = G.ScalarInverse(r1) A_bar = r2 * B_bar - e * A_prime # Commit to the next Credential's nullifier. K_n = kstar * H2 + rn * H3 Com1: list[Element] = [] Com_c: Element | None = None witness = [e, r2, r3, G.scalar(c), r, kstar, rn] # Commit to the remainder: bitwise when it must be shown to be in # range, in one commitment when it is the balance of a refresh. if s + a > 0: b1 = Bits(v1, w) s1 = derived[4:] Com1 = [b1[j] * H1 + s1[j] * H3 for j in range(n)] u1 = [(G.scalar(1) - b1[j]) * s1[j] for j in range(n)] r_star = rn for j in range(n): r_star = r_star + G.scalar(w[j]) * s1[j] witness += b1 + s1 + u1 else: rc = derived[4] Com_c = G.scalar(c) * H1 + rc * H3 r_star = rn + rc witness += [rc] H1_prime = B + k * H2 + ctx * H4 relation = SpendRelation( A_prime, B_bar, A_bar, H1_prime, K_n, s, a, Com1, Com_c ) pok = Prove(Tag(b"Spend", [ctx_spend]), relation, witness) # The commitment the refund will sign, opened by the new # Credential's secrets; the Moderator recomputes it from `proof`. K_prime = G.scalar(v1) * H1 + kstar * H2 + r_star * H3 state = ClientSpendState(kstar, r_star, v1, s, a, K_prime) proof = SpendMessage( k, s, a, A_prime, B_bar, K_n, Com1, Com_c, pok ) return state, proof ]]> A_bar is not sent: the Moderator computes it as skM * A_prime. The values kstar and r_star are the nullifier and blinding factor of the Credential the refund will produce. They open K_prime, which equals K_n + V1 with V1 the balance commitment of BalanceCommitment below; the Moderator recomputes it from proof and signs it in IssueRefund, and the Client keeps it in state to check the refund. ProveSpend consumes the Credential: an implementation MUST NOT allow a second call on the same Credential value. The Client MUST treat the Credential as spent, and MUST have stored state durably, no later than the moment proof becomes observable outside the Client; the refund is unusable without the state, and a second proof from the same Credential reveals the same nullifier (). state holds everything FinalizeRefund needs. The Client additionally retains proof for refund recovery.

Spend Verification The Moderator checks the spend proof under its own key and contexts. None: k, s, a, A_prime, B_bar, K_n, Com1, Com_c, pok = proof if not (0 <= s < 2**L and 0 <= a < 2**L): raise AmountError if s + a >= 2**L: raise AmountError ctx = CreateContextScalar(ctx_cred) A_bar = skM * A_prime H1_prime = B + k * H2 + ctx * H4 relation = SpendRelation( A_prime, B_bar, A_bar, H1_prime, K_n, s, a, Com1, Com_c ) if not Verify(Tag(b"Spend", [ctx_spend]), relation, pok): raise VerifyError ]]> The shape of proof is fixed by s and a (): Com_c is present exactly when s + a = 0, and otherwise Com1 holds one commitment per weight of RangeWeights(2^L - 1 - (s + a)); a message of any other shape is rejected at deserialization, and SpendRelation raises a VerifyError on one. The amount checks of precede verification (). VerifySpend does not check whether k has been seen before, nor whether the Moderator is willing to grant the top-up a. The Moderator MUST do both. It MUST record k atomically, failing if k is already recorded, and MUST NOT accept the spend or release a refund unless k was recorded.

Refund Issuance After a successful VerifySpend, the Moderator signs the remainder plus its chosen return amount, proving the Signature relation under the Refund tag. Element: k, s, a, A_prime, B_bar, K_n, Com1, Com_c, pok = proof if s + a > 0: w = RangeWeights(2**L - 1 - (s + a)) if len(Com1) != len(w): raise VerifyError V1 = G.Identity() for j in range(len(w)): V1 = V1 + G.scalar(w[j]) * Com1[j] else: if Com_c is None: raise VerifyError V1 = Com_c return K_n + V1 def IssueRefund( skM: Scalar, ctx_cred: bytes, proof: SpendMessage, t: int ) -> RefundMessage: k, s, a, A_prime, B_bar, K_n, Com1, Com_c, pok = proof if not 0 <= t < 2**L or t > s + a: raise AmountError ctx = CreateContextScalar(ctx_cred) K_prime = BalanceCommitment(proof) X_A = B + K_prime + G.scalar(t) * H1 + ctx * H4 e = SigningExponent(skM, b"Refund", X_A) x = e + skM A = G.ScalarInverse(x) * X_A X_G = G.ScalarMultGen(x) tag = Tag(b"Refund", []) pok = Prove(tag, SignatureRelation(A, X_A, X_G), [x]) return RefundMessage(A, e, t, pok) ]]> The comparison t <= s + a is between integers (). This bound keeps the new balance below 2^L without a range proof over the refund (). The Moderator places the new balance anywhere in [c - s, c + a] without learning where in that interval it falls.

Refund Finalization The Client checks the refund and assembles its new Credential. Credential: kstar, r_star, v1, s, a, K_prime = state A, e, t, pok = refund if not 0 <= t < 2**L or t > s + a or v1 + t >= 2**L: raise AmountError ctx = CreateContextScalar(ctx_cred) X_A = B + K_prime + G.scalar(t) * H1 + ctx * H4 X_G = G.ScalarMultGen(e) + pkM tag = Tag(b"Refund", []) if not Verify(tag, SignatureRelation(A, X_A, X_G), pok): raise VerifyError return Credential(kstar, v1 + t, r_star, A, e) ]]> A refund issued for a different spend signs a different K_prime and fails verification. FinalizeRefund consumes state: a Client MUST NOT finalize one spend state against two refunds, since the two Credentials would share the nullifier kstar. The Client MUST NOT spend the consumed Credential again, whether or not the refund arrives. A Client that has sent a spend proof and not received a valid refund keeps state and MAY ask the Moderator for the refund again, and the Moderator recognizes the request by the recorded nullifier k. The Moderator can answer with the refund it issued, which requires storing it with the nullifier, or run IssueRefund again. The latter produces a second signature under a different exponent; this is harmless, because every refund of one spend carries the nullifier kstar, so at most one of them can ever be spent ().

Encodings This section gives the encoding of the four messages exchanged and of the Credential the Client stores. Element and Scalar are the fixed-length encodings of SerializeElement and SerializeScalar, of Ne and Ns bytes. A recipient MUST deserialize every received Element and Scalar and MUST raise a DeserializeError if deserialization fails, which in particular rejects the identity element. Amounts are uint64 values, checked against 2^L as requires. Every pok field is a compact NARG string () of (Nw + 1) * Ns bytes, where Nw is the number of witness scalars of its relation: 2 for the request, 1 for the response and the refund, and for the spend 0 else 1), where n = len(RangeWeights(2^L - 1 - (s + a))) ]]> A recipient MUST reject a message whose pok has any other length, and MUST reject a SpendMessage whose shape does not match its s and a. A recipient of a SpendMessage MUST raise an AmountError if s + a >= 2^L, before computing n. Rejecting the identity element at deserialization keeps every relation of this document valid (). The Client opens issuance with its commitment: The Moderator answers with the signature and the balance it chose: The Client spends with a proof whose shape follows its two amounts, as above. The select clause distinguishes a refresh from other spends: The Moderator answers a valid spend with the refund: Neither context appears in these messages; both are inputs held by each party (, ). The Credential is held by the Client and never sent: With Ne = 33 and Ns = 32, the request is 129 bytes and the response and refund are 137 bytes each. The spend message is 468 bytes for a refresh (s = a = 0) and otherwise 129 * n + 403 bytes, at most 129 * L + 403, with n = L whenever s + a < 2^(L-1). The spend message dominates and is linear in L; asks deployments to keep L small for this reason.

Ciphersuites A ciphersuite fixes the group, hash functions, encodings, and domain separation tags. Both parties MUST agree on the ciphersuite as specified in . ctx_proto is as computed in . The seed length, that of the random input to every derivation, is Nseed = 48 bytes. EC-ACTv1 is specified against the -03 revisions of and . A later revision that changes the NARG string or its derivation MUST be adopted under a new ciphersuite identifier, and so a new ctx_proto; EC-ACTv1-P256-SHA256 then never denotes two transcript formats.

EC-ACT(P-256, SHA-256) This ciphersuite uses P-256 (secp256r1) for the group and SHA-256 for the hash function. The value of the ciphersuite identifier is b"P256-SHA256". Use the P-256 group, SHA-256 hash, hash-to-curve and hash-to-scalar algorithms, and canonical encodings of Section 7.1 of . EC-ACT uses Ne = 33, Ns = 32, and Nseed = 48. Instantiate every hash with the EC-ACT ctx_proto of , including the explicit DSTs of G.DeriveScalars, G.ExpandScalars, G.DeriveNonces, and G.DeriveKeyPair. For this ciphersuite MAX_BIT_LENGTH = 64, which allows amounts to be carried as uint64 values and keeps 2^(L+1) far below the group order ().

Randomness Every random value in this document is drawn with random and consumed in inputs of Nseed bytes, by G.DeriveScalars (), by G.DeriveKeyPair () for a key, or, for the values listed below, by G.DeriveNonces (Section 4.3 of ); no scalar is sampled directly. Implementations MUST draw with a cryptographically secure random number generator and MUST NOT reuse randomness across derivations. Randomness is as sensitive as the values derived from it, and the constant-time requirement of covers both. The following values MUST be derived with G.DeriveNonces, with the inputs stated where they are used; drawing them directly is not conformant:

• the Moderator's signing exponent e in IssueResponse and IssueRefund, through SigningExponent ();
• every nonce of a ProveCompact prover of the Credential scheme, through ProverNonces ().

The Client's k, r, r1, r2, kstar, rn, rc, and s1 are derived with G.DeriveScalars from randomness alone; a repetition among them harms only that Client. The signing exponent and the prover nonces are also derived from a secret, because a repeated signing exponent, or a prover nonce repeated under a different challenge, can compromise skM or reveal a witness scalar ().

Security Considerations The Credential scheme is a keyed-verification anonymous credential over the pairing-free BBS-style signature of as analysed by , with the balance, the nullifier, the blinding factor, and the context scalar as the signed attributes. Because the Moderator is both issuer and verifier and there is no pairing, the scheme is an algebraic MAC in the sense of , of the shape introduced as MAC_BB by .

Assumptions:

Credit conservation rests on the q-SDH assumption in G, for the unforgeability of the signature ; on no party knowing a nontrivial linear relation among B, H1, H2, H3, and H4, which the hash-to-curve derivation of provides in the random oracle model; and on the random oracle model for HashToGroup, HashToScalar, and the Fiat-Shamir transform of , with the special soundness of the relations of . The reduction is expected to follow that of in the algebraic group model with a programmable random oracle: the keyed-verification oracle is answered from the adversary's algebraic representations, since skM * B, skM * H_i, and skM * A_j are all computable by the reduction, and the derived signing exponents are programmed. covers the keyed-verification setting for the underlying MAC.

The credit-conservation reduction and the statistical unlinkability argument for the idealized scheme remain to be written out. Bounds for the concrete scalar and nonce derivations in the random oracle model, and unlinkability against quantum random-oracle queries, also remain open. The arguments below describe the intended guarantees and proof strategy.

Credit conservation:

Fix a Moderator key, a credential context, and a balance width L. For any sequence of presentations the Moderator accepts, with amounts s_i and return amounts t_i, and any set of issuances with balances c_j, except with negligible probability, for an adversary controlling every Client, provided the nullifier store (see "Nullifier store" below) rejects a repeated nullifier. The right-hand side is under the Moderator's control. The property rests on the following:

• an accepted spend proof yields, by special soundness, a signature under skM on (c, k, r, ctx);
• every such signature was produced by IssueResponse or IssueRefund, whose signing oracles are constrained by the proofs they verify, or q-SDH is broken;
• the balance constraints of hold over the integers ("Amount validation" below), so the refund Credential has balance exactly c - s + t; and
• a recorded nullifier is never counted twice.

Unlinkability:

The intended property is that a spend hides which issuance or refund produced its Credential, and the balance beyond the public amounts and predicates, from a Moderator that sees every message and holds skM. The idealized argument uses independent uniform blinding scalars and prover nonces: the commitments K, K_n, and the bit commitments are hiding , the pair (A_prime, B_bar) rerandomizes the signature , and the proofs are statistically zero-knowledge in the random oracle model (). This idealized argument does not rely on the hardness of discrete logarithms. For the specified hash-derived scalars and nonces, we are assuming the security of Hash based pseudorandom generators in addition. The proof strategy replaces the derived vectors by independent random scalars, with a loss accounting for scalar-reduction bias, collisions, and queries to secret derivation inputs (Section 4.2 of ). Concrete bounds for this replacement and its composition with the proofs remain to be established. The public amounts s, a, and t, and the configuration, determine which Credentials could have produced a presentation; states the anonymity-set requirements.

Quantum adversaries:

A quantum computer capable of solving discrete logarithms in G can recover skM from pkM and forge tokens. The unlinkability of recorded transcripts under the specified hash-derived randomness requires an analysis in the quantum random oracle model. This analysis remains open for this construction.

Amount validation:

The spend relation constrains c, s, a, and v1 only modulo p: the bit equations show that v1 = sum_j w[j] * b1[j] lies in [0, m] as an integer, since every weight is positive and the weights sum to m = 2^L - 1 - (s + a), while c = s + v1 holds in the scalar field. For this to hold over the integers, s and a must be small, and they are small only if the Moderator checks them, so VerifySpend MUST raise AmountError on either being >= 2^L, or on s + a >= 2^L, before verifying the proof. With those checks, s + v1 + a <= 2^L - 1 < p, which MAX_BIT_LENGTH = 64 guarantees, so the relation cannot wrap: the balance c equals s + v1 as an integer and c + a < 2^L. A refresh has no range proof and relies on c < 2^L by induction: IssueResponse rejects c >= 2^L, and a refund produces v1 + t <= c + a, which is c for a refresh and was proved below 2^L otherwise. The same reasoning requires t <= s + a in IssueRefund, which keeps every balance below 2^L without a range proof over the refund.

Randomness reuse:

A repeated nonce in the IssueResponse or Refund proof reveals skM, and a repeated signing exponent e under one context lets a Client holding two Credentials with that exponent forge Credentials at any balance below 2^L, each with a fresh nullifier, which the nullifier store cannot detect. Both values are therefore derived with G.DeriveNonces (Section 4.3 of ) from the key and the operation (, ), so that a rolled back or snapshotted random source reproduces an earlier response instead of yielding a second one. An implementation that draws either value directly MUST treat every repetition as a compromise of skM.

Identity elements:

Deserialization rejects the identity element (), and the verifier of rejects an instance that contains one. The check is soundness-critical for A_prime: were it the identity, A_bar would be too, the first spend equation would hold with r2 = 0, and the second would let a prover present B_bar as a blinding of any message of its choosing, at any balance, without holding a signature. An implementation whose group library accepts an encoding of the identity must perform the rejection itself.

Nullifier store:

The Moderator MUST check the nullifier of a spend against a permanent record and add it to the record atomically, so that a spend is either fully processed or not at all. Losing the record re-admits every Credential spent while it was in effect; the record covers at least the lifetime of the credential context it was recorded under.

Single use of Credentials and states:

A Client MUST treat a Credential as spent, and MUST have stored the returned state durably, no later than the moment the spend proof becomes observable outside the Client, and MUST NOT run ProveSpend on it again, whether or not the refund arrives. An implementation MUST have ProveSpend consume the Credential value, FinalizeIssue consume the issuance state, and FinalizeRefund consume the spend state, so that no process can use any of them twice; a Credential or state restored from a backup after use is the wallet's responsibility. A second spend of the same Credential presents the same nullifier, which the Moderator rejects, and links the two presentations to each other; one issuance state finalized against two responses, or one spend state against two refunds, yields Credentials that share a nullifier, of which at most one can ever be spent. A Client that loses the spend state after the Moderator has recorded the nullifier loses the balance.

Constant time:

Bits, every operation on the witness of the spend relation, and every operation on the Client's randomness and the scalars derived from it MUST be implemented in constant time with respect to those secrets (). The bit equations are linear in the bits, so nothing is selected by a bit's value. On the Moderator, skM * A_prime in VerifySpend and the inversion of e + skM and the multiplications by x in IssueResponse and IssueRefund operate on the signing key with inputs the Client chooses, and MUST be constant time with respect to skM; A_bar then enters the verification through a group element rather than a scalar, which addresses for keyed-verification credentials.

Derived prover nonces:

ProverNonces derives the nonces of a proof together with G.DeriveNonces (Section 4.3 of ) from the witness, the session, the relation, and Nseed bytes of fresh randomness. Its security analysis must establish that the nonce vector is indistinguishable from fresh uniform randomness to parties without the witness, as required by . This requires bounds on oracle queries and collisions, as well as the accumulated scalar-reduction bias of . If the random source fails independently of the witness, the argument additionally requires sufficient entropy in the witness that is unknown to the adversary.

Verification key secrecy:

VerifySpend requires skM, so a Credential can be verified only by the Moderator that issued it. A Moderator that shares skM with another party lets that party issue Credentials in its name.

Context granularity:

The credential context is visible at every spend through the fact that the proof verifies under it, and so partitions Clients into the set sharing its value. It MUST be coarse: every Client issued under a given context MUST derive the byte-identical ctx_cred. The spend context does not partition Clients, since it binds a single presentation to a single challenge.

Balance width:

L is public and identical for all Clients of a Moderator, and fixed for the lifetime of a key and context (). A Moderator that used different values of L for different Clients would partition them by the length of their spend proofs, and one that changed L under a key and context with outstanding Credentials would invalidate the balance invariant of the conservation argument.

System requirements:

The requirements on deployments are those of "Nullifier store", "Context granularity", and "Single use of Credentials and states" above, consistent configuration across Clients (), and the randomness requirements of .

IANA Considerations This document has no IANA actions.

References Normative References Google LLC Mozilla Cloudflare Moderation of unLinkable Endorsements (MOLE) is an architecture that lets a party performing access control (a Moderator) bootstrap trust in a client from a third party (an Anchor) that already has a trust relationship with that client, and then adjust that trust over time in response to the client's behaviour, for example by dynamically rate-limiting access. MOLE targets open deployments, in which independent parties may be responsible for access control and for vouching for clients, whilst maintaining strong privacy protections for clients. These protections are designed to hold even if participants in the ecosystem collude or otherwise misbehave. This document specifies the roles, the information flows between them, the privacy and security requirements, and deployment considerations. CNRS Apple, Inc. This document describes Sigma Protocols for proving knowledge of preimages of linear maps in prime-order elliptic curve groups. These are sometimes also called _Maurer Proofs_, or _proofs of knowledge of a preimage of a group homomorphism_. Examples include zero-knowledge proofs for discrete logarithm relations, ElGamal encryptions, Pedersen commitments, and range proofs. CNRS This document describes the Fiat-Shamir transformation, which allows making a public-coin protocol non-interactive by means of a cryptographic hash function. It specifies how the hash function is employed, how prover messages are encoded as hash-function input, and how verifier messages are decoded from the hash function's output, as well as the serialization and deserialization of the non-interactive argument string. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

Test Vectors The vectors below cover the Credential scheme under the P256-SHA256 ciphersuite at L = 4: the generators of , CreateContextScalar, one key pair, one issuance, and a chain of four spends with their refunds, one for each pair of zero and nonzero amounts s and a (). Byte strings are in hexadecimal, wrapped at 64 digits with the continuation lines indented; amounts and L are decimal. Every algorithm is a deterministic function of the bytes it draws from random. Each rand entry is the concatenation of every random call the algorithm makes, in the order made, including those of SigningExponent and ProverNonces; an implementation replays a vector by serving those bytes in place of random. The order is: for G.GenerateKeyPair, the key seed; for IssueRequest, the Nseed bytes of k and r, then the prover's Nseed bytes; for IssueResponse and IssueRefund, the Nseed bytes of e, then the prover's Nseed bytes; for ProveSpend, the Nseed bytes of its scalars, then the prover's Nseed bytes. The state entries are the ClientIssuanceState (k, r, K) as SerializeScalar(k) || SerializeScalar(r) || SerializeElement(K), and the ClientSpendState (kstar, r_star, v1, s, a, K_prime) as SerializeScalar(kstar) || SerializeScalar(r_star) || I2OSP(v1, 8) || I2OSP(s, 8) || I2OSP(a, 8) || SerializeElement(K_prime). Every message and credential entry is the encoding of , and the spend context of every spend is ctx_spend.

Ciphersuite

Key Pair

Issuance

Spend 1: ordinary spend (s = 3, a = 0)

Spend 2: refresh (s = 0, a = 0)

Spend 3: pure top-up (s = 0, a = 2)

Spend 4: spend with top-up (s = 3, a = 2)

Acknowledgments The authors thank Watson Ladd for the single range proof construction, and Christopher Patton and Thibault Meunier for review and improvements to the protocol description.

Changelog draft-schlesinger-mole-ec-act-00

• Initial version.