Nicknames for Group Signatures (NGS)

• NGS is a cryptographic scheme that extends traditional group signatures by allowing anyone to derive a nickname for a member without their cooperation.
• It combines group admission with flexible public keys, providing both strong privacy and controlled traceability through designated opening authorities.
• The concrete construction employs bilinear pairings, zero-knowledge proofs, and Ethereum-based prototypes to ensure secure, auditable nickname derivation and signature validation.

Searching arXiv for the named scheme and related prototype papers to ground the article in current sources. Nicknames for Group Signatures (NGS) is a cryptographic signing scheme that extends Group Signatures (GS) with Signatures with Flexible Public Keys (SFPK) to enable anonymous, yet auditable, transfers through recipient-traceable public identities called nicknames. In NGS, the issuer defines a master public key $\mathrm{mpk}$ for each member’s equivalence class $[\mathrm{mpk}]_{R}$; anyone can derive a nickname $\mathrm{nk} \in [\mathrm{mpk}]_{R}$ for a designated member without that member’s cooperation or private key; the member can test whether a nickname belongs to their class and prove control of it; and a designated opener can identify the controlling user and produce a publicly verifiable opening proof. The scheme is formalized with a security model, instantiated in the Random Oracle Model, and illustrated through Ethereum-based systems including NickPay and NickHat (Quispe et al., 25 Mar 2025, Quispe et al., 4 Aug 2025).

1. Conceptual basis and motivation

NGS was introduced to fill a specific gap left by classic group signatures. GS and dynamic GS allow registered members to sign anonymously on behalf of a group while preserving the possibility of de-anonymization by an opening authority. What they do not provide is a built-in, privacy-preserving mechanism to address value or messages to a specific group member without revealing that member’s identity. NGS adds that missing addressing layer through nicknames.

A nickname is not a signature. Rather, it is a flexible, re-randomizable public representative tied to a member’s equivalence class. The core idea is that each member $i$ is associated with an equivalence class $[\mathrm{mpk}_i]_{R}$ of public representatives. Anyone can derive a fresh nickname from the member’s published master public key, and the member later proves control of that nickname when authorizing an action. This realizes what the NickPay paper describes as a stealth-address-like capability inside a group-signature framework.

The motivation for NGS is clearest in comparison with adjacent primitives. Linkable group signatures provide public linkability, either globally or per tag, and therefore weaken unlinkability. DAA and EPID provide per-verifier pseudonyms, but those pseudonyms are generated by the holder and do not provide a group-managed public addressing layer that allows a third party to derive an identity for the recipient. SFPK allows public-key re-randomization within an equivalence class, but does not natively provide group admission, opening, or the broader semantics of group signatures. NGS combines these capabilities: GS-like admission and opening, together with SFPK-like flexible public representatives. This gives privacy by default, controlled linkability through user and auditor mechanisms, and public verifiability of group-level validity (Quispe et al., 25 Mar 2025, Quispe et al., 4 Aug 2025).

2. Formal model, roles, and interfaces

The NGS model distinguishes five roles. The issuer manages group admission and creates per-user master public keys and registration records. The opener acts as opening authority and can identify the controller of a nickname with a public proof. The user or group member holds a digital-signature keypair together with a master secret key and a trapdoor. The verifier checks nickname validity and user consent proofs. The judge verifies opening proofs.

The formal interface is given by a tuple of PPT algorithms. The second paper presents the interface as a scheme with issuer key generation, opener key generation, user key generation, join and issue, nickname derivation, tracing, public group verification, opening, public judging, signing, and user-signature verification. A notable design choice is the split between public verification of nickname validity and verification of user consent. In the first paper this is emphasized as the split between $\mathrm{GVf}(\mathrm{ipk}, \mathrm{nk})$, which checks that a nickname is a valid group representative, and $\mathrm{UVf}(\mathrm{nk}, m, \sigma)$, which checks that the signer controls the nickname and authorized message $m$.

The public state includes at least a registration table $\mathrm{reg}$, a public table of master public keys $\mathrm{mpk}[i]$, and a public table of users’ digital-signature keys $[\mathrm{mpk}]_{R}$0. The issuer writes registration state, while the opener has read access to registration information. The scheme also relies on a vetted digital signature scheme that is EUF-CMA secure.

The equivalence-class structure is explicit. One formulation defines

$[\mathrm{mpk}]_{R}$1

with element-wise exponentiation on tuples; in the concrete construction, $[\mathrm{mpk}]_{R}$2 and $[\mathrm{mpk}]_{R}$3. This is the algebraic basis for nickname derivation by public re-randomization (Quispe et al., 4 Aug 2025).

3. Concrete construction

The base construction uses a type-3 bilinear pairing

$[\mathrm{mpk}]_{R}$4

over groups of prime order $[\mathrm{mpk}]_{R}$5, with generators $[\mathrm{mpk}]_{R}$6 and $[\mathrm{mpk}]_{R}$7. The issuer samples $[\mathrm{mpk}]_{R}$8 and publishes

$[\mathrm{mpk}]_{R}$9

The opener samples $\mathrm{nk} \in [\mathrm{mpk}]_{R}$0 and publishes $\mathrm{nk} \in [\mathrm{mpk}]_{R}$1.

On the user side, the join protocol selects $\mathrm{nk} \in [\mathrm{mpk}]_{R}$2, computes

$\mathrm{nk} \in [\mathrm{mpk}]_{R}$3

and defines the trapdoor

$\mathrm{nk} \in [\mathrm{mpk}]_{R}$4

The trapdoor is ElGamal-encrypted under the opener’s key, and the user provides a zero-knowledge proof of correctness together with a digital signature on

$\mathrm{nk} \in [\mathrm{mpk}]_{R}$5

If the issuer accepts the request, it computes

$\mathrm{nk} \in [\mathrm{mpk}]_{R}$6

and stores the registration record and master public key

$\mathrm{nk} \in [\mathrm{mpk}]_{R}$7

This tuple satisfies the defining pairing relation

$\mathrm{nk} \in [\mathrm{mpk}]_{R}$8

Nickname derivation is then public. For $\mathrm{nk} \in [\mathrm{mpk}]_{R}$9, anyone computes

$i$0

Because the pairing relation is preserved under this re-randomization, the nickname remains a valid representative of the same equivalence class.

The user-side trace test is equally direct. Given $i$1 and a nickname $i$2, the member checks

$i$3

In the more restrictive formulation, tracing also conjoins this test with $i$4. This is holder-only controlled linkability: only the trapdoor holder can efficiently test class membership in this way.

Signing under a nickname is implemented as a proof of knowledge that the signer knows $i$5 such that $i$6, bound to the message. The first paper writes this as

$i$7

and gives a Fiat–Shamir instantiation with response pair $i$8. Public verification of a nickname uses the pairing equation above, while verification of user consent checks the proof of knowledge attached to the message.

Opening proceeds by scanning the registration table, decrypting the stored trapdoor candidate for each entry, and testing whether it matches the nickname through the relations

$i$9

When a unique match is found, the opener produces a proof

$[\mathrm{mpk}_i]_{R}$0

and the judge verifies $[\mathrm{mpk}_i]_{R}$1, the digital signature on $[\mathrm{mpk}_i]_{R}$2, and the group-validity condition for the nickname. The result is auditable de-anonymization with a public proof, rather than opaque supervisor action (Quispe et al., 25 Mar 2025).

4. Security properties

Correctness is stated in both formulations as probability $[\mathrm{mpk}_i]_{R}$3: if the parties are honest, join and issue succeed, any nickname generated from a valid master public key passes group verification, a valid user signature passes user verification, opening returns the correct identity with an accepting judgment, and the owner’s trace test accepts.

The principal accountability property is non-frameability, also described as exculpability in the first paper. Informally, no PPT adversary should be able to produce a valid nickname, message, consent proof, and opening proof that implicate an honest user who did not authorize the action. The proof sketches reduce such a forgery to breaking at least one of the following: simulation soundness of the opening proof system, EUF-CMA security of the auxiliary digital signature scheme, or the symmetric discrete logarithm assumption.

Traceability, or openability, requires that no PPT adversary can produce a valid nickname, message, and user proof such that opening fails or yields an opening that the judge rejects. The reductions rely on a Modified GPS assumption together with simulation soundness of the join proof system and the soundness of the user-side proof of knowledge.

The later treatment isolates two additional consistency notions. Optimal opening soundness states that it is infeasible to produce a nickname that opens to two distinct users with both proofs accepted. Opening coherence states that it is infeasible to produce a nickname that an honest user traces as their own while the judge accepts an opening proof pointing to a different user. Both properties are derived from proof soundness together with join-time uniqueness conditions on the underlying secret exponent.

Privacy is articulated through anonymity and unlinkability. The first paper characterizes anonymity more specifically as selfless anonymity: the adversary may corrupt the issuer but not the opener, and does not receive Trace access. This captures the asymmetry that a member can recognize their own nicknames, but third parties cannot. Public unlinkability is explicit: NGS does not export a public $[\mathrm{mpk}_i]_{R}$4 function. Controlled linkability exists only through holder-side $[\mathrm{mpk}_i]_{R}$5 and auditor-side $[\mathrm{mpk}_i]_{R}$6. A common misconception is therefore to treat NGS as a linkable group-signature system with better routing; the papers describe the opposite design choice, namely strong public unlinkability with only controlled tracing and opening (Quispe et al., 25 Mar 2025, Quispe et al., 4 Aug 2025).

5. Efficiency and prototype systems

The base instantiation is designed to be compact. The first paper gives the asymptotic sizes: the issuer public key consists of $[\mathrm{mpk}_i]_{R}$7 elements in $[\mathrm{mpk}_i]_{R}$8; a master public key or nickname consists of $[\mathrm{mpk}_i]_{R}$9 elements in $\mathrm{GVf}(\mathrm{ipk}, \mathrm{nk})$0; and the trapdoor is $\mathrm{GVf}(\mathrm{ipk}, \mathrm{nk})$1 element in $\mathrm{GVf}(\mathrm{ipk}, \mathrm{nk})$2, stored encrypted in the registry. The join proof and opening proof are constant-size NIZK or SPK objects over pairing equations. The user signature is an SPK over the relation $\mathrm{GVf}(\mathrm{ipk}, \mathrm{nk})$3, represented concretely by $\mathrm{GVf}(\mathrm{ipk}, \mathrm{nk})$4 scalars $\mathrm{GVf}(\mathrm{ipk}, \mathrm{nk})$5 in $\mathrm{GVf}(\mathrm{ipk}, \mathrm{nk})$6 plus the hash transcript.

The online costs are correspondingly structured. Nickname generation requires $\mathrm{GVf}(\mathrm{ipk}, \mathrm{nk})$7 exponentiations in $\mathrm{GVf}(\mathrm{ipk}, \mathrm{nk})$8. Public nickname verification requires $\mathrm{GVf}(\mathrm{ipk}, \mathrm{nk})$9 pairings. User signing requires one exponentiation for the commitment term, one hash, and one scalar operation for the response. User-signature verification requires two exponentiations in $\mathrm{UVf}(\mathrm{nk}, m, \sigma)$0, one group multiplication, and one hash check. Opening is linear in the registry size because it tests each entry until a unique match is found.

Both papers describe batching for group verification. Using the small exponent test, verification over $\mathrm{UVf}(\mathrm{nk}, m, \sigma)$1 nicknames can reduce $\mathrm{UVf}(\mathrm{nk}, m, \sigma)$2 pairings to $\mathrm{UVf}(\mathrm{nk}, m, \sigma)$3 pairings total. This is significant for settings with many nickname-validity checks, although the papers present it as an optional optimization rather than a change to the core scheme.

Two Ethereum prototypes instantiate the design. NickPay is described as an auditable, privacy-preserving, nickname-based payment system built on Ethereum, with Solidity verification for $\mathrm{UVf}(\mathrm{nk}, m, \sigma)$4 and $\mathrm{UVf}(\mathrm{nk}, m, \sigma)$5 and Rust off-chain code using Arkworks; its implementation uses BN254 on Ethereum, which the paper associates with approximately 100-bit security, and notes that higher security would use BLS12-381 or BW6 curves off-chain (Quispe et al., 25 Mar 2025). NickHat is described as a blockchain-based token-exchange prototype on Ethereum. Its architecture includes a Verifier contract embedding $\mathrm{UVf}(\mathrm{nk}, m, \sigma)$6 and $\mathrm{UVf}(\mathrm{nk}, m, \sigma)$7 with fixed issuer key, a key-registry contract storing $\mathrm{UVf}(\mathrm{nk}, m, \sigma)$8, a NickHat contract maintaining $\mathrm{UVf}(\mathrm{nk}, m, \sigma)$9, and a Forwarder implementing ERC-2771 meta-transactions. The reported gas costs include 39,230 gas for inserting $m$0, 263,610 gas for deposit, 292,480 gas for transfer, 248,980 gas for lock in the HTLC workflow, and 369,830 gas for claim (Quispe et al., 4 Aug 2025).

6. Relation to adjacent primitives, limitations, and open questions

The closest predecessors are GS, DGS, SFPK, DAA or EPID, and other anonymous-transfer mechanisms. Relative to classic GS or DGS, NGS adds native addressability: anyone can derive a per-use public representative for a specific member. Relative to linkable group signatures, NGS abandons public linkability in favor of public unlinkability with controlled tracing and opening. Relative to DAA or EPID, NGS reverses the direction of pseudonym creation: in DAA the signer derives a pseudonym for a label, whereas in NGS anyone derives a nickname from a public master key and the member later proves control. Relative to SFPK-only systems, NGS adds issuer-managed admission, group-membership verification, opening, judging, and a user trapdoor supporting self-identification of nicknames.

Several limitations are explicit in the papers. The base scheme includes no public $m$1 function. Revocation is not part of the base construction, although both texts state that revocation mechanisms from group signatures can be incorporated with care. Label-bound nicknames are not required by the core design; they appear only as an optional application-level variant, for example by hashing a label into the randomization or representative. The Ethereum-oriented construction also exposes a degenerate case: if a sender chooses $m$2, then $m$3, which can reduce anonymity; the papers suggest enforcing $m$4 or even requiring a proof of correct randomization.

The trust model is likewise explicit. The issuer is trusted to run issue correctly unless one works in a corruption game. The opener is trusted operationally, but its outputs are constrained by publicly checkable proofs verified by the judge. This suggests that the main residual trust concentration lies in admission and opening availability rather than in unverifiable discretionary power. The open questions listed in the papers therefore focus on threshold or decentralized issuer and opener designs, scalable revocation, deterministic label-bound nicknames with formally characterized controlled linkability, selective opening of specific events, more direct opening methods than linear registry scan, and SNARK-friendly or otherwise more scalable verification paths for on-chain deployment (Quispe et al., 25 Mar 2025, Quispe et al., 4 Aug 2025).