Delegatable Anonymous Credentials from Mercurial Signatures

Cited by 34 publications

(56 citation statements)

References 17 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In previous instantiations [BCC + 09, Fuc11] of the latter, the showing of a credential is anonymous to anyone, in particular to a user that has delegated said credential to the one showing it. However, in the construction from the ECS variant mercurial signatures [CL19], if Alice delegates a credential to Bob, she can identify Bob whenever he uses the credential to authenticate, which represents a serious infringement to Bob's privacy. In fact, anonymity towards the authority issuing (or delegating) credentials has been considered a fundamental property of anonymous credential schemes.…”

Section: Shortcomings Of Ecsmentioning

confidence: 99%

“…In [CL19], when Alice delegates a credential to Bob, she uses her secret key (x 0 , x 1 ) ∈ (Z |G| * ) 2 to sign Bob's pseudonym under her own pseudonym (P 0 , P 1 ) = (rx 0 G, rx 1 G) for a random r, which becomes part of Bobs credential. When Bob shows it, he randomizes Alice's pseudonym to (P 0 , P 1 ) := (r P 0 , r P 1 ) for a random r , which Alice can recognize by checking whether x 1 P 0 = x 0 P 1 .…”

Section: Shortcomings Of Ecsmentioning

confidence: 99%

“…Signatures with flexible public key [BHKS18] and mercurials signatures [CL19] are extensions of ECS that allow signatures to be adapted not only to multiples of the signed message, but also to multiples of the verification key. This has been used to build delegatable anonymous credentials [BCC + 09] in [CL19]. Delegatable credentials allow for hierarchical structures, in which users can delegate obtained credentials to users at lower levels.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Efficient Signatures on Randomizable Ciphertexts

Bauer

Fuchsbauer

2020

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Randomizable encryption lets anyone randomize a ciphertext so it is distributed like a fresh encryption of the same plaintext. Signatures on randomizable ciphertexts (SoRC), introduced by Blazy et al. (PKC'11), let one adapt a signature on a ciphertext to a randomization of the latter. Since signatures can only be adapted to ciphertexts that encrypt the same message as the signed ciphertext, signatures obliviously authenticate plaintexts. SoRC have been used as a building block in e-voting, blind signatures and (delegatable) anonymous credentials. We observe that SoRC can be seen as signatures on equivalence classes (JoC'19), another primitive with many applications to anonymous authentication, and that SoRC provide better anonymity guarantees. We first strengthen the unforgeability notion for SoRC and then give a scheme that provably achieves it in the generic group model. Signatures in our scheme consist of 4 bilinear-group elements, which is considerably more efficient than prior schemes.

show abstract

Section: Shortcomings Of Ecsmentioning

confidence: 99%

Section: Shortcomings Of Ecsmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Efficient Signatures on Randomizable Ciphertexts

Bauer

Fuchsbauer

2020

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…Mercurial signatures were introduced in a recent paper by Crites and Lysyanskaya [15]. The construction consists of messages and public keys that are vectors of group elements of a certain fixed length.…”

Section: Introductionmentioning

confidence: 99%

“…In particular, suppose Alice issues a level-2 credential to Bob that grants him access to the same buildings or a subset of the buildings to which she has access, potentially limiting the hours during which Bob is authorized. Under the mercurial signature scheme of [15], if Alices's public key is of length and her attributes are of length k, the CA's public key must be of length + k. This, in turn, severely limits the kinds of keyattribute pairs that Alice can sign with a public key of length and Bob can sign with a public key of length − |attr Bob | (and so on down the chain). Furthermore, while the construction of [15] permits this kind of delegation, the proofs of security do not.…”

Section: Introductionmentioning

confidence: 99%

Mercurial Signatures for Variable-Length Messages

Crites¹,

Lysyanskaya

2021

Proceedings on Privacy Enhancing Technologies

Self Cite

View full text Add to dashboard Cite

Mercurial signatures are a useful building block for privacy-preserving schemes, such as anonymous credentials, delegatable anonymous credentials, and related applications. They allow a signature σ on a message m under a public key pk to be transformed into a signature σ′ on an equivalent message m′ under an equivalent public key pk′ for an appropriate notion of equivalence. For example, pk and pk′ may be unlinkable pseudonyms of the same user, and m and m′ may be unlinkable pseudonyms of a user to whom some capability is delegated. The only previously known construction of mercurial signatures suffers a severe limitation: in order to sign messages of length ℓ, the signer’s public key must also be of length ℓ. In this paper, we eliminate this restriction and provide an interactive signing protocol that admits messages of any length. We prove our scheme existentially unforgeable under chosen open message attacks (EUF-CoMA) under a variant of the asymmetric bilinear decisional Diffie-Hellman assumption (ABDDH).

show abstract