Generalized Pseudonym Scheme
- Generalized pseudonym scheme is a configurable cryptographic framework that transforms stable identities into domain-specific pseudonyms using various techniques like hash-based and OPRF-based derivations.
- The scheme covers a wide design space with implementations including two-tier network coding, delegatable pseudonyms, and Merkle-tree constructions, each tailored for specific applications such as mobile cloud privacy and federated authentication.
- It emphasizes flexible trust distribution, update semantics, and security properties such as unlinkability, traceability, and revocability, while balancing efficiency and deployment constraints across diverse systems.
A generalized pseudonym scheme is a cryptographic or protocol framework in which a stable identity, identifier set, or long-term credential is transformed into pseudonyms that are context-specific, domain-specific, dynamic, delegatable, user-generated, or short-lived, while preserving some combination of unlinkability, anonymity, traceability, revocability, and efficient authentication. In the literature, this design space includes two-tier network-coding pseudonyms for mobile cloud data, dynamic pseudonym identities for multi-server authentication, delegatable pseudonyms for national eID systems, stateless scoped pseudonyms derived through an OPRF-style protocol, Merkle-tree-based user-generated pseudonyms, variable -pseudonym sets for 5G anonymous access, hybrid-certificate pseudonym schemes for vehicular communications, and designated-verifier pseudonyms in anonymous single sign-on (Chen et al., 2017, Xue et al., 2012, Krenn et al., 28 May 2026, Heher et al., 2024, Kermezis et al., 2021, Ma et al., 2021, Chen et al., 12 Jun 2026, Han et al., 2018).
1. Conceptual scope and defining characteristics
The surveyed literature does not treat pseudonymization as a single mechanism. Instead, pseudonym schemes are parameterized by who computes the pseudonym, which party can verify it, whether a trusted authority can open it, whether the pseudonym is refreshed over time, and whether the security objective is computational, information-theoretic, or partly physical. A generalized pseudonym scheme therefore denotes a family of constructions rather than a single canonical protocol.
Several design axes recur. One axis is origin of computation: pseudonyms may be generated by a trusted authority, by the user, by a designated service provider, or collaboratively. Another is scope binding: a pseudonym can be tied to a server, verifier, service domain, context identifier, or epoch. A third is recoverability: some schemes deliberately provide traceability or opening by a central authority, while others are designed to eliminate the need for a third party in pseudonym generation. A fourth is update semantics: pseudonyms may be static within a domain, periodically refreshed, changed at every authentication epoch, or derived for globally aligned validity intervals.
This broader view is explicit in multiple strands of work. In multi-server authentication, dynamic pseudonym identity is used to hide and while preserving traceability by a control server (Xue et al., 2012). In mobile cloud privacy, a two-tier network-coding construction is designed so that pseudonyms decouple stored data from the owner pseudonyms and remain unconditionally secure even against attackers with unlimited compute (Chen et al., 2017). In national eID, a delegatable pseudonym system gives users the right to compute their own pseudonyms and allows subsets of service providers to compute pseudonyms only within their own domain (Krenn et al., 28 May 2026). In federated authentication, BISON derives a trusted, scoped, immutable pseudonym while hiding the service provider’s identity from the identity provider and requiring no long-lived state on the user device (Heher et al., 2024).
2. Architectural models and trust distribution
Generalized pseudonym schemes differ sharply in their trust models. In centrally mediated designs, a trusted authority or control server holds master secrets and mediates registration, verification, update, or opening. The dynamic pseudonym identity protocol for multi-server architecture uses a fully trusted Control Server (CS) that registers users and servers, holds master secrets and , and supports both user and server pseudonym derivation through and (Xue et al., 2012). The network-coding mobile-cloud scheme similarly uses a Trusted Certifying Server (TCS) that knows , issues and re-issues pseudonyms, and keeps the generator matrices and secret from the cloud database (Chen et al., 2017).
Delegated and distributed models shift part of this functionality outward. The bPk# framework formalizes a delegatable pseudonym scheme with algorithms 0, 1, 2, 3, 4, 5, 6, and 7. The Central Authority (CA) still holds a long-term master keypair 8 and is legally allowed to open any pseudonym, but users may generate their own domain-specific pseudonyms offline and designated service providers may compute pseudonyms locally for any user in their domain (Krenn et al., 28 May 2026). BISON moves further toward relationship privacy: the IdP verifies the real identity and maps each real user to a private OPRF key 9, but it sees only the blinded group element 0, not the underlying 1, and therefore does not learn which scope is being used (Heher et al., 2024).
User-generated models reduce or eliminate the role of a third party. The Merkle-tree pseudonymisation scheme constructs per-context pseudonyms locally, without the need of a third party, by committing a set of identifiers 2 into a Merkle root using both 3 and 4 leaves (Kermezis et al., 2021). By contrast, conceptual proof-of-personhood systems such as pseudonym parties rely less on central cryptographic issuance and more on public transparency, synchronized closing times, bulletin boards, and cross-witnessing; the security claim that no one can obtain more than one token in a single cycle depends on the physical assumption that each real person has exactly one body (Ford, 2020).
Vehicular systems expose an additional dimension: infrastructure-assisted pseudonyms with revocation and alignment constraints. RHyTHM assumes a VPKI with LTCA, PCA, GM, and RA, but allows on-the-fly self-certified pseudonyms under intermittent connectivity, combined with randomized participation by neighbors so that disconnected users blend into a larger anonymity set (Khodaei et al., 2017). The hybrid-certificate SCMS model retains RCA, ICA, ECA, PCA, RA, and end entities, but redesigns certificate contents so that enrollment credentials and pseudonym certificates can use different algorithm families while preventing inference of correlation between the pseudonym public key and the enrollment public key (Chen et al., 12 Jun 2026).
3. Construction paradigms and representative mechanisms
The main construction families can be summarized as follows.
| Paradigm | Core mechanism | Representative source |
|---|---|---|
| Dynamic hash-based pseudonyms | 5, 6 | (Xue et al., 2012) |
| Two-tier network coding | 7 and 8 from 9, 0 over 1 | (Chen et al., 2017) |
| Stateless scoped derivation | 2, blind/unblind, 3 | (Heher et al., 2024) |
| Delegatable pseudonyms | NIKE + encryption + signature + NIZK + opening | (Krenn et al., 28 May 2026) |
| Merkle-tree pseudonymisation | Root of hashed and HMAC-tagged identifier leaves | (Kermezis et al., 2021) |
| Variable 4-pseudonym sets | One real shard pseudonym plus 5 decoys | (Ma et al., 2021) |
| Vehicular pseudonym certificates | Hybrid certificates and encrypted pseudonym-key issuance | (Chen et al., 12 Jun 2026) |
| Designated-verifier pseudonyms | Per-verifier pseudonyms and authentication tags | (Han et al., 2018) |
Hash-based dynamic identity schemes derive protected pseudonyms from real identities and locally chosen randomness. In the multi-server protocol, the user pseudonym is 6, the server pseudonym is 7, and the session key is computed as 8. The protocol binds messages to timestamps and fresh nonces and allows pseudonym update by replacing 9 or 0 without re-personalizing a verification table on service servers (Xue et al., 2012).
Information-theoretic schemes replace conventional hash pseudonyms with coding-theoretic mixing. In the mobile-cloud construction, the user vector 1 is first encoded as 2, from which a 3-length subvector becomes 4. A seed 5 is then combined with 6 and encoded again as 7. The design uses 8, typically 9, 0, and 1, with Vandermonde matrices selected so that the resulting pseudonyms reveal zero mutual information about 2 (Chen et al., 2017).
Scoped OPRF-style designs derive a pseudonym directly from a scope identifier and a user-specific secret held by the identity provider. BISON maps a public scope identifier to a curve point 3, blinds it as 4, obtains 5 plus a signature from the IdP, unblinds to 6, and outputs 7. The result is stable within one scope, unlinkable across different scopes, and does not require a long-lived secret on the user device beyond ephemeral randomness (Heher et al., 2024).
Delegatable frameworks generalize this further by allowing both user-side and service-provider-side pseudonym generation. In bPk#, the generic construction combines an EUF-CMA signature scheme 8, an IND-CPA encryption scheme 9, a NIKE scheme 0 with commutativity and an injective 1 mapping 2, and a weakly simulation-sound extractable NIZK proof system 3. The user computes 4, encrypts 5, and proves that the pseudonym, ciphertext, and CA signature are jointly well formed; service providers with delegated secret keys compute the same pseudonym locally as 6 (Krenn et al., 28 May 2026).
Merkle-tree pseudonymisation organizes multiple identifiers into a cryptographic accumulator. For each context 7, leaves are defined as alternating 8 and 9, internal nodes are hashes of child concatenations, and the root 0 becomes 1. This yields per-context pseudonyms that depend on several user identifiers, remain unlinkable across contexts because each context uses an independent MAC key 2, and support ownership proofs through standard Merkle authentication paths (Kermezis et al., 2021).
Other constructions specialize to particular infrastructures. The 5G variable 3-pseudonym scheme computes a shard pseudonym
4
where 5 is extracted from a ZUC keystream initialized by values derived from 6, 7, 8, and 9. A 0-pseudonym set then contains 1 and 2 decoy identities, possibly supplemented by HSS-supplied assistant IDs (Ma et al., 2021). In CPPS signcryption, a distinct line of work proposes a dynamical pseudonym self-generation mechanism (DPSGM) combined with certificateless cryptography and elliptic-curve cryptography to reduce computation and communication burden for resource-constrained smart terminals (Li et al., 2022). In anonymous single sign-on, pseudonyms are verifier-specific:
3
and are embedded into authentication tags that only the designated verifier can validate, while a central verifier can later trace the user and service set if required (Han et al., 2018).
4. Security properties and formal models
Unlinkability is the most common objective, but it is formalized differently across schemes. In the network-coding model, unlinkability is information-theoretic: with full-rank Vandermonde matrices and the prescribed parameter relations, the construction proves
4
and therefore an adversary with infinite CPU learns no information about 5 from either pseudonym layer (Chen et al., 2017). In BISON, unlinkability is computational and scope-based: given 6 and 7, colluding service providers with different 8 values cannot decide whether the same user secret was used unless they can solve a DDH-hard problem in 9 (Heher et al., 2024).
Generalized frameworks often separate anonymity from non-frameability. The bPk# model defines Exp0 for non-frameability and Exp1 for anonymity/unlinkability. Non-frameability reduces to EUF-CMA security of 2 and simulation-soundness of 3; anonymity is established by a hybrid argument replacing real proofs by simulated proofs, real encryptions by encryptions of 4, and real NIKE shares by challenge-independent values, under IND-CPA and NIKE indistinguishability assumptions (Krenn et al., 28 May 2026).
Dynamic authentication schemes add freshness and traceability. The multi-server protocol binds authentication to timestamps and nonces 5, with explicit timestamp checks 6 and 7, and claims resistance to replay attack, Deny-of-Service attack, internal attack, eavesdropping attack, and masquerade attack. At the same time, CS preserves traceability because it knows the master secrets used to derive 8 and 9 (Xue et al., 2012).
Designated-verifier systems introduce verifier exclusivity. In the anonymous SSO construction, a tag for verifier 00 can only be checked by 01, not by any other verifier, even if verifiers collude. The formal model includes games for unlinkability, unforgeability, and traceability, with reductions to DDH, 02-SDH, and DL in a Type-III bilinear setting (Han et al., 2018). Vehicular schemes add revocation and anti-Sybil conditions: RHyTHM assumes an HSM that enforces that at any point only one private key is used for signing outgoing beacons, while the group manager and resolution authority can revoke or open group signatures if needed (Khodaei et al., 2017).
A common misconception is that pseudonymization automatically implies the absence of traceability. The literature shows the opposite. Some constructions are intentionally openable: the CA in bPk# can recover the underlying 03 through 04; the central verifier in anonymous SSO recovers both the user’s identity and service set; the GM and RA in RHyTHM can resolve group signatures; and the multi-server CS can trace protected pseudonym identities back to registered entities (Krenn et al., 28 May 2026, Han et al., 2018, Khodaei et al., 2017, Xue et al., 2012). Another misconception is that all pseudonym schemes share the same threat model. In fact, some rely on honest-but-curious servers, some on hardness assumptions such as DDH or XDH, and some on physical attendance and public auditability (Kermezis et al., 2021, Heher et al., 2024, Ford, 2020).
5. Efficiency, certificate size, and deployment contexts
Efficiency claims are central because many pseudonym systems target constrained devices, dense networks, or latency-sensitive authentication. The mobile-cloud network-coding scheme reports measurements on an HTC Desire with a 1 GHz ARM CPU and IMSI length 50–150 bits. At 50 bits IMSI, MD5 takes 05 ms, SHA-1 06 ms, SHA-256 07 ms, NC over 08 09 ms, and NC over 10 11 ms; the corresponding total energies are 12, 13, 14, 15, and 16 mJ. The reported result is that NC is 17 faster for realistic IMSI lengths 18 bits, while the abstract states that the proposed two-tier mechanism can reduce more than 90 percent of processing time as well as 10 percent of energy consumption (Chen et al., 2017).
BISON emphasizes lightweight elliptic-curve computation. Pseudonym derivation requires a total of four elliptic curve scalar-point multiplications and four hash function evaluations, taking 19 ms in the proof-of-concept implementation, and was designed as an OpenID Connect extension for deriving PPID pseudonyms (Heher et al., 2024). The delegatable bPk# construction, implemented in Rust with arkworks over BLS12-381 on a 2022 Intel Core i7, reports 20 including the NIZK at 21 ms and 22 at 23 ms. User and service-provider public keys are one 24 element of 48 bytes, signatures 25 are three 26 elements, and the proof 27 is roughly 5 group elements plus 1 EC challenge, approximately 360 B (Krenn et al., 28 May 2026).
Vehicular systems impose both packet-size and throughput constraints. The hybrid-certificate SCMS reports that a hybrid certificate using a Falcon-512 signature and an ECDSA P-256 VKI has size 28 B 29 30 B 31 32 B, which is below the 1400-byte constraint for V2V messages. A V2V signed SPDU with the full pseudonym certificate is approximately 813 B in the proposed hybrid scheme, while the PC-digest form remains approximately 122 B. On Raspberry Pi 4, the sender cost for a signed BSM SPDU is 33 ms and the receiver cost is 34 ms under the proposed hybrid scheme, and the study states that even at the highest congestion a Raspberry Pi 4 can sign 10 SPDU/s and verify 100 SPDU/s, meeting real-time BSM requirements (Chen et al., 12 Jun 2026). RHyTHM, by contrast, measures the privacy cost of cooperative self-certification: group-signature signing is approximately 56 ms, verification approximately 82.5 ms, and with 35 and 36 s each participating vehicle pays approximately 1.6 s extra of group-signature work per pseudonym change (Khodaei et al., 2017).
The deployment contexts are correspondingly diverse. Generalized pseudonym schemes have been proposed for group LBS and untrusted cloud databases, multi-server authentication, 5G anonymous access authentication, national eID systems, OpenID Connect and federated sign-in, cyber-physical power systems, vehicular communications, mobile crowdsensing, IoT swarms, smart grid, e-Health, M2M, and digital-democracy mechanisms such as online voting, deliberative polls, and UBI-style minting (Chen et al., 2017, Xue et al., 2012, Ma et al., 2021, Krenn et al., 28 May 2026, Heher et al., 2024, Li et al., 2022, Chen et al., 12 Jun 2026, Ford, 2020).
6. Limitations, misconceptions, and open directions
The literature also delineates clear limitations. Some schemes obtain strong properties only under restrictive assumptions. The Merkle-tree construction assumes honest-but-curious organizations that will not collude out-of-band to link pseudonyms, a trusted local device, and post-quantum-secure hash and MAC primitives (Kermezis et al., 2021). The dynamic multi-server protocol assumes a one-way and collision-resistant hash function, ideal XOR and concatenation operations, and loosely synchronized clocks (Xue et al., 2012). RHyTHM assumes honest-but-curious VPKI entities that do not collude and depends on HSM enforcement of one-signing-key-per-interval (Khodaei et al., 2017). Delegatable national-eID pseudonyms still rely on a CA trusted to generate keys correctly, keep 37 secret, and only open pseudonyms under lawful request (Krenn et al., 28 May 2026).
Another limitation is that “generalized pseudonym scheme” can denote very different security semantics. In some work, the emphasis is information-theoretic unlinkability; in others, designated-verifier exclusivity, traceability, or post-quantum robustness is equally central. A plausible implication is that comparing pseudonym schemes only by whether they hide a stable identifier misses the more consequential distinctions: whether pseudonyms are domain-scoped or globally reusable, whether updates are synchronous or asynchronous, whether opening exists, whether a verifier-specific proof is required, and whether the construction is stateful or stateless.
Open directions are also explicit. The bPk# framework states that by swapping 38, 39, 40, and 41 for post-quantum analogs, the same generic scheme remains secure, and suggests adding per-epoch key rotation or revocation by signing 42 and maintaining a revocation accumulator or revocation list (Krenn et al., 28 May 2026). The Merkle-tree scheme notes dynamic-update limitations: adding a new identifier requires rebuilding the tree and obtaining a fresh set of pseudonyms, motivating future integration with sparse Merkle trees or vector commitments (Kermezis et al., 2021). Vehicular hybrid certificates frame crypto-agility as a design goal, recommending pure PQC certificates for infrastructure and hybrid certificates for pseudonym certificates under V2V size constraints (Chen et al., 12 Jun 2026). In cyber-physical power systems, the signcryption work identifies dynamic pseudonym self-generation, certificateless cryptography, and ECC as a route to reduced burden for resource-constrained smart terminals, but the available summary does not reproduce the detailed DPSGM algorithms, proofs, or performance figures (Li et al., 2022).
Taken together, these works show that a generalized pseudonym scheme is best understood as a configurable privacy architecture. It may be hash-based, coding-based, tree-based, OPRF-based, NIKE-based, certificate-based, or physically grounded; it may prioritize unconditional security, designated verification, traceability, statelessness, post-quantum security, or low-overhead deployment; and it is typically evaluated not only by whether it conceals a real identity, but by how precisely it allocates computation, trust, scope, and opening authority across the system.