Aggregate Signatures with Versatile Randomization and Issuer-Hiding Multi-Authority Anonymous Credentials

Anonymous credentials (AC) offer privacy in user-centric identity management. They enable users to authenticate anonymously, revealing only necessary attributes. With the rise of decentralized systems like self-sovereign identity, the demand for efficient AC systems in a decentralized setting has grown. Relying on conventional AC systems, however, require users to present independent credentials when obtaining them from different issuers, leading to increased complexity. AC systems should ideally support being multi-authority for efficient presentation of multiple credentials from various issuers. Another vital property is issuer hiding, ensuring that the issuer's identity remains concealed, revealing only compliance with the verifier's policy. This prevents unique identification based on the sole combination of credential issuers. To date, there exists no AC scheme satisfying both properties simultaneously. This paper introduces Issuer-Hiding Multi-Authority Anonymous Credentials (IhMA), utilizing two novel signature primitives: Aggregate Signatures with Randomizable Tags and Public Keys and Aggregate Mercurial Signatures. We provide two constructions of IhMA with different trade-offs based on these primitives and believe that they will have applications beyond IhMA. Besides defining the notations and rigorous security definitions for our primitives, we provide provably secure and efficient constructions, and present benchmarks to showcase practical efficiency.


INTRODUCTION
Authentication and authorization are essential and security-critical tasks in a digital world.They are aimed to ensure that the communication partner is the one it claims to be and to enforce access control to digital resources such as services.A central concept is that of a digital identity, which can be seen as a collection of attributes (e.g., name, age, nationality, gender, etc.) representing a (real-world) entity in the digital realm.
On the Internet, a widely adopted practice is to have centralized identity providers (IdP), e.g., Google or Meta, to maintain the digital identity of users.Other services can then simply rely on the identity provided by the IdP.From a privacy perspective, however, this is problematic as users lose control over their digital identity (all their attributes reside at the IdP), and the IdP learns all the services a user consumes on the Internet (and data related to the use).
Already in the 1980s, Chaum [24,25] envisioned cryptographic techniques for creating more privacy-friendly and user-centric solutions to authentication and authorization.They put users in control of their identity and allow users to selectively reveal information (i.e., attributes) about their digital identities in an unlinkable and thus untraceable way.Such techniques are commonly known as anonymous credentials (ACs), and there is a vast body of research into different approaches to construct such AC systems [2, 3, 12, 17-20, 27, 32, 35, 39, 49, 52, 54].
While early AC systems such as U-Prove [51] and Idemix [22] did not see a widespread adoption, nowadays related techniques such as direct anonymous attestation (DAA) [14,15] and Enhanced Privacy ID (EPID) [13] are deployed in billions of devices.Most recently, ACs have seen adoption within the popular Signal messenger to realize private groups [23].They also see increasing popularity in the form of anonymous tokens (with private or public metadata bit) [31,42,56].Among the applications are private browsing with DDoS protection being standardized by the IETF1 (Privacy Pass [31] and Private Access Tokens [45]) or the PrivateStats by Facebook 2 to privately collect client-side telemetry from WhatsApp.Decentralized identity.Like with centralized IdPs, all AC solutions mentioned so far are in a centralized setting, i.e., a single party called the issuer is issuing credentials to users.Today we however see a trend to move away from this centralized setting towards a decentralized identity.A popular concept in the decentralized identity space is that of self-sovereign identity (SSI) with Sovrin 3 being a prominent example.In SSI users are collecting certified attributes (called verifiable credentials) from different sources and then presenting (subsets of) verifiable credentials from this collection.There is an increasing push towards standardization of this verifiable credentials concept within W3C 4 and large efforts such as the future European data infrastructure (Gaia-X) 5 or the European Blockchain Services Infrastructure (EBSI) 6 are adopting this approach.
Within the verifiable credential initiative in W3C, it is also observed that privacy related features are important.In particular well-known features from AC systems such as supporting selective disclosure and proving predicates about attributes 7 .To realize this functionality within W3C it is intended to base this upon the BBS+ signature scheme 8 , a well-known building block for ACs currently being standardized as the BBS variant [58] within the IETF 9 .Privacy in a decentralized setting.The aforementioned approach allows to preserve privacy in a setting where a user wants to show a single verifiable credential issued by a single party.However, for a decentralized setting, where typically a subset of a collection of verifiable credentials from different issuers needs to be shown, the problem of how to efficiently realize this arises.A naive way is to conduct a parallel credential showing with all the required verifiable credentials.However, apart from reduced efficiency, this also has privacy implications.In particular, every verifiable credential reveals the exact issuer providing a lot of contextual partial information, e.g., a passport issued from a certain country or a driving license issued by a certain state reveals geographic information.This can be highly privacy intrusive in many settings and undermining the very objective of SSI systems [10].Consequently, it would be desirable to be able to show a credential in a way that it is only revealed that it comes from one of a larger set of issuers acceptable by a verifier.A set of recent independent works introduced a property providing this features for AC systems, which is called issuer-hiding [6,10,27].While this is a step towards countering the above privacy issues, these works only consider single issuers and are thus not yet suitable for a decentralized setting with multiple issuers.
ACs in a decentralized setting.Due to not being directly comparable as they are either only threshold or require a dedicated infrastructure (i.e., a transparency log, Byzantine system, or a blockchain) and TDAC by [49] and the lack of space we defer to [47] for a discussion of existing approaches in a decentralized setting due to Garman et al. [36], Sonnino et al. [57], Doerner et al. [33] and Rosenberg et al. [53].
Finally, and most related, we want to discuss the work by Hébant and Pointcheval [40].The authors introduced the concept of (traceable) Multi-Authority Anonymous Credentials (MA-ACs).Loosely speaking, their approach to realize MA-ACs is based on so called aggregate signatures with randomizable tags and allows to aggregate showings of credentials of different issuers (but with respect to the same tag) into one compact showing.Due to randomizability of signatures and tags, it is possible to produce unlinkable showings.Moreover, the tag component has a secret part representing the user secret.While this is an interesting concept, it does not provide an efficient way of providing the issuer-hiding (IH) feature [6,10,27].There is an obvious generic way to use a succinct NIZK (i.e., a zk-SNARK) and prove that the aggregated signature verifies for the given attributes under a subset of issuer keys without revealing which ones.While this can lead to an asymptotically compact solution, the prover will concretely be very expensive due to the size of the verification keys (they are of size G 3+2 efficient decentralized AC systems with advanced properties.We will close this gap by introducing aggregate (structure-preserving) signatures with the ability to randomize signatures, tags, (messages,) and verification keys.

Our Contribution
Our contribution in this paper is twofold: Aggregate signatures with randomization features.The key technique to achieve our goal is to introduce tag-based aggregate signatures with randomizable tags and public keys.We further extend them to additionally support randomization of messages resembling the functionality of equivalence class signatures (SPSEQ) [35].For both of these types of schemes we provide rigorous formal security models as well as instantiations that are provably secure in this model.More precisely, we introduce: Aggregate signatures with randomizable keys and tags (AtoSa10 for short) where signatures are associated to tags (consisting of a private and a public part) and signatures with respect to the same tag can be aggregated.Aside from signatures, verification keys and tags can be randomized.Tags and verification keys are defined with respect to equivalence classes and randomization switches between representatives of these classes. 11Then existing signatures can be adapted to ones that verify under the randomized public keys and tags.We provide an AtoSa scheme based on the well-known Pointcheval-Sanders (PS) signatures [52].PS signatures have already served as a basis for various privacy-preserving primitives such as group signatures and anonymous credentials [52], redactable [54,55] or dynamically malleable signatures [5].They are very efficient and have interesting features such as support for blind signing, i.e., signing of committed (hidden) messages, and efficient ways of proving their knowledge.Aggregate Mercurial Signatures with Randomizable Tags (ATMS) extend the functionality of AtoSa to support the randomization of messages, i.e., equivalence classes of messages similar to (SPSEQ).This means that in addition to AtoSa existing signatures can be adapted to verify under randomized messages (i.e., other representatives of the message class).Consequently, we obtain a version of mercurial signatures [30] that is both aggregatable and has randomizable tags.To the best of our knowledge, this is the first instance of an aggregate structure-preserving signature (and, additionally the first aggregatable SPSEQ).We provide an ATMS construction inspired by the message-indexed SPS in [29], which on itself is a variant of Ghadafi's SPS [37] scheme.Restrictions of our Constructions.We should mention that in contrast to standard aggregate signatures, our constructions 1) either require that all aggregated messages and corresponding verification keys are known before requesting the first signature or 2) to make the same assumption as within synchronized aggregate signatures [1,41].In particular, adapted to our setting, latter means that every issuer ensures that for each tag only a single signature is issued.We will present our results based on the first approach and discuss adaptions for the second (which do not change any of the interfaces or security definitions and proofs).Since our main application is anonymous credentials, depending on the concrete application scenario either the first or the second approach can be chosen.It remains an interesting open question to get fully dynamic signatures without any of the above assumptions.
Like other types of signatures with randomization features, we also expect that our schemes will find applications beyond the one presented here.
Issuer-Hiding Multi-Authority Anonymous Credentials.We present a rigorous formal model for issuer-hiding multi-authority anonymous credentials (IhMA).Then we present two constructions based on AtoSa (called IhMA AtoSa ) and ATMS (called IhMA ATMS ) respectively, where both are concretely very efficient but offer some trade-offs (as discussed below).Thus this represents an important contribution to the field of ACs in that it provides a solution that addresses the challenges of user privacy and scalability in multiauthority (decentralizing) settings.In our constructions, obtaining a credential amounts to obtaining signatures on desired attributes from a set of issuers on different attributes, but under the same tag (which can be thought of as the user's identity in credential schemes).Showing simply amounts to randomizing signatures from issuers that should be shown as well as the tags and aggregating them.Finally, one provides the aggregated signature and either opens (subsets of) attributes or proves predicates over them along with proof of knowledge of the secret tag part.
Supporting the issuer-hiding feature [7,27] works roughly as follows: Each verifier generates a so-called key-policy, which defines a set of issuers (via their verification keys) that the verifier would accept an (aggregated) credential from.This policy is a collection of SPSEQ signatures on verification keys of the AtoSa or ATMS scheme.Since the equivalence classes of the SPSEQ (the message space) match with the key equivalence class of AtoSa and ATMS, showing a credential then works as above, but all verification keys of the AtoSa or ATMS are randomized, and the respective SPSEQ signatures in the key-policy are adapted accordingly.
For the IhMA ATMS scheme, instead of directly signing attributes, we use the framework of Fuchsbauer et al. [35].Here the signature scheme is used to sign set commitments to attribute sets.Moreover, in order to prove the anonymity of this construction as an additional contribution we introduce a generalization of the decisional uber assumption family by Boyen [11] along with an interactive version.Using this approach is however not straightforward as we have to make set commitments compatible with the message space of our ATMS.While IhMA AtoSa and IhMA ATMS share a common aim, the differences in constructions entail certain trade-offs in terms of functionality and efficiency: • Credential size: The IhMA ATMS scheme can yield a fixed-sized credential, while the IhMA AtoSa scheme does not achieve this without utilizing Zero Knowledge Proof of Knowledge (ZKPOK) of signatures.• Efficiency: The IhMA ATMS scheme is more efficient at showing and verifying credentials compared to the IhMA AtoSa scheme.• Need for a trusted party: The IhMA ATMS scheme requires a trusted party, while the IhMA AtoSa scheme does not.This is because IhMA ATMS relies on a trusted party to hold a trapdoor to generate set commitments, whereas IhMA AtoSa does not require such a trusted party.• Expressiveness: The IhMA ATMS supports revealing a subset of attributes from a set of attributes per issuer, i.e., selective disclosure per issuer.The IhMA AtoSa scheme only supports a single attribute for each credential.Consequently, it only supports selective disclosure over all issuers.However, both schemes allow for proving arbitrary predicates over signed messages.
Overall, the choice of the concrete construction depends on the specifics of the use case or application and priorities set in the overall system.

Comparison of IhMA with Previous Work
We have already discussed that there is only one dedicated MA-AC scheme [40].This is however not issuer-hiding (IH) and as mentioned, adding IH comes with a significant overhead.In Table 1, we compare our IhMA approaches to other schemes in the literature that provide the IH feature [6,10,27] and for comparison we use the naive approach to achieve MA, i.e., parallel showings of single credentials, which we indicate by ≈.We compare them in terms of the size of credential |Cred|, communication cost of showing |Show|, and computational cost of showing Show for user (P) and verifier (V).We provide concrete analysis for our schemes' communication cost in our full version [47].To ensure a fair comparison between the schemes, we consider a typical case of  out of  attributes from  out of  issuers where  is the total number of attributes given to the user by  issuers, and  is the number of attributes involved in the showing (and  the number of issuers involved).
With respect to credential size |Cred|, the naive approach to MA leads to  () complexity.Our IhMA ATMS scheme maintains a constant credential size even when there are  > 1 issuers, while our IhMA AtoSa scheme has  () credentials.However, we can aggregate credentials and then during showing apply a ZKPOK of a PS signature, which allows us to reduce the credential size to a constant size.In contrast, others have a credential size linear in the number of issuers .
In terms of communication cost in showing (|Show|), our schemes require sending the randomized vks of the  issuers, along with two signatures (one for the credential and one for the key policy), overall giving  ().In [6], the communication size is based on sending  blinded credentials and  blinded signatures in the key policy and provide a ZKPOK of having correctly done so.The scheme in [10] is similar to [6], but the size of the policy is fixed.Finally, in the scheme described in [27], one needs to prove knowledge of  out of  verification keys (a linear sized OR statement) and sends them along with  credentials.Note that the size of ZKPOK includes many group elements and significantly more than only transferring  verification keys, as it is the case for our constructions.
When it comes to the computational cost of showing, i.e., Show (P) and Show (V), our IhMA AtoSa scheme has a minimal computational cost for provers as they only need to perform a small/constant number of operations for aggregation, along with  exponentiations for randomizing the verification keys vk.Our IhMA ATMS scheme involves additional computation in the creation of a witness for set commitments corresponding to undisclosed attributes (a multi-exponentiation of  ()).In [6], this cost includes proving knowledge of  signatures (in the key policy),  credentials, and  disclosed attributes.Similarly, [10] requires the computation of generating witness for their aggregator (accumulator) on  credentials, proving knowledge of  credential, but it does not need to prove knowledge of signatures in the policy.Moreover, in [27], proving knowledge of -out-of- verification keys is necessary, along with the computation of generating witness on undisclosed attributes for set commitments on  credentials.Again, the cost of ZKPOK for credentials or committed attributes is significantly more expensive than in our case, which is needed only to prove a secret key and some multi-exponentiation for creating witness.We should mention here that by leveraging ZKPOK, arbitrary relationships can be proved on attributes.
In summary, while the efficiency of different schemes may appear to be close asymptotically, our IhMA approaches are significantly more efficient than existing approaches while providing both properties simultaneously.Indeed, we only need  () group operations in G  .In contrast, other schemes require proving knowledge of signatures or keys, which is significantly more expensive.

PRELIMINARIES
Notation.We use BG = (, G 1 , G 2 , G  , , , P) ← BGGen(1  ) to denote a bilinear group generator for asymmetric type 3 groups, where  is a prime of bitlength .When applying a scalar  componentwise to a vector T ∈ G  1 we write T  = (  1 ,  2 , . . .,   ).We write [] R to denotes denote representative  of the equivalence class for given relation R. Given a finite set , we denote by  ←  or  $ ←  the sampling of an element uniformly at random from .For an algorithm A, let  ← A() be the process of running A on input  with access to uniformly random coins and assigning the result to .With A B we denote that A has oracle access to B. We use ⟨O⟩ to denote oracles defined in games and use  to indicate a negligible function.We assume all algorithms are polynomial-time (PPT) unless otherwise specified and public parameters are an implicit input to all algorithms in a scheme.

Indexed Diffie-Hellman Message Space M 𝐻
iDH [29].Given a bilinear group (G 1 , G 2 , G  , , , , ĝ) ← BGGen(1  ), an index set I, and a random oracle  : One can efficiently decide subset membership by checking  (, P) =  (ℎ,  ).The uniqueness property guarantees that no two messages use the same index, which needs to be ensured by signers.We use the Camenisch-Stadler notation [21] for ZKPOK.Please refer to the full version for complete definitions [47].

AGGREGATE SIGNATURES WITH RANDOMIZABLE KEYS AND TAGS
Now we introduce a novel primitive named AtoSa where one can aggregate signatures of different messages under different keys ★ We present the scheme in a way that supports ad-hoc attribute/issuer aggregation, but for fixed signatures, a constant size credential is achievable.For ATMS we will show how to achieve this in Section 5.2.★★  refers to proving knowledge of  credentials and  signatures of key policy in Showing.
† Since the ad-hoc aggregation cost is negligible, it is skipped here.Also, without considering IH, it becomes  (1).‡ This scheme uses standard assumptions in the ROM while other schemes use the GGM.
only if they are associated with the same tag (consisting of a private and a public part).Moreover, apart from allowing randomizing signatures, verification keys as well as tags can be randomized.Unlike mercurial signatures, our AtoSa scheme does not allow for randomization of messages.Tags and verification keys are defined with respect to equivalence classes and randomization switches between representatives of these classes.We introduce a comprehensive formal model and a construction which as a starting point takes PS signatures [52].For our AtoSa scheme we show how to integrate tags into PS signatures, use the above discussed features to make them aggregatable, and show that the key-randomization features of PS signatures (cf.[26] with Δ 2 = 0) applies to our modification.

Formal Definitions
The public key randomization is similar to that of mercurial signatures [30], which allow to define equivalence classes on the key space [vk] R vk , [sk] R sk .Let a tag be (, T), where  and T are the secret and public parts of tag respectively.For the tag randomization, we define equivalence classes [T] R  ([] R  for secret parts) on the tag space T similar to [vk] R vk and [sk] R sk as: We denote the space of all tags as T and the messages space is Z  .In contrast to SPSEQ (and mercurial) signatures, we do not consider equivalence classes on the message space for AtoSa.
Definition 1 (Aggregate Signatures with Randomizable Public Keys and Tag (AtoSa)).An AtoSa for parameterized equivalence relations R  , R sk and R vk , consists of the following algorithms: Setup(1  ) → pp: On input the security parameter , output the public parameters pp.KeyGen (pp) → (sk, vk): On input the public parameters pp, output a key pair (sk, vk).VKeyGen (sk): On input a secret key sk, output a verification key vk.We note that VKeyGen is only required in the security definition and is never used in the construction.Although the signer receives the tag secret key , we replace this with a ZKP in our IhMA scheme.

Security Definitions
Correctness.We require that honest signatures verify as expected, but need to consider all the randomizations and aggregation.Unforgeability.We model unforgeability following the ideas in the chosen-key model [9,46], where the adversary A is given a single public key vk ′ and access to a signing oracle on the challenge key.The adversary wins if the aggregate signature, , is a valid aggregate signature on a vector of messages M = ( 1 , . . .,   ) under keys (vk 1 , . . ., vk  ), and  is nontrivial, i.e., the adversary did not request a signature on a   for vk  = vk ′ or more precisely where vk  is in the same equivalence class as the challenge key vk ′ .
A has the power to choose all public keys except the challenger's public key vk ′ .For our instantiation, however, we have to work in a slightly weakened model which is equivalent to the certified-keys model [43,44].In this setting the A registers pairs of (vk, sk) with exception of the challenge key.To model this, we have the adversary output the secret keys of the verification keys they provide in our security games.In the real world, such a key registration can be realized by requiring issuers to prove knowledge of their sk, which in the formal analysis allows a reduction to extract the secret key.
Definition 2 (Unforgeability).An AtoSa signature is unforgeable if for all PPT algorithms A having access to the oracle O Sign() , there exists a negligible function  such that: where the experiment ExpUnf AtoSa,A () is defined in Fig. 1 and  is the set of queries that A has issued to the O Sign .
Privacy guarantees.Similar to mercurial signatures [30], we define the following privacy notion for randomized keys vk and tags: Definition 3 (Public key class-hiding).For all PPT adversaries A, and pp ← Setup(1  ) there exists a negligible  such that:

+𝜖 (𝜆)
Definition 4 (Tag class-hiding).For all PPT adversaries A there is a negligible function  (•) such that The tag class-hiding property for R  is implied by the DDH assumption.
The following definition guarantees that a signature with tag T on a message  under vk output by ConvertSig and fed into RndSigTag produces a uniformly random signature under a uniformly random tag (from the respective tag class) and uniformly random key (from the respective key class).

Construction
We construct the AtoSa scheme based on the PS signature [52].We can observe that to make PS signatures (ℎ  ,   ) aggregateable, we need the ℎ  components to be identical for all signatures to be aggregated.While in the original PS construction ℎ is a random element independently chosen during signing, this can be emulated in AtoSa by generating ℎ for all signatures via a hash function based on some common information embedded in aux.For example, aux, could be a concatenation of all the messages and the tag.This technique was implicitly used in Coconut [57] and Camenisch et al. [16], and has recently been formalized by Crites et al. in [29].
We note that we should be careful when computing ℎ, i.e., in choosing aux, as in PS signatures one can forge signatures when obtaining two signatures on two different messages with respect to the same element ℎ.To prevent forgeries when aiming to aggregate signatures, a unique base ℎ for a set of messages signed under the same tag is required.Therefore, we compute ℎ as a hash of a concatenation of the messages to be signed and corresponding verification keys, denoted as aux.This approach ensures that every signer computes signatures on the same base ℎ.We also introduce a new definition and function: Aux binding.To ensure this property of ℎ while making our construction modular, we define a straightforward property of GenAuxTag(), i.e., no adversary can "open" an aux to two messages for the same signer.This definition is paired with the function VerifyAux which is called by Sign.
Definition 7 (Aux binding).We split aux into a preimage and an opening: (, ).For all PPT A, and pp ← Setup(1  ) and (sk, vk) ← VKeyGen(1  ) there exists a negligible  such that: We will then hash the preimage,  in our construction to reduce to the GPS assumption [29] effectively.The  value in this definition may seem unnecessary, but it will become useful when we introduce our IhMA construction in Section 5. We've left aux binding out of our definition and rather defined it in our construction in order to make our definition more generic as aux binding is simply a property we use in the proof to ensure that our construction satisfies the definition of AtoSa.
Synchronicity assumption.We note that when we do not want to fix messages and verification keys in aux beforehand, then we can make assumption as in synchronized aggregate signatures [1,41] and require each signer to only issue a single signature per tag.In this case aux only contains the tag and in the construction below we set  =   1 ||  2 and Definition 7 is trivially satisfied.
We involve the tag in signatures by exponentiating the component ℎ with the secret part of the tag ℎ  and compute the component  using this value, which clearly can be checked via a pairing with the tag's public part and verified like a standard PS signature.Moreover, AtoSa allows the randomization of tag, vk and signatures via a change of representatives tag, vk and a matching signature update.
ExpUnf AtoSa,A (): O Sign (, aux, (, T)): •  ← Sign(sk ′ , , aux, ) Our construction.The construction is as follows: . Next set all aux  = (, ⊥).Compute ℎ =  () and output aux and a tag pair Verify(vk  , T,   ,   ): Given a vk  , tag T = ( 1 , 2 ), message   and signature   , parse   as ℎ ′ ,   and return 1 if the following checks hold and 0 otherwise: ConvertTag(T, ) → T ′ : On input a tag T and randomness , output a randomized tag 2 ).RndSigTag(vk, T, , , ) → ( ′ , T ′ ): Given a signature  on message  under a valid tag T and vk, and randomness .Return a randomized signature  ′ and a randomized tag: where is a valid signature for a new tag representative The correctness of our construction follows from inspection.We formally show the unforgeability and privacy notations.
Theorem 8 (Unforgeability).Our construction achieves the EUF-CMA security stated in Def 2, under the hardness of GPS assumption, in the random oracle model.Theorem 9 (Privacy).Our construction is origin-hiding of Con-vertSig, origin-hiding of RndSigTag, tag class hiding and has public key class-hiding based on Def. 5, Def. 6, Def. 4, and Def. 3, respectively.
The proofs of Theorem 9 and Theorem 8 are provided in the full version [47].

AGGREGATE MERCURIAL SIGNATURES WITH RANDOMIZABLE TAGS
We now present an aggregate mercurial signature with randomizable tags (ATMS).Similar to AtoSa, (see Def. 1), one can aggregate mercurial signatures of different messages under different keys under the same tag and randomize those signatures, public keys, and tags.ATMS differs from AtoSa by in addition supporting equivalence classes on the message space.This further allows the randomization of messages, leading to a feature known from structure-preserving signature on equivalence classes (SPSEQ) and, more precisely, mercurial signatures.
To achieve the aggregation property, we follow the strategy presented by Crites et al. in context of threshold SPS [29], where the authors define a so called Indexed Diffie-Hellman message space M  iDH .But the main problem with this approach, as it is defined over both groups, is that we can not define indistinguishable equivalence classes over G  1 × G  2 , since spanning both groups makes DDH easy and would yield trivial linkability.Note that given both (( 1 ,  2 ), ( TDH and its corresponding EQ relation.We essentially define one equivalence class per group and tie them together via the message, the tag, and an index obtained via some auxiliary information (similar to the aux in the case of AtoSa).Indeed we adapt the Diffie-Hellman message space M DH to a Tag-based DH message space M  TDH for a tuple (aux, ℎ, T, ,  ), which includes a tag T with auxiliary data aux (instead of the ).
This new message space then allows us to aggregate and define an equivalence (EQ) relation which gives an indistinguishable message space.

Formal Definitions
We begin our definitions by introducing Tag-based DH message space M  TDH and give an instantiation in the random oracle model (ROM).Then we define a new EQ relation regarding this message space M  TDH , and finally, we define our new primitive ATMS.A Tag-based DH message space.We adapt the message indexing technique introduced by [29] (cf.Def. 2) to tags: Definition 10 (A Tag-based DH message space (M  TDH )).Let  be a random oracle.For the aux and tag T = (ℎ   )  ∈ [ ] , we define M  TDH as a tag based DH message space, if the following property hold: For the messages vector (M, N) = ( 1 , . . .,   ,  1 , . . .,   ) there exists   ∈ Z  s.t. for each tuple (aux,  = ℎ   ,   =     ,   = P  ), the following holds:  (  , P) =  (  ,   ).
We provide an instantiation in Fig. 2. Let us assume WLOG a message vector with the length  = 2 as m = ( 1 ,  2 ), this can be generalized to any length  > 1.  of messages and keys, output auxiliary data aux  and a tag pair (, T) where  is the secret part and T is the public part of tag and all vk  should be distinct.Sign(sk  , , aux  , (M  , N  )) →   : On input a secret key sk  , tag's secret , auxiliary data aux  and message vector (M  , N  ) ∈ M  TDH , output a signature   under the , vk  and (M  , N  ).Verify(vk  , T, (M  , N  ),   ) → {0, 1}: Given a verification key vk  , tag's public T, message vector (M  , N  ) and signature   , output 1 if   is valid relative to vk  , (M  , N  ) and T, and 0 otherwise.VerifyTag(T, , ) → {0, 1}: Given a tag's public T, tag's secret signature , output 1 if T is valid relative to , and , and 0 otherwise.

Security Definitions
Correctness.As usual we require that honest signatures verify as expected, but need to consider all the randomizations as well as the aggregation.
Unforgeability.The unforgeability game follows the unforgeability definition of AtoSa (see Def. 2).It is slightly modified to fit with our additional EQ relation (Def.11), i.e., unforgeability is defined with respect to message classes and in addition need to check VerifyTag.

Definition 13 (Unforgeability
).An ATMS is unforgeable if for all PPT A having access to the oracle O Sign() there exists a negligible function  s.t: Pr[ExpUnf ATMS,A () = 1] ≤  () where the experiment ExpUnf ATMS,A () is defined in Fig. 3 and  is the set of queries that A has issued to O Sign() .
However, since this is a variant of SPSEQ we consider the adaption property similar to [35] below, an additional property which guarantees that signatures from ChangRep and Sign are identically distributed.This definition also covers Origin-hiding of ConvertTag.

Construction
Our construction is inspired by the message-indexed SPS by Crites et al. [29], which is a variant of Ghadafi's SPS [37].We use the tagbased message definition M  TDH (Def.10) instead of the messageindexed (Def.2).For simplicity, we assume a message vector with the length  = 2 as (M, N) = (( 1 ,  2 ), ( 1 ,  2 )), but this can be straightforwardly generalized to any length  > 1.Similar to the construction in Section 3.3, we again need aux binding to make this particular construction work.
Definition 16 (Aux binding for ATMs).We split aux into a preimage and an opening: (, ).For all PPT A, and pp ← Setup(1  ) and (sk, vk) ← VKeyGen(1  ) there exists a negligible  such that: Synchronicity assumption.Same as in Section 3.3, instead of fixing messages and verification keys in aux, we can make same assumption as in synchronized aggregate signatures and simply set  =   1 ||  2 in the construction below and Definition 7 is trivially satisfied.

Note that one can reduce the number of paring operations in
VerifyAggr by using batching verification techniques (cf.[34]).
Theorem 18 (Unforgeability).Our construction is EUF-CMA secure regarding the definition 13 in the generic group model for Type-III bilinear groups.
The proofs of Theorem 18 and Theorem 17 are provided in the full version [47].

APPLICATION TO AC
As our core application we present Issuer-Hiding Multi-Authority Anonymous Credentials (IhMA).In a multi-authority setting [40], credentials come from ℓ-different credential issuers.Naively, the showing of credentials requires ℓ-independent credentials to be shown.This can be overcome [40] by leveraging aggregate signatures, obtaining a compact AC system with compact-size credentials, and showing costs.However, verifying a user's credentials needs knowledge of all issuers' verification keys, which might violate user privacy.Thus, in the vein of [6] we introduce the issuer-hiding property for multi-authority credentials.We recall that here the verifier can define a set of acceptable issuers in an ad-hoc manner.Then a user can prove that the subset of credentials shown were issued by acceptable issuers without revealing which credential corresponds to which issuer.This is an important feature, especially in multi-authority settings where disclosing issuer keys can reveal too much information compared to a single issuer setting and already lead to identification of the user.

Formal Definition
Our definition supports multiple users (  )  ∈ [ℓ ] and multiple credential issuers (CI  )  ∈ [ℓ ] .An issuer can generate a key pair of secret and verification keys (sk, vk) via IKeyGen().Similarly, users runs UKeyGen() to generate a user key pair (sk, vk).Each issuer can then issue a credential (cred) on an attribute () or attribute-set (A) to a user who can verify the received credential locally.Indeed, when we use AtoSa, we consider an attribute  (i.e., the attribute set includes only one attribute); when we use ATMS, we consider an attribute set, A. We use the notation A, to define security and formal definitions for consistency of definitions.
Users can then use the CredAggr algorithm to aggregate all credentials and create a single credential valid for all attributes and verification keys.To define the set of accepted issuers, a verifier generates a key-policy  using GenPolicies (it is known as Presentation policies in [6]), which can be checked for well-formedness by everyone.Finally, with an aggregate credential (disclosing a subset attributes ) and some key-policy  from the verifier, a user uses Show to derive a proof, which a verifier can verify.
Definition 19 (Issuer-Hiding Multi-Authority Credentials (IhMA)).An IhMA is defined by the following algorithms/protocols: • Setup: On input a security parameter , output public parameters pp (implicit input to all algorithms) .• IKeyGen: Generate a key pair (sk, vk) for an issuer .
• UKeyGen: Take a message-key set , generate a user key pair (sk, vk) which acts as user's identity and auxiliary data aux.Due to the lack of space we refer to the full version [47] for our security model.

Constructions
Now we are ready to describes our two constructions of IhMA, the first being based on AtoSa (Def. 1) and SPSEQ [35] and the second based on ATMS (Def.12), a set commitment scheme SC [35,48], and SPSEQ.To enhance users' privacy and prevent issuers from learning attributes issued by other issuers, we change how aux for the signatures is computed.In particular, we commit to the attributes (messages) instead of including them in plaintext.For example, this can be achieved using a hash-based commitment scheme, where a commitment value  is generated by computing  :=  ′ (,  ) with  ′ being a hash function modeled as a random oracle,  being the attributing being committed to, and  a sufficiently large random value.When issuing a credential, users can reveal the relevant message (attribute) , the opening , and the commitment value .The signer then verifies if the  is correct for  and  before issuing the corresponding credential.We modify GenAuxTag(S) and VerifyAux in AtoSa and ATMS as follows: • GenAuxTag(S): where    is a hash commitment to 'th message and all vk are distinct.Output aux = (,   ) and tag  = (( 1 ,  2 ), ( 1 = ℎ  1 , 2 = ℎ  2 )) with ℎ =  ().
• VerifyAux(sk, aux, ,   ) Parse aux as (, ).Check that  ∈  (i.e., that  has the form:   1 ||  2 ||...) check that   exists such that (  , vk) ∈  and Open(  , ,   ) = 1 where vk is a verification key related to sk (in the same equivalence class).Also check that no other vk in aux has the same equivalence class as sk.
In our IhMA schemes, tags are user identities and are used to verify the user before issuing attributes.

5.2.1
AtoSa based IhMA Construction in Fig. 4. Here, every issuer creates a credential (signature)  1 on an attribute   for the user  with tag  (and the respective aux) verified with vk by the AtoSa scheme.We cannot reveal the secret part of the tag to signers (issuers) as this would violate the security of the user.To obtain a credential through the Issuing protocols, a user is required to disclose the public parts of tag as identity to the issuer and then authenticate their identity via a ZKPOK.Interactive signing.We can adapt the signing in a way that signers (issuers) don't learn ( 1 ,  2 ) as follows: •  sends (aux, (ℎ, T), ), where aux We note that this interactive signing outputs signatures that are identical to that output by Sign and this is used in Issuance.For the Show protocol, we assume that verifier(s) have signed all accepted issuer keys using an SPSEQ scheme [35].A user  can take  and the set of disclosed credentials , aggregates the respective credentials (signatures) and randomizes the aggregated signature and tag.We note that alternatively, a user could already after Issuance aggregate all credentials to a constant-size (single) credential and then in Show protocol can provide a ZKPOK of the signature and selectively disclose the required attributes (as originally done for PS signatures in [52]).This also yields constant size credentials as noted in Table 1.We stick with the former approach here as it is more efficient for showing credentials, but one can easily switch to the other option.Moreover, In IhMA AtoSa , only one attribute per vk can be issued.However, if an issuer needs to issue multiple attributes, they can easily generate multiple vks.
To hide the issuer's keys,  randomizes them using a random  and adapts the signature for these randomized keys using ConvertSig.So far, we have created a compact randomized credential (proof) for attributes in  where issuer verification keys of this signature are hidden.The next step is to show that these random verification keys correspond to those keys signed by the verifier (using SPSEQ signatures) in .In this direction,  first collects signatures in  according to issuer keys that are needed in the proof.Then  runs ChangRep of SPSEQ to randomize messages (which are issuer public keys) and signatures with the same randomness  used in convert, i.e., randomized keys.Randomized issuer keys in a credential match with the messages signed by verifier in .
Finally,  uses the randomized tag as a pseudonym for communication and provides a ZKPOK of secret part of tag (secret keys and randomness) used in the credentials.

ATMS based
IhMA Construction in Fig. 5.We use the framework in [35] in which one can combine mercurial or SPSEQ with a set commitment such that a credential is a signature on set commitment SC.One can then open a subset of messages from this commitment while randomizing both set commitment and signature together.This provides unlinkability and selective disclosure at the same time (see [35]).Unlike the previous construction, we can aggregate credentials immediately after receiving them and have a constant-size credential but still avoid zero-knowledge proof of a signature in showing protocol (because of compatibility of EQ message relation of ATMS and SC randomization).
In the Show protocol, similar to the previous construction,  first collects the signatures required to prove the attributes  from .Then, for issuer-hiding similar to AtoSa it randomizes these SPSEQ signatures using ChangRep of SPSEQ with .For preparing a proof for , a user () randomizes issuer verification keys in credentials using ConvertVK and converts the ATMS signature using ConvertSig with .Subsequently,  randomizes the signature with a tag using ChangRep.Finally,  opens a subset of attributes  from the set commitments.Now a verifier can check if these attributes are in the set commitments signed by some issuers in .Same as in the first construction, since all issuer keys are randomized due to the SPSEQ signature the issuers are hidden.We run a ZKPOK to prove that  knows all secret values related to the randomized tag like before.The only point left is the signing of set commitments, which is defined in one source group in [35], but we need both groups.Subsequently, we show how one can combine set commitments with a tag-based DH message space.
Then, TA and  interact to computes ( ( Ĉ , C  ) ∈ [ℓ ] ) ← SC.Commit 3 (A  , , T), for all attribute sets.-Issuance: The interaction between an issuer  and a user  for one attribute-set A ∈ Z p and (C, Ĉ) acts as follows: •  hands over (T, (C, Ĉ), aux  ,  ) to an issuer , where  is zero knowledge proof the secret parts of the tag.
• An issuer  checks that the proof is correct, then runs  ← Σ   converting messages to the M  TDH message space and generating tags.While in AtoSa, PC includes generating tags and aux using Pedersen commitment, but note that one could also use a hash based commitment instead.We can observe that signing is faster than verifying the signature -due to the pairing operation in the latter.Moreover, verification of ATMS is slower than AtoSa because of additional pairing operations that are needed to check if messages are in M  TDH .We increase the number () of signers from 2 to 10     open question is whether it is possible to present constructions in a fully dynamic setting, i.e., there are no assumptions about prior knowledge of messages and verification keys, nor requirement for a stateful issuer to keep track of the signed information aux.2) Revocation is another intriguing avenue.While issuer revocation in our scheme is straightforward, as revoked issuers can be excluded from the key policy, user revocation poses greater challenges.The user revocation within our framework, and for issuer-hiding anonymous credentials in general, are an interesting future work.

Figure 2 :
Figure 2: Tag based Diffie-Hellman message space in ROM Note that the EQ relation for an aggregate signature on a set of vectors M = ((M  , N  ))  ∈ [ℓ ] is the family (set) of relation as above, while all vectors use the same randomness M = ((M   , N   ))  ∈ [ℓ ] .For instance, the 'th message vector (M  , N  ) ∈ [(M, N)] R  TDH is in the class R  TDH ∈ IR ℓ and if one more signature-message pair is added to the set, we have R +1 TDH ∈ IR ℓ , where  + 1 < ℓ.Moreover, we consider the EQ relation for verification keys vk and Tag similar to AtoSa and indicate as R vk and R  as stated in Def.3.1.We again denote by T the space of all tags and present the ATMS in Def.12. Definition 12 (Aggregate Mercurial Signatures with Randomizable Tag (ATMS)).An ATMS scheme, associated with the parameterized equivalence relations IR ℓ , R TDH , R  and R vk , and also message space M  TDH consists of the algorithms: Setup(1  ) → pp: On input the security parameter , output the public parameters pp.KeyGen (pp) → (sk, vk): On input the public parameters pp, output a key pair (sk, vk).VKeyGen (sk): On input a secret key sk, output a verification key vk.GenAuxTag() → (aux  , (, T)): Given a set  = M  , N  , vk   ∈ [] and the same tag T, output a signature  on the messages M = ((M  , N  ))  ∈ [ℓ ] under the tag T and verification key avk = (vk  )  ∈ [ℓ ] .VerifyAggr(avk, T, M, ) → {0, 1}: Given a verification key avk, tag T, messages M and signature , output 1 if  is valid relative to avk, M and T, and 0 otherwise.ConvertTag(T, ) → T ′ : On input a tag T and randomness , output a randomized tag T ′ ∈ [T] R  (i.e., a new representative of tag).ChangRep((M, N), , T, (, )) → ( ′ , T ′ ): On input a representative (M, N) ∈ [(M, N)] R TDH , T ∈ [T] R  , signature  and randomness (, ), return a new signature ((M ′ , N ′ ), T ′ ,  ′ ), where M ′ = M  ∧ N ′ = N  ∈ [(M, N)] R TDH and T ′ ← ConvertTag(T, ) are the new representatives and  ′ is valid for (M ′ , N ′ ) and [T] R  .This will also apply for a set representative M such that one can get a new set representative M ′ by scaling all message with the same (, ).ConvertSK(sk, ) → sk ′ : On input a sk and key converter , output a new secret key sk ′ .ConvertVK(vk, ) → vk ′ : On input a vk and key converter , output a new public key vk ′ .ConvertSig(vk, T, (M, N), , ) →  ′ : On input a vk, message vector (M, N), signature with tag (, T), and key converter , return a new signature  ′ such that Verify(vk ′ , T, (M, N),  ′ ) = 1, where vk ′ ← ConvertVK(vk, ).The VerifyTag and VKeyGen are only used for the security game.

Table 1 :
Comparison of AC schemes in MA setting (: Attributes; : Disclosed attributes, : Undisclosed attributes,  : Total issuers in policy, : issuers in showing) Sign(sk  , , aux  ,   ) →   : On input a secret key sk  , tag's secret , auxiliary data aux  and message   ∈ Z  , output a signature   for (, T) and   under the verification key vk  .Verify(vk  , T,   ,   ) → {0, 1}: Given a verification key vk  , tag's public T, message   and signature   , output 1 if   is valid relative to vk  ,   and T, and 0 otherwise.
output auxiliary data {aux  }  ∈ [] correlated to (vk  ,   ) and a tag pair (, T), where all vk  should be distinct.
, P, ) ← BGGen(1  ) with a prime number order , where  is a generator of G 1 , P a generator of G 2 .Pick  as a hash function:  : {0, 1} * → G 1 .Output public parameters pp = {BG,  }.KeyGen (pp): Choose (,  1 ,  2 )  and set the secret key sk = (,  1 ,  2 ) and verification key vk $← Z , aux, ,   ) Parse aux as (, ).Check that  ∈  (i.e., that  has the form   1 ||  2 ||...) and (  , vk) ∈  where vk is a verification key related to sk (in the same equivalence class).Also check that no other vk  in aux has the same equivalence class as sk.This can be done by checking that .If these checks pass, it means that this is in the same equivalence class as the verifier's key.If the check doesn't pass, it means the vk  is not in the same equivalence class.Sign(sk  , , aux  ,   ): Given a sk  = ( 1 ,  2 ,   ), , aux  and a message   .If VerifyAux(sk  , aux  , , ) ≠ 1 return ⊥.Else, parse aux as (, ) and compute ℎ =  () and output: ) =  ( ′ 2 ,  1 ) hold.So we adapt M  iDH and define a new message space called a Tag-based DH message space M • Issuance: In this protocol, an issuer  associated to (sk, vk) creates a credential cred on an attributes-set A to a user  associated to (sk, vk) as follows:[CredObtain(sk, vk, A) ↔ CredIssue(sk, vk, A)] → cred • CredAggr: Take as input a sk of user and a list of credentials (vk, A  , cred  ) for  ∈ [ℓ] and output an aggregated credential cred of attributes-set {A  }  ∈ [ℓ ] : CredAggr sk, {(vk, A  , cred  )}  ∈ [ℓ ] → cred • GenPolicies: A verifier with the secret key sk can define policies defining sets of issuers {ivk}  ∈ [] they are willing to accept for certain Show sessions, we have: GenPolicy(sk, {ivk}  ∈ [] ) → , where  ≤ ℓ Note that  defines the sets of accepted issuers by a verifier, but not which attributes a verifier needs to disclose.Thus,  can be reused for multiple contexts, reducing the number of policies.• Show: In this protocol, a user  with (sk, vk) runs CredShow and interacts with a verifier running CredVerify to prove that she owns a valid credential cred on disclosed attribute sets  ⊆ {A  }  ∈ [ℓ ] issued respectively by one or some credential issuers in : CredShow(sk, , {(vk, A  )}  ∈ [ℓ ] , cred, ) ↔

Table 2 :
Running times for ATMS and AtoSa (ms)