]> Google LLC

sgschlesinger@gmail.com

Akamai Technologies

watsonbladd@gmail.com

Georgia Institute of Technology

dmohan@gatech.edu

moderation endorsement unlinkability privacy This document specifies EC-IHAT, a cryptographic construction used to produce and consume MOLE Endorsements. An Endorsement is an anonymous token that an Anchor issues to a Client, and that the Client later redeems at a Moderator without the Anchor being able to link the redemption to the issuance. This document defines the endorsement issuance protocol, built from a pairing-free partially blind signature scheme, together with the group, encoding, and context-binding rules that both the Anchor and the Client follow. 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 MOLE Endorsements have a number of constraints imposed by the architecture . They must be unlinkable by the Anchor that issued them, they must be publicly verifiable, and a redemption must hide which Anchor issued the Endorsement among the set of Anchors a Moderator accepts. Existing systems do not meet all of these needs. This document defines such a system, EC-IHAT, an Issuer-Hiding Anonymous Token (IHAT). EC-IHAT follows the construction described in Section 3.4 of , which in turn is based on the pairing-free partially blind signature of . An Anchor holds a signing key and issues, in three moves, a signature on a Client-chosen message that the Anchor never sees. Each Endorsement is also bound at issuance time to two contexts. These may be used to limit the validity scope of each Endorsement, i.e., when and for whom it may later be used:

• The issuance context ctx_iss is agreed out of band among the Client, the Anchor, and the Moderator. ctx_iss can encode, for instance, the time period in which the Endorsement is issued, ensuring Endorsements expire.
• The redemption context ctx_red is agreed out of band between the Client and the Moderator. For example, it may be a long-term identity of the target Moderator. This may be used to prevent Endorsement reuse across Moderators without requiring a synchronized state between them.

The remainder of this document is organized as follows. After defining conventions and cryptographic preliminaries (), we given an overview of issuance and specify some functionalities common to issuance and redemption . specifies the issuance flow, including message encodings and session handling. specifies issuer-hiding redemption, including key rerandomization and the proof that the issuing Anchor belongs to the Moderator's Anchor Set. defines the supported ciphersuites, and discusses the construction's security and deployment considerations. covers IANA considerations, and provides test vectors for the ciphersuites defined here.

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 terms Client, Anchor, Moderator, Endorsement, Credential, and Anchor Set are used as defined in . Unless otherwise specified, this document encodes protocol messages in TLS notation (). Moreover, all constants are in network byte order. For variable-size vectors written <V>, the length prefix is a variable-length integer (), whose width depends on the length of the contents it carries. The minimum-size encoding is recommended. Algorithms are specified in Python and use the following functions, types, and notation. Type bytes is used for byte strings, int for integers, and Sequence for a read-only sequence. For any byte string x, len(x) denotes its length in bytes. For two byte strings x and y, x + y denotes their concatenation, and, if they are of equal length, _xor(x, y) denotes their bytewise exclusive or. For a byte string x, x[i:j] denotes the substring of x that begins at its byte with index i and ends just before its byte with index j, where indices start at zero. Its length is j - i bytes. For a list x, x[i] denotes its element at index i, counting from zero, x[i:j] denotes the sublist from index i up to but not including index j, and len(x) denotes the number of elements it holds. I2OSP(value, length) converts a nonnegative integer into a byte string of the requested length in big-endian byte order, as described in . We write U16Prefixed(value) for the concatenation of I2OSP(len(value), 2) and byte string value. random(n) returns n uniformly random bytes. Implementations MUST generate them with a cryptographically secure random number generator. It is the only source of randomness in this document: every other value that has to be unpredictable is derived from its output (). Seed(x, k) denotes the k-th seed in a byte string of concatenated seeds, that is x[k * Nseed:(k + 1) * Nseed], with k counted from zero. fixes the seed length Nseed. This function is defined as follows: bytes: return value[index * Nseed : (index + 1) * Nseed] ]]> Byte strings such as b"Challenge" contain the corresponding ASCII bytes and do not include a terminating NUL byte. The definitions of the record types named in function signatures are implicit. Parameters become constant values once the ciphersuite is fixed. An algorithm that can fail raises an error; the errors used in this document are listed in .

Preliminaries The construction has two dependencies:

Group:

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

Hash:

A cryptographic hash function whose output length is Nh bytes.

Prime-Order Group This document uses an additive, prime-order group, denoted G, of order p, as described in . The types Element and Scalar denote elements of the group and of its scalar field respectively. Group elements are added with + and subtracted with -; scalar multiplication of an Element A by a Scalar r is written r * A. Scalars are added, subtracted, and multiplied modulo p. In the Python snippets, G.scalar(x) converts an integer x in [0, p) to a Scalar. The group also provides G.DeriveScalars, G.ExpandScalars, G.DeriveNonces, G.DeriveKeyPair, and G.GenerateKeyPair, defined in , , and . The following member functions are used. Except where noted, they are as defined in .

Order():

Outputs the order p of the group.

Identity():

Outputs the identity element of the group.

Generator():

Outputs the generator element B of the group.

ScalarMultGen(r):

Outputs r * B, where B is the group generator.

HashToGroup(x, DST):

Deterministically maps a byte string x to an Element, using the byte string DST as the domain separation tag. The map is specified in .

HashToGroup(x):

Equivalent to HashToGroup(x, DST=b"HashToGroup-" + ctx_proto) where ctx_proto is as defined in .

HashToScalar(x, DST):

Deterministically maps a byte string x to a Scalar, using the byte string DST as the domain separation tag. The map is specified in .

HashToScalar(x):

Equivalent to HashToScalar(x, DST=b"HashToScalar-" + ctx_proto) where ctx_proto is as defined in .

ScalarInverse(s):

Outputs the multiplicative inverse of the nonzero Scalar s modulo p.

SerializeElement(A):

Maps an Element A other than the identity element to a canonical byte string of fixed length Ne. Raises a ValueError if A is the identity element, which has no such encoding.

DeserializeElement(buf):

Attempts to map a byte string buf to an Element. Raises a DeserializeError if buf is not the canonical encoding of a group element, or if it encodes the identity element.

SerializeScalar(s):

Maps a Scalar s to a canonical byte string of fixed length Ns.

DeserializeScalar(buf):

Attempts to map a byte string buf to a Scalar. Raises a DeserializeError if buf does not encode a Scalar in the range [0, p-1].

This document does not use the RandomScalar() member of . Every scalar that has to be unpredictable is instead obtained from G.DeriveScalars (), G.DeriveNonces (), or G.DeriveKeyPair (), each deterministic in its random input. Each algorithm is therefore a deterministic function of its random input, which the test vectors of fix.

Errors The following errors are used.

DeserializeError:

A byte string is not a canonical encoding of the expected type.

VerifyError:

A received value failed a verification check.

DeriveError:

A deterministic derivation failed to produce a usable scalar. See .

ValueError:

An input has an invalid length or is outside its permitted range.

An implementation that raises an error MUST abort the protocol run. Errors are fatal to the affected session; see .

The Endorsement Scheme Issuance is a three-move protocol between a Client and an Anchor, followed by a local finalization step at the Client. The Anchor moves first and holds per-session state between its two moves, as shown in . The Anchor speaks first. This document does not prescribe how the three messages are carried, nor how a Client that wants an Endorsement reaches an Anchor in the first place; both are the business of the transport, and a Client will in general have to signal its intent by some means that carries no protocol data. For example, over HTTP a Client might ask for issuance in a request that names how many Endorsements it wants, receive the commitments in the response, send the challenges in a second request, and receive the responses in the reply to that. specifies the encoding of the three messages. Neither context is carried in these messages. Both parties already hold the issuance context, having agreed on it out of band; the redemption context is known only to the Client and Moderator. The Client's output is an Endorsement that is publicly verifiable under the Anchor's public key pkA (). The Anchor learns neither the nullifier nor the redemption context bound into it, and cannot link the Endorsement to the session that produced it.

Configuration and Protocol Context A ciphersuite () is identified by an ASCII string identifier. Both parties MUST agree on the ciphersuite before running the protocol. The protocol context, written ctx_proto, is the domain separation tag that this document derives from that identifier: bytes: return b"EC-IHATv1-" + identifier ]]> Throughout the remainder of this document, ctx_proto denotes the output of CreateProtocolContext for the ciphersuite in use. It is distinct from the issuance and redemption contexts of : those are inputs to the protocol, chosen by its participants, whereas ctx_proto is fixed by the ciphersuite. Every hash this document computes, other than the round functions of the permutation P (), is domain-separated by ctx_proto, which appears in its DST. HashToGroup and HashToScalar are so parameterized (), as are G.DeriveScalars and G.ExpandScalars () and G.DeriveNonces (). Every algorithm below therefore depends on ctx_proto, even where it does not appear, and a value produced under one ciphersuite does not verify under another. The Python group instance G stores this context as G.ctx_proto. The group methods below use self for that instance, so the context is fixed when G is constructed.

Deriving Scalars The group method G.DeriveScalars derives count values in the scalar field of G from Nseed bytes of randomness rand. An algorithm that needs random scalars derives them all with one call, under an info string that names the algorithm. rand and info are hashed into a key, which is expanded into the scalars: list[Scalar]: if len(rand) != Nseed: raise ValueError(f"rand must be exactly {Nseed} bytes") key = expand_message_xmd( rand + U16Prefixed(info), b"DeriveScalars-" + self.ctx_proto, Nh, ) return self.ExpandScalars(key, count) ]]> The group method G.ExpandScalars hashes the key and an index to each scalar in turn: list[Scalar]: scalars = [] for i in range(count): s = self.HashToScalar( key + I2OSP(i, 4), DST=b"ExpandScalars-" + self.ctx_proto ) if s.isZero(): raise DeriveError scalars.append(s) return scalars ]]> expand_message_xmd is that of , over the hash function of the ciphersuite. rand MUST be Nseed bytes of output of random and MUST NOT be used for more than one derivation. A derived scalar is zero, and DeriveError raised, with negligible probability; implementations might choose to panic rather than handle the exception. The two-stage derivation used here and in avoids the output-length limit of a single hash_to_field call using expand_message_xmd. XMD produces at most 255 * Nh bytes per call, which allows at most 170 scalars with SHA-256 and L = 48 (see EC-IHAT(P-256, SHA-256) ). Although EC-IHAT's issuer-hiding proof needs fewer scalars, other protocols that share these methods need larger vectors.

Deriving Nonces The nonces of a proof of knowledge, and the other secret values of its first move, must not be reused under a different challenge. The group method G.DeriveNonces derives them together from rand, a secret the party holds, and a public description of the operation, as the hedged signatures of derive theirs: list[Scalar]: if len(rand) != Nseed: raise ValueError(f"rand must be exactly {Nseed} bytes") derive_nonce_input = ( PadToBlock(rand) + PadToBlock(I2OSP(len(secret), 4) + secret) + U16Prefixed(label) + I2OSP(len(instance), 4) + instance ) key = expand_message_xmd( derive_nonce_input, b"DeriveNonces-" + self.ctx_proto, Nh ) return self.ExpandScalars(key, count) ]]> PadToBlock appends zero bytes up to a multiple of s_in_bytes, the input block size of the hash function (): bytes: return value + bytes(-len(value) % s_in_bytes) ]]> expand_message_xmd starts its input with a block of zeros, so the hash function absorbs rand in a block of its own and then secret in blocks of its own, before any public input, as recommends against side-channel and fault attacks. When rand is uniformly random, the nonces are distributed as derived scalars (). If the random source fails in a way that does not depend on secret, the nonces are still hash outputs on an input that contains secret, so to an adversary that does not know secret a change to any part of rand or instance changes every nonce unpredictably, except with negligible probability, and no nonce is reused under a different challenge. Repeating all of rand for the same operation reproduces the same proof. Every instance in this document is an unambiguous encoding, with its variable-length parts length-prefixed. Implementations MUST wipe secret, derive_nonce_input, key, and the returned values once they have been used.

Key Generation An Anchor holds a key pair (skA, pkA). It is derived from a seed, which is what allows the test vectors in to fix a key. The procedure is the key generation of . The secrecy of skA rests on that of seed; info is usually public. tuple[Scalar, Element]: if len(seed) != Nseed: raise ValueError(f"seed must be exactly {Nseed} bytes") derive_input = seed + U16Prefixed(info) for counter in range(256): skA = self.HashToScalar( derive_input + I2OSP(counter, 1), DST=b"DeriveKeyPair-" + self.ctx_proto, ) if not skA.isZero(): return (skA, self.ScalarMultGen(skA)) raise DeriveError ]]> The derivation differs from that of only in its domain separation tag, which comes from the protocol context of this document rather than from an OPRF context string, and in the length of the seed. The loop terminates after one iteration except with probability about 1/p. A fresh key pair is generated by deriving one from a random seed. tuple[Scalar, Element]: seed = random(Nseed) return self.DeriveKeyPair(seed, b"GenerateKeyPair") ]]> The Anchor publishes SerializeElement(pkA) in its configuration.

Context Binding Each Endorsement is bound at issuance to two contexts, the issuance context and the redemption context, and a redemption succeeds only if the Client and the Moderator agree on both values. Both are opaque byte strings. ctx_iss is at most 2^16 - 1 bytes. Because the encoded message is itself passed to U16Prefixed, ctx_red is at most 2^16 - 1 - Nn - 4 bytes. These bounds are enforced by U16Prefixed. The two contexts are bound by deliberately different means, reflecting who is trusted to choose each. The examples below illustrate their cryptographic roles. The issuance context, written ctx_iss, restricts when, and potentially where, an Endorsement may be redeemed; it might for example name the epoch the Endorsement was issued in. Both parties hold it. It is bound by deriving the second commitment base from it: Element: context_base_input = U16Prefixed(ctx_iss) + b"ContextBase" return G.HashToGroup(context_base_input) ]]> The Anchor forms its commitment under this base, and the base is recomputed at verification time. The Client and the Anchor MUST agree on the issuance context. Disagreement causes issuance to fail: a Client that uses any other value fails the commitment-opening check in Finalize. The binding is therefore enforced by the construction rather than by an explicit check, and a Client cannot bind an Endorsement to an issuance context of its own choosing. The redemption context, written ctx_red, restricts where an Endorsement may be redeemed: a redemption succeeds only under the value the Endorsement was issued under. It might for example identify the Moderator the Client intends to redeem at, in which case the Endorsement is redeemable at that Moderator and at no other. It is chosen by the Client and is hidden from the Anchor. It is bound by placing it, together with a fresh Client-chosen nullifier nf of Nn = 32 bytes, in the signed message: bytes: if len(nf) != Nn: raise ValueError(f"nullifier must be exactly {Nn} bytes") return U16Prefixed(nf) + U16Prefixed(ctx_red) ]]> A redemption under a different redemption context recomputes a different message, for which the Client holds no valid signature. Two consequences follow. A Client has to fix ctx_red before it runs Challenge, that is, before the Endorsement exists; and an Endorsement cannot afterwards be re-bound to another value, so a Client that needs to redeem under several redemption contexts needs a separate Endorsement, and so a separate issuance, for each. Anchors bound how many Endorsements they grant a given Client in order to keep Endorsements scarce (), so that budget is consumed per redemption context rather than per Client. The nullifier nf MUST be a fresh string of Nn uniformly random bytes, generated by the Client, and MUST NOT be reused across Endorsements. It is revealed during redemption, so the Moderator ensures each Endorsement is redeemed at most once. The values the two contexts take determine the anonymity set a Client redeems in, and a deployment can destroy the unlinkability the construction provides without breaking any of its cryptographic properties; see .

Endorsement Issuance Issuance produces a signature on the message Message(nf, ctx_red) relative to the public input ctx_iss. It consists of four algorithms, run in the order shown in .

Endorsement issuance overview | | | | Respond | | |<-------- response (s, y, t) -------+ | | Finalize | | | endorsement | ]]>

Commit and Respond are run by the Anchor; Challenge and Finalize are run by the Client. Both parties input the issuance context ctx_iss; only the Client inputs the redemption context ctx_red. Each of the first three algorithms outputs one protocol message, and the next algorithm takes that message as a single input. The messages are the commitment, a pair of points (A, C); the challenge, a single scalar; and the response, a triple of scalars (s, y, t). The types Commitment and Response denote the first and the last of these. The wire format of each message is defined in . All four algorithms treat G, ctx_proto, Nn, and Nseed as global variables.

Anchor Commitment The Anchor opens a session by committing to the values it will later reveal. tuple[AnchorState, Commitment]: Z = CreateContextBase(ctx_iss) rand = random(Nseed) (a, t, y) = G.DeriveScalars(rand, b"Commit", 3) A = G.ScalarMultGen(a) C = G.ScalarMultGen(t) + y * Z state = AnchorState(a, y, t) commitment = Commitment(A, C) return (state, commitment) ]]> The Anchor stores state for the duration of the session and sends commitment to the Client in a CommitMessage (). The signing key is not needed until Respond.

Client Challenge The Client blinds the Anchor's commitment, derives the challenge over the blinded values, and returns the challenge in blinded form. tuple[ClientState, Scalar]: if pkA.isIdentity(): raise VerifyError (A, C) = commitment rand = random(Nn + Nseed) nf = rand[:Nn] (r1, r2, gamma1, gamma2) = G.DeriveScalars( rand[Nn:], b"Challenge", 4 ) m = Message(nf, ctx_red) gamma = gamma1 * G.ScalarInverse(gamma2) blinded_A = G.ScalarMultGen(r1) + gamma * A blinded_C = gamma1 * C + G.ScalarMultGen(r2) blinded_commitment = Commitment(blinded_A, blinded_C) c = ComputeChallenge(ctx_iss, blinded_commitment, m) if c.isZero(): raise VerifyError challenge = c * gamma2 state = ClientState( nf, ctx_iss, commitment, r1, r2, gamma1, gamma2, challenge, c, ) return (state, challenge) ]]> ComputeChallenge is as follows: Scalar: (A, C) = commitment Am = G.SerializeElement(A) Cm = G.SerializeElement(C) challenge_transcript = ( U16Prefixed(ctx_iss) + U16Prefixed(Am) + U16Prefixed(Cm) + U16Prefixed(m) + b"Challenge" ) c = G.HashToScalar(challenge_transcript) return c ]]> Two challenge values appear here: c is computed over the blinded commitment and is the value that ends up in the Endorsement (); it never leaves the Client. The challenge message the Anchor receives is its blinded form c * gamma2, and the Anchor cannot recover c from it because gamma2 is uniform and secret. HashToScalar can return zero, and the construction requires a nonzero challenge. Challenge aborts in that case, which keeps the challenge a deterministic function of the transcript; this happens with probability about 1/p (). The Client sends challenge to the Anchor encoded as a ChallengeMessage () and retains state for the next step.

Anchor Response The Anchor answers the challenge and closes the session. Response: (a, y, t) = state if challenge.isZero(): raise VerifyError s = a + challenge * y * skA response = Response(s, y, t) return response ]]> The resulting Response is encoded as a ResponseMessage () and sent to the Client. An Anchor MUST call Respond at most once per session state produced by Commit, and MUST destroy that state immediately afterwards. Answering two distinct challenges on the same state discloses the signing key: from s1 = a + c1 * y * skA and s2 = a + c2 * y * skA with c1 != c2, and y revealed in the response, an attacker recovers skA = (s1 - s2) * ScalarInverse((c1 - c2) * y). An Anchor MUST NOT run Respond on a state it has already used or discarded.

Client Finalization The Client checks the Anchor's response and unblinds it into an Endorsement. Endorsement: if pkA.isIdentity(): raise VerifyError (nf, ctx_iss, (A, C), r1, r2, gamma1, gamma2, challenge, c) = state (s, y, t) = response Z = CreateContextBase(ctx_iss) if y.isZero(): raise VerifyError if C != G.ScalarMultGen(t) + y * Z: raise VerifyError if G.ScalarMultGen(s) != A + (challenge * y) * pkA: raise VerifyError gamma = gamma1 * G.ScalarInverse(gamma2) s_final = gamma * s + r1 y_final = gamma1 * y t_final = gamma1 * t + r2 return Endorsement(c, s_final, y_final, t_final, nf) ]]> The three checks verify that the Anchor opened its commitment honestly and answered the challenge under its published key. A Client whose Finalize raises an error MUST discard the session state and MUST NOT retry the exchange with the same state. An Endorsement consists of the signature (c, s, y, t) together with the nullifier; its encoding is given in .

Endorsement Verification An Endorsement is publicly verifiable under the issuing Anchor's public key. The two contexts are inputs to Verify in addition to the Endorsement. A verifier therefore states the pair it is willing to accept and learns whether the Endorsement was issued under it. bool: if pkA.isIdentity(): return False (c, s, y, t, nf) = endorsement if len(nf) != Nn or c.isZero() or y.isZero(): return False Z = CreateContextBase(ctx_iss) m = Message(nf, ctx_red) C = G.ScalarMultGen(t) + y * Z A = G.ScalarMultGen(s) - (c * y) * pkA if A.isIdentity() or C.isIdentity(): return False commitment = Commitment(A, C) return c == ComputeChallenge(ctx_iss, commitment, m) ]]> A Moderator never runs Verify under an Anchor's public key: a redemption does not reveal which Anchor issued the Endorsement, so the Moderator runs it under a rerandomized key and checks an issuer-hiding proof alongside (). The Client MUST NOT reveal the Anchor's public key to the Moderator. Verify rejects a reconstructed A or C equal to the identity element, which SerializeElement cannot encode. Under an Anchor's key this happens with negligible probability, but the rerandomized key is the Client's choice, and a Client that knows its discrete logarithm x reaches the identity by setting s = c * y * x. An honestly produced Endorsement always verifies. Writing gamma for gamma1 * ScalarInverse(gamma2), and A_anchor and C_anchor for the two elements of the Anchor's commitment, the commitment reconstructed by Verify is exactly the blinded commitment the Client hashed in Challenge: where the last step uses s = a + challenge * y * skA and challenge = c * gamma2, so that the two terms in skA cancel.

Encodings This section gives the encoding of the three messages exchanged during issuance and of the Endorsement they produce. Element and Scalar are the fixed-length encodings produced by SerializeElement and SerializeScalar, of Ne and Ns bytes respectively. A recipient MUST deserialize every received Element and Scalar, and MUST abort the session with a DeserializeError if deserialization fails. In particular, deserializing an Element rejects the group identity element. Deserialization of a structure also fails if its input is truncated, if bytes remain after it, or if a vector's length is not a multiple of the size of its elements.

Issuance Messages The Anchor opens a session with its commitment: The Client replies with the blinded challenge: The Anchor replies with its response, which closes the session:

Endorsement The output of Finalize is encoded as follows. This structure is never sent to an Anchor. The Client holds it until it is redeemed, and defines what is sent to a Moderator then. The issuance and redemption contexts are not carried in it: they are inputs to Verify () and to redemption, held by the verifier.

Session Handling An Anchor is stateful: it holds the secret state produced by Commit from the moment it sends CommitMessage until it answers or discards the session. That state is single-use; see and . An Anchor SHOULD bound both the number of concurrent open sessions per Client and the lifetime of an open session, and SHOULD discard state for sessions that are not completed within that lifetime. Discarding state early is always safe: it causes the Client's Finalize to be unreachable, but cannot produce an invalid Endorsement.

Endorsement Redemption A Client redeems an Endorsement at a Moderator. An Endorsement is single-use (), so redemption does not have to hide the signature: the Client reveals it, and the Moderator deduplicates on the nullifier. What redemption must hide is which Anchor issued it. The signature of verifies under one Anchor's public key, so presenting it against that key would name the Anchor. Instead the Client rerandomizes the key () and proves in zero knowledge that the rerandomized key belongs to some Anchor in the Moderator's Anchor Set (). Redemption is one message from the Client, answering a challenge from the Moderator. The Moderator holds the ordered Anchor Set and carries it in that challenge; the Client learns it there and locates its own Anchor in it. Both parties input the two contexts.

Endorsement redemption overview | | | | VerifyRedemption | | | nf ]]>

anchor_set is the list of Anchor public keys the Moderator accepts. Both parties MUST use the same list in the same order. A proof computed over a different list or order will not verify. challenge_digest binds the redemption to the challenge that triggered it. This document treats it as an opaque byte string. The Moderator SHOULD set it to a collision-resistant digest, such as SHA-256, of the encoded challenge, so that a redemption produced for one challenge does not verify under another. Note that this challenge is the Moderator's, and has nothing to do with the issuance challenge of . In the remainder, let index denote the index of the issuing Anchor in anchor_set.

Key Rerandomization The Client shifts the Anchor's public key by a secret scalar delta of its own choosing and adapts the signature to the shifted key. Writing pkA for anchor_set[index] and (c, s, y, t, nf) for the Endorsement: Here B denotes the group's base point, i.e., B = G.Generator(). The result is an Endorsement (c, s_hat, y, t, nf) that verifies under X_hat exactly as the original verifies under pkA, because the shift cancels in the reconstruction of A: Every other value Verify recomputes is untouched, so a Moderator can check the signature by running Verify () with X_hat in place of pkA. Because this shift is additive, issuance is left unmodified and the unforgeability of carries over to the modified Endorsement (). But X_hat by itself provides no evidence that it was derived from an Anchor key. The Client therefore also proves knowledge of delta relating X_hat to a key in anchor_set, without revealing which key.

The Issuer-Hiding Proof The Client proves knowledge of delta such that X_hat - anchor_set[i] = delta * B for at least one i, without revealing which. This is a one-out-of-n disjunction of proofs of knowledge of a discrete logarithm, all over the base B = G.Generator(). Such a disjunction is classically composed with the technique of Cramer, Damgard and Schoenmakers , in which the Client answers the branch it can and simulates the others, sending one challenge and one response per branch. That proof is linear in n, and the Anchor Set is also the anonymity set (). This document instead composes the branches with the stacking technique of Goel, Green, Hall-Andersen and Kaptchuk , whose proof is logarithmic in n: the Client sends a single response, which every branch reuses, together with a commitment whose opening forces one branch to have been answered honestly. The proof takes the rerandomized key of as its statement and leaves issuance and unchanged. The construction below first defines the branch proof, then builds a partially binding tree commitment over its branches. It finally specifies the Fiat-Shamir challenge and the proving and verification algorithms. Each branch is the discrete logarithm proof of ; this document specifies the composition, its transcript, and its encodings.

The Branch Proof The disjunction is proved over the statements of which the Client can answer branch index, where Y[index] = delta * B. A single branch is proved by the usual three moves: the Client draws a nonce r and commits T = r * B; the verifier sends a challenge proof_challenge; the Client answers response = r - proof_challenge * delta; and the verifier checks that T = proof_challenge * Y[index] + response * B. Read the other way round, that check determines the commitment from the challenge and the response: Element: return proof_challenge * Y + G.ScalarMultGen(response) def Statements( anchor_set: Sequence[Element], X_hat: Element, ) -> list[Element]: return [X_hat - pkA for pkA in anchor_set] ]]> Two properties make this branch proof stackable in the sense of . First, a verifying commitment can be computed for any statement from a challenge and a response, by the function above, without knowing a witness; this is the extended honest-verifier zero-knowledge property. Second, the response is a fixed shift of the derived nonce r, and so is statistically close to uniform independently of the statement and witness; see . One response can therefore be reused across branches without revealing which branch produced it. A Moderator given proof_challenge and one response can therefore compute an accepting commitment for every branch. Soundness comes from the commitment of : the Client fixes the commitment of one branch before the challenge exists and cannot change it afterwards.

Partially Binding Commitments A partially binding vector commitment commits to a vector of values such that one position, chosen when the commitment key is generated and hidden from the Moderator, is binding, while every other position can afterwards be opened to any value. The Client commits the branch commitment of index at the binding position, and after the challenge is known it opens every other position to the branch commitment that the shared response determines. The branch at the binding position uses the actual witness and a commitment fixed before the challenge; the index of the branch remains hidden by the commitment key. This document uses the commitment of the appendix of over pairs, and then assembles them into a tree. The inputs to the commitments are arbitrary strings of bytes, and the outputs are compressed group elements. The commitment to a pair uses a permutation P on group elements. The inverse of this permutation is denoted Pinv (). The two values are hashed to scalars and committed under the bases Q and P(Q): bytes: C = ( randomness * B + G.HashToScalar(left) * Q + G.HashToScalar(right) * G.P(Q) ) return G.SerializeElement(C) ]]> The committer knows the discrete logarithm of one base, and that is the position it can later open to another value. A key that binds the left position is one whose P(Q) has the known logarithm, and vice versa: Element: T = secret * B (Q, _) = G.PermutationPair(T, bind_left) return Q ]]> bind_left is a secret boolean: true binds the left position and false binds the right. G.PermutationPair () returns (Q, P(Q)), with T = P(Q) when binding left and T = Q when binding right. It walks the same permutation edge in either case, hiding which endpoint has the known logarithm. Its second output can be cached for use in CommitStep. The secret is the trapdoor: replacing the equivocal value shifts the opening by the difference of the hashes times the trapdoor, and the commitment is unchanged: Scalar: old = G.HashToScalar(oldb) new = G.HashToScalar(newb) return randomness + (old - new) * secret ]]> A vector V[0], ..., V[n-1] of byte strings is committed by pairing neighbours level by level. Each level has its own key and its own opening; a vector of odd length carries its last element up unchanged. bytes: if len(V) == 1: return V[0] V_prime = [] for i in range(len(V) // 2): V_prime.append( CommitStep( commitment_keys[0], V[2 * i], V[2 * i + 1], openings[0] ) ) if len(V) % 2 == 1: V_prime.append(V[-1]) return VecCommit(V_prime, commitment_keys[1:], openings[1:]) ]]> A vector of n values has Depth(n) levels, each with one key and one opening: int: q = 0 while 2**q < n: q += 1 return q ]]> Bit j of index is the side of its pair that the binding value is on at level j, which fixes the direction of that level's key; each key has its own trapdoor: list[Element]: commitment_keys = [] for j in range(len(trapdoors)): bind_left = ((index >> j) & 1) == 0 commitment_keys.append(GenerateStep(bind_left, trapdoors[j])) return commitment_keys ]]> The first move commits the value at index with every other leaf empty, under one opening per level: bytes: V = [b"" for _ in range(n)] V[index] = value return VecCommit(V, commitment_keys, openings) ]]> Once the other leaves are known, each level's opening is shifted so that the sibling of the binding path takes its new value and the node above is unchanged. An odd last element on the binding path has no sibling and keeps its opening. list[Scalar]: if len(old) != len(new): raise ValueError("vectors must have the same length") if old[index] != new[index]: raise ValueError("the binding position cannot change") if len(old) == 1: return [] if index == len(old) - 1 and len(old) % 2 == 1: opening = openings[0] else: partner = index - 1 if index % 2 == 1 else index + 1 opening = EquivocateStep( old[partner], new[partner], openings[0], trapdoors[0] ) old_prime = [] new_prime = [] for i in range(len(old) // 2): Q = commitment_keys[0] old_prime.append( CommitStep(Q, old[2 * i], old[2 * i + 1], openings[0]) ) new_prime.append( CommitStep(Q, new[2 * i], new[2 * i + 1], opening) ) if len(old) % 2 == 1: old_prime.append(old[-1]) new_prime.append(new[-1]) rest = VecEquivocate( commitment_keys[1:], trapdoors[1:], openings[1:], old_prime, new_prime, index // 2, ) return [opening] + rest def VecEquivocateFromZero( commitment_keys: Sequence[Element], trapdoors: Sequence[Scalar], openings: Sequence[Scalar], new: Sequence[bytes], index: int, ) -> list[Scalar]: V = [b"" for _ in new] V[index] = new[index] return VecEquivocate( commitment_keys, trapdoors, openings, V, new, index ) ]]>

The Permutation P is a permutation on the elements of G, computed on their compressed encodings by cycle walking: a permutation of the encoding space is applied until the result decodes to an element, and Pinv walks the same cycle backwards. Since a permutation partitions its domain into cycles, the two are inverse to each other. The following direct implementations define the permutation and its inverse for the P-256 group. Other ciphersuites MUST define the permutation to be used. They MAY be used on public points, including the commitment keys in CommitStep. Key generation instead uses G.PermutationPair (), which is designed to be side-channel resistant. In particular, its execution does not distinguish the two binding directions when its outputs are fixed. Element: buf = bytearray(self.SerializeElement(element)) buf[0] = buf[0] - 0x02 while True: buf = PermuteBytes(buf) try: return self.DeserializeElement( bytes([buf[0] + 0x02]) + bytes(buf[1:]) ) except DeserializeError: continue def Pinv(self, element: Element) -> Element: buf = bytearray(self.SerializeElement(element)) buf[0] = buf[0] - 0x02 while True: buf = UnpermuteBytes(buf) try: return self.DeserializeElement( bytes([buf[0] + 0x02]) + bytes(buf[1:]) ) except DeserializeError: continue ]]> The permutation of the encoding space is an eight-round Feistel network over 33-byte strings whose first byte is 0x02 or 0x03, carried as its low bit. Each iteration of the loop below computes two rounds, one per half: bytearray: left, right = bytearray(buf[0:17]), bytearray(buf[17:33]) for i in range(4): label = f"left round {i}".encode() left = bytearray(_xor(left, _sha256(right + label)[0:17])) left[0] = left[0] & 0x01 label = f"right round {i}".encode() right = bytearray(_xor(right, _sha256(left + label)[0:16])) return left + right def UnpermuteBytes(buf: bytearray) -> bytearray: left, right = bytearray(buf[0:17]), bytearray(buf[17:33]) for i in reversed(range(4)): label = f"right round {i}".encode() right = bytearray(_xor(right, _sha256(left + label)[0:16])) label = f"left round {i}".encode() left = bytearray(_xor(left, _sha256(right + label)[0:17])) left[0] = left[0] & 0x01 return left + right ]]> The binding argument of models P as a random permutation. An eight-round balanced Feistel network with independent random round functions is indifferentiable from a random permutation . Here the round functions are SHA-256 separated by label, over halves of 129 and 128 bits, an imbalance does not cover.

Walking a Permutation Edge G.PermutationPair(T, bind_left) returns (Q, P(Q)). If bind_left is true, it walks backwards from T = P(Q) to Q. Otherwise it walks forwards from T = Q to P(Q). At each iteration it computes both one-step byte permutations, selects the next encoding using the secret bit, and tests whether that encoding is valid. It selects the order of the endpoints before decoding them, so both final decodings operate on the same public values Q and P(Q), in that order. tuple[Element, Element]: if not isinstance(bind_left, bool): raise ValueError("bind_left must be a boolean") start = bytearray(self.SerializeElement(element)) start[0] -= 0x02 buf = start while True: forward = PermuteBytes(buf) backward = UnpermuteBytes(buf) buf = SelectBytes(forward, backward, bind_left) if IsValidPermutationEncoding(buf): break left = SelectBytes(start, buf, bind_left) right = SelectBytes(buf, start, bind_left) Q = self.DeserializeElement( bytes([left[0] + 0x02]) + bytes(left[1:]) ) PQ = self.DeserializeElement( bytes([right[0] + 0x02]) + bytes(right[1:]) ) return (Q, PQ) def SelectBytes( left: bytearray, right: bytearray, choose_right: bool ) -> bytearray: mask = -int(choose_right) return bytearray( (a & ~mask) | (b & mask) for a, b in zip(left, right, strict=True) ) ]]> SelectBytes takes equal-length inputs and selects right if its boolean argument is true, or left otherwise. Implementations MUST perform this selection without secret-dependent branches or memory accesses. For P-256, encoding validity can be tested without attempting a point decoding or raising exceptions. Here FIELD_MODULUS, CURVE_A, and CURVE_B are the P-256 field modulus and Weierstrass coefficients from . Since the field modulus is 3 modulo 4, the fixed exponent below computes a square-root candidate; squaring it tests whether a root exists. P-256 has prime, odd order, so an affine point with y = 0 cannot occur. Each valid x therefore supports both sign bits. The identity has no affine encoding. bool: if len(buf) != 33: return False x = int.from_bytes(buf[1:], "big") rhs = ( pow(x, 3, FIELD_MODULUS) + CURVE_A * x + CURVE_B ) % FIELD_MODULUS y = pow(rhs, (FIELD_MODULUS + 1) // 4, FIELD_MODULUS) return ( ((buf[0] == 0) | (buf[0] == 1)) & (x < FIELD_MODULUS) & (y * y % FIELD_MODULUS == rhs) ) ]]> The validity test MUST execute in constant time for all 33-byte candidates, including those with an out-of-range coordinate or no square root. Every condition is evaluated, so neither an exception-based decoder nor short-circuit evaluation may be used. The byte permutations, selections, initial serialization of T, and computation of T = secret * B MUST likewise have no secret-dependent timing or memory access patterns. The Python snippets specify the computation and operation schedule; Python integer arithmetic and the reference implementation's group operations do not provide these constant-time guarantees. To see why the loop may stop at the first valid encoding, fix the public output Q. Let k be the number of applications of PermuteBytes needed to reach P(Q) from Q. None of the k - 1 intermediate encodings is valid. Walking backwards from P(Q) therefore reaches Q after exactly k applications of UnpermuteBytes, with the same sequence of validity results: k - 1 failures followed by one success. Each orientation executes one forward permutation, one inverse permutation, one selection, and one validity test per iteration. Thus the observable operation schedule depends only on Q, which is included in the proof, and can be reproduced from it. This argument also covers fixed points and does not assume that P is random. Implementations MUST NOT optimize away the unused permutation direction. Calling Pinv(T) only for left binding leaks the direction directly. Computing Pinv(T) for both directions and selecting an endpoint afterwards also leaks: for a fixed public Q, its walk length describes the edge leaving Q in one case and the edge entering Q in the other. Both one-step permutations MUST be computed on each iteration of the selected walk.

Challenge Computation ProofStatement encodes the statement being proven: the Anchor Set, the rerandomized key X_hat, the signature being presented (encoded by the endorsement), the issuance and redemption context, and the challenge digest. The Fiat-Shamir challenge covers it together with the first move of the proof, which is the commitment keys and the root of the tree. bytes: (c, s_hat, y, t, nf) = endorsement n = len(anchor_set) anchor_set_enc = b"" for i in range(n): anchor_set_enc += G.SerializeElement(anchor_set[i]) return ( I2OSP(n, 2) + anchor_set_enc + G.SerializeElement(X_hat) + G.SerializeScalar(c) + G.SerializeScalar(s_hat) + G.SerializeScalar(y) + G.SerializeScalar(t) + U16Prefixed(nf) + U16Prefixed(ctx_iss) + U16Prefixed(ctx_red) + U16Prefixed(challenge_digest) ) def ComputeProofChallenge( anchor_set: Sequence[Element], X_hat: Element, endorsement: Endorsement, ctx_iss: bytes, ctx_red: bytes, challenge_digest: bytes, commitment_keys: Sequence[Element], root: bytes, ) -> Scalar: ck_enc = b"" for j in range(len(commitment_keys)): ck_enc += G.SerializeElement(commitment_keys[j]) proof_transcript = ( ProofStatement( anchor_set, X_hat, endorsement, ctx_iss, ctx_red, challenge_digest, ) + ck_enc + root + b"IssuerProof" ) return G.HashToScalar(proof_transcript) ]]> The length of the Anchor Set n is prefixed and Element encodings are fixed-length, so anchor_set_enc and ck_enc are unambiguous without length prefixes of their own; the number of commitment keys, q = Depth(n), is determined by n. The label "IssuerProof" separates this transcript from the issuance transcript of , which is hashed with the same function.

Proving tuple[Scalar, Scalar, Sequence[Element], Sequence[Scalar]]: Y = Statements(anchor_set, X_hat) q = Depth(len(anchor_set)) if not 0 <= index < len(anchor_set): raise ValueError("index is outside the Anchor Set") if len(rand) != Nseed: raise ValueError("invalid issuer proof randomness length") instance = ProofStatement( anchor_set, X_hat, endorsement, ctx_iss, ctx_red, challenge_digest, ) derived = G.DeriveNonces( G.SerializeScalar(delta) + I2OSP(index, 2), b"ProveIssuer", instance, rand, 2 * q + 1, ) r = derived[0] trapdoors = derived[1 : q + 1] first_openings = derived[q + 1 :] T = r * B commitment_keys = GenerateVecBind(index, trapdoors) # First move: commit along the binding path; other leaves empty. root = CommitValAtPlace( commitment_keys, len(Y), index, G.SerializeElement(T), first_openings, ) proof_challenge = ComputeProofChallenge( anchor_set, X_hat, endorsement, ctx_iss, ctx_red, challenge_digest, commitment_keys, root, ) response = r - proof_challenge * delta V = [] for i in range(len(Y)): commitment = BranchCommitment(proof_challenge, response, Y[i]) V.append(G.SerializeElement(commitment)) openings = VecEquivocateFromZero( commitment_keys, trapdoors, first_openings, V, index ) return (proof_challenge, response, commitment_keys, openings) ]]> ProveIssuer derives the nonce r, the trapdoors of the q commitment keys, and the q openings of its first move with one call to G.DeriveNonces (), with delta and index as the secret and the proof statement as the instance. The first move commits only the path from leaf index to the root: at each level the Client commits the value it holds on one side and an empty value on the other, having generated that level's key so that the other side is the equivocal one. The third move then computes the branch commitment of every statement from the single response, equivocates each level to the value its sibling subtree now has, and rebuilds the tree with the equivocated openings. The root is unchanged, so the Moderator recomputes the same root.

Verifying bool: n = len(anchor_set) if n == 0: return False Y = Statements(anchor_set, X_hat) q = Depth(n) if len(commitment_keys) != q: return False if len(openings) != q: return False V = [] for i in range(n): commitment = BranchCommitment(proof_challenge, response, Y[i]) if commitment.isIdentity(): return False V.append(G.SerializeElement(commitment)) root = VecCommit(V, commitment_keys, openings) return proof_challenge == ComputeProofChallenge( anchor_set, X_hat, endorsement, ctx_iss, ctx_red, challenge_digest, commitment_keys, root, ) ]]> The Moderator computes a commitment for every branch from the single response, rebuilds the whole tree from those commitments and the openings it was given, and checks that the root it arrives at is the one the challenge was computed over. Neither the branch commitments nor the interior nodes are transmitted. VerifyIssuer returns false rather than raising an error, as Verify () does. Its checks on the lengths of commitment_keys and openings repeat what deserialization enforces (), and an empty Anchor Set means the Moderator is misconfigured. It also rejects a branch commitment equal to the identity element, which SerializeElement cannot encode and which a Client can produce on its own branch by answering response = -proof_challenge * delta. An interior node is the identity only for a Client that knows a discrete logarithm relation among B, Q, and P(Q) for the key Q of its level, which the binding property of rules out, so VecCommit does not check for it. A proof produced by ProveIssuer is accepted by VerifyIssuer. On branch index, This is the commitment the Client committed at the binding leaf, and every other leaf holds by definition the commitment the verifier recomputes. Each level then reproduces the node the Client committed: the binding side is unchanged, and the equivocal side was shifted to match. Conversely, the binding leaf is fixed before proof_challenge exists and cannot be moved afterwards, so a Client that could produce an accepting proof for two different challenges would yield delta for that leaf's statement. The soundness of the proof rests on that alone; see .

Redemption The Client produces a redemption from an Endorsement it holds. Redemption: (c, s, y, t, nf) = endorsement n = len(anchor_set) if not 0 <= index < n: raise ValueError("index is outside the Anchor Set") rand = random(2 * Nseed) (delta,) = G.DeriveScalars(Seed(rand, 0), b"delta", 1) X_hat = anchor_set[index] + delta * B s_hat = s + (c * y) * delta shown = Endorsement(c, s_hat, y, t, nf) (proof_challenge, response, commitment_keys, openings) = ProveIssuer( anchor_set, index, delta, X_hat, shown, ctx_iss, ctx_red, challenge_digest, Seed(rand, 1), ) return Redemption( X_hat, shown, proof_challenge, response, commitment_keys, openings, ) ]]>

Redemption Verification The Moderator checks the signature under the rerandomized key and the proof against its Anchor Set. bytes: ( X_hat, shown, proof_challenge, response, commitment_keys, openings, ) = redemption if not Verify(X_hat, shown, ctx_iss, ctx_red): raise VerifyError if not VerifyIssuer( anchor_set, X_hat, shown, ctx_iss, ctx_red, challenge_digest, proof_challenge, response, commitment_keys, openings, ): raise VerifyError return shown.nf ]]> The first check is the endorsement verification of , run against the rerandomized key. Together the two checks establish that the Client holds an Endorsement issued under ctx_iss and ctx_red by one of the Anchors in anchor_set, and reveal nothing further about which one. On success, VerifyRedemption returns the nullifier; either failed check raises a VerifyError. VerifyRedemption does not enforce single use. The nullifier nf is in the clear in the redemption, and a Moderator that accepts a redemption MUST reject it if it has already recorded that nf, and MUST record nf before granting anything on the strength of it. A Moderator SHOULD scope its nullifier store to the issuance context, since an Endorsement issued under a different ctx_iss does not verify anyway. An Anchor Set of one key gives a tree of depth zero: the redemption carries no commitment keys or openings, and the issuer-hiding proof is a proof of knowledge of delta for that key. The redemption then names its Anchor, as the Anchor Set itself does; see .

Encodings A Client sends the encoded Redemption to the Moderator in the Redeem & Issue flow (). ; Scalar openings; } Redemption; ]]> shown_endorsement uses the Endorsement structure of , with s carrying s_hat, but is rerandomized such that it verifies under rerandomized_key (), not the Endorsement the Client stored, which the Client MUST NOT send. A Moderator deserializes a Redemption against its Anchor Set of n keys, as in . It MUST raise a DeserializeError unless commitment_keys is Depth(n) * Ne bytes long and openings is Depth(n) * Ns bytes long ().

Ciphersuites A ciphersuite fixes the group, the hash function, the associated encodings, and a ciphersuite identifier. Both parties are assumed to agree on the ciphersuite in use (). For each ciphersuite, ctx_proto is as computed in . The nullifier length is Nn = 32 bytes and the seed length, that of the random input to every derivation, is Nseed = 48 bytes for the ciphersuite below.

EC-IHAT(P-256, SHA-256) This ciphersuite uses P-256 (secp256r1) for the group and SHA-256 for the hash function, with Nh = 32 and s_in_bytes = 64. The value of the ciphersuite identifier is "P256-SHA256". The interface of is instantiated as follows.

Order():

Return 0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551.

Identity(), Generator(), ScalarMultGen(r):

As defined in .

HashToGroup(x, DST):

Use hash_to_curve with suite P256_XMD:SHA-256_SSWU_RO_ and input x, using the given DST.

HashToScalar(x, DST):

Use hash_to_field from with count = 1, m = 1, L = 48, expand_message_xmd with SHA-256, input x, a prime modulus equal to Order(), and the given DST. Return the single resulting field element as a Scalar.

ScalarInverse(s):

The multiplicative inverse of s modulo Order().

SerializeElement(A):

The compressed Elliptic-Curve-Point-to-Octet-String method of ; Ne = 33.

DeserializeElement(buf):

Deserialize a 33-byte input using the compressed Octet-String-to-Elliptic-Curve-Point method of , then perform partial public key validation as in . This includes checking that the coordinates are in range, that the point is on the curve, and that the point is not the identity element. Raise a DeserializeError if any check fails.

SerializeScalar(s):

The Field-Element-to-Octet-String conversion of ; Ns = 32.

DeserializeScalar(buf):

Deserialize a 32-byte input using Octet-String-to-Field-Element from . Raise a DeserializeError if the result is not in [0, Order()-1].

P:

The SHA-256 Feistel permutation and cycle walk in . Compressed SEC1 prefixes are 0x02 and 0x03; subtracting 0x02 gives the one-bit prefix used by the byte permutation. Pinv reverses the walk. PermutationPair () is used during commitment key generation. For a random encoding permutation, the walk takes about two iterations on average.

Security Considerations The security of EC-IHAT is studied in . The underlying blind signature is that of Tessaro and Zhu , instantiated with the public input set to the issuance context. Security is analysed in the random oracle model, and one-more unforgeability additionally in the algebraic group model under the discrete logarithm assumption.

Blindness:

All the Anchor receives in a session is the blinded challenge c * gamma2. With uniform blinding factors, the blinded challenge is uniformly distributed and independent of the message and of the resulting signature, and the underlying scheme is perfectly blind . The blinding factors of this document are derived by hashing, so in the random oracle model the scheme is statistically blind: an Anchor can link an Endorsement to the session that produced it only by evaluating the hash function on one of the secret inputs from which the Client derives its blinding factors (). Endorsement grants and redemptions are therefore unlinkable, as requires.

One-more unforgeability:

A Client that completes k issuance sessions under a given issuance context cannot produce k+1 distinct valid Endorsements under that context, regardless of how many sessions it has completed under other issuance contexts . This is what allows a Moderator to conclude that an accepted Endorsement corresponds to exactly one grant by a trusted Anchor. This security guarantee holds even with concurrent sessions.

Unforgeability under rerandomization:

Lemma 1 of establishes strong key randomizability of . Thus, Theorem 1 of reduces issuer-hiding one-more unforgeability to , provided the issuer-hiding proof is straight-line extractable. Appendix C of claims straight-line extractability for , but does not establish it for the stacked proof used here. Applying Theorem 1 to this construction therefore remains an open proof obligation.

Issuer hiding:

Theorem 2 of establishes issuer-hiding blindness from perfect blindness of issuance, strong key randomizability (as defined by ), and perfect zero knowledge of the issuer-hiding proof, assuming uniform randomness. Up to a negligible statistical distance, a redemption reveals nothing about which Anchor in anchor_set issued the Endorsement, so a Moderator, an Anchor, and the two colluding learn only that some key in anchor_set was used. X_hat and the response of the single branch proof are statistically close to uniform independently of the branch (), and the commitment of hides which position it binds: a commitment key is distributed independently of that position, and an opening independently of whether the value it opens to was committed or equivocated. The stacked composition is therefore witness indistinguishable (appendix and Section 7 of ).

Partially binding commitments:

The soundness of the issuer-hiding proof rests on two things: the commitment of binding one position of each node, and the collision resistance of HashToScalar on the leaf and node encodings, without which a position could be opened to a colliding value and no discrete logarithm would be extractable. Binding is computational. A Client that opens the value under base Q two ways knows the discrete logarithm of Q, and one that opens the value under P(Q) two ways knows that of P(Q); the key generation gives it one of the two. Opening both positions would require both logarithms. That a Q with both known is as hard to find as a discrete logarithm when P is modelled as a random permutation () is the assumption under which the pair commitment of the appendix of binds.

Constant-time proving:

ProveIssuer treats one leaf, and one side of each node on the path to it, differently from the others, and that leaf is the secret the proof hides. Implementations MUST NOT allow the binding path to be distinguished by timing or memory access patterns. The first move places the real branch commitment at index and empty values at every other leaf; both commitment passes visit every node of the tree. That placement and the later equivocation MUST avoid observable secret-dependent branches and memory accesses. The number of distinct node commitments at a level of the first move depends on index, so an implementation that computes each only once MUST compute the same number at every level for every index.

Commitment key generation uses the balanced walk of . Its iteration count is determined by the published commitment key, and both binding directions execute the same operation schedule for that key. This addresses the permutation walk only: secret-index selection, scalar arithmetic, and the rest of the proving algorithm still require constant-time implementations.

Single-use sessions:

Implementations MUST ensure that the session state produced by Commit is never used more than once. If an Anchor answers two distinct challenges c1 != c2 on one Commit state, then from the two responses s1 = a + c1*y*skA and s2 = a + c2*y*skA, with y revealed in both, anyone recovers the signing key as skA = (s1 - s2) * ScalarInverse((c1 - c2) * y). The requirement extends to process restarts, to replicas sharing a signing key, and to any retry or replay of a ChallengeMessage: an Anchor MUST treat a session as closed the moment it emits a response, and MUST NOT recompute a response for a repeated challenge on that session. Anchors are stateful for this reason.

Context binding:

The issuance context enters both the commitment base and the challenge transcript, and the redemption context enters the signed message, so an Endorsement does not verify under any other pair of contexts. Neither context is carried in the Endorsement; both are supplied by the verifier (), so a Client cannot assert the pair its Endorsement is checked against. A Client also cannot select the issuance context unilaterally: it is never sent from the Client to the Anchor, and using a value other than the one the Anchor committed under fails the opening check in Finalize.

Aborts on zero:

Challenge aborts when the challenge hashes to zero and Respond aborts on a zero challenge. Both events occur with probability approximately 1/p for honest parties, where p is the order of the group. A Client that observes such an abort learns nothing and SHOULD start a fresh session.

Context granularity:

The unlinkability arguments above are cryptographic; the anonymity set they operate over is set by the contexts. Both contexts are visible at redemption, the issuance context directly and the redemption context through the fact that the Endorsement verifies under it, so each partitions Clients into the set that shares its value. A deployment that refines either value, for instance by using a per-request timestamp rather than a shared epoch, or a per-Client identifier rather than a value shared by every Client redeeming in the same place, reduces the anonymity set accordingly, down to a single Client, without violating any cryptographic property of the construction.

Session identifiers:

Any identifier the transport uses to correlate the messages of , such as a per-batch session identifier, is chosen by the Anchor and so is a value the Anchor recognises. It MUST be confined to the transport: it is not an input to any algorithm of , nor is it included in the challenge transcript. Were it bound into the Endorsement, the Anchor could recognise its own identifier at redemption and link the redemption to the issuance session.

Anonymity sets:

The effective privacy a Client obtains also depends on deployment properties beyond this document, in particular the number of Clients an Anchor serves per epoch and the size of a Moderator's Anchor Set; see .

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. 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. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between a client and a server for computing the output of a Pseudorandom Function (PRF). The server provides the PRF private key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF private key, and the server learns neither the PRF input nor output. An OPRF can also satisfy a notion of 'verifiability', called a VOPRF. A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol. A VOPRF can also be partially oblivious, called a POPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, and POPRF instantiated within standard prime-order groups, including elliptic curves. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. National Institute of Standards and Technology (NIST) Standards for Efficient Cryptography Group (SECG) 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 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. Ericsson Ericsson Ericsson Deterministic elliptic-curve signatures such as deterministic ECDSA and EdDSA have gained popularity over randomized ECDSA as their security does not depend on a source of high-quality randomness. Recent research, however, has found that implementations of these signature algorithms may be vulnerable to certain side-channel and fault injection attacks due to their deterministic nature. One countermeasure to such attacks is hedged signatures where the calculation of the per-message secret number includes both fresh randomness and the message. This document updates RFC 6979 and RFC 8032 to recommend hedged constructions in deployments where side- channel attacks and fault injection attacks are a concern. The updates are invisible to the validator of the signature and compatible with existing ECDSA and EdDSA validators.

Test Vectors The vectors below cover the ciphersuite of : G.DeriveScalars, the permutation P, a key pair, one issuance, and redemptions of the resulting Endorsement against Anchor Sets of two keys, of five, and of one. Byte strings are in hexadecimal, wrapped at 64 digits with the continuation lines indented; integers are decimal. Every algorithm is a deterministic function of the bytes it draws from random. derive.rand is the rand argument of G.DeriveScalars; every other rand entry is the concatenation of every random call the algorithm makes, in the order made, and an implementation replays it by serving those bytes in place of random. For G.GenerateKeyPair the rand entry is the key seed; for Commit, the Nseed bytes of (a, t, y); for Challenge, the Nn bytes of the nullifier and then the Nseed bytes of the blinding factors; and for Redeem, the Nseed bytes of delta and then the Nseed bytes of the issuer-hiding proof. The commit.state entry is the AnchorState (a, y, t) as SerializeScalar(a) + SerializeScalar(y) + SerializeScalar(t), and the challenge.state entry is nf + SerializeScalar(r1) + SerializeScalar(r2) followed by SerializeScalar(gamma1) + SerializeScalar(gamma2) + SerializeScalar(c). issue.Z is CreateContextBase(ctx_iss), and key.P_pkA is P(pkA). Every message and endorsement entry is an encoding of or . The keys of each Anchor Set other than key.pkA were generated for the vectors. Every redemption presents the same Endorsement, which a Moderator would accept only once; each nf entry is the output of VerifyRedemption.

Ciphersuite

Scalar Derivation

Key Pair

Issuance

Redemption Against 2 Anchors

Redemption Against 5 Anchors

Redemption Against 1 Anchor

Acknowledgments The authors thank Christopher Patton and Thibault Meunier for review and improvements to the protocol description.

Changelog draft-ladd-mole-ec-ihat-00

• Initial version.