Practical "Signatures with Efficient Protocols" from Simple Assumptions

Abstract

Digital signatures are perhaps the most important base for authentication and trust relationships in large scale systems. More specifically, various applications of signatures provide privacy and anonymity preserving mechanisms and protocols, and these, in turn, are becoming critical (due to the recently recognized need to protect individuals according to national rules and regulations). A specific type of signatures called "signatures with efficient protocols", as introduced by Camenisch and Lysyanskaya (CL), efficiently accommodates various basic protocols and extensions like zero-knowledge proofs, signing committed messages, or re-randomizability. These are, in fact, typical operations associated with signatures used in typical anonymity and privacy-preserving scenarios. To date there are no "signatures with efficient protocols" which are based on simple assumptions and truly practical. These two properties assure us a robust primitive: First, simple assumptions are needed for ensuring that this basic primitive is mathematically robust and does not require special ad hoc assumptions that are more risky, imply less efficiency, are more tuned to the protocol itself, and are perhaps less trusted. In the other dimension, efficiency is a must given the anonymity applications of the protocol, since without proper level of efficiency the future adoption of the primitives is always questionable (in spite of their need). In this work, we present a new CL-type signature scheme that is rerandomizable under a simple, well-studied, and by now standard, assumption (SXDH). The signature is efficient (built on the recent QA-NIZK constructions), and is, by design, suitable to work in extended contexts that typify privacy settings (like anonymous credentials, group signature, and offline e-cash). We demonstrate its power by presenting practical protocols based on it.

A Survey on Group Signatures and Ring Signatures: Traceability vs. Anonymity

“…In 1991, Chaum and van Heyst [1] introduced group signatures. Over the past three decades, numerous group signature schemes have been presented to reduce the barriers for use in real life: based on random oracles [9,[11][12][13][14][15][16][17][18], without random oracles [19,20], improving security [8,9,[21][22][23][24][25][26][27], and efficiency [9,12,13,24,[28][29][30].…”

Practical dynamic group signatures without knowledge extractors

“…If so, α = log g f 1 = log u w holds for some unknown α, because of the simulation soundness of or traceability security analyses. All their non-frameability proofs are justified under the hardness of some computational problems such as the (S)DL [11,25,41,45] or the co-Diffie-Hellmam Inversion [26], and like the security analysis of the Schnorr signature, the witness used as the user secret key must be extracted as the solution of their underlying computational hardness problem. Furthermore, regarding the traceability proofs, BCN+10, LMP+16, and PS16 require sequential O(q) rewinding extractions for dealing with O(q) joining queries that are issued by an adversary.…”

“…In this regard, it is no surprise that group signature is still a very active cryptographic topic 30 years after its introduction, with countless contributions (see, e.g. [11,14,23,25,26,36,[40][41][42]45]). Although all these constructions have their own features, they share a common idea.…”

“…To the best of our knowledge, all existing DGS schemes that are secure in the ROM (including [11,18,25,41,45]) suffer from the loose security reduction inherent to such rewinding strategies. More precisely, knowledge extractors are required in traceability and non-frameability security proofs.…”

Group Signatures with Message-Dependent Opening: Formal Definitions and Constructions

“…Since group signatures were first proposed by Chaum and van Heyst [1], many efficient constructions have been proposed, most of which depend on a random oracle [10,[16][17][18][19][20][21][22][23]. Many earlier schemes were based on the strong RSA assumption [24,25].…”