Anonymous Rate-Limited Credentials Cryptography

Introduction This document specifies the Anonymous Rate-Limited Credential (ARC) protocol, a specialization of keyed-verification anonymous credentials with support for rate limiting. ARC is privately verifiable (keyed-verification), yet differs from similar token-based protocols in that each credential can be presented multiple times without violating unlinkability of different presentations. Servers issue credentials to clients that are cryptographically bound to client secrets and some public information. Afterwards, clients can present this credential to the server up to some fixed number of times, where each presentation provides proof that it was derived from a valid (previously issued) credential and bound to some public information. Each presentation is pairwise unlinkable, meaning the server cannot link any two presentations to the same client credential, nor can the server link a presentation to the preceding credential issuance flow. Notably, the maximum number of presentations from a credential is fixed by the application. ARC is useful in settings where applications require a fixed number of zero-knowledge proofs about client secrets that can also be cryptographically bound to some public information. This capability lets servers use credentials in applications that need throttled or rate-limited access from anonymous clients.

Conventions and Definitions

Notation and Terminology The following functions and notation are used throughout the document.

concat(x0, ..., xN): Concatenation of byte strings. For example, concat(0x01, 0x0203, 0x040506) = 0x010203040506.
bytes_to_int and int_to_bytes: Convert a byte string to and from a non-negative integer. bytes_to_int and int_to_bytes are implemented as OS2IP and I2OSP as described in , respectively. Note that these functions operate on byte strings in big-endian byte order.
random_integer_uniform(M, N): Generate a random, uniformly distributed integer R between M inclusive and N exclusive, i.e., M <= R < N.
random_integer_uniform_excluding_set(M, N, S): Generate a random, uniformly distributed integer R between M inclusive and N exclusive, i.e., M <= R < N, such that R does not exist in the set of integers S.

All algorithms and procedures described in this document are laid out in a Python-like pseudocode. Each function takes a set of inputs and parameters and produces a set of output values. Parameters become constant values once the protocol variant and the ciphersuite are fixed. The notation T U[N] refers to an array called U containing N items of type T. The type opaque means one single byte of uninterpreted data. Items of the array are zero-indexed and referred as U[j] such that 0 <= j < N. The notation {T} refers to a set consisting of elements of type T. For any object x, we write len(x) to denote its length in bytes. String values such as "CredentialRequest", "CredentialResponse", "Presentation", and "Tag" are ASCII string literals. The following terms are used throughout this document.

Client: Protocol initiator. Creates a credential request, and uses the corresponding server response to make a credential. The client can make multiple presentations of this credential.
Server: Computes a response to a credential request, with its server private keys. Later the server can verify the client's presentations with its private keys. Learns nothing about the client's secret attributes, and cannot link a client's request/response and presentation steps.

Preliminaries The construction in this document has one primary dependency:

Group: A prime-order group implementing the API described below in . See for specific instances of groups.

Prime-Order Group In this document, we assume the construction of an additive, prime-order group Group for performing all mathematical operations. In prime-order groups, any element (other than the identity) can generate the other elements of the group. Usually, one element is fixed and defined as the group generator. In the ARC setting, there are two fixed generator elements (generatorG, generatorH). Such groups are uniquely determined by the choice of the prime p that defines the order of the group. (There may, however, exist different representations of the group for a single p. lists specific groups which indicate both order and representation.) The fundamental group operation is addition + with identity element I. For any elements A and B of the group, A + B = B + A is also a member of the group. Also, for any A in the group, there exists an element -A such that A + (-A) = (-A) + A = I. Scalar multiplication by r is equivalent to the repeated application of the group operation on an element A with itself r-1 times, this is denoted as r*A = A + ... + A. For any element A, p*A=I. The case when the scalar multiplication is performed on the group generator is denoted as ScalarMultGen(r). Given two elements A and B, the discrete logarithm problem is to find an integer k such that B = k*A. Thus, k is the discrete logarithm of B with respect to the base A. The set of scalars corresponds to GF(p), a prime field of order p, and are represented as the set of integers defined by {0, 1, ..., p-1}. This document uses types Element and Scalar to denote elements of the group and its set of scalars, respectively. We now detail a number of member functions that can be invoked on a prime-order group.

Order(): Outputs the order of the group (i.e. p).
Identity(): Outputs the identity element of the group (i.e. I).
Generator(): Outputs the fixed generator of the group.
HashToGroup(x, info): Deterministically maps an array of bytes x with domain separation value info to an element of Group. The map must ensure that, for any adversary receiving R = HashToGroup(x, info), it is computationally difficult to reverse the mapping. Security properties of this function are described in .
HashToScalar(x, info): Deterministically maps an array of bytes x with domain separation value info to an element in GF(p). Security properties of this function are described in .
RandomScalar(): Chooses at random a non-zero element in GF(p).
ScalarInverse(s): Returns the inverse of input Scalar s on GF(p).
SerializeElement(A): Maps an Element A to a canonical byte array buf of fixed length Ne.
DeserializeElement(buf): Attempts to map a byte array buf to an Element A, and fails if the input is not the valid canonical byte representation of an element of the group. This function can raise a DeserializeError if deserialization fails or A is the identity element of the group; see for group-specific input validation steps.
SerializeScalar(s): Maps a Scalar s to a canonical byte array buf of fixed length Ns.
DeserializeScalar(buf): Attempts to map a byte array buf to a Scalar s. This function can raise a DeserializeError if deserialization fails; see for group-specific input validation steps.

For each group, there exists two distinct generators, generatorG and generatorH, generatorG = G.Generator() and generatorH = G.HashToGroup(G.SerializeElement(generatorG), "generatorH"). The group member functions GeneratorG() and GeneratorH() are shorthand for returning generatorG and generatorH, respectively. contains details for the implementation of this interface for different prime-order groups instantiated over elliptic curves.

ARC Protocol The ARC protocol is a two-party protocol run between client and server consisting of three distinct phases:

Key generation. In this phase, the server generates its private and public keys to be used for the remaining phases. This phase is described in .
Credential issuance. In this phase, the client and server interact to issue the client a credential that is cryptographically bound to client secrets. This phase is described in .
Presentation. In this phase, the client uses the credential to create a "presentation" to the server, where the server learns nothing more than whether or not the presentation is valid and corresponds to some previously issued credential, without learning which credential it corresponds to. This phase is described in .

This protocol bears resemblance to anonymous token protocols, such as those built on Blind RSA and Oblivious Pseudorandom Functions with one critical distinction: unlike anonymous tokens, an anonymous credential can be used multiple times to create unlinkable presentations (up to the fixed presentation limit). This means that a single issuance invocation can drive multiple presentation invocations, whereas with anonymous tokens, each presentation invocation requires exactly one issuance invocation. As a result, credentials are generally longer lived than tokens. Applications configure the credential presentation limit after the credential is issued such that client and server agree on the limit during presentation. Servers are responsible for ensuring this limit is not exceeded. Clients that exceed the agreed-upon presentation limit break the unlinkability guarantees provided by the protocol. The rest of this section describes the three phases of the ARC protocol.

Key Generation In the key generation phase, the server generates its private and public keys, denoted ServerPrivateKey and ServerPublicKey, as follows. The server public key can be serialized as follows: The length of this encoded response structure is NserverPublicKey = 3*Ne.

Issuance The purpose of the issuance phase is for the client and server to cooperatively compute a credential that is cryptographically bound to the client's secrets. Clients do not choose these secrets; they are computed by the protocol. The issuance phase of the protocol requires clients to know the server public key a priori, as well as an arbitrary, application-specific request context. It requires no other input. It consists of three distinct steps:

The client generates and sends a credential request to the server. This credential request contains a proof that the request is valid with respect to the client's secrets and request context. See for details about this step.
The server validates the credential request. If valid, it computes a credential response with the server private keys. The response includes a proof that the credential response is valid with respect to the server keys. The server sends the response to the client. See for details about this step.
The client finalizes the credential by processing the server response. If valid, this step yields a credential that can then be used in the presentation phase of the protocol. See for details about this step.

Each of these steps is described in the following subsections.

Credential Request Given a request context, the process for creating a credential request is as follows: See for more details on the generation of the credential request proof. The resulting request can be serialized as follows. The length of this encoded request structure is Nrequest = 2*Ne + 5*Ns.

Credential Response Given a credential request and server public and private keys, the process for creating a credential response is as follows. The resulting response can be serialized as follows. See for more details on the generation of the credential response proof. The length of this encoded response structure is Nresponse = 6*Ne + 8*Ns.

Finalize Credential Given a credential request and response, server public keys, and the client secrets produced when creating a credential request, the process for finalizing the issuance flow and creating a credential is as follows.

Presentation The purpose of the presentation phase is for the client to create a "presentation" to the server which can be verified using the server private key. This phase is non-interactive, i.e., there is no state stored between client and server in order to produce and then verify a presentation. Client and server agree upon a fixed limit of presentations in order to create and verify presentations; presentations will not verify correctly if the client and server use different limits. This phase consists of three steps:

The client creates a presentation state for a given presentation context and presentation limit. This state is used to produce a fixed amount of presentations.
The client creates a presentation from the presentation state and sends it to the server. The presentation is cryptographically bound to the state's presentation context, and contains proof that the presentation is valid with respect to the presentation context. Moreover, the presentation contains proof that the nonce (an integer) associated with this presentation is within the presentation limit. The nonce value used in each presentation is hidden in a Pedersen commitment, ensuring servers cannot link presentations using the nonce.
The server verifies the presentation with respect to the presentation context and presentation limit.

Details for each of these steps are in the following subsections.

Presentation State Presentation state is used to track the number of presentations for a given credential. This state is important for ARC's unlinkability goals: reuse of state can break unlinkability properties of credential presentations. State is initialized with a credential, presentation context, and presentation limit. It is then mutated after each presentation construction (as described in ).

Presentation Construction Creating a presentation requires a credential, presentation context, and presentation limit. This process is necessarily stateful on the client since the number of times a credential is used for a given presentation context cannot exceed the presentation limit; doing so would break presentation unlinkability, as two presentations created with the same nonce can be directly compared for equality (via the "tag"). As a result, the process for creating a presentation accepts as input a presentation state and then outputs an updated presentation state. = state.presentationLimit: raise LimitExceededError nonce = state.nextNonce # This step mutates the state by incrementing nextNonce by 1. state.nextNonce += 1 a = G.RandomScalar() r = G.RandomScalar() z = G.RandomScalar() U = a * state.credential.U UPrime = a * state.credential.UPrime UPrimeCommit = UPrime + r * generatorG m1Commit = state.credential.m1 * U + z * generatorH # Create Pedersen commitment to the nonce nonceBlinding = G.RandomScalar() nonceCommit = G.Scalar(nonce) * generatorG + nonceBlinding * generatorH generatorT = G.HashToGroup(state.presentationContext, "Tag") tag = (state.credential.m1 + nonce)^(-1) * generatorT V = z * state.credential.X1 - r * generatorG # Generate presentation proof with integrated range proof presentationProof = MakePresentationProof(U, UPrimeCommit, m1Commit, tag, generatorT, state.credential, V, r, z, nonce, nonceBlinding, nonceCommit, state.presentationLimit, rng) presentation = (U, UPrimeCommit, m1Commit, tag, nonceCommit, presentationProof) return state, nonce, presentation ]]> OPEN ISSUE: should the tag also fold in the presentation limit? The resulting presentation can be serialized as follows. See for more details on the generation of the presentation proof. The presentation proof integrates the range proof as described in . The length of the Presentation structure is Npresentation = 5*Ne + Npresentationproof. Npresentationproof = k * Ne + (6 + 3 * k) * Ns, which includes the D commitments (k * Ne), the challenge (Ns), the response scalars for presentation variables (5 scalars: m1, z, -r, nonce, nonceBlinding), and range proof variables (3 * k scalars: b[i], s[i], s2[i] for each bit). k is the number of bits it takes to represent the presentationLimit, i.e., k = ceil(log2(presentationLimit))

Presentation Verification The server processes the presentation by verifying the integrated presentation proof, which includes verification of the range proof, against server-computed values. Note that the server does not receive the raw nonce value, only the Pedersen commitment to it. Implementation-specific steps: the server must perform a check that the tag (presentation.tag) has not previously been seen, to prevent double spending. It then stores the tag for use in future double spending checks. To reduce the overhead of performing double spend checks, the server can store and look up the tags corresponding to the associated requestContext and presentationContext values.

Zero-Knowledge Proofs This section uses the Interactive Sigma Protocol to create zero-knowledge proofs of knowledge for various ARC operations, and the Fiat-Shamir Transform to make those proofs non-interactive.

CredentialRequest Proof The request proof is a proof of knowledge of (m1, m2, r1, r2) used to generate the encrypted request. Statements to prove:

CredentialRequest Proof Creation Where the request proof returned is a serialization of the following: ~~~ - challenge: Scalar, the challenge used in the proof of valid encryption. - response0: Scalar, the response corresponding to m1. - response1: Scalar, the response corresponding to m2. - response2: Scalar, the response corresponding to r1. - response3: Scalar, the response corresponding to r2. ~~~

CredentialRequest Proof Verification

CredentialResponse Proof The response proof is a proof of knowledge of (x0, x1, x2, x0Blinding, b) used in the server's CredentialResponse for the client's CredentialRequest. Statements to prove:

CredentialResponse Proof Creation Where the response proof returned is a serialization of the following: ~~~ - challenge: Scalar, the challenge used in the proof of valid response. - response0: Scalar, the response corresponding to x0. - response1: Scalar, the response corresponding to x1. - response2: Scalar, the response corresponding to x2. - response3: Scalar, the response corresponding to x0Blinding. - response4: Scalar, the response corresponding to b. - response5: Scalar, the response corresponding to t1. - response6: Scalar, the response corresponding to t2. ~~~

CredentialResponse Proof Verification

Presentation Proof The presentation proof is a proof of knowledge of (m1, r, z, nonce, nonceBlinding) used in the presentation, as well as a proof that nonce is in the range [0, presentationLimit). Statements to prove:

Presentation Proof Creation Where the presentation proof returned is a serialization of the following: ~~~ - challenge: Scalar, the challenge used in the proof of valid presentation. - response0: Scalar, the response corresponding to m1. - response1: Scalar, the response corresponding to z. - response2: Scalar, the response corresponding to -r. - response3: Scalar, the response corresponding to nonce. ~~~

Presentation Proof Verification

Range Proof for Arbitrary Values This section specifies a range proof to prove a secret value nonce lies in an arbitrary interval [0, presentationLimit). Before specifying the proof system, we first give a brief overview of how it works. For simplicity, assume that presentationLimit is a power of two, that is, presentationLimit = 2^k for some integer k > 0. To prove a value lies in [0,(2^k)-1), we prove it has a valid k-bit representation. This is proven by committing to the full value nonce, then all bits of the bit decomposition b of the value nonce, and then proving each coefficient of the bit decomposition is actually 0 or 1 and that the sum of the bits multiplied by their associated bases equals the full value nonce. This involves the following steps:

Commit to the bits of nonce. That is, for each bit b[i] of the k-bit decomposition of nonce, let D[i] = b[i] * generatorG + s[i] * generatorH, where s[i] is a blinding scalar.
Prove that b[i] is in {0,1} by proving the algebraic relation b[i] * (b[i]-1) == 0 holds. This quadratic relation can be linearized by adding an auxilary witness s2[i] and adding the linear relation D[i] = b[i] * D[i] + s2[i] * generatorH to the equation system. A valid witness s2[i] can only be computed by the prover if b[i] is in {0,1}, and is computed as s2[i] = (1 - b[i]) * s[i]. Successfully computing a witness for any other value, while satisfying the linear relation constraints, requires the prover to break the discrete logarithm problem.
In addition to verifying the proof of the above relation, the verifier checks that the sum of the bit commitments is equal to the sum of the commitment to nonce:

The third step is verified outside of the proof by adding the commitments homomorphically. To support the general case, where presentationLimit is not necessarily a power of two, we extend the range proof for arbitrary ranges by decomposing the range up to the second highest power of two and adding an additional, non-binary range that covers the remaining range. This is detailed in ComputeBases below. Note that by extending the range proof for arbitrary ranges, we are changing the bases used for decomposition and therefore introducing the potential for multiple valid decompositions of a value (the nonce). Implementations compliant with this specification MUST follow the canonical decomposition defined in .

Range Proof Creation Using the bases from ComputeBases, the function MakeRangeProofHelper represents the secret nonce as a linear combination of the bases, using the resulting bit representation to generate the cryptographic commitments and witness values for the range proof. This helper function is called from within MakePresentationProof to add range proof constraints to the presentation proof statement. = base) else 0 remainder -= bitValue * base b.append(G.Scalar(bitValue)) # Compute commitments to bits D = [] s = [] s2 = [] partial_sum = G.Scalar(0) for i in range(len(bases) - 1): s.append(G.RandomScalar()) partial_sum += bases[i] * s[i] s2.append((G.Scalar(1) - b[i]) * s[i]) D.append(b[i] * generatorG + s[i] * generatorH) # Blinding value for the last bit commitment is chosen strategically # so that all the bit commitments will sum up to nonceCommit. idx = len(bases) - 1 s.append(G.ScalarInverse(bases[idx]) * (nonceBlinding - partial_sum)) s2.append((G.Scalar(1) - b[idx]) * s[idx]) D.append(b[idx] * generatorG + s[idx] * generatorH) # Allocate scalar variables (b, s, s2 for each bit) num_bits = len(b) vars_b = statement.allocate_scalars(num_bits) vars_s = statement.allocate_scalars(num_bits) vars_s2 = statement.allocate_scalars(num_bits) # Allocate and set element variables for bit commitments D vars_D = statement.allocate_elements(num_bits) statement.set_elements([(vars_D[i], D[i]) for i in range(num_bits)]) # Add constraints proving each b[i] is in {0,1} for i in range(len(b)): # D[i] = b[i] * generatorG + s[i] * generatorH statement.append_equation(vars_D[i], [(vars_b[i], genGVar), (vars_s[i], genHVar)]) # D[i] = b[i] * D[i] + s2[i] * generatorH (proves b[i] is in {0,1}) statement.append_equation(vars_D[i], [(vars_b[i], vars_D[i]), (vars_s2[i], genHVar)]) # Build witness array: all b values, then all s values, then all s2 values rangeWitness = [] rangeWitness.extend(b) rangeWitness.extend(s) rangeWitness.extend(s2) return (statement, D, rangeWitness) ]]>

Range Proof Verification

Ciphersuites A ciphersuite (also referred to as 'suite' in this document) for the protocol wraps the functionality required for the protocol to take place. The ciphersuite should be available to both the client and server, and agreement on the specific instantiation is assumed throughout. A ciphersuite contains an instantiation of the following functionality:

Group: A prime-order Group exposing the API detailed in , with the generator element defined in the corresponding reference for each group. Each group also specifies HashToGroup, HashToScalar, and serialization functionalities. For HashToGroup, the domain separation tag (DST) is constructed in accordance with the recommendations in . For HashToScalar, each group specifies an integer order that is used in reducing integer values to a member of the corresponding scalar field.

This section includes an initial set of ciphersuites with supported groups. It also includes implementation details for each ciphersuite, focusing on input validation.

ARC(P-256) This ciphersuite uses P-256 for the Group. The value of the ciphersuite identifier is "P256". The value of contextString is "ARCV1-P256".

Group: P-256 (secp256r1)
- Order(): Return 0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551.
- Identity(): As defined in .
- Generator(): As defined in .
- RandomScalar(): Implemented by returning a uniformly random Scalar in the range [1, G.Order() - 1]. Refer to for implementation guidance.
- HashToGroup(x, info): Use hash_to_curve with suite P256_XMD:SHA-256_SSWU_RO_ , input x, and DST = "HashToGroup-" || contextString || info.
- HashToScalar(x, info): Use hash_to_field from using L = 48, expand_message_xmd with SHA-256, input x and DST = "HashToScalar-" || contextString || info, and prime modulus equal to Group.Order().
- ScalarInverse(s): Returns the multiplicative inverse of input Scalar s mod Group.Order().
- SerializeElement(A): Implemented using the compressed Elliptic-Curve-Point-to-Octet-String method according to ; Ne = 33.
- DeserializeElement(buf): Implemented by attempting to deserialize a 33-byte array to a public key using the compressed Octet-String-to-Elliptic-Curve-Point method according to , and then performs partial public-key validation as defined in section 5.6.2.3.4 of . This includes checking that the coordinates of the resulting point are in the correct range, that the point is on the curve, and that the point is not the point at infinity. Additionally, this function validates that the resulting element is not the group identity element. If these checks fail, deserialization returns an InputValidationError error.
- SerializeScalar(s): Implemented using the Field-Element-to-Octet-String conversion according to ; Ns = 32.
- DeserializeScalar(buf): Implemented by attempting to deserialize a Scalar from a 32-byte string using Octet-String-to-Field-Element from . This function can fail if the input does not represent a Scalar in the range [1, G.Order() - 1].

Random Scalar Generation Two popular algorithms for generating a random integer uniformly distributed in the range [1, G.Order() -1] are as follows:

Rejection Sampling Generate a random byte array with Ns bytes, and attempt to map to a Scalar by calling DeserializeScalar in constant time. If it succeeds and is non-zero, return the result. Otherwise, try again with another random byte array, until the procedure succeeds. Failure to implement DeserializeScalar in constant time can leak information about the underlying corresponding Scalar. As an optimization, if the group order is very close to a power of 2, it is acceptable to omit the rejection test completely. In particular, if the group order is p, and there is an integer b such that |p - 2^b| is less than 2^(b/2), then RandomScalar can simply return a uniformly random integer of at most b bits.

Random Number Generation Using Extra Random Bits Generate a random byte array with L = ceil(((3 * ceil(log2(G.Order()))) / 2) / 8) bytes, and interpret it as an integer; reduce the integer modulo G.Order() and return the result. See for the underlying derivation of L.

Security Considerations For arguments about correctness, unforgeability, anonymity, and blind issuance of the ARC protocol, see the "Formal Security Definitions for Keyed-Verification Anonymous Credentials" in . This section elaborates on unlinkability properties for ARC and other implementation details necessary for these properties to hold.

Credential Request Unlinkability Client credential requests are constructed such that the server cannot distinguish between any two credential requests from the same client and two requests from different clients. We refer to this property as issuance unlinkability. This property is achieved by the way the credential requests are constructed. In particular, each credential request consists of two Pedersen commitments with fresh blinding factors, which are used to commit to a freshly generated client secret and request context. The resulting request is therefore statistically hiding, and independent from other requests from the same client. More details about this unlinkability property can be found in and .

Credential Issuance Unlinkability The server commitment to x0 is defined as X0 = x0 * G.generatorG() + x0Blinding * G.GeneratorH(), following the definitions in . This is computationally binding to the secret key x0. This means that unless the discrete log is broken, the credentials issued under one server commitment X0, X1, ... will all be issued under the same private keys x0, x1, ... However, an adversary breaking the discrete log (e.g., a quantum adversary) can find pairs (x0, x0Blinding) and (x0', x0Blinding') both committing to X0 and use them to issue different credentials. This capability would let the adversary partitioning the client anonymity set by linking clients to the underlying secret used for credential issuance, i.e., x0 or x0'. This requires an active attack and therefore is not an immediate concern. Statistical anonymity is possible by committing to x0 and x0Blinding separately, as in . However, the security of this construction requires additional analysis.

Presentation Unlinkability Client credential presentations are constructed so that all presentations are indistinguishable, even if coming from the same user. We refer to this property as presentation unlinkability. This property is achieved by the way the credential presentations are constructed. The presentation elements [U, UPrimeCommit, m1Commit] are indistinguishable from all other presentations made from credentials issued with the same server keys, as detailed in . The indistinguishability set for these presentation elements is sum_{i=0}^c(p_i), where c is the number of credentials issued with the same server keys, and p_i is the number of presentations made for each of those credentials. The presentation elements [tag, nonceCommit, presentationContext, presentationProof, rangeProof] are indistinguishable from all presentations made from credentials issued with the same server keys for that presentationContext. The nonce is never revealed to the server since it is hidden within a Pedersen commitment. The range proof ensures the committed nonce is within the valid range [0, presentationLimit) without revealing its value. This provides strong unlinkability properties: the server cannot link presentations based on nonce values, as the nonce commitment uses a fresh random blinding factor for each presentation. The indistinguishability set for these presentation elements is sum_{i=0}^c(p_i[presentationContext]), where c is the number of credentials issued with the same server keys and p_i[presentationContext] is the number of presentations made for each of those credentials with the same presentationContext. Unlike protocols where nonces are revealed, presentations can not be linked by comparing nonce values, resulting in maximum unlinkability within the presentation context.

Timing Leaks To ensure no information is leaked during protocol execution, all operations that use secret data MUST run in constant time. This includes all prime-order group operations and proof-specific operations that operate on secret data, including proof generation and verification.

Alternatives considered ARC uses the MACGGM algebraic MAC as its underlying primitive, as detailed in and . This offers the benefit of having a lower credential size than MACDDH, which is an alternative algebraic MAC detailed in . The BBS anonymous credential scheme, as detailed in and its variants, is efficient and publicly verifiable, but requires pairings for verification. This is problematic for adoption because pairings are not supported as widely in software and hardware as non-pairing elliptic curves. It is possible to construct a keyed-verification variant of BBS which doesn't use pairings, as discussed in and . However these keyed-verification BBS variants require more analysis, proofs of security properties, and review to be considered mature enough for safe deployment.

IANA Considerations This document has no IANA actions.

Test Vectors

Seeded PRNG For interoperability, the random number generator used for test vectors is implemented using the SeededPRNG defined in Section A.1 of . The following sections contain test vectors for the ARC ciphersuites specified in this document.

ARCV1-P256

Acknowledgments The authors would like to acknowledge helpful conversations with Tommy Pauly about rate limiting and Privacy Pass integration, as well as Lena Heimberger for specifying the range proof.