DGMT: A Fully Dynamic Group Signature from Symmetric-Key Primitives

Abstract

A group signature scheme allows a user to sign a message anonymously on behalf of a group and provides accountability by using an opening authority who can “open” a signature and reveal the signer’s identity. Group signature schemes have been widely used in privacy-preserving applications, including anonymous attestation and anonymous authentication. Fully dynamic group signature schemes allow new members to join the group and existing members to be revoked if needed. Symmetric-key based group signature schemes are post-quantum group signatures whose security rely on the security of symmetric-key primitives, and cryptographic hash functions. In this paper, we design a symmetric-key based fully dynamic group signature scheme, called DGMT, that redesigns DGM (Buser et al. ESORICS 2019) and removes its two important shortcomings that limit its application in practice: (i) interaction with the group manager for signature verification, and (ii) the need for storing and managing an unacceptably large amount of data by the group manager. We prove security of DGMT (unforgeability, anonymity, and traceability) and give a full implementation of the system. Compared to all known post-quantum group signature schemes with the same security level, DGMT has the shortest signature size. We also analyze DGM signature revocation approach and show that despite its conceptual novelty, it has significant hidden costs that makes it much more costly than using the traditional revocation list approach.

1. Introduction

Digital signatures underpin trust and secure authentication and authorization over the internet. They have been used to construct certificates in public key infrastructure, credentials for user authentication and authorization, and signing transactions in electronic commerce and cryptocurrencies. Today’s widely used digital signatures, such as (EC)DSA and RSA signature scheme, rely on the hardness of two computational problems, Discrete Logarithm Problem and Integer Factorization Problem, that can be efficiently solved by the Shor’s quantum algorithm [1]. The prospect of the development of quantum computers, that potentially lead to the collapse of the cryptographic infrastructure of the Internet, has generated a flurry of research and development in academia and industry to design and develop post-quantum cryptographic systems, and has initiated standardization efforts around the world including NIST [2] and ETSI [3].

Post-quantum secure (PQ-secure) digital signature schemes provide security against adversaries with access to quantum computers. Known PQ-secure signature schemes have based their security on the hardness of computational problems for which no efficient quantum algorithm is known [4,5,6,7,8], or use only hash functions [9,10,11,12,13,14]. Security of the second approach against quantum computers primarily relies on the Grover’s search algorithm [15].

Hash-based signature schemes were first introduced in [12] as a One-Time Signature (OTS) scheme, using only hash functions and designed for signing a single message. Multi-message signature (MMS) schemes with short public key was proposed by Merkle by constructing a Merkle tree over a set of OTS public keys and using the root of the tree as the scheme’s public key [14]. Merke tree approach and its variations reduce the size of the public key but increase the signature size, as the OTS public key and the authentication path from the leaf to the root must be included in the signature. Winternitz One-Time Signature scheme (WOTS) [14] is a particularly attractive OTS design in which the public key of the OTS can be derived from the OTS signature and so need not be included in the MMS signature, when using Merkle tree approach. Winternitz signature scheme and its variations serve as the main building block of stateful hash-based signature schemes that have been standardized by NIST, including XMSS [9,16] and LMS [13].

Group Signature Schemes (GSS) [17] allow members of a group to sign on behalf of the group and provide anonymity and accountability for (group) members. In a GSS, a manager initializes the system and enrolls members to the group. A group member can sign anonymously on behalf of the group and their signature can be verified by the group public key. To provide accountability, signatures can be opened by the manager (or a separate opening authority) to reveal the identity of the signer. GSSs can be static where group membership is determined at the initialization time, partially dynamic that allow new members to join or existing members to be revoked after the initialization, and fully dynamic that support both joining new members and revoking existing members during the lifetime of the system [18,19,20]. GSSs and their variations have been used for Direct Anonymous Attestation in Trusted Platform Modules 1.2 [21], Enhanced Privacy Identification (EPID) [22], anonymous reputation systems [23], and digital rights management systems [24].

Symmetric-key based GSSs: Group Merkle (GM or G-Merkle) is the first hash-based GSS. GM is a static GSS [25] and is based on a hash-based multi-message signature scheme in which the public key is the root of a Merkle tree. The tree is constructed over the public keys of a set of OTSs where each OTS (hash of the) public key forming a leaf node of the tree. The manager assigns a random subset of leaves to each user. The innovation of GM is that it constructs the random subset by applying a strong pseudorandom permutation to the leaves of the tree which hides the association of the users to the leaves and ensures the users’ anonymity. The manager knows the secret key of the strong pseudorandom permutation and can reveal the identity of the signer, guaranteeing accountability. However, based on the GM’s implementation, it supports $2^{18}$ signatures and can accommodate up to $2^{17}$ users as each user must be allocated at least two OTSs.

${\mathrm{GM}}^{\mathrm{MT}}$: is a partially dynamic hash-based GSS [26] that uses GM approach and allows user revocation but not join. The scheme replaces the Merkle tree of GM with a multi-layer Merkle tree to increase the total number of signatures while keeping initialization time practical.

Dynamic GM (DGM) is a fully dynamic hash-based GSS that extends GM approach to support user join and revoke operations [27]. DGM uses an IMT/SMT tree structure that consists of two types of Merkle trees: (i) An Initial Merkle Tree (IMT) that is built on a set of random strings that serve as its leaves, and (ii) a set of Signing Merkle Trees (SMT), each built on the public keys of a set of OTSs. The root of each SMT is linked to an internal node of the IMT, referred to as a fallback node, using a fallback key that is part of the signature (We use the terminology from [27], particularly for terms like ‘fallback node’ and ‘fallback key’). See Section 3.2 for more details and Figure 3 as a concrete example. The number of fallback keys increases with the number of OTSs that DGM provides. The manager generates and stores fallback keys as new users join the group. During verification, the verifier queries the validity of a fallback key, that is part of the signature, by interacting with the manager. This IMT/SMT structure allows the manager to gradually construct the tree over the system’s lifetime and avoid the high computation cost of building the entire tree during the initialization phase. This, however, requires interaction with the group manager for verification. See Section 3.2 for more details on DGM.

DGM permits multiple SMTs per fallback node and so allows the total number of signatures provided by the system to grow. However, this is not formalized and is not part of the security proof. DGM also uses an innovative approach to user revocation that employs a Symmetric Puncturable Encryption scheme (SPE). In SPEs the decryption key can be updated and punctured on a desired input to prevent decryption of a ciphertext corresponding to that input. Revocation in DGM uses encryption and decryption functions of SPE to determine whether a signature is revoked or not. See Section 2.1 and Section 6 for more details on SPE and SPE-based revocation of DGM, respectively.

DGM shortcomings. DGM has two important shortcomings: (i) It requires interaction between the verifier and the manager for every signature verification, requiring the manager to be online continuously to respond to the verifiers’ queries on the validity of the fallback key which is a part of the signature; (ii) It requires the manager to store the index of each OTS assigned to every user in order to “open" the signatures (“Openning a signature” is a functionality in group signature that allows the group manager to find the identity of the signer of a signature. See Section 3 for details) and revoke the users, leading to a storage size that grows linearly with the total number of signatures generated by the scheme, denoted by ${\mathsf{T}}_{\mathsf{tot}}$. Additionally, the manager must store all fallback keys to verify them for users. For instance, to support ${\mathsf{T}}_{\mathsf{tot}}=2^{64}$ OTSs, the manager would need to store $2^{64}$ leaf node indexes for signature opening and revocation, along with $2^{62}$ fallback keys, amounting to approximately ${10}^{8.7}$ Terabytes of storage [26]. This storage demand is unacceptably large, making it impractical for real-world applications.

Another less obvious drawback of DGM that is uncovered by our work is the very inefficient approach to revocation. DGM SPE-based approach to revocation although appears novel, incurs significant cost. See Section 6.

1.1. Our Contributions

In this work, we propose a symmetric-key based fully dynamic group signature scheme, called DGMT, that addresses the design shortcomings of DGM, and implements and evaluates its performance. Our main contributions are as follows.

1—A new tree structure. In all existing symmetric-key based GSSs discussed above, a virtual tree is constructed on a set of leaves that each corresponds to the public key of an OTS. The root of this tree is the GSS’s public key. The innovation of each system is in the way the tree leaves are managed during assignment and revocation, with the goal of providing user anonymity and accountability, and security and efficiency for the GSS. We construct a virtual tree on the set of OTSs that extends the IMT/SMT structure of DGM to $\mathrm{IMT}/{\mathrm{SMT}}^{\mathrm{MT}}$ and explicitly uses multiple ${\mathrm{SMT}}^{\mathrm{MT}}$ per each $\mathrm{IMT}$ internal node. The tree is designed to accommodate the required total number of signatures, ${\mathsf{T}}_{\mathsf{tot}}$, using a relatively small number of fallback keys. This allows the list of fallback keys to be generated and published during initialization (e.g., on a public bulletin board). The verifier can directly verify a signature by accessing the published information without the need to interact with the manager.

2—Reducing server storage. We design a new signature assignment algorithm where the manager’s storage is proportional to the maximum number of users, denoted by ${\mathsf{N}}_{\mathsf{max}}$, rather than the total number of signatures ${\mathsf{T}}_{\mathsf{tot}}$. This significantly reduces the manager’s storage requirements, as each user is typically associated with a large number of OTSs. To achieve this, we assign a fixed, unique (and disjoint) interval of the list $[0,1,\dots ,\alpha -1]$ for an integer $\alpha$, to each user, and use a strong pseudorandom permutation to map the intervals to (pseudo)random leaves of the signature tree.

3—Implementation. We provide a full implementation of DGMT and all its algorithms. The software is written in C language, which is the NIST-recommended reference language, and the code is available at https://github.com/submissionOfCode/DGMT_ref, accessed on 19 November 2024. In addition to signature and verification algorithms, we have implemented key management algorithms, that consist of the initial key assignment, and user join and revocation. Key generation, and storage that support signature opening, and management of revocation list are the most complex parts of our code (DGM only provides implementation of the signing and verification algorithms).

For user revocation, DGMT uses a public revocation list. In Section 6, we analyse the user revocation approach of DGM that is based on SPE, and compare it with DGMT approach, demonstrating that DGM’s approach is significantly more costly in both computation and storage cost. Table A1 summarizes our results. In Appendix A, we show an alternative way of using SPE-based revocation in DGM which improves its efficiency and reduces the cost of revocation.

1.2. Related Work

To provide combined anonymity and accountability, symmetric-key based group signature schemes have used two approaches. The schemes in [25,26,27,28] use multi-time hash-based signature schemes together with pseudorandom permutations and/or symmetric-key encryption. The group public key is the root of a Merkle tree that is constructed over a set of leaves where each leaf corresponds to an OTS public key. The group manager allocates a “random’’ subset of leaves to each user and provides them with the secret keys of the allocated OTSs and the corresponding authentication paths to the root of the Merkle tree. The user uses one OTS and its associated authentication path at most once. DGM and ${\mathrm{GM}}^{\mathrm{MT}}$ allow the user to request additional OTS keys from the group manager by presenting their secret credentials, that are obtained during enrollment, to authenticate themselves. The schemes in [22,29,30] also use symmetric-key primitives and Merkle tree but employ Non-Interactive Zero-Knowledge (NIZK) proofs to construct the signature. We note that the scheme in [22] is an EPID and does not provide opening function to link a signature to a user, and the scheme in [30] is a static group signature. The scheme in [29] however is a fully dynamic symmetric-key based group signature that uses a hybrid approach: it uses a multi-time hash-based signature scheme, that is a modified version of ${\mathrm{SPHINCS}}^{+}$ (Stateless Practical Hash-based Incredibly Nice Cryptographic Signatures) [31], and is optimized for multiparty computation, and a NIZK to achieve anonymity. In Section 4.1 we give a comparison of DGM and DGMT algorithms, and in Section 1.2.1 give a more detailed look at Sphinx-in-the-Head (SiTH) [29] and its comparison with DGMT.

Table 1 summarizes comparison of all known symmetric-key based group signature schemes. All rows except the last row of the Table 1 are sourced from Table 1 in [29].

Table 1. A Comparison of Hash-Based Group Signature Schemes.

Schemes †	Underlying Signatures	Group Credentials	Static/Fully Dynamic	Group Size *	Non-Frameability
G-Merkle [25]	OTS	Merkle signature	static	$2^6$ **	no
DGM [27]	OTS	Merkle signature	Fully dynamic	–	no
DGM+ [28]	OTS	XMSS-T‡	Fully dynamic	–	no
GMMT [26]	OTS	XMSS-T	dynamic	$2^{10}$ ***	no
KKW [30]	NIZK	Merkle signature	static	$2^{13}$	no
BEF [22]	NIZK	Merkle or Goldreich signature	static	–	no
SiTH [29]	NIZK	F-SPHINCS+ ‡	Fully dynamic	$2^{60}$	yes
This work	OTS	Merkle signature	Fully dynamic	$2^{15}$	no

^† The first column indicates the name of the schemes or the initials of the authors. ^‡ XMSS-T is the multi-target resistant variant of XMSS^MT [32]. F-SPHINCS⁺ is a variant of SPHINCS⁺ with extra properties [29] * refers to the maximum group size that has been implemented and reported in the paper; “–” indicates that no implementation has been reported. ** To ensure the anonymity of GM, each user requires two OTSs. Therefore, according to the GM’s implementation in Table 1 [25], if the GM provides 2¹⁸ OTSs, it can support up to 2¹⁷ users. *** In Table 4 in [26], it is mentioned at most 2¹⁰, but it can support up to 2¹⁹ users if the height of the lowest layer is 20.

1.2.1. Sphinx-in-the-Head

Sphinx-in-the-Head (SiTH) is a post-quantum fully-dynamic symmetric-key based group signature scheme. It uses a new mult-message hash-based signature scheme which is a modification of ${\mathrm{SPHINCS}}^{+}$ with the goal of making it more “friendly” for MPC (multiparty computation) that is needed for NIZK that is used in the scheme.

SiTH splits the role of the manager between a group issuer and a group tracer each receiving a corresponding private key from the user, preventing each of the two authorities to “frame” the user by generating a signature on their behalf, and hence providing non-frameability. This makes SiTH unique among other post-quantum symmetric-key based full-dynamic group signature schemes that use a single trusted group manager and do not provide non-frameability. SiTH scheme uses NIZK that allows the user to prove to the verifier a set of relations that are defined by its secret values, the signed message, and the published values of the system. Using NIZK results in a much slower signature generation and verification time, and a significantly larger signature size, compared to DGMT.

Similar to DGMT, SiTH uses a revocation list to keep track of the revoked users. The revocation list will include the secret tracing key of the user and so revokes all the signatures of the user, including the past ones. Authors noted that SiTH can be made forward anonymous by including the hash of the private tracing key in the revocation list. This however increases the computation cost of the signer who must show that the signing key has not been revoked.

In DGMT however the signatures are individually revoked. In our revocation algorithm we will include all signatures of a revoked user to the revocation list and so effectively revoke all signatures of the user. DGMT, however, can provide forward anonymity by revoking the signatures individually. This is by including the output of the strong pseudorandom permutation on the index of the revoked OTSs and all the remaining keys of the user, leaving out its past signatures. Thus will require minor changes to the current algorithms (e.g., “revoked” flag) that will not affect security.

1.2.2. DGMT and Other Post-Quantum GSSs

There is a large body of research on Lattice-based GSSs including static [4,33,34,35], partially dynamic [36,37,38], and fully dynamic lattice-based GSSs [39]. There are also constructions of code-based [40,41] and isogeny-based [4] GSS. Table 2 gives a comparison of signature sizes of the most efficient known post-quantum GSSs. Rows 3–5 of the table are from Table 1 in [4]. All schemes except DGMT and SiTH are static. The only fully dynamic GSS based on a computational assumption is the lattice-based GSS presented in [39]. However, it is not included in the table as its signature size is provided only in asymptotic terms, specifically $\tilde{O}(\lambda logN)$ bits, where $\lambda$ represents the security parameter and N denotes the group size. As seen in the table, DGMT has the shortest signature size among all known schemes.

Table 2. Signature size of the most efficient post-quantum GSSs, given in Kilobyte (KB). The signature sizes of the GSSs [4,29,33,40] depend on the number of users (group size), denoted by N. To show how many users are accommodated in each scheme, we consider $N\in \{2^4,2^5,2^{10},2^{12},2^{15},2^{20},2^{21},2^{24},2^{60}\}$.

GSS	Signature Type	Based on	Bit Security	N
				${\mathbf{2}}^{\mathbf{4}}$	${\mathbf{2}}^{\mathbf{5}}$	${\mathbf{2}}^{\mathbf{10}}$	${\mathbf{2}}^{\mathbf{12}}$	${\mathbf{2}}^{\mathbf{15}}$	${\mathbf{2}}^{\mathbf{20}}$	${\mathbf{2}}^{\mathbf{21}}$	${\mathbf{2}}^{\mathbf{24}}$	${\mathbf{2}}^{\mathbf{60}}$
ELLNW [40]	Static	Code	80	157	–	–	205	–	–	–	200704	–
LNPS [42]	Static	Lattice	–	203
BDKLP [4]	Static	Lattice	–	–	126	129	–	–	–	134	–	–
ESZ [33]	Static	Lattice	–	–	12	19	–	–	–	–	–	–
BDKLP [4]	Static	Isogeny	128	–	6	9	–	–	–	15.5	–	–
SiTH [29]	Fully dynamic	Symmetric	128	–	–	571	–	–	851	–	–	2000
DGMT	Fully dynamic	Symmetric	128	5.75 *					–	–	–	–
DGMT	Fully dynamic	Symmetric	192	11.62 *					–	–	–	–

* See the Section 4.4 for computing signature size and the bit security of DGMT. “–” shows that either scheme cannot accommodate N users or no information has been reported in their papers.

1.3. Organization

Section 2 is preliminaries and Section 3 introduces a security model for fully dynamic symmetric-key based GSS. Section 4 gives the construction of DGMT, followed by the presentation of its security proof in Section 5. An analysis of the revocation using SPE in DGM is provided in Section 6. Section 7 is the implementation of DGMT and its experimental results. Appendix A gives a more efficient SPE-based revocation method for DGM, and Appendix B outlines an approach for reducing setup time in DGMT.

1.4. Notations

Let $\mathbb{N}$ be the set of positive integers and $\lambda \in \mathbb{N}$ be the security parameter. For two given integers $a,b\in \mathbb{N}$, we denote the representation of a in base b by ${\left(a\right)}_b$, and for $a\le b$, we denote the set $\{x\in \mathbb{Z}\mid a\le x\le b\}$ by $[a,b]$. For a given list L, we denote the n-th element of this list by $L\left[n\right]$. For two given strings x and y, we denote their concatenation by $x\Vert y$. If S is a set or a list, we denote its size by $\left|S\right|$ and the operation of randomly selecting an element x from S by $x\stackrel{\$}{\leftarrow }S$. We write $x\leftarrow A\left(a\right)$ for an algorithm A that runs on input a and outputs x. We call a function $ϵ(·):\mathbb{N}\to {\mathbb{R}}^{+}$ negligible in the security parameter $\lambda$ if for every polynomial $p(·)$ and all sufficiently large values of $\lambda$, $ϵ\left(\lambda \right)<{\displaystyle \frac{1}{p\left(\lambda \right)}}$ holds. $\lceil ·\rceil$ is the ceiling function. For a given adversary $\mathcal{A}$ and $i\in \mathbb{N}$, ${\mathcal{A}}^{f_1,\dots ,f_i}$, indicates that the adversary $\mathcal{A}$ is given access to the oracles $f_1,\dots ,f_i$.

2. Preliminaries

In the following, we recall some cryptographic primitives [43,44,45,46]. Let $m\left(x\right)$ and $\ell \left(x\right)$ be two polynomials and $\lambda \in \mathbb{N}$ be the security parameter.

One-way Function (OWF): A function $f:{\{0,1\}}^{*}\to {\{0,1\}}^{*}$ is one-way if (i) for all $x\in {\{0,1\}}^{*}$, $f\left(x\right)$ is efficiently computable, and (ii) it is hard to invert the function; that is for every Probabilistic Polynomial Time (PPT) adversary $\mathcal{A}$

$$\mathrm{Pr}[x\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }\mid f\left(\mathcal{A}(1^{\lambda },f\left(x\right))\right)=f\left(x\right)]$$

is negligible in terms of $\lambda$.

Pseudorandom Function (PRF): A function

$$F:{\{0,1\}}^{\lambda }\times {\{0,1\}}^{m\left(\lambda \right)}\to {\{0,1\}}^{\ell \left(\lambda \right)}$$

is pseudorandom if (i) for all k and x, $F(k,x)$ is efficiently computable, and (ii) for any PPT adversary $\mathcal{A}$

$$Ad{v}_{\mathcal{A}}^{\mathsf{PRF}}=\left|\mathrm{Pr}\left[{\mathcal{A}}^{F(k,·)}\left(1^{\lambda }\right)=1\right]-\mathrm{Pr}\left[{\mathcal{A}}^{f(·)}\left(1^{\lambda }\right)=1\right]\right|$$

is negligible in terms of $\lambda$, where $k\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$ and f is chosen randomly from the set of all functions mapping $m\left(\lambda \right)$ bits to $\ell \left(\lambda \right)$ bits.

Strong Pseudorandom Permutation (SPRP): A function

$$\mathsf{E}:{\{0,1\}}^{\lambda }\times {\{0,1\}}^{m\left(\lambda \right)}\to {\{0,1\}}^{m\left(\lambda \right)}$$

is a strong pseudorandom permutation if (i) for all k and x, $\mathsf{E}(k,x)$ and ${\mathsf{E}}^{-1}(k,x)$ is efficiently computable, where ${\mathsf{E}}^{-1}:{\{0,1\}}^{\lambda }\times {\{0,1\}}^{m\left(\lambda \right)}\to {\{0,1\}}^{m\left(\lambda \right)}$, and (ii) for any PPT adversary $\mathcal{A}$

$$\begin{array}{c}\hfill Ad{v}_{\mathcal{A}}^{\mathsf{SPRP}}=\left|\mathrm{Pr}\left[{\mathcal{A}}^{\mathsf{E}(k,·),{\mathsf{E}}^{-1}(k,·)}\left(1^{\lambda }\right)=1\right]-\right.\left.\mathrm{Pr}\left[{\mathcal{A}}^{\pi (·),{\pi }^{-1}(·)}\left(1^{\lambda }\right)=1\right]\right|\end{array}$$

is negligible in terms of $\lambda$, where $k\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$ and $\pi$ is chosen randomly from the set of all permutations on ${\{0,1\}}^{m\left(\lambda \right)}$.

Collision-resistant Hash Function (CRH): A set of functions

$$\mathcal{HF}={\{{\mathsf{H}}_k:{\{0,1\}}^{m\left(\lambda \right)}\to {\{0,1\}}^{\lambda }\}}_{k\in {\{0,1\}}^{\lambda },m\left(\lambda \right)>\lambda },$$

is a family of collision-resistant hash functions if (i) for all key $k\in {\{0,1\}}^{\lambda }$ and $x\in {\{0,1\}}^{m\left(\lambda \right)}$, ${\mathsf{H}}_k$ is efficiently computable, (ii) for all PPT adversaries $\mathcal{A}$

$$\begin{array}{c}\hfill Ad{v}_{\mathcal{A},\mathcal{HF}}^{\mathsf{col}}=\mathrm{Pr}[k\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda },(x,x^{\prime })\leftarrow \mathcal{A}\left(k\right)\mid x\ne x^{\prime },\mathrm{and} {\mathsf{H}}_k\left(x\right)={\mathsf{H}}_k\left(x^{\prime }\right)]\end{array}$$

is negligible in terms of $\lambda$.

Symmetric Key Encryption: A symmetric key encryption scheme is a tuple of polynomial-time algorithms $\mathcal{SE}=(\mathsf{SE}.\mathsf{KG},\mathsf{SE}.\mathsf{Enc},\mathsf{SE}.\mathsf{Dec})$ where the key generation algorithm $\mathsf{SE}.\mathsf{KG}$ generates a random $\lambda$-bit key $k\leftarrow \mathsf{SE}.\mathsf{KG}\left(1^{\lambda }\right)$, and the encryption and decryption algorithms work as follows. The encryption algorithm $\mathsf{SE}.\mathsf{Enc}:{\{0,1\}}^{\lambda }\times {\{0,1\}}^{m\left(\lambda \right)}\to {\{0,1\}}^{m\left(\lambda \right)}$ encrypts a message m into the ciphertext c as $c\leftarrow \mathsf{SE}.\mathsf{Enc}(k,m)$, and the decryption algorithm $\mathsf{SE}.\mathsf{Dec}:{\{0,1\}}^{\lambda }\times {\{0,1\}}^{m\left(\lambda \right)}\to {\{0,1\}}^{m\left(\lambda \right)}$ decrypts a ciphertext c into the plaintext m as $m\leftarrow \mathsf{SE}.\mathsf{Dec}(k,c)$. The correctness property of $\mathcal{SE}$ says that $\mathsf{SE}.\mathsf{Dec}(k,\mathsf{SE}.\mathsf{Enc}(k,m\left)\right)=m$.

2.1. Symmetric Puncturable Encryption Scheme (SPE)

DGM uses an SPE-based revocation scheme. To provide a concrete analysis of DGM revocation algorithm, we recall the SPE algorithm that was proposed in [47] and used in DGM. The construction uses the puncturable pseudorandom function (Pun-PRF) given in [48].

Let $\mathcal{K},{\mathcal{K}}_P$, $\mathcal{Y}$ and $\mathcal{T}$ be the set of key space, punctured key space, output space, and tag space (or input) of the Pun-PRF, respectively. Let $F^{\prime }:\mathcal{K}\times \mathcal{T}\to \mathcal{Y}$ be a PRF. A Pun-PRF F, constructed from $F^{\prime }$ is a PRF with a pair of algorithms $(\mathsf{F}.\mathsf{Punc},\mathsf{F}.\mathsf{Eval})$ defined as follows: $\mathsf{F}.\mathsf{Punc}$ takes a key $k\in \mathcal{K}$ and a tag $t\in \mathcal{T}$, and outputs a punctured key $p{k}_t\in {\mathcal{K}}_P$. The evaluation function $\mathsf{F}.\mathsf{Eval}$ takes a punctured key $p{k}_t$ and a tag $t^{\prime }$, computes $\mathsf{F}.\mathsf{Eval}(k,t^{\prime })=F^{\prime }(k,t^{\prime })$ if $p{k}_t$ is not punctured at tag $t^{\prime }$, and outputs fail (⊥), otherwise. That is,

$$\begin{array}{ccc}& & \mathsf{F}.\mathsf{Punc}:\mathcal{K}\times \mathcal{T}\to {\mathcal{K}}_P,\mathrm{s}.\mathrm{t}.\mathsf{F}.\mathsf{Punc}(k,t)=p{k}_t\hfill \\ & & \mathsf{F}.\mathsf{Eval}:{\mathcal{K}}_P\times \mathcal{T}\to \mathcal{Y}\cup \{\perp \},\mathrm{s}.\mathrm{t}.\hfill \\ & & \mathsf{F}.\mathsf{Eval}(p{k}_t,t^{\prime })=\left\{\begin{array}{cc}{F}^{\prime }(k,t^{\prime })=y,\hfill & \mathrm{if}t\ne t^{\prime },\hfill \\ \perp ,\hfill & \mathrm{if}t=t^{\prime }.\hfill \end{array}\right.\hfill \end{array}$$

A Construction for SPE. A symmetric d-puncturable encryption scheme is a tuple of algorithms

$$\mathcal{SPE}=(\mathsf{SPE}.\mathsf{KeyGen},\mathsf{SPE}.\mathsf{Enc},\mathsf{SPE}.\mathsf{Punc},\mathsf{SPE}.\mathsf{Dec})$$

that allows the input key to be punctured on up to d tags. The $\mathcal{SPE}$ master key $msk$ remains unchanged. The encryption key is computed once but the decryption key is updated with each puncturing of a tag. The construction in [47] uses three building blocks: (i) a family of collision-resistant hash functions ${\{{\mathsf{H}}_k:\mathbb{N}\to \mathcal{K}\}}_{k\in \mathcal{K}}$ (ii) a symmetric key encryption system $(\mathsf{SE}.\mathsf{Enc},\mathsf{SE}.\mathsf{Dec})$ with key space $\mathcal{K}$ and (iii) a PRF $F^{\prime }$ as defined above.

The initial decryption key of $\mathcal{SPE}$ is the same as the encryption key $msk$, that is $S{K}_0=\left\{msk\right\}$. The decryption key, however, is updated with each punctured tag $t_i^{\prime }$. $\mathcal{SPE}$ algorithms are outlined below.

• $msk\leftarrow \mathsf{SPE}.\mathsf{KeyGen}(1^{\lambda },d):$ The algorithm takes the security parameter $\lambda$ and $d\in \mathbb{N}$ and outputs the master encryption key $msk=(s{k}_0,d)$, where $s{k}_0\stackrel{\$}{\leftarrow }\mathcal{K}$.
• $c{t}_t\leftarrow \mathsf{SPE}.\mathsf{Enc}(msk,m,t):$ The algorithm takes the encryption key $msk$, message m and tag t, and outputs the ciphertext $c{t}_t$.

  $$\begin{array}{cc}\hfill & \{s{k}_i:1\le i\le d,s{k}_i\leftarrow {\mathsf{H}}_{s{k}_{i-1}}\left(i\right)\},\hfill \\ \hfill & {\kappa }_t\leftarrow \underset{i=0}{\overset{d}{⨁}}{F}^{\prime }(s{k}_i,t),\hfill \\ \hfill & c{t}_t\leftarrow \mathsf{SE}.\mathsf{Enc}({\kappa }_t,m).\hfill \end{array}$$
• The Decryption algorithm uses a punctured key, a ciphertext, and a tag as inputs and outputs a ciphertext or failure. First, we describe how $\mathsf{SPE}.\mathsf{Punc}$ updates the decryption key, and then how to decrypt the ciphertext.
  • $S{K}_i\leftarrow \mathsf{SPE}.\mathsf{Punc}(S{K}_{i-1},t_i^{\prime }):$ The algorithm updates the decryption key for the i-th punctured tag, given the previous key and the associated set of punctured tags. It takes $S{K}_{i-1}=\{ms{k}_{i-1},ps{k}_1,\dots ,ps{k}_{i-1}\}$, where $ms{k}_{i-1}=(s{k}_{i-1},d)$ for $1\le i\le d$ and $S{K}_0=msk$, for the set of tags $T_{i-1}=\{t_1^{\prime },t_2^{\prime },\dots ,t_{i-1}^{\prime }\}$, and outputs $S{K}_i$. $\mathsf{F}.\mathsf{Punc}$ is defined recursively below.

    $$\begin{array}{ccc}& & ps{k}_i\leftarrow \mathsf{F}.\mathsf{Punc}(s{k}_{i-1},t_i^{\prime }),\hfill \\ & & s{k}_i\leftarrow {\mathsf{H}}_{s{k}_{i-1}}\left(i\right),\hfill \\ & & ms{k}_i=(s{k}_i,d)\hfill \\ & & S{K}_i=\{ms{k}_i,ps{k}_1,\dots ,ps{k}_i\}.\hfill \end{array}$$
  • $m_t\leftarrow \mathsf{SPE}.\mathsf{Dec}(S{K}_i,c{t}_t,t):$ The algorithm takes the $S{K}_i$, the ciphertext $c{t}_t$ and a tag t, and outputs the plaintext $m_t$ as follows. If $1\le i<d$, compute $s{k}_j\leftarrow {\mathsf{H}}_{s{k}_{j-1}}\left(j\right)$ for $i<j\le d$.

    $$\begin{array}{ccc}& & {\kappa }_t^{\prime }\leftarrow \underset{j=1}{\overset{i}{⨁}}\mathsf{F}.\mathsf{Eval}(ps{k}_i,t)\underset{j=i}{\overset{d}{⨁}}{F}^{\prime }(s{k}_i,t),\hfill \\ & & m_t\leftarrow \mathsf{SE}.\mathsf{Dec}({\kappa }_t^{\prime },c{t}_t)\hfill \end{array}$$

2.2. One-Time Signature (OTS)

An OTS scheme is a digital signature scheme that is designed for signing a single message. It consists of three polynomial-time algorithms $\mathcal{OTS}=(\mathsf{OTS}.\mathsf{KG},\mathsf{OTS}.\mathsf{Sig},\mathsf{OTS}.\mathsf{Vf})$, which operate as follows

• $(\mathsf{OTS}.\mathsf{sk},\mathsf{OTS}.\mathsf{pk})\leftarrow \mathsf{OTS}.\mathsf{KG}\left(1^{\lambda }\right)$. This algorithm generates a key pair $(\mathsf{OTS}.\mathsf{sk},\mathsf{OTS}.\mathsf{pk})$, where $\mathsf{OTS}.\mathsf{sk}$ is the secret key and $\mathsf{OTS}.\mathsf{pk}$ is the public key.
• $\sigma \leftarrow \mathsf{OTS}.\mathsf{Sig}(\mathsf{OTS}.\mathsf{sk},m)$. This algorithm signs a message m with a secret key $\mathsf{OTS}.\mathsf{sk}$ and outputs a valid digital signature $\sigma$.
• $0/1\leftarrow \mathsf{OTS}.\mathsf{Vf}(m,\sigma ,\mathsf{OTS}.\mathsf{pk})$. This is a deterministic algorithm that checks the validity of the signature $\sigma$ on message m using $\mathsf{OTS}.\mathsf{pk}$. $\mathsf{OTS}.\mathsf{Vf}$ outputs 1 if the message and signature pair is valid, otherwise, it outputs 0.

An OTS scheme is called existentially unforgeable under chosen message attack (EU-CMA) if for any PPT adversary $\mathcal{A}$

$$\begin{array}{cc}\hfill Ad{v}_{\mathcal{A},\mathcal{OTS}}^{\mathsf{EU}-\mathsf{CMA}}& =\mathrm{Pr}[(\mathsf{OTS}.\mathsf{sk},\mathsf{OTS}.\mathsf{pk})\leftarrow \mathsf{OTS}.\mathsf{KG}\left(1^{\lambda }\right);(m^{*},{\sigma }^{*})\leftarrow {\mathcal{A}}^{\mathsf{OTS}.\mathsf{Sig}(\mathsf{OTS}.\mathsf{sk},·)}(\mathsf{OTS}.\mathsf{pk});\\ & \mathrm{Let}(m,\sigma )\mathrm{be} \mathrm{the} \mathrm{query}\text{-}\mathrm{answer} \mathrm{pair} \mathrm{of}\mathsf{OTS}.\mathsf{Sig}(\mathsf{OTS}.\mathsf{sk},·)\\ & \mid m\ne m^{*}\wedge 1\leftarrow \mathsf{OTS}.\mathsf{Vf}(m^{*},{\sigma }^{*},\mathsf{OTS}.\mathsf{pk})]\end{array}$$

is negligible in terms of $\lambda$ [10].

Winternitz One-time Signature (WOTS) is one of the most efficient OTS schemes, designed for both lightweight performance and strong security.

Let $f:{\{0,1\}}^{*}\to {\{0,1\}}^{\lambda }$ be a one-way function, $\mathsf{H}$ be a hash function chosen randomly from the collision-resistant hash function family $\mathcal{HF}$, and $f^i$ be the i-fold iteration function of f for every $i\in \mathbb{N}$, i.e., for all $x\in {\{0,1\}}^{*}$ if $i>0$, $f^i\left(x\right)=f\left(f^{i-1}\left(x\right)\right)$, and $f^0\left(x\right)=x$ (From now on, for simplicity, we only write $\mathsf{H}$ rather than ${\mathsf{H}}_k$.). WOTS relies on two key parameters: the security parameter $\lambda$ and the Winternitz parameter w. These parameters are used to define the following quantities:

$${\xi }_1=\lceil {\displaystyle \frac{\lambda }{w}}\rceil ,{\xi }_2=\lfloor {\displaystyle \frac{log\left({\xi }_1(2^w-1)\right)}{w}}\rfloor +1,\xi ={\xi }_1+{\xi }_2.$$

WOTS consists of three algorithms

$$\mathcal{WOTS}=(\mathsf{WOTS}.\mathsf{KG},\mathsf{WOTS}.\mathsf{Sig},\mathsf{WOTS}.\mathsf{Vf}),$$

and works as follows.

$(\mathsf{WOTS}.\mathsf{sk},\mathsf{WOTS}.\mathsf{pk})\leftarrow \mathsf{WOTS}.\mathsf{KG}\left(1^{\lambda }\right):$ The key generation algorithm produces a secret key $\mathsf{WOTS}.\mathsf{sk}=(x_0,x_1,\dots ,x_{\xi -1})$, where $x_i\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$ for all $0\le i\le \xi -1$, and computes the public key $\mathsf{WOTS}.\mathsf{pk}=(y_0,y_1,\dots ,y_{\xi -1})$, where $y_i=f^{2^w-1}\left(x_i\right)$ for all $0\le i\le \xi -1$.

$\mathsf{WOTS}.\sigma \leftarrow \mathsf{WOTS}.\mathsf{Sig}(\mathsf{WOTS}.\mathsf{sk},m):$ For a given message m, this sginng algorithm first computes $d\leftarrow \mathsf{H}\left(m\right)$ and represents d in base $2^w$ as ${\left(d\right)}_{2^w}={(b_0,\dots ,b_{{\xi }_1-1})}_{2^w}$. Then, it computes the checksum $c={\sum }_{i=0}^{{\xi }_1-1}(2^w-1-b_i),$ and appends ${\left(c\right)}_{2^w}$ to ${\left(d\right)}_{2^w}$ to obtain

$$B={\left(d\right)}_{2^w}{\Vert \left(c\right)}_{2^w}={(b_0,\dots ,b_{{\xi }_1-1},b_{{\xi }_1},b_{{\xi }_1+1},\dots ,b_{\xi -1})}_{2^w}.$$

The signature on message m is $\mathsf{WOTS}.\sigma =({\sigma }_0,\dots ,{\sigma }_{\xi -1})$, where

$${\sigma }_i=f^{b_i}\left(x_i\right),\mathrm{for}\mathrm{all}0\le i\le \xi -1.$$

$0/1\leftarrow \mathsf{WOTS}.\mathsf{Vf}(m,\mathsf{WOTS}.\sigma ,\mathsf{WOTS}.\mathsf{pk}):$ The verification algorithm computes $B={\left(d\right)}_{2^w}{\Vert \left(c\right)}_{2^w}$ using the message m as done in the signing algorithm $\mathsf{WOTS}.\mathsf{Sig}$. It verifies the signature $\mathsf{WOTS}.\sigma$ by outputting 1 if

$$\mathsf{WOTS}.\mathsf{pk}=\left(f^{2^w-1-b_0}\left({\sigma }_0\right),\dots ,f^{2^w-1-b_{\xi -1}}\left({\sigma }_{\xi -1}\right)\right),$$

otherwise, it outputs 0.

2.3. Merkle Tree and Multi-Message Signature Scheme (MSS)

A Merkle tree is a binary tree in which every leaf node is the hash value of a data block, and each non-leaf node is the hash value of the concatenation of its two children. The root of the Merkle tree, also known as the Merkle root, serves as a compact representation of the entire dataset, that can be used to provide membership proof for the dataset elements. This structure efficiently verifies the integrity of any data block using a logarithmic number of hash operations and a comparison.

Figure 1 gives an example of a Merkle tree of height 3 constructed on 8 data blocks. The leaf nodes $y_3\left[i\right]$, $0\le i\le 7$, are the hash values of the data blocks and all the other nodes are computed as $y_j\left[i\right]\leftarrow \mathsf{H}(y_{j+1}\left[2i\right]\Vert y_{j+1}[2i+1])$, where $0\le j\le 2$, $0\le i<2^j$, and $\mathsf{H}$ is chosen randomly from the collision-resistant hash function family $\mathcal{HF}$. To verify the membership of a data block, say $y_3\left[3\right]$ (marked in orange), we provide the authentication path that is the sibling nodes of the nodes on the path from the mentioned data block to the root. For example the authentication path for $y_3\left[3\right]$ is the set $\{y_3\left[2\right],y_2\left[0\right],y_1\left[1\right]\}$ (marked in yellow). Now we can sequentially compute the nodes $y_2\left[1\right],y_1\left[0\right]$ and $y_0\left[0\right]$ (marked in green) which are on the path from $y_3\left[3\right]$ to root $y_0\left[0\right]$. By comparing the computed root and published root, we can determine the membership of a data block.

Figure 1. A Merkle tree of height 3.

Multimessage signaure scheme (MSS). To construct an MSS that supports up to ${\mathsf{T}}_{\mathsf{tot}}=2^h$ signatures and has a short public key, Merkle [14] proposed to construct a Merkle tree on the hash values of the public keys of the set OTSs that are used in the signature, and use the root of the tree as the MSS public key. Specifically, for $0\le i<2^h$, the i-th leaf node is defined as $y_h\left[i\right]\leftarrow \mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_i)$, where $(\mathsf{OTS}.{\mathsf{sk}}_i,\mathsf{OTS}.{\mathsf{pk}}_i)$ is the i-th OTS key pair. For $0\le j<h$ and $0\le i<2^j$, the i-th node at height j is computed as $y_j\left[i\right]\leftarrow \mathsf{H}(y_{j+1}\left[2i\right]\Vert y_{j+1}[2i+1])$. The root of the Merkle tree, $y_0\left[0\right]$, acts as the public key of the scheme.

MSS uses leaf nodes of the Merkle tree to sign messages. The signature of a message m, using the i-th OTS is $\sigma =(i,\mathsf{OTS}.{\sigma }_i,\mathsf{OTS}.{\mathsf{pk}}_i,A.pat{h}_i)$, where $\mathsf{OTS}.{\sigma }_i\leftarrow \mathsf{OTS}.\mathsf{Sig}(\mathsf{OTS}.{\mathsf{sk}}_i,m)$, and $A.pat{h}_i=(a_0,a_1,\dots ,a_{h-1})$ is authentication path for the i-leaf node, that is $y_h\left[i\right]$. To verify the signature $\sigma$ on the message m, the verifier first verifies the $\mathsf{OTS}.{\sigma }_i$ by the algorithm $\mathsf{OTS}.\mathsf{Vf}(m,\mathsf{OTS}.{\sigma }_i,\mathsf{OTS}.{\mathsf{pk}}_i)$ and upon success they compute the root of the Merkle tree using the authentication path $A.pat{h}_i$ and $y_h\left[i\right]$. If the computed root is the same as the given public key $y_0\left[0\right]$, signature ${\sigma }_i$ will be accepted.

Remark 1. 

Using WOTS in a multi-message signature scheme removes the need for including the public key of the OTS in the signature. The signature of message m using the WOTS key pair $(\mathsf{WOTS}.{\mathsf{sk}}_i,\mathsf{WOTS}.{\mathsf{pk}}_i)$ is $\sigma =(i,\mathsf{WOTS}.{\sigma }_i,A.pat{h}_i)$, where $\mathsf{WOTS}.{\sigma }_i=({\sigma }_0,\dots ,{\sigma }_{\xi -1})\leftarrow \mathsf{WOTS}.\mathsf{Sig}(\mathsf{WOTS}.{\mathsf{sk}}_i,m)$. To verify the message-signature pair $(m,\sigma )$, the verifier computes $\left(f^{2^w-1-b_0}\left({\sigma }_0\right),\dots ,f^{2^w-1-b_{\xi -1}}\left({\sigma }_{\xi -1}\right)\right)$ to derive the corresponding leaf node $y_h\left[i\right]$, and verifies if the computed leaf node and the authentication path $A.pat{h}_i$ matches the root of the Merkle tree, $y_0\left[0\right]$. If the match succeeds the signature σ is accepted.

Multi-tree structure. As we discussed above, constructing an MSS using a Merkle tree requires deriving the public key by computing all the leaves of the tree first. For a large number ${\mathsf{T}}_{\mathsf{tot}}$, this would require a significant amount of initial computation and storage. A d-layer Merkle tree reduces the initial computation required for a large number ${\mathsf{T}}_{\mathsf{tot}}$ by constructing the tree gradually [49].

An overview of a d-layer Merkle tree is shown in Figure 2. The root of the Layer 0 Merkle tree is the public key of the signature scheme and to compute the public key, only the topmost layer of the multi-tree has to be constructed. Every leaf node of a Merkle tree of layer $d-1$ signs a message, and every leaf node of the sub-trees of the layer $0\le i<d-1$ signs the Merkle root of a sub-tree of the layer below, like ${\sigma }_{d-1}$ and ${\sigma }_0$ in Figure 2, respectively. Thus, each signature of MSS in a multi-tree structure contains d OTS signatures, one for each layer. Consequently, verifying an MSS signature in a multi-tree structure includes the cost of verifying d OTS signatures.

Figure 2. A d-layer Merkle tree.

3. Fully Dynamic Group Signature

In this section, we describe a model of a fully dynamic group signature ($\mathcal{FDGS}$). Our model is based on [19,20] and is adapted to fully dynamic symmetric-key based GSS [27]. Similar to [27] (i) we consider a single trusted authority for key generation and group management (i.e., join and revoke), as well as opening of signatures, and (ii) include a request subroutine that allows users to request new keys when their existing keys are run out.

Our security model is based on [19,20,50] and loosely follows [27]. In particular, we adopt the anonymity notion that was introduced in [50] and do not allow the adversary to corrupt the manager or the two selected honest users in the anonymity game.

A $\mathcal{FDGS}$ is composed of three types of entities:

• A Trusted manager, denoted by $\mathcal{M}$, is the central authority responsible for the perfect functioning of the group. $\mathcal{M}$ allows new members to join the group, can reveal the identity of a signer, and can revoke the signing ability of misbehaved members and their generated signatures.
• Members/users anonymously sign messages on behalf of the group.
• Verifier verifies the validity of a group signature using only the public parameters.

Let $\lambda$ be the security parameter and $\mathsf{FDGS}.\mathsf{SetPr}$ be the setup parameters. A $\mathcal{FDGS}$ consists of the following polynomial-time algorithms.

• $(\mathsf{FDGS}.\mathsf{SK},\mathsf{FDGS}.\mathsf{PubPr})\leftarrow \mathsf{FDGS}.\mathsf{KG}(1^{\lambda },\mathsf{FDGS}.\mathsf{SetPr}):$ The manager $\mathcal{M}$ runs this algorithm to generate the manager’s secret key $\mathsf{FDGS}.\mathsf{SK}$, including the manager master secret key $\mathsf{msk}$ and other group secret information, and the public parameters $\mathsf{FDGS}.\mathsf{PubPr}$, including the group public key $\mathsf{gpk}$ and other group public information that are necessary for verifying signatures.
• $(({\mathsf{PL}}_{\mathcal{M}},\mathsf{ID}),(\mathsf{id},c_{\mathsf{id}}))/\perp \leftarrow \mathsf{FDGS}.\mathsf{Join}\left(\mathsf{Username}\right):$ This is an interactive joining protocol between a user with identity $\mathsf{Username}$, and the manager $\mathcal{M}$. In line with the model in [19], the communication occurs over secure (i.e., private and authenticated) channels, with the user initiating the protocol by sending their identity $\mathsf{Username}$. Let $\mathsf{ID}$ represent the list of identities of users who have already joined the group and ${\mathsf{N}}_{\mathsf{max}}$ denote the maximum number of users the system supports. Upon receiving the identity $\mathsf{Username}$, if $\mathsf{Username}\in \mathsf{ID}$ or $\left|\mathsf{ID}\right|\ge {\mathsf{N}}_{\mathsf{max}}$, the algorithm outputs ⊥. Otherwise, i.e., if $\mathsf{Username}\notin \mathsf{ID}$ and $\left|\mathsf{ID}\right|<{\mathsf{N}}_{\mathsf{max}}$, the manager $\mathcal{M}$ selects the smallest unassigned identifier $\mathsf{id}$ with $1\le \mathsf{id}\le {\mathsf{N}}_{\mathsf{max}}$ and generates a corresponding secret value $c_{\mathsf{id}}$ and sends $(\mathsf{id},c_{\mathsf{id}})$ to the user. Then, $\mathcal{M}$ stores(i) $(\mathsf{id},c_{\mathsf{id}},\mathsf{Active})$ in a private list ${\mathsf{PL}}_{\mathcal{M}}$, where $\mathsf{Active}$ indicates that the user is valid, and (ii) the user’s identity $\mathsf{Username}$ as the $\mathsf{id}$-th element in the list $\mathsf{ID}$, i.e., $\mathsf{ID}\left[\mathsf{id}\right]=\mathsf{Username}$. Thus knowing the identifier $\mathsf{id}$ allows the manager to retrieve the identity $\mathsf{Username}$ and vice versa. Two lists ${\mathsf{PL}}_{\mathcal{M}}$ and $\mathsf{ID}$ are both initially empty and ${\mathsf{PL}}_{\mathcal{M}}$ is private. When a user with identifier $\mathsf{id}$ needs new keys, the user proves their identity by securely transmitting $(\mathsf{id},c_{\mathsf{id}})$ to $\mathcal{M}$ through the secure channel. If $(\mathsf{id},c_{\mathsf{id}},\mathsf{Active})\in {\mathsf{PL}}_{\mathcal{M}}$, the manager $\mathcal{M}$ sends new keys to the user through the secure channel.
• $\sigma \leftarrow \mathsf{FDGS}.\mathsf{Sig}(m,{\mathbf{gsk}}^{\mathsf{id}}):$ This algorithm is run by a user with identifier $\mathsf{id}$. It takes a message m and a key ${\mathbf{gsk}}^{\mathsf{id}}$ and generates a group signature $\sigma$.
• $0/1\leftarrow \mathsf{FDGS}.\mathsf{Vf}(m,\sigma ,\mathsf{FDGS}.\mathsf{PubPr}):$ This is a deterministic verification algorithm run by a verifier. It takes as input a message m, a group signature $\sigma$, and the public parameters $\mathsf{FDGS}.\mathsf{PubPr}$, and outputs 1 if $\sigma$ is a valid group signature on m with respect to $\mathsf{FDGS}.\mathsf{PubPr}$, and 0 otherwise.
• $\mathsf{id}/\perp \leftarrow \mathsf{FDGS}.\mathsf{Op}(\sigma ,\mathsf{FDGS}.\mathsf{SK}):$ This deterministic opening algorithm is run by $\mathcal{M}$. It takes a valid group signature $\sigma$ and the manager’s secret key $\mathsf{FDGS}.\mathsf{SK}$, and outputs either the identifier $\mathsf{id}$ of the user who generated $\sigma$, or ⊥ if the signature cannot be attributed to any specific user. With $\mathsf{id}$, the manager can retrieve the identity $\mathsf{Username}$ of the user by looking up the $\mathsf{id}$-th entry in the list $\mathsf{ID}$, where $\mathsf{Username}$ is stored.
• $({\mathsf{PL}}_{\mathcal{M}},\mathsf{FDGS}.\mathsf{PubPr})\leftarrow \mathsf{FDGS}.\mathsf{Rev}(\mathsf{FDGS}.\mathsf{SK},{\mathsf{PL}}_{\mathcal{M}},\mathsf{FDGS}.\mathsf{PubPr},\mathsf{R}):$ The manager $\mathcal{M}$ runs this algorithm to revoke users with identifiers in a set $\mathsf{R}$ and invalidate their signatures. It takes as input a set $\mathsf{R}$, the manager’s secret key $\mathsf{FDGS}.\mathsf{SK}$, the private list ${\mathsf{PL}}_{\mathcal{M}}$, and the public parameters $\mathsf{FDGS}.\mathsf{PubPr}$, and updates both the public parameters $\mathsf{FDGS}.\mathsf{PubPr}$ and the private list ${\mathsf{PL}}_{\mathcal{M}}$. Specifically, for each $\mathsf{id}\in \mathsf{R}$, the manager replaces $(\mathsf{id},c_{\mathsf{id}},\mathsf{Active})$ with $(\mathsf{id},c_{\mathsf{id}},\mathsf{Revoked})$ in ${\mathsf{PL}}_{\mathcal{M}}$, preventing these users from requesting further keys.

3.1. Fully Dynamic Group Signature: Security Model

A fully dynamic group signature must satisfy four properties: Correctness, Unforgeability, Anonymity, and Traceability. Each of these properties is defined using the game, where each game is defined between a PPT adversary denoted by $\mathcal{A}$ and a Challenger. Each of these properties is quantified by the success probability of $\mathcal{A}$ in its game. In these games, the adversary has access to various oracles, each specifying their capabilities, which can be invoked a polynomially many times during the game.

We first describe the oracles in Table 3, and then in Definition 1 formally define the security properties of the signature scheme. The corresponding security experiments are given in Table 4. In the following, the notations $\mathcal{H}$, $\mathcal{C}$, and $\mathcal{R}$ denote the set of honest, corrupted, and revoked users, respectively. N, ${\mathsf{N}}_{\mathsf{max}}$, $\mathsf{ID}$, and ${\mathsf{PL}}_{\mathcal{M}}$ denote the number of users who have already joined the group, the max number of users that the group supports, the list of identities of users (i.e., $\mathsf{Username}$s of the joined users) and the private list of manager. Also, $\mathsf{CL}$ and $\mathsf{SL}$ indicate the challenging list and the signing list.

Table 3. Oracles.

Table 4. Experiments.

${\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{\mathbf{Corr}}\left(\mathit{\lambda }\right)$
$(\mathsf{FDGS}.\mathsf{SK},\mathsf{FDGS}.\mathsf{PubPr})\leftarrow \mathsf{FDGS}.\mathsf{KG}(1^{\lambda },\mathsf{FDGS}.\mathsf{SetPr})$; $N=0;\mathsf{ID}=\varnothing ;\mathsf{id}=\perp ;\mathcal{H}=\varnothing ;\mathcal{C}=\varnothing ;\mathcal{R}=\varnothing$; $m,\mathsf{id}\leftarrow {\mathcal{A}}^{\mathsf{AddHU},\mathsf{AddCU},\mathsf{Revoke}}(\mathsf{FDGS}.\mathsf{PubPr})$; if  $\mathsf{id}\notin \mathcal{H}$, then return 0; $\sigma \leftarrow \mathsf{FDGS}.\mathsf{Sig}(m,{\mathsf{gsk}}^{\mathsf{id}})$; if  $\mathsf{FDGS}.\mathsf{Vf}(m,\sigma ,\mathsf{FDGS}.\mathsf{PubPr})=0$, then return 1; if  $\mathsf{FDGS}.\mathsf{Op}(\sigma ,\mathsf{FDGS}.\mathsf{SK})\ne \mathsf{id}$, then return 1; return 0;
${\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Unforg}}\left(\lambda \right)$
$(\mathsf{FDGS}.\mathsf{SK},\mathsf{FDGS}.\mathsf{PubPr})\leftarrow \mathsf{FDGS}.\mathsf{KG}(1^{\lambda },\mathsf{FDGS}.\mathsf{SetPr})$; $N=0;\mathsf{ID}=\varnothing ;\mathcal{H}=\varnothing ;\mathcal{C}=\varnothing ;\mathcal{R}=\varnothing ;\mathsf{SL}=\varnothing$; $(m,\sigma )\leftarrow {\mathcal{A}}^{\mathsf{AddHU},\mathsf{AddCU},\mathsf{SignHU},\mathsf{Revoke}}(\mathsf{FDGS}.\mathsf{PubPr})$; if  $(m,\sigma )\in \mathsf{SL}\vee \mathsf{FDGS}.\mathsf{Vf}(m,\sigma ,\mathsf{FDGS}.\mathsf{PubPr})=0$, then return 0; if  $\mathsf{FDGS}.\mathsf{Op}(\sigma ,\mathsf{FDGS}.\mathsf{SK})\notin \mathcal{H}$, then return 0; return 1;
${\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Anon}-\mathrm{b}}\left(\lambda \right)$
$(\mathsf{FDGS}.\mathsf{SK},\mathsf{FDGS}.\mathsf{PubPr})\leftarrow \mathsf{FDGS}.\mathsf{KG}(1^{\lambda },\mathsf{FDGS}.\mathsf{SetPr})$; $N=0;\mathsf{ID}=\varnothing ;\mathcal{H}=\varnothing ;\mathcal{C}=\varnothing ;\mathcal{R}=\varnothing ;\mathsf{CL}=\varnothing$; $b^{\prime }\leftarrow {\mathcal{A}}^{\mathsf{AddHU},\mathsf{AddCU},\mathsf{SignHU},\mathsf{Revoke},\mathsf{Open},{\mathsf{Ch}}_b}(\mathsf{FDGS}.\mathsf{PubPr})$; return $b^{\prime }$;
${\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Trace}}\left(\lambda \right)$
$(\mathsf{FDGS}.\mathsf{SK},\mathsf{FDGS}.\mathsf{PubPr})\leftarrow \mathsf{FDGS}.\mathsf{KG}(1^{\lambda },\mathsf{FDGS}.\mathsf{SetPr})$; $N=0;\mathsf{ID}=\varnothing ;\mathcal{H}=\varnothing ;\mathcal{C}=\varnothing ;\mathcal{R}=\varnothing$; $(m,\sigma )\leftarrow {\mathcal{A}}^{\mathsf{AddHU},\mathsf{AddCU},\mathsf{SignHU},\mathsf{Revoke}}(\mathsf{FDGS}.\mathsf{PubPr})$; if  $\mathsf{FDGS}.\mathsf{Vf}(m,\sigma ,\mathsf{FDGS}.\mathsf{PubPr})=0$, then return 0; if  $\mathsf{FDGS}.\mathsf{Op}(\sigma ,\mathsf{FDGS}.\mathsf{SK})=\perp$, then return 1; return 0;

• $\mathsf{AddHU}\left(\mathsf{Username}\right):$ This oracle simulates the join protocol $\mathsf{FDGS}.\mathsf{Join}$ between a user with identity $\mathsf{Username}$ and the manager $\mathcal{M}$. If $\mathsf{Username}\notin \mathsf{ID}$ and $N<{\mathsf{N}}_{\mathsf{max}}$, this oracle adds this user to the group as an honest user, i.e., adds $(\mathsf{id},c_{\mathsf{id}},\mathsf{Active})$ to the private list ${\mathsf{PL}}_{\mathcal{M}}$ and stores the user’s identity $\mathsf{Username}$ as the $\mathsf{id}$-th element in the list $\mathsf{ID}$, where $\mathsf{id}$ is the smallest unassigned identifier in $[1,{\mathsf{N}}_{\mathsf{max}}]$. Finally, it returns $\mathsf{id}$ to the adversary $\mathcal{A}$. $\mathcal{A}$ does not learn $c_{\mathsf{id}}$.
• $\mathsf{AddCU}\left(\mathsf{id}\right):$ This oracle allows the adversary $\mathcal{A}$ to corrupt an honest user with identifier $\mathsf{id}$. It adds $\mathsf{id}$ to $\mathcal{C}$ and removes $\mathsf{id}$ from $\mathcal{H}$ and finally returns the secret value $c_{\mathsf{id}}$ to $\mathcal{A}$, enabling $\mathcal{A}$ to communicate with the manager $\mathcal{M}$ and receive this user’s keys from $\mathcal{M}$.
• $\mathsf{Revoke}\left(\mathsf{R}\right):$ This oracle allows the adversary $\mathcal{A}$ to revoke the set $\mathsf{R}$ of users by updating the private list ${\mathsf{PL}}_{\mathcal{M}}$ and the public parameters $\mathsf{FDGS}.\mathsf{PubPr}$. Specifically, for any $\mathsf{id}\in \mathsf{R}$, $(\mathsf{id},c_{\mathsf{id}},\mathsf{Active})$ will be replaced with $(\mathsf{id},c_{\mathsf{id}},\mathsf{Revoked})$ in ${\mathsf{PL}}_{\mathcal{M}}$, preventing these $\mathsf{id}$s from requesting further keys. Also, it invalidates their previously generated signatures by updating $\mathsf{FDGS}.\mathsf{PubPr}$.
• ${\mathsf{Ch}}_b({\mathsf{id}}_0,{\mathsf{id}}_1,m):$ This oracle takes the identifiers ${\mathsf{id}}_0$ and ${\mathsf{id}}_1$ of two honest users along with a message m, then randomly selects a bit b and outputs the signature ${\sigma }_b$ on m by an unused secret key of the user ${\mathsf{id}}_b$. It keeps $(m,{\sigma }_b)$ in the challenge list $\mathsf{CL}$ to prevent $\mathcal{A}$ from calling the opening oracle $\mathsf{Open}(·,·)$ on $(m,{\sigma }_b)$ in the Anonymity experiment.
• $\mathsf{Open}(m,\sigma ):$ This oracle takes as input a pair $(m,\sigma )$. If $\sigma$ is a valid signature on m and $(m,\sigma )\notin \mathsf{CL}$, it returns $\mathsf{FDGS}.\mathsf{Op}(\sigma ,\mathsf{FDGS}.\mathsf{SK})$, which is either the identifier $\mathsf{id}$ of the user who produced the signature $\sigma$, or ⊥ if $\sigma$ cannot be attributed to any user.
• $\mathsf{SignHU}(\mathsf{id},m):$ This oracle takes as input an identifier $\mathsf{id}$ and a message m. If this user is honest, it returns $\sigma \leftarrow \mathsf{FDGS}.\mathsf{Sig}(m,{\mathbf{gsk}}^{\mathsf{id}})$, where ${\mathbf{gsk}}^{\mathsf{id}}$ is a secret key of this user. The oracle also adds $(m,\sigma )$ to the signing list $\mathsf{SL}$ to prevent $\mathcal{A}$ from using $(m,\sigma )$ in the Unforgeability experiment.

The Correctness property ensures that even if the adversary $\mathcal{A}$ corrupts a set of users (possibly all except one), the honest user can successfully enroll and create valid signatures that can be traced back to them. The Unforgeability property ensures that the adversary cannot produce a valid signature that can be falsely attributed to an honest user, even if the adversary corrupts the rest of the users. Anonymity is defined through an indistinguishability experiment between the adversary and the challenger. In this experiment, the adversary knows the secret keys of all users except two. The Anonymity property requires that the adversary has only a negligible advantage in distinguishing a signature generated by randomly selecting one of the two identifiers and using the corresponding private key to sign the message. Finally, the Traceability property ensures that every valid signature is linked to a user.

Definition 1. 

For any security parameter $\lambda \in \mathbb{N}$ and for any PPT adversary $\mathcal{A}$, we say that an $\mathcal{FDGS}$ provides:

1.

Correctness if there exists a negligible function ${ϵ}_1$ such that

$$\begin{array}{c}\hfill {\mathbf{Adv}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Corr}}\left(\lambda \right)=\mathrm{Pr}\left[{\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Corr}}\left(\lambda \right)=1\right]\le {ϵ}_1\left(\lambda \right),\end{array}$$

2.

Unforgeability if there exists a negligible function ${ϵ}_2$ such that

$$\begin{array}{c}\hfill {\mathbf{Adv}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Unforg}}\left(\lambda \right)=\mathrm{Pr}\left[{\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Unforg}}\left(\lambda \right)=1\right]\le {ϵ}_2\left(\lambda \right),\end{array}$$

3.

Anonymity if there exists a negligible function ${ϵ}_3$ such that

$$\begin{array}{c}\hfill {\mathbf{Adv}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Anon}}\left(\lambda \right)=\left|\mathrm{Pr}\left[{\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{Anon-0}\left(\lambda \right)=1\right]\right.-\left.\mathrm{Pr}\left[{\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{Anon-1}\left(\lambda \right)=1\right]\right|\le {ϵ}_3\left(\lambda \right),\end{array}$$

4.

Traceability if there exists a negligible function ${ϵ}_4$ such that

$$\begin{array}{c}\hfill {\mathbf{Adv}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Trace}}\left(\lambda \right)=\mathrm{Pr}\left[{\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Trace}}\left(\lambda \right)=1\right]\le {ϵ}_4\left(\lambda \right),\end{array}$$

where ${\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Corr}}\left(\lambda \right)$, ${\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Unforg}}\left(\lambda \right)$, ${\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Anon}-\mathrm{b}}\left(\lambda \right)$ and ${\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Trace}}\left(\lambda \right)$ are defined in Table 4.

3.2. An Overview of $\mathrm{DGM}$

DGM is a fully dynamic group signature scheme based on symmetric primitives that uses a collision-resistant hash function $\mathsf{H}$, an $\mathcal{OTS}$ scheme, a symmetric puncturable encryption scheme $\mathcal{SPE}$, and a symmetric key encryption scheme $\mathcal{SE}$. DGM employs two types of Merkle trees: One Initial Merkle tree (IMT) and multiple Signing Merkle trees (SMT). This IMT/SMT structure allows the manager to gradually construct the tree, avoiding the unacceptable computational cost of building the entire tree during the setup phase. In the following, we review DGM and mention its main shortcomings. See [27] for further details.

In DGM, the IMT is of height 20 and its leaf nodes are randomly chosen strings. The root of the IMT is the group public key $\mathsf{DGM}.\mathsf{gpk}$. SMTs are variable-height Merkle trees and their leaf nodes correspond to the OTSs that are used to sign messages by users. Each SMT is connected to only one internal node of the IMT. While DGM allows multiple SMTs per fallback node, this is not formalized or included in the security proof. The height of an SMT is equal to $20-h^{*}$, where $h^{*}$ is the height of the corresponding internal node in the IMT. When a user requires B signing keys, they send a request to the manager, who randomly selects B internal nodes from the IMT and allocates the next available B OTSs from the B SMTs linked to those internal nodes. If an SMT has no available OTS, the manager generates a new SMT, links it to the corresponding internal node, and assigns an OTS from the newly created SMT.

SMT Generation. SMTs are generated gradually and linked randomly to the internal nodes of IMT and their leaf nodes will be distributed among the users. Let the height of the t-th SMT be $h^{\prime }$. The DGM manager generates $z=2^{h^{\prime }}$ OTS key pairs $(\mathsf{OTS}.{\mathsf{sk}}_{t,l},\mathsf{OTS}.{\mathsf{pk}}_{t,l})$ for $0\le l<z$, and shuffles the leaf nodes of this SMT, indexed by ${\left\{(t,l)\right\}}_{l=0}^{z-1}$, using the symmetric encryption scheme $\mathcal{SE}$. More precisely, the leaf nodes are constructed as $\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{t,l}\Vert \mathsf{DGM}.{\mathsf{pos}}_{t,l})$, where $\mathsf{DGM}.{\mathsf{pos}}_{t,l}\leftarrow \mathsf{SE}.\mathsf{Enc}(\mathsf{msk},t\Vert l)$, with $\mathsf{msk}$ being the manager’s secret key. These nodes are then sorted in increasing order based on their $\mathsf{DGM}.{\mathsf{pos}}_{t,l}$ values for $0\le l<z$. We note that after sorting the leaf nodes, the l-th leaf node will be located at index $l^{\prime }$.

Let $r_t$ be the root of the t-th SMT, which is connected to an internal node of the IMT, denoted by $F{n}_i$ (called fallback node), using a fallback key $F{k}_t\leftarrow \mathsf{SE}.\mathsf{Dec}(r_t,F{n}_i)$ (See Figure 3). The signature of a message m by $\mathsf{OTS}.{\mathsf{sk}}_{t,l}$ is

$${\sigma }_{DGM}=((i,l^{\prime }),\mathsf{OTS}.{\sigma }_{t,l},\mathsf{OTS}.{\mathsf{pk}}_{t,l},\mathsf{DGM}.{\mathsf{pos}}_{t,l},F{k}_t,\mathsf{DGM}.{\mathsf{path}}_{i,l^{\prime }}),$$

where i is the index of fallback node $F{n}_i$, $l^{\prime }$ is the index of the leaf node of the OTS key pair $(\mathsf{OTS}.{\mathsf{sk}}_{t,l},\mathsf{OTS}.{\mathsf{pk}}_{t,l})$ after sorting the leaf nodes, $\mathsf{OTS}.{\sigma }_{t,l}\leftarrow \mathsf{OTS}.\mathsf{Sig}(\mathsf{OTS}.{\mathsf{sk}}_{t,l},m)$, and $\mathsf{DGM}.{\mathsf{path}}_{i,l^{\prime }}$ is the authentication path from the leaf node with index $(i,l^{\prime })$ in SMT to the root of IMT. See Figure 3 for the IMT/SMT structure of DMG.

Figure 3. IMT/SMT structure of DGM. The red node represents the group public key $\mathsf{DGM}.\mathsf{gpk}$, the orange nodes represent the fallback nodes ${\left\{F{n}_i\right\}}_{i=1}^6$, the green nodes $F{k}_t$ and $F{k}_{t^{\prime }}$ represent the fallback keys, and the yellow nodes are the root of the $\mathrm{SMT}$s. The fallback key $F{k}_t$ is computed as $F{k}_t\leftarrow \mathsf{SE}.\mathsf{Dec}(r_t,F{n}_i)$, where $r_t$ is the key.

DGM Limitations. There are two main shortcomings in DGM. First, during verification, the verifier must interact with the manager to check the validity of the fallback key $F{k}_t$, requiring the manager to be always online. This creates a system bottleneck and a single point of failure. Second, the manager must maintain a list containing all the allocated $\mathsf{DGM}.{\mathsf{pos}}_{t,l}$ to users for the purpose of opening signatures via list-based searches, and revoking users. Thus, the manager’s storage grows linearly with the total number of signatures in the system and becomes unacceptably large when a large number of signatures is required. For instance, to accommodate ${\mathsf{T}}_{\mathsf{tot}}=2^{64}$ OTSs, the manager requires $\sim {10}^{8.7}$ Terabytes of storage (see [26] for details).

4. DGMT: A Flexible Fully Dynamic Symmetric-Key Based GSS

DGMT is an improved version of DGM that removes DGM’s notable shortcomings, such as the need for interactive verification and the unreasonable storage requirements proportional to ${\mathsf{T}}_{\mathsf{tot}}$, the total number of supported signatures. In this section, we first present an overview of DGMT in Section 4.1, then explain the details of the DGMT’s tree construction and its algorithms in Section 4.2 and Section 4.3, respectively. Finally, we discuss the typical parameters of DGMT in Section 4.4. The main symbols used in DGMT are summarized in Table 5.

Table 5. List of Symbols.

$\mathrm{IMT}$	Initial Merkle Tree
$r_{\mathrm{IMT}}$	The root of IMT
$F{n}_i$	The i-th internal node of IMT (the i-th fallback node)
${\mathrm{SMT}}^{\mathrm{MT}}$	Multilayer Signing Merkle Tree; We use 2-layer tree
${\mathrm{SMT}}^{\left(1\right)}$	First (or Upper) layer of ${\mathrm{SMT}}^{\mathrm{MT}}$
${\mathrm{SMT}}^{\left(2\right)}$	Second (or Lower) layer of ${\mathrm{SMT}}^{\mathrm{MT}}$
${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\mathrm{MT}}$	The j-th ${\mathrm{SMT}}^{\mathrm{MT}}$ that is attached to $F{n}_i$
${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$	${\mathrm{SMT}}^{\left(1\right)}$ of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\mathrm{MT}}$
${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$	${\mathrm{SMT}}^{\left(2\right)}$ attached to the k-th leaf node (from left) of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$
$(i,j,k)$	The index of the k-th leaf node of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$
$(i,j,k,l)$	The index of the l-th-leaf node of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$
$h_I,h_{SM},h_S$	Heights of $\mathrm{IMT}$, ${\mathrm{SMT}}^{\mathrm{MT}}$, and ${\mathrm{SMT}}^{\left(1\right)}$ (${\mathrm{SMT}}^{\left(2\right)}$), respectively
$\alpha$	The number of leaves of ${\mathrm{SMT}}^{\left(1\right)}$ and ${\mathrm{SMT}}^{\left(2\right)}$, $\alpha =2^{h_S}$
${\mathsf{T}}_{\mathsf{tot}}$	The total number of signatures that DGMT supports
${\mathsf{N}}_{\mathsf{max}}$	The maximum member of users that DGMT supports
$\beta$	The number of keys allocated to a user in each ${\mathrm{SMT}}^{\left(2\right)}$
$\mathsf{msk}$	The manager’s master secret key of the SPRP ${\mathsf{g}}_2$
$\mathsf{IMT}.\mathsf{key}$	The key of the PRF $\mathsf{f}$ for generating the leaf nodes of the IMT
${\mathsf{SMT}}_{\mathsf{1}}.\mathsf{key}$	The key of the PRF $\mathsf{f}$ for generating the leaf nodes of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$
${\mathsf{SMT}}_{\mathsf{2}}.\mathsf{key}$	The key of the PRF $\mathsf{f}$ for generating the leaf nodes of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$
$\mathsf{shuffle}.\mathsf{key}$	The secret key of the SPRP ${\mathsf{g}}_1$ for shuffling the leaves of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$
$(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k})$	OTS key pair corresponding to the leaf node at index $(i,j,k)$
$(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k,l},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l})$	OTS key pair corresponding to the leaf node at index $(i,j,k,l)$
$r_{i,j}$	The root of the ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\mathrm{MT}}$ (or ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)})$
$r_{i,j,k}$	The root of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$
$\gamma$	The number of ${\mathrm{SMT}}^{\mathrm{MT}}$s linked to each internal node of IMT
$\mathcal{FK}$	The list of fallback keys
$F{k}_{i,j}$	The fallback key that links ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\mathrm{MT}}$ to the internal node $F{n}_i$. $F{k}_{i,j}$ is stored as the $\left(\right(i-1)\gamma +j)$-th elemenet of the list $\mathcal{FK}$.
$\mathcal{RL}$	The revocation list
${\mathcal{I}}_t$	The interval $\left[\beta \right(t-1),t\beta -1]$ for index t
$\mathsf{DGMT}.\mathsf{SetPr}$	The setup parameters of DGMT, (hI, hSM, γ, ${\mathsf{T}}_{\mathsf{tot}}$, ${\mathsf{N}}_{\mathsf{max}}$
$\mathsf{DGMT}.\mathsf{SK}$	The secret keys $(\mathsf{msk},\mathsf{IMT}.\mathsf{key},{\mathsf{SMT}}_{\mathsf{1}}.\mathsf{key},{\mathsf{SMT}}_{\mathsf{2}}.\mathsf{key},\mathsf{shuffle}.\mathsf{key})$
$\mathsf{DGMT}.\mathsf{gpk}$	The group public key, which is the root of IMT, i.e., $r_{\mathrm{IMT}}$
$\mathsf{DGMT}.\mathsf{PubPr}$	The group public parameters $(\mathsf{DGMT}.\mathsf{gpk},\mathcal{FK},\mathcal{RL})$
${\mathcal{L}}_{i,j,k}$	The shuffled index list of leaves of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$
${\sigma }_{i,j,k}$	The signature $\mathsf{OTS}.\mathsf{Sig}(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k},r_{i,j,k})$
${\sigma }_{i,j,k,l}$	The signature $\mathsf{OTS}.\mathsf{Sig}(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k,l},m)$
$\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}$	${\mathsf{g}}_2(\mathsf{msk},i\Vert j\Vert k\Vert l)$
$A.pat{h}_i$	Authentication path from $F{n}_i$ to $r_{\mathrm{IMT}}$
$A.pat{h}_{i,j,k}$	Authentication path from leaf node with index $(i,j,k)$ to $r_{ij}$
$A.pat{h}_{i,j,k,l^{\prime }}$	Authentication path from leaf node with index $(i,j,k,l^{\prime })$ to $r_{i,j,k}$

4.1. DGMT: An Overview

DGMT uses a hash function $\mathsf{H}:{\{0,1\}}^{*}\to {\{0,1\}}^{\lambda }$ that is randomly selected from a collision-resistant hash function family $\mathcal{HF}$, an EU-CMA one-time signature scheme $\mathcal{OTS}=(\mathsf{OTS}.\mathsf{KG},\mathsf{OTS}.\mathsf{Sig},\mathsf{OTS}.\mathsf{Vf})$, a PRF $\mathsf{f}:{\{0,1\}}^{\lambda }\times {\{0,1\}}^{\lambda }\to {\{0,1\}}^{\lambda }$, and two SPRPs ${\mathsf{g}}_1:{\{0,1\}}^{\lambda }\times {\{0,1\}}^{\lambda }\to {\{0,1\}}^{\lambda }$ and ${\mathsf{g}}_2:{\{0,1\}}^{\lambda }\times {\{0,1\}}^{\lambda }\to {\{0,1\}}^{\lambda }$.

Tree structure. DGMT uses the $\mathrm{IMT}/{\mathrm{SMT}}^{\mathrm{MT}}$ structure, which is similar to the $\mathrm{IMT}/\mathrm{SMT}$ structure of DGM, with two key modifications outlined below. First, similar to DGM, the IMT is a Merkle tree generated over a set of randomly chosen leaf nodes and its root forms the group public key, denoted by $\mathsf{DGMT}.\mathsf{gpk}$. However, in DGMT all nodes of IMT, except the root node, are used as fallback nodes. Second, unlike DGM which uses $\mathrm{SMT}$s with variable heights, DGMT employs ${\mathrm{SMT}}^{\mathrm{MT}}$s with the same height, where each ${\mathrm{SMT}}^{\mathrm{MT}}$ is a two-layer Merkle tree, and both layers have the same height $h_S$. The root node of an ${\mathrm{SMT}}^{\mathrm{MT}}$ is connected to a fallback node using a fallback key. A fallback node is used to attach $\gamma$ number of ${\mathrm{SMT}}^{\mathrm{MT}}$s, each using a distinct fallback key, to the IMT. We use the numbering of IMT nodes and the multiplicity number of ${\mathrm{SMT}}^{\mathrm{MT}}$s that are attached to an IMT node to give a unique sequential index to each ${\mathrm{SMT}}^{\mathrm{MT}}$. Thus the j-th ${\mathrm{SMT}}^{\mathrm{MT}}$ that is connected to the i-fallback node $F{n}_i$ will be labeled ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\mathrm{MT}}$ and will be associated with the fallback key $F{k}_{i,j}$. The $\mathrm{IMT}/{\mathrm{SMT}}^{\mathrm{MT}}$ structure is explained in Algorithm 1 and illustrated in Figure 4.

Figure 4. $\mathrm{IMT}/{\mathrm{SMT}}^{\mathrm{MT}}$ structure of DGMT. The red node represents the group public key $\mathsf{DGMT}.\mathsf{gpk}$, the orange nodes represent the fallback nodes ${\left\{F{n}_i\right\}}_{i=1}^6$, the yellow nodes $F{k}_{6,1}$ and $F{k}_{6,2}$ represent two of the fallback keys, the green nodes are the root of the ${\mathrm{SMT}}^{\mathrm{MT}}$s and play the role of the keys, say $F{k}_{6,1}\leftarrow {\mathsf{g}}_1(r_{6,1},F{n}_6)$, where $r_{6,1}$ is the root of the ${\mathrm{SMT}}_{6,1}^{\mathrm{MT}}$ and $r_{6,1}$ is the key.

The top and bottom layers of the two-layer ${\mathrm{SMT}}^{\mathrm{MT}}$ are denoted by ${\mathrm{SMT}}^{\left(1\right)}$ and ${\mathrm{SMT}}^{\left(2\right)}$, respectively. In particular, the ${\mathrm{SMT}}^{\left(1\right)}$ of the ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\mathrm{MT}}$ is denoted by ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$ and the ${\mathrm{SMT}}^{\left(2\right)}$ of the ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\mathrm{MT}}$ linked to the k-th leaf node (from left) of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$ is denoted by ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$. From now on, we let $(i,j,k)$ be the index of the k-th leaf node of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$, and $(i,j,k,l)$ be the index of the l-th leaf node of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$.

The manager uses the PRF $\mathsf{f}$ and a secret key ${\mathsf{SMT}}_{\mathsf{1}}.\mathsf{key}$ to generate OTS key pairs $(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k})$, for $0\le k<2^{h_s}$, and construct the ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$ as an MSS, as described in Section 2.3. Also, the manager uses the PRF $\mathsf{f}$ and a secret key ${\mathsf{SMT}}_{\mathsf{2}}.\mathsf{key}$ to generate the OTS key pairs $(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k,l},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l})$, for $0\le l<2^{h_s}$, and construct ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$ for all $i,j,k$. However, for ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$s the manager first permutes the set $\{(i,j,k,l)\mid 0\le l<2^{h_s}\}$ using the SPRP ${\mathsf{g}}_1$ (See Algorithm 2). Let the index $(i,j,k,l^{\prime })$ be the permuted position of the index $(i,j,k,l)$. After permutation, the leaf node at index $(i,j,k,l^{\prime })$, for $0\le l^{\prime }<2^{h_s}$, is computed as $\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}\Vert \mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l})$, where $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}\leftarrow {\mathsf{g}}_2(\mathsf{msk},i\Vert j\Vert k\Vert l)$ and $\mathsf{msk}$ is the manager’s master secret key of the SPRP ${\mathsf{g}}_2$. Finally, ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$ is constructed as an MSS using these permuted leaf nodes. See Algorithm 3.

Setup phase. During the setup phase, the manager performs the following steps: (i) Generates the group secret keys $\mathsf{DGMT}.\mathsf{SK}$ using the Algorithm 4 (ii) Constructs the IMT to compute the group public key $\mathsf{DGMT}.\mathsf{gpk}$, (iii) Constructs all ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$, for all valid i and j, and uses the root of each ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$, denoted by $r_{i,j}$, to compute its corresponding fallback key $F{k}_{i,j}\leftarrow {\mathsf{g}}_1(r_{i,j},F{n}_i)$, linking ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\mathrm{MT}}$ to the internal node $F{n}_i$ of IMT, and (iv) Publishes the group public parameter $\mathsf{DGMT}.\mathsf{PubPr}=(\mathsf{DGMT}.\mathsf{gpk},\mathcal{FK},\mathcal{RL})$, where $\mathcal{FK}$ is the list of all fallback keys and $\mathcal{RL}$ is the revocation list, initially empty. There are $\gamma$ fallback keys for each IMT internal node, and $F{k}_{i,j}$ is stored as the $\left(\gamma \right(i-1)+j)$-th element in the list $\mathcal{FK}$. See Section 4.2 specifically Algorithm 1.

Join and Request OTS key pairs. In DGMT, a user first joins the group and receives $(\mathsf{id},c_{\mathsf{id}})$ using the Algorithm 5. When the user with identifier $\mathsf{id}$ needs OTS key pairs, they send $(\mathsf{id},c_{\mathsf{id}})$ as a request for new keys to the manager. Upon receiving this request, if $(\mathsf{id},c_{\mathsf{id}})$ is valid and the user has not been revoked (i.e., $(\mathsf{id},c_{\mathsf{id}},\mathsf{Active})\in {\mathsf{PL}}_{\mathcal{M}}$), the manager randomly selects B fallback nodes ${\left\{F{n}_i\right\}}_{i=1}^B$ and allocates the first available OTS key pair from the corresponding ${\mathrm{SMT}}^{\mathrm{MT}}$s. If no available OTS keys remain in a selected ${\mathrm{SMT}}^{\mathrm{MT}}$, the manager deterministically generates a new ${\mathrm{SMT}}^{\mathrm{MT}}$, ensuring the fallback keys match those computed during the setup phase. This request can be repeated when all OTS keys are exhausted to receive new keys. This process is similar to the approach used in DGM. See Section 4.2 and Algorithm 6.

Signing. The format of the DGMT signature ${\sigma }_{DGMT}$ on a message m, generated using the OTS key pair $(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k,l^{\prime }},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }})$ at index $(i,j,k,l^{\prime })$, is as follows:

$$\begin{array}{cc}\hfill {\sigma }_{\mathrm{DGMT}}=& ((i,j,k,l^{\prime }),\mathsf{OTS}.\mathsf{Sig}(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k,l^{\prime }},m),\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l},\hfill \\ & A.pat{h}_{i,j,k,l^{\prime }},\mathsf{OTS}.\mathsf{Sig}(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k},r_{i,j,k}),\mathsf{OTS}.{\mathsf{pk}}_{i,j,k},A.pat{h}_{i,j,k},A.pat{h}_i).\hfill \end{array}$$

(1)

$\mathsf{OTS}.\mathsf{Sig}(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k,l^{\prime }},m)$ is the only part of ${\sigma }_{\mathrm{DGMT}}$ that is computed by signer, while the remainder is provided by the manager during the OTS key pair request phase. Each signature has a unique and secret value $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}$ that is used for both tracing and revoking signatures. The authentication path from the leaf node indexed by $(i,j,k,l^{\prime })$ to $\mathsf{DGMT}.\mathsf{gpk}$ consists of three parts: (i) the authentication path $A.pat{h}_{i,j,k,l^{\prime }}$ from the leaf node at index $(i,j,k,l^{\prime })$ to the root ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$, denoted by $r_{i,j,k}$, (ii) the authentication path $A.pat{h}_{i,j,k}$ from the leaf node at index $(i,j,k)$ to the root ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$, denoted by $r_{i,j}$, and (iii) the authentication path $A.pat{h}_i$ from $F{n}_i$ to $\mathsf{DGMT}.\mathsf{gpk}$. Moreover, $\mathsf{OTS}.\mathsf{Sig}(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k},r_{i,j,k})$ is the signature on $r_{i,j,k}$ by the OTS key pair $(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k})$. See Algorithm 7.

Revoking a user. DGMT employs the SPRP ${\mathsf{g}}_2$ to compute and add all assigned $\mathsf{DGMT}.\mathsf{pos}$s of a misbehaving user to the revocation list $\mathcal{RL}$. In DGMT, each user is assigned a unique interval, allowing the manager to run this process efficiently without the need to store all users’ $\mathsf{DGMT}.\mathsf{pos}$s in advance, computing them only when necessary. In contrast, in DGM, the manager uses a symmetric puncturable encryption scheme $\mathcal{SPE}$ to puncture all $\mathsf{DGM}.{\mathsf{pos}}_{t,l}$ of a misbehaved user. Our revocation list-based method requires significantly less storage and computation compared to $\mathcal{SPE}$-based revocation of DGM. See Section 6 for a detailed analysis.

Verification. Verifying a signature ${\sigma }_{DGMT}$ on a message m involves the following four steps: (i) Ensure that $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}\notin \mathcal{RL}$, (ii) Verify $\mathsf{OTS}.\mathsf{Sig}(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k,l^{\prime }},m)$ and $\mathsf{OTS}.\mathsf{Sig}(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k},r_{i,j,k})$ using the public keys $\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}$ and $\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}$, (iii) Compute $F{n}_i\leftarrow {\mathsf{g}}_{\mathsf{1}}^{-\mathsf{1}}\left(r_{i,j},\mathcal{FK}\left[(\gamma (i-1)+j)\right]\right)$, where $\mathcal{FK}\left[\right(\gamma (i-1)+j\left)\right]$ is the $\left(\gamma \right(i-1)+j)$-th element of the list $\mathcal{FK}$, and (iv) Verify that the computed group public key from $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}$, the authentication path, and $F{n}_i$ equals to $\mathsf{DGMT}.\mathsf{gpk}$. For details on the verification algorithm and user revocation, see Algorithm 8 and Algorithm 9, respectively. Unlike DGM, DGMT’s verification is non-interactive, and the fallback key is not included in the signature.

Opening. DGMT opens the signature ${\sigma }_{DGMT}$ by computing $i\Vert j\Vert k\Vert l\leftarrow {\mathsf{g}}_2^{-1}(\mathsf{msk},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l})$. Indeed, the method of distributing leaf nodes among users and including $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}$ as part of the signature ${\sigma }_{DGMT}$ allows the manager to trace each signature using the secret key $\mathsf{msk}$. See Algorithm 10 for details. In contrast, in DGM, the manager must store $\mathsf{DGM}.{\mathsf{pos}}_{t,l}$ in a list and search through the list to open each signature, a process that becomes prohibitively expensive for large ${\mathsf{T}}_{\mathsf{tot}}$.

4.2. Constructing DGMT Tree

In this section, we provide a detailed explanation of the DGMT tree framework and discuss how its design effectively removes the limitations of DGM.

4.2.1. Setup Parameters

DGMT is designed to support ${\mathsf{T}}_{\mathsf{tot}}$ signatures and ${\mathsf{N}}_{\mathsf{max}}$ users. Based on these values, DGMT selects three parameters $h_I$, $h_{SM}$, and $\gamma$ and defines its setup parameters as

$$\mathsf{DGMT}.\mathsf{SetPr}=(h_I,h_{SM},\gamma ,{\mathsf{T}}_{\mathsf{tot}},{\mathsf{N}}_{\mathsf{max}}),$$

where $h_I$, $h_{SM}$, and $\gamma$ represent the height of the IMT, the height of the ${\mathrm{SMT}}^{\mathrm{MT}}$s, and the number of ${\mathrm{SMT}}^{\mathrm{MT}}$s attached to each fallback node, respectively. These parameters provide flexibility to the system, allowing it to efficiently generate at least ${\mathsf{T}}_{\mathsf{tot}}$ OTS key pairs and accommodate ${\mathsf{N}}_{\mathsf{max}}$ users. DGMT also uses two public lists: (i) A list $\mathcal{FK}$ of the fallback keys, and (ii) A revocation list $\mathcal{RL}$ of revoked signatures. The following relations hold in the $\mathrm{IMT}/{\mathrm{SMT}}^{\mathrm{MT}}$ structure of DGMT.

1.

Each ${\mathrm{SMT}}^{\mathrm{MT}}$ is a two-layer Merkle tree with layers of equal height $h_S$, so $h_{SM}=2h_S$.

2.

Given the parameters $h_I$, $h_{SM}$, and $\gamma$ in DGMT, the total number of OTS key pairs is ${\mathsf{T}}_{\mathsf{tot}}=\gamma (2^{h_I+1}-2)2^{h_{SM}}$.

3.

The number of fallback keys in DGMT for the given setup parameters $\mathsf{DGMT}.\mathsf{SetPr}$ is $\left|\mathcal{FK}\right|=\gamma (2^{h_I+1}-2)={\mathsf{T}}_{\mathsf{tot}}/2^{h_{SM}}$.

4.

Each user must receive at least two keys from each ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$, for every $(i,j,k)$, thus $h_S$ must satisfy ${\mathsf{N}}_{\mathsf{max}}\le \alpha /2$, where $\alpha =2^{h_S}$ (See the Anonymity proof in Section 5).

5.

For each tuple $(i,j,k)$ and $(i,j,k,l)$, we have $1\le i<2^{h_I+1}-1,1\le j\le \gamma ,\mathrm{and}0\le k,l\le \alpha -1$, where $\alpha =2^{h_S}$.

Based on the second and third relations mentioned above, for a given ${\mathsf{T}}_{\mathsf{tot}}$ the number of fallback keys is $\left|\mathcal{FK}\right|=\gamma (2^{h_I+1}-2)={\mathsf{T}}_{\mathsf{tot}}/2^{h_{SM}}$. Therefore, if the manager selects $h_{SM}$ so that ${\mathsf{T}}_{\mathsf{tot}}/2^{h_{SM}}$ is sufficiently small, the manager can effectively generate and publish all the fallback keys at the setup phase. This allows the verifier to check the validity of the fallback keys without interacting with the manager, making DGMT a non-interactive group signature scheme and addressing the first shortcoming of DGM.

Remark 2. 

For a given ${\mathsf{T}}_{\mathsf{tot}}$, the parameters $h_I,h_{SM},$ and γ are chosen such that ${\mathsf{T}}_{\mathsf{tot}}=\gamma (2^{h_I+1}-2)2^{h_{SM}}$, ensuring $\left|\mathcal{FK}\right|={\mathsf{T}}_{\mathsf{tot}}/2^{h_{SM}}$ is sufficiently small. This creates a trade-off between γ and $h_I$: a smaller γ results in a larger IMT. Since IMT nodes are stored in memory, a larger $h_I$ increases memory costs. Therefore, γ must be large enough to have a reasonable $h_I$. The terms “sufficiently small” and “large enough” depend on the available system and communication cost.

4.2.2. Tree Construction and Allocation of Intervals to Users

Constructing the DGMT tree is a two-step process.

1.

In the setup phase, the manager constructs the IMT along with all ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$s, for every i and j, to compute and publish $\mathsf{DGMT}.\mathsf{gpk}$ and

$$\mathcal{FK}=[F{k}_{i,j}\leftarrow {\mathsf{g}}_1(r_{i,j},F{n}_i)|1\le i<2^{h_I+1}-1,1\le j\le \gamma ],$$

where $r_{i,j}$ is the root of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\mathrm{MT}}$ and $F{n}_i$ is the i-th fallback node. See Algorihtm 1.

2.

During the join phase when a user requests keys (or during the sign phase when a user requests new OTS key pairs) and no available key pairs remain in some current ${\mathrm{SMT}}^{\left(2\right)}$s for this user, the manager must construct new ${\mathrm{SMT}}^{\left(2\right)}$s. The manager then randomly selects new OTS key pairs from these newly constructed trees and assigns them to the user.

To explain the different steps of constructing DGMT’s tree, we assume the manager has generated the secret key $\mathsf{DGMT}.\mathsf{SK}=(\mathsf{msk},\mathsf{IMT}.\mathsf{key},{\mathsf{SMT}}_{\mathsf{1}}.\mathsf{key},{\mathsf{SMT}}_{\mathsf{2}}.\mathsf{key},\mathsf{shuffle}.\mathsf{key})$, where each of them is a $\lambda$-bit random strings (See Algorithm 4 for details). Also, let $\mathsf{DGMT}.\mathsf{SetPr}=(h_I,h_{SM},\gamma ,{\mathsf{T}}_{\mathsf{tot}},{\mathsf{N}}_{\mathsf{max}})$ be the setup parameters. Thus, the number of leaf nodes in ${\mathrm{SMT}}^{\left(1\right)}$s and ${\mathrm{SMT}}^{\left(2\right)}$s is $\alpha =2^{h_S}$ and $h_{SM}=2h_S$.

Algorithm 1 $\mathsf{DGMT}.\mathsf{PubPrCons}$

Input: The security parameter $\lambda$, $\mathsf{DGMT}.\mathsf{SetPr}=(h_I,h_{SM},\gamma ,{\mathsf{T}}_{\mathsf{tot}},{\mathsf{N}}_{\mathsf{max}})$, and $\mathsf{DGMT}.\mathsf{SK}=(\mathsf{msk},\mathsf{IMT}.\mathsf{key},{\mathsf{SMT}}_{\mathsf{1}}.\mathsf{key},{\mathsf{SMT}}_{\mathsf{2}}.\mathsf{key},\mathsf{shuffle}.\mathsf{key})$. Output: $\mathsf{DGMT}.\mathsf{PubPr}=(\mathsf{DGMT}.\mathsf{gpk},\mathcal{FK},\mathcal{RL})$. 1: $\mathcal{RL}=\left[\right]$;  $\mathcal{FK}=\left[\right]$; 2: /* Construction of IMT */ 3: for $1\le i\le 2^{h_I}$do; 4:    Compute $\mathsf{f}(\mathsf{IMT}.\mathsf{key},i)$; 5: end for 6: Construct a Merkle tree using ${\left\{\mathsf{f}(\mathsf{IMT}.\mathsf{key},i)\right\}}_{i=1}^{2^{h_I}}$, called IMT; Let its root be $r_{\mathrm{IMT}}$; 7: $\mathsf{DGMT}.\mathsf{gpk}=r_{\mathrm{IMT}}$; 8: /* Construction of the Fallback keys */ 9: for $1\le i<2^{(h_I+1)}-1$ do 10:     for $1\le j\le \gamma$ do 11:         for $0\le k\le \alpha -1$ do 12:           $\mathsf{OTS}.{\mathsf{sk}}_{i,j,k}\leftarrow \mathsf{f}({\mathsf{SMT}}_{\mathsf{1}}.\mathsf{key},i\Vert j\Vert k)$; 13:           Compute $\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}$ from $\mathsf{OTS}.{\mathsf{sk}}_{i,j,k}$; 14:         end for 15:         Construct a Merkle tree using ${\{\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}\}}_{k=0}^{\alpha -1}$, called ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$; Let the root of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$ be $r_{i,j}$; 16:        $F{k}_{i,j}\leftarrow {\mathsf{g}}_1(r_{i,j},F{n}_i)$; 17:        Append $F{k}_{i,j}$ to the list $\mathcal{FK}$; 18:     end for 19: end for 20: $\mathsf{DGMT}.\mathsf{PubPr}=(\mathsf{DGMT}.\mathsf{gpk},\mathcal{FK},\mathcal{RL})$; 21: return $\mathsf{DGMT}.\mathsf{PubPr}$;

1.

Constructing the IMT and ${\mathrm{SMT}}^{\left(1\right)}$s and publishing $\mathsf{DGMT}.\mathsf{PubPr}$: The manager runs this process to publish $\mathsf{DGMT}.\mathsf{PubPr}=(\mathsf{DGMT}.\mathsf{gpk},\mathcal{FK},\mathcal{RL})$. This process is detailed in Algorithm 1, where the $\mathsf{DGMT}.\mathsf{gpk}$ is computed in lines 3–7 and $\mathcal{FK}$ is computed in lines 9–19. The fallback key for ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\mathrm{MT}}$ is $F{k}_{i,j}\leftarrow {\mathsf{g}}_1(r_{i,j},F{n}_i)$, where $r_{i,j}$ serves as the key for ${\mathsf{g}}_1$ (line 16). $\mathcal{FK}$ is a public list, and its $\left(\gamma \right(i-1)+j)$-th element is $F{k}_{i,j}$, where $1\le i<2^{h_I+1}-1$ and $1\le j\le \gamma$. Also, $\mathcal{RL}$ is initially empty and will be updated by the Algorithm 9 whenever the manager revokes a misbehaving user.

2.

Constructing ${\mathrm{SMT}}^{\left(2\right)}$s and allocating their leaf nodes to users: The manager constructs ${\mathrm{SMT}}^{\left(2\right)}$s when they want to randomly allocate the leaf nodes to users. Each user $\mathsf{id}\in [1,{\mathsf{N}}_{\mathsf{max}}]$ is assigned a unique interval

$${\mathcal{I}}_{\mathsf{id}}=[\beta (\mathsf{id}-1),\beta \mathsf{id}-1]=\{\beta (\mathsf{id}-1),\dots ,\beta \mathsf{id}-1\},$$

for the following purposes:

(a)

Efficient Random Allocation. The manager shuffles the leaf nodes of ${\mathrm{SMT}}^{\left(2\right)}$ using Algorithm 2, which takes an index $(i,j,k)$ and $\mathsf{shuffle}.\mathsf{key}$, and outputs the shuffled index list of leaves of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$ as

$$\begin{array}{c}\hfill {\mathcal{L}}_{i,j,k}=[l_0^{\prime },\dots ,l_{\beta -1}^{\prime },\dots ,l_{\beta ({\mathsf{N}}_{\mathsf{max}}-1)}^{\prime },\dots ,l_{\beta {\mathsf{N}}_{\mathsf{max}}-1}^{\prime }].\end{array}$$

For each $1\le \mathsf{id}\le {\mathsf{N}}_{\mathsf{max}}$, sublist $[l_{\beta (\mathsf{id}-1)}^{\prime },\dots ,l_{\beta \mathsf{id}-1}^{\prime }]$ represents the $\beta$ leaf nodes of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$ allocated to user $\mathsf{id}$, which the manager uses to assign the corresponding OTS key pairs to user $\mathsf{id}$.

(b)

Efficient Opening and Revocation. Each signature ${\sigma }_{DGMT}$ contains a unique $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}\leftarrow {\mathsf{g}}_2(\mathsf{msk},i\Vert j\Vert k\Vert l)$. To open a signature, the manager computes $i\Vert j\Vert k\Vert l\leftarrow {\mathsf{g}}_2^{-1}(\mathsf{msk},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l})$ and identifies the identifier $\mathsf{id}$ as the signer if $l\in {\mathcal{I}}_{\mathsf{id}}$ (or equivalently announce $\mathsf{id}=\lceil {\displaystyle \frac{l+0.5}{\beta }}\rceil$ as the signer). This approach results in an efficient signature opening algorithm. Additionally, by using these intervals, the manager only needs to compute and add some specific $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}$s to the revocation list $\mathcal{RL}$, ensuring efficient signature revocation. See Algorithms 9 and 10.

Remark 3. 

As discussed in Section 3.2, DGM’s second limitation is its inefficient management of storage, which scales linearly with ${\mathsf{T}}_{\mathsf{tot}}$. Indeed, this inefficiency arises from its simple random allocation of leaf nodes, requiring the manager to store all $\mathsf{DGM}.{\mathsf{pos}}_{t,l}$ values, for each t and l, to enable signature opening and revocation. This approach demands an impractical amount of storage, requiring approximately ${10}^{8.7}$ Terabytes to support ${\mathsf{T}}_{\mathsf{tot}}=2^{64}$ OTSs [26]. In contrast, our proposed interval-based method overcomes this limitation and reduces storage requirements to scale with the number of intervals (or equivalently ${\mathsf{N}}_{\mathsf{max}}$), rather than ${\mathsf{T}}_{\mathsf{tot}}$.

Algorithm 2 $\mathrm{DGMT}.\mathsf{Shuffle}$

Input: The secret key $\mathsf{DGMT}.\mathsf{SK}=(\mathsf{msk},\mathsf{IMT}.\mathsf{key},{\mathsf{SMT}}_{\mathsf{1}}.\mathsf{key},{\mathsf{SMT}}_{\mathsf{2}}.\mathsf{key},\mathsf{shuffle}.\mathsf{key})$ and the index $(i,j,k)$ (the index of the k-th leaf node of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$). Output: ${\mathcal{L}}_{i,j,k}$, the shuffled index list of leaves of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$ 1: ${\mathcal{L}}_{i,j,k}=\left[\right]$; 2: ${\mathcal{L}}_1=[{\mathsf{g}}_1(\mathsf{shuffle}.\mathsf{key},i\Vert j\Vert k\Vert l)\mid 0\le l\le \alpha -1]$; 3: ${\mathcal{L}}_2\leftarrow Sort\left({\mathcal{L}}_1\right)$; ▹ Sorting ${\mathcal{L}}_1$ in ascending integer order 4: for $0\le l\le \alpha -1$ do 5:      Append the position of ${\mathcal{L}}_1\left[l\right]$ in the list ${\mathcal{L}}_2$ to the list ${\mathcal{L}}_{i,j,k}$; 6: end for; 7: return ${\mathcal{L}}_{i,j,k}$;

• To construct ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$, the manager first computes ${\mathcal{L}}_{i,j,k}$. The l-th element in this list indicates the position of the leaf node $(i,j,k,l)$ after permuting the leaf nodes. Then, the manager computes the OTS key pairs $(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k,l^{\prime }},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }})$ and $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}$ for all $0\le l,l^{\prime }\le \alpha -1$. The $l^{\prime }$-th leaf node of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$ is $\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}\Vert \mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}).$ After computing all the leaf nodes of this tree, the manager constructs ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$ and signs its root, $r_{i,j,k}$, by $\mathsf{OTS}.{\mathsf{sk}}_{i,j,k}$ to attach ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$ to ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$. See Algorithm 3.

Algorithm 3 $\mathsf{DGMT}.\mathsf{SMTTWOCons}$

Input: The secret key $\mathsf{DGMT}.\mathsf{SK}=(\mathsf{msk},\mathsf{IMT}.\mathsf{key},{\mathsf{SMT}}_{\mathsf{1}}.\mathsf{key},{\mathsf{SMT}}_{\mathsf{2}}.\mathsf{key},\mathsf{shuffle}.\mathsf{key})$ and index $(i,j,k)$. Output: ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$. 1: ${\mathcal{L}}_{i,j,k}\leftarrow \mathrm{DGMT}.\mathsf{Shuffle}(\mathsf{DGMT}.\mathsf{SK},(i,j,k));$ 2: for $0\le l\le \alpha -1$ do 3:      $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}\leftarrow {\mathsf{g}}_2(\mathsf{msk},i\Vert j\Vert k\Vert l)$; 4:      $l^{\prime }={\mathcal{L}}_{i,j,k}\left[l\right]$; 5:      $\mathsf{OTS}.{\mathsf{sk}}_{i,j,k,l^{\prime }}\leftarrow \mathsf{f}({\mathsf{SMT}}_{\mathsf{2}}.\mathsf{key},i\Vert j\Vert k\Vert l^{\prime })$; 6:      Compute $\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}$ from $\mathsf{OTS}.{\mathsf{sk}}_{i,j,k,l^{\prime }}$; 7:      $h_{l^{\prime }}\leftarrow \mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}\Vert \mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l})$; 8: end for 9: Construct a Merkle tree using ${\left\{h_{l^{\prime }}\right\}}_{l^{\prime }=0}^{\alpha -1}$, called ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$; 10: return ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$;

4.3. DGMT’s Algorithms

In Section 3, we presented the algorithms of a $\mathcal{FDGS}$. Here, we describe all the algorithms of DGMT in detail, as a $\mathcal{FDGS}$.

1.

$(\mathsf{DGMT}.\mathsf{SK},\mathsf{DGMT}.\mathsf{PubPr})\leftarrow \mathsf{DGMT}.\mathsf{KG}(1^{\lambda },$$\mathsf{DGMT}.\mathsf{SetPr})$: The manager runs the Algorithm 4 on the security parameter $\lambda$ and the setup parameters $\mathsf{DGMT}.\mathsf{SetPr}=(h_I,h_{SM},\gamma ,{\mathsf{T}}_{\mathsf{tot}},{\mathsf{N}}_{\mathsf{max}})$ to obtain $(\mathsf{DGMT}.\mathsf{SK},\mathsf{DGMT}.\mathsf{PubPr})$, where $\mathsf{DGMT}.\mathsf{SK}=(\mathsf{msk}$, $\mathsf{IMT}.\mathsf{key},{\mathsf{SMT}}_{\mathsf{1}}.\mathsf{key},{\mathsf{SMT}}_{\mathsf{2}}.\mathsf{key},\mathsf{shuffle}.\mathsf{key})$ and $\mathsf{DGMT}.\mathsf{PubPr}=(\mathsf{DGMT}.\mathsf{gpk},\mathcal{FK},\mathcal{RL})$. These values are generated as follows:

• $\mathsf{msk}\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$ is the manager’s master secret key of the SPRP ${\mathsf{g}}_2$ that is used for opening signatures, revoking users, and generating ${\mathrm{SMT}}^{\left(2\right)}$s.
• $\mathsf{IMT}.\mathsf{key}\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$ is the secret key of the PRF $\mathsf{f}$ for generating an $\mathrm{IMT}$ of height $h_I$, where its root, i.e., $r_{\mathrm{IMT}}$, is the group public key $\mathsf{DGMT}.\mathsf{gpk}$.
• ${\mathsf{SMT}}_{\mathsf{1}}.\mathsf{key}\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$ is the secret key of the PRF $\mathsf{f}$ for generating the ${\mathrm{SMT}}^{\left(1\right)}$s on the OTS key pairs $(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k})$, with $1\le i<2^{h_I+1}-1$, $1\le j\le \gamma$ and $1\le k\le \alpha$.
• ${\mathsf{SMT}}_{\mathsf{2}}.\mathsf{key}\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$ is the secret key of the PRF $\mathsf{f}$ for generating the ${\mathrm{SMT}}^{\left(2\right)}$s on the OTS key pairs $(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k,l},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l})$s, with $1\le i<2^{h_I+1}-1$, $1\le j\le \gamma$ and $1\le k,l\le \alpha$.
• $\mathsf{shuffle}.\mathsf{key}\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$ is the secret key of the SPRP ${\mathsf{g}}_1$ for shuffling the leaf nodes of ${\mathrm{SMT}}^{\left(2\right)}$s.
• $\mathcal{FK}=[F{k}_{i,j}\leftarrow {\mathsf{g}}_1(r_{i,j},F{n}_i)|1\le i<2^{h_I+1}-1,1\le j\le \gamma ].$
• $\mathcal{RL}$ is the revocation list that is initially empty.

Algorithm 4 $\mathsf{DGMT}.\mathsf{KG}$

Input: The security parameter $\lambda$ and $\mathsf{DGMT}.\mathsf{SetPr}=(h_I,h_{SM},\gamma ,{\mathsf{T}}_{\mathsf{tot}},{\mathsf{N}}_{\mathsf{max}})$. Output: $(\mathsf{DGMT}.\mathsf{SK},\mathsf{DGMT}.\mathsf{PubPr})$ 1: $\mathsf{msk},\mathsf{IMT}.\mathsf{key},{\mathsf{SMT}}_{\mathsf{1}}.\mathsf{key},{\mathsf{SMT}}_{\mathsf{2}}.\mathsf{key},\mathsf{shuffle}.\mathsf{key}\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$; 2: $\mathsf{DGMT}.\mathsf{SK}=(\mathsf{msk},\mathsf{IMT}.\mathsf{key},{\mathsf{SMT}}_{\mathsf{1}}.\mathsf{key},{\mathsf{SMT}}_{\mathsf{2}}.\mathsf{key},\mathsf{shuffle}.\mathsf{key})$; 3: $\mathsf{DGMT}.\mathsf{PubPr}\leftarrow \mathsf{DGMT}.\mathsf{PubPrCons}(1^{\lambda },\mathsf{DGMT}.\mathsf{SetPr},\mathsf{DGMT}.\mathsf{SK})$; 4: return $(\mathsf{DGMT}.\mathsf{SK},\mathsf{DGMT}.\mathsf{PubPr})$;

2.

$(({\mathsf{PL}}_{\mathcal{M}},\mathsf{ID}),(\mathsf{id},c_{\mathsf{id}}))/\perp \leftarrow \mathsf{DGMT}.\mathsf{Join}\left(\mathsf{Username}\right):$ This interactive joining protocol, the same as $\mathsf{FDGS}.\mathsf{Join}$ in Section 3.1, occurs between the manager $\mathcal{M}$ and a prospective user with identity $\mathsf{Username}$ over a secure channel. If $\mathsf{Username}\notin \mathsf{ID}$ and $\left|\mathsf{ID}\right|<{\mathsf{N}}_{\mathsf{max}}$, the manager $\mathcal{M}$ allocates the smallest unassigned identifier $\mathsf{id}$ with $1\le \mathsf{id}\le {\mathsf{N}}_{\mathsf{max}}$ along with a secret value $c_{\mathsf{id}}$ to this user and sends $(\mathsf{id},c_{\mathsf{id}})$ to the user. Otherwise, the algorithm outputs ⊥. The manager $\mathcal{M}$ stores $(\mathsf{id},c_{\mathsf{id}},\mathsf{Active})$ in the private list ${\mathsf{PL}}_{\mathcal{M}}$ and the user’s identity $\mathsf{Username}$ as the $\mathsf{id}$-th element in the list $\mathsf{ID}$, where $\mathsf{ID}$ is the list of the users’ identities who have already joined the group and is initially empty. See Algorithm 5 for details.

Algorithm 5 $\mathsf{DGMT}.\mathsf{Join}$

Input: The identity $\mathsf{Username}$ of a user Output: $(({\mathsf{PL}}_{\mathcal{M}},\mathsf{ID}),(\mathsf{id},c_{\mathsf{id}}))/\perp$ 1: The user sends $\mathsf{Username}$ along with a request to join the group; 2: If $\mathsf{Username}\in \mathsf{ID}$ or $\left|\mathsf{ID}\right|\ge {\mathsf{N}}_{\mathsf{max}}$, then outputs ⊥; End if; 3: The manager $\mathcal{M}$ takes the next available unassigned $\mathsf{id}\le {\mathsf{N}}_{\mathsf{max}}$; 4: $\mathcal{M}$ generates $c_{\mathsf{id}}\stackrel{\$}{\leftarrow }{\{0,1\}}^{\lambda }$; 5: $\mathcal{M}$ sends $(\mathsf{id},c_{\mathsf{id}})$ to $\mathsf{Username}$; 6: $\mathsf{Username}$ stores the received $(\mathsf{id},c_{\mathsf{id}})$; 7: $\mathcal{M}$ appends $(\mathsf{id},c_{\mathsf{id}},\mathsf{Active})$ to the list ${\mathsf{PL}}_{\mathcal{M}}$; 8: $\mathcal{M}$ appends $\mathsf{Username}$ to the $\mathsf{id}$-th position in the list $\mathsf{ID}$.

When a user with identifier $\mathsf{id}$ requires new OTS key pairs, they initiate Subroutine Algorithm 6 by sending a request to the manager via the Algorithm $\mathsf{DGMT}.\mathsf{OTSReq}(\mathsf{id},c_{\mathsf{id}})$. Upon receiving the request, the manager allocates B new private keys ${\left\{{\mathsf{gsk}}_{i_r,j,k,l^{\prime }}^{\mathsf{id}}\right\}}_{r=1}^B$ to the user by executing the Algorithm $\mathsf{DGMT}.\mathsf{KeyDist}\left(\mathsf{id}\right)$, provided that $(\mathsf{id},c_{\mathsf{id}},\mathsf{Active})\in {\mathsf{PL}}_{\mathcal{M}}$, i.e., the user has already joined the group and has not been revoked. To execute the key allocation effectively, the manager assigns each user with identifier $\mathsf{id}\in [1,{\mathsf{N}}_{\mathsf{max}}]$ a list:

$${\mathsf{Index}}_{\mathsf{id}}=[(i,(j,k,l))\mid 1\le i<2^{h_I}-1].$$

This list corresponds to the internal nodes of the IMT, where the second component of the i-th entry, i.e., $(j,k,l)$, represents the last signing key assigned to the user $\mathsf{id}$ from the ${\mathrm{SMT}}^{\mathrm{MT}}$ linked to the internal node $F{n}_i$. In other words, the entry $(i,(j,k,l))\in {\mathsf{Index}}_{\mathsf{id}}$ indicates that user $\mathsf{id}$ has received their l-th signing key from ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$. Initially, this list is set as ${\mathsf{Index}}_{\mathsf{id}}=[(i,(1,0,0))\mid 1\le i<2^{h_I}-1]$, and is updated after each allocation. Algorithm $\mathsf{DGMT}.\mathsf{KeyDist}$ explains the process of selecting the next B available indexes for the user $\mathsf{id}$ and updating ${\mathsf{Index}}_{\mathsf{id}}$ accordingly.

Remark 4. 

In lines 5–9 of Algorithm $\mathsf{DGMT}.\mathsf{KeyDist}$, we maintain the bound $l\le \beta -2$ to ensure that every user has at least one unused key in each ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$, as required by the anonymity proof.

Algorithm 6 Subroutines of Key Distribution of $\mathsf{DGMT}$

3.

${\sigma }_{\mathrm{DGMT}}\leftarrow \mathsf{DGMT}.\mathsf{Sig}(m,{\mathsf{gsk}}_{i,j,k,l^{\prime }}^{\mathsf{id}}):$ The signing algorithm takes as input a message m and an unused private key ${\mathsf{gsk}}_{i,j,k,l^{\prime }}^{\mathsf{id}}$ that belongs to the user $\mathsf{id}$ and outputs a signature ${\sigma }_{DGMT}$ as explained in Algorithm 7.

Remark 5. 

In Algorithm 7, the depth μ of the internal node $F{n}_i$ in the IMT is used. The use of fixed-height ${\mathrm{SMT}}^{\mathrm{MT}}$s results in variable-length signatures, and including μ as part of the signed message helps prevent potential exploitation of this variability in signature length.

Algorithm 7 $\mathsf{DGMT}.\mathsf{Sig}$

Input: A message m and an unused signing key ${\mathsf{gsk}}_{i,j,k,l^{\prime }}^{\mathsf{id}}$. Output: ${\sigma }_{\mathrm{DGMT}}$ 1: Parse ${\mathsf{gsk}}_{i,j,k,l^{\prime }}^{\mathsf{id}}$ as $$\begin{array}{cc}\hfill {\mathsf{gsk}}_{i,j,k,l^{\prime }}^{\mathsf{id}}=(& (i,j,k,l^{\prime }),\mathsf{OTS}.{\mathsf{sk}}_{i,j,k,l^{\prime }},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l},\hfill \\ & A.pat{h}_{i,j,k,l^{\prime }},{\sigma }_{i,j,k},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k},A.pat{h}_{i,j,k},A.pat{h}_i);\end{array}$$ 2: Compute the height $\mu$ of $F{n}_i$ in the IMT from i; 3: $m^{\prime }\leftarrow \mathsf{H}(m\parallel \mu )$; 4: ${\sigma }_{i,j,k,l^{\prime }}\leftarrow \mathsf{OTS}.\mathsf{Sig}(\mathsf{OTS}.{\mathsf{sk}}_{i,j,k,l^{\prime }},m^{\prime });$ 5: Compute ${\sigma }_{\mathrm{DGMT}}$ as $$\begin{array}{c}\hfill {\sigma }_{\mathrm{DGMT}}=((i,j,k,l^{\prime }),{\sigma }_{i,j,k,l^{\prime }},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l},\\ \hfill A.pat{h}_{i,j,k,l^{\prime }},{\sigma }_{i,j,k},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k},A.pat{h}_{i,j,k},A.pat{h}_i);\end{array}$$ (3) 6: if ${\mathsf{gsk}}_{i,j,k,l^{\prime }}^{\mathsf{id}}$ was the last unused key of user $\mathsf{id}$, then 7:        user $\mathsf{id}$ requests for new keys by the Algorithm $\mathsf{DGMT}.\mathsf{OTSReq}(\mathsf{id},c_{\mathsf{id}})$; 8: end if 9: return ${\sigma }_{\mathrm{DGMT}}$;

4.

$0/1\leftarrow \mathsf{DGMT}.\mathsf{Vf}(m,{\sigma }_{\mathrm{DGMT}},\mathsf{DGMT}.\mathsf{PubPr}):$ To verify a pair $(m,{\sigma }_{\mathrm{DGMT}})$, the verifier runs the deterministic Algorithm 8, which outputs 1 if and only if ${\sigma }_{\mathrm{DGMT}}$ is a valid signature on m.

Remark 6. 

In DGMT, having $(i,j)$ allows the verifier to uniquely determine the fallback key $F{k}_{i,j}$ from the public list $\mathcal{FK}$. Therefore, unlike DGM where $F{k}_{i,j}$ is a part of the signature, in DGMT $F{k}_{i,j}$ is not a part of the signature.

Algorithm 8 $\mathsf{DGMT}.\mathsf{Vf}$

Input: message m, signature ${\sigma }_{\mathrm{DGMT}}$, and $\mathsf{DGMT}.\mathsf{PubPr}=(\mathsf{DGMT}.\mathsf{gpk},\mathcal{FK},\mathcal{RL})$. Output: 0/1 1: Parse  ${\sigma }_{\mathrm{DGMT}}$ as $$\begin{array}{cc}\hfill {\sigma }_{\mathrm{DGMT}}=(& (i,j,k,l^{\prime }),{\sigma }_{i,j,k,l^{\prime }},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l},\hfill \\ & A.pat{h}_{i,j,k,l^{\prime }},{\sigma }_{i,j,k},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k},A.pat{h}_{i,j,k},A.pat{h}_i);\end{array}$$ 2: if $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}\in \mathcal{RL}$, then return 0; 3: end if 4: Compute the height $\mu$ of $F{n}_i$ in the IMT from i; 5: $m^{\prime }\leftarrow \mathsf{H}(m\parallel \mu )$; 6: if $\mathsf{OTS}.\mathsf{Vf}(m^{\prime },{\sigma }_{i,j,k,l^{\prime }},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }})=0$, then return 0; 7: end if 8: $h^{\prime }\leftarrow \mathsf{H}\left(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}\Vert \mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}\right);$ 9: Compute $r_{i,j,k}^{\prime }$, as the root of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$, using the index $(i,j,k,l^{\prime })$, $h^{\prime }$, and $A.pat{h}_{i,j,k,l^{\prime }};$ 10: if $\mathsf{OTS}.\mathsf{Vf}(r_{i,j,k}^{\prime },{\sigma }_{i,j,k},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k})=0$, then return 0; 11: end if 12: Compute $r_{i,j}^{\prime }$, as the root of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$, using the index $(i,j,k)$, $\mathsf{OTS}.{\mathsf{pk}}_{i,j,k},$ and $A.pat{h}_{i,j,k};$ 13: $F{n}_i^{\prime }\leftarrow {\mathsf{g}}_{\mathsf{1}}^{-\mathsf{1}}(r_{i,j}^{\prime },\mathcal{FK}[\gamma (i-1)+j]);$ 14: Compute $r_{\mathrm{IMT}}^{\prime }$ from $i,F{n}_i^{\prime },$ and $A.pat{h}_i;$ 15: if $r_{\mathrm{IMT}}^{\prime }=\mathsf{DGMT}.\mathsf{gpk}$ then return 1; 16: else return 0; 17: end if

5.

$({\mathsf{PL}}_{\mathcal{M}},\mathsf{DGMT}.\mathsf{PubPr})\leftarrow \mathsf{DGMT}.\mathsf{Rev}(\mathsf{DGMT}.\mathsf{SK},{\mathsf{PL}}_{\mathcal{M}},\mathsf{DGMT}.\mathsf{PubPr},\mathsf{R}):$ To revoke a set $\mathsf{R}$ of users, the manager runs Algorithm 9 to update both ${\mathsf{PL}}_{\mathcal{M}}$ and $\mathsf{DGMT}.\mathsf{PubPr}$. In particular, this algorithm changes the status of each $\mathsf{id}\in \mathsf{R}$ in ${\mathsf{PL}}_{\mathcal{M}}$, preventing them from requesting any further keys. See Algorithm 9. For two given indexes $(j_1,k_1,l_1)$ and $(j_2,k_2,l_2)$, we have $(j_1,k_1,l_1)\le (j_2,k_2,l_2)$ if $j_1<j_2$, or $(j_1=j_2\wedge k_1<k_2)$, or $(j_1=j_2\wedge k_1=k_2\wedge l_1\le l_2)$.

Algorithm 9 $\mathsf{DGMT}.\mathsf{Rev}$

Input: A list $\mathsf{R}$, ${\mathsf{PL}}_{\mathcal{M}}$, $\mathsf{DGMT}.\mathsf{SK}=(\mathsf{msk},\mathcal{FK},\mathcal{RL})$, and $\mathsf{DGMT}.\mathsf{PubPr}=(\mathsf{DGMT}.\mathsf{gpk},\mathcal{FK},\mathcal{RL})$ Output: $({\mathsf{PL}}_{\mathcal{M}},\mathsf{DGMT}.\mathsf{PubPr})$ 1: for $\mathsf{id}\in \mathsf{R}$ do 2:     for $1\le i<2^{h_I}-1$ do 3:     Replace $(\mathsf{id},c_{\mathsf{id}},\mathsf{Active})$ with $(\mathsf{id},c_{\mathsf{id}},\mathsf{Revoked})$ in ${\mathsf{PL}}_{\mathcal{M}}$. 4:     $(j_i,k_i,l_i)\leftarrow$ Retrieve the second component of the i-th entry in ${\mathsf{assign}}_{\mathsf{id}}$; 5:      $\mathcal{RL}=\mathcal{RL}\cup \{{\mathsf{g}}_2(\mathsf{msk},i\Vert j\Vert k\Vert l+(\mathsf{id}-1)\beta \left)\right|forall(j,k,l)\le (j_i,k_i,l_i)\}$; 6:     end for; 7: end for; 8: $\mathsf{DGMT}.\mathsf{PubPr}=(\mathsf{DGMT}.\mathsf{gpk},\mathcal{FK},\mathcal{RL})$; 9: return $({\mathsf{PL}}_{\mathcal{M}},\mathsf{DGMT}.\mathsf{PubPr}$);

6.

$\mathsf{id}/\perp \leftarrow \mathsf{DGMT}.\mathsf{Op}({\sigma }_{\mathrm{DGMT}},\mathsf{DGMT}.\mathsf{SK}):$ The manager runs the deterministic Algorithm 10 to open the signature ${\sigma }_{\mathrm{DGMT}}$. This algorithm outputs either the identifier $\mathsf{id}$ of the user who generated $\sigma$, or ⊥ if the signature cannot be attributed to any specific user. As we already mentioned, the manager can retrieve the identity $\mathsf{Username}$ of the user by looking up the $\mathsf{id}$-th entry in the list $\mathsf{ID}$.

Algorithm 10 $\mathsf{DGMT}.\mathsf{Op}$

Input: A signature ${\sigma }_{\mathrm{DGMT}}$ and $\mathsf{DGMT}.\mathsf{SK}=(\mathsf{msk},\mathcal{FK},\mathcal{RL})$. Output: $\mathsf{id}/\perp$ 1: Extract $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}$ from ${\sigma }_{\mathrm{DGMT}}$; 2: $i\Vert j\Vert k\Vert l\leftarrow {\mathsf{g}}_2^{-1}(\mathsf{msk},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l});$ 3: if $(1\le i<2^{h_I+1}-1)\wedge (0\le j\le \gamma )\wedge (0\le k,l\le \alpha -1),$ then return $\mathsf{id}=\lceil {\displaystyle \frac{l+0.5}{\beta }}\rceil ;$ 4: else return ⊥; 5: end if

4.4. Instantiating DGMT and Parameter Estimation

To compute the signature and public key size of DGMT, we use WOTS as the OTS. As argued in Remark 1, using WOTS allows us to omit $\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}$ and $\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}$ from the DGMT signature and it will be as:

$$\begin{array}{c}\hfill {\sigma }_{\mathrm{DGMT}}=((i,j,k,l^{\prime }),{\sigma }_{i,j,k,l^{\prime }},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l},A.pat{h}_{i,j,k,l^{\prime }},{\sigma }_{i,j,k},A.pat{h}_{i,j,k},A.pat{h}_i).\end{array}$$

Now we compute the signature and public key sizes of DGMT in terms of the setup parameters of the system, security parameter $\lambda$ and Winternitz parameter w.

• Signature size:

• $(i,j,k,l^{\prime })$ is the index of the leaf node and is $\lambda$ bits.
• ${\sigma }_{i,j,k,l^{\prime }}$ and ${\sigma }_{i,j,k}$ are WOTS signature, each of size $\xi \lambda$ bits, where $\xi$ is the number of elements in WOTS signature.
• $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}$ is the output of the SPRP ${\mathsf{g}}_2$ and is $\lambda$ bits.
• $A.pat{h}_{i,j,k,l^{\prime }},A.pat{h}_{i,j,k},$ and $A.pat{h}_i$ are the authentication paths in the ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$, ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$, and IMT, which is totally $(h_I+h_{SM})\lambda$ bits.

Thus, the signature size in bits, is bounded by

$$\begin{array}{c}\hfill (h_I+h_{SM}+2+2\xi )\lambda .\end{array}$$

(4)

Public key size: The public key of DGMT is the root of the IMT, and is $\lambda$ bits.

Parameter selection in our implementation: We consider a GSS with ${\mathsf{T}}_{\mathsf{tot}}=2^{64}$ OTSs and ${\mathsf{N}}_{\mathsf{max}}=2^{12}$ users, and choose the setup parameters $\mathsf{DGMT}.\mathsf{SetPr}=(h_I,h_{SM},\gamma ,{\mathsf{T}}_{\mathsf{tot}},{\mathsf{N}}_{\mathsf{max}})=(16,32,2^{16},2^{64},2^{12})$. The configuration allows each user to receive up to $2^{52}$ OTSs from the manager (This configuration provides exactly $\gamma (2^{h_I}-2)2^{h_{SM}}=2^{64}-2^{48}\simeq 2^{64}$ OTSs, and since ${\mathsf{N}}_{\mathsf{max}}$ is bounded to $2^{h_S-1}$, the system can accommodate $2^{15}$ users.). The number of fallback keys is $2^{32}$ which can be generated comfortably during initialization.

Let the security parameter $\lambda \in \{256,384\}$ and $\omega =4$. Given these parameters, Table 6 provides the signature size and public key size of DGMT. Theorem 1 shows that the security of DGMT relies on the security of SPRPs and the collision resistance of the underlying hash family. Thus classic and quantum security when $\lambda$ is the output size of the hash function, are respectively $\lambda /2$ bits and $\lambda /3$ qbits. Therefore, for $\lambda =256,384$ its classic security is respectively 128 and 192 bits, and its quantum security is respectively 85 and 128 qbits [30,51].

Table 6. Signature and public key sizes of DGMT for the given parameters.

Security Parameter	${\mathit{\xi }}_1=⌈\frac{\mathit{\lambda }}{\mathit{w}}⌉$	${\mathit{\xi }}_2=⌊\frac{log\left({\mathit{\xi }}_1(2^{\mathit{w}}-1)\right)}{\mathit{w}}⌋+1$	$\mathit{\xi }={\mathit{\xi }}_1+{\mathit{\xi }}_2$	$|{\mathit{\sigma }}_{\mathit{DGMT}}|=({\mathit{h}}_{\mathit{I}}+{\mathit{h}}_{\mathbf{SM}}+2+2\mathit{\xi })\mathit{\lambda }$	$|\mathsf{DGMT}.\mathsf{gpk}|=\mathit{\lambda }$
$\lambda =256$	64	3	67	$(16+32+2+2\times 67)256$ bits = 5.75 KB	256 bits
$\lambda =384$	96	3	99	$(16+32+2+2\times 99)384$ bits = 11.62 KB	384 bits

Remark 7. 

Security DGMT relies on the collision resistance of the hash function that is used to construct the Merkle trees (IMT and $SM{T}^{MT}$). Using the approach in [52] one can modify the trees so that the security of the resulting signature relies on the second pre-image resistance. This will allow the output size of the hash function to be halved for the same security level (the complexity of the best collision and pre-image attacks for a hash function with output size λ is $2^{\lambda /2}$ and $2^{\lambda }$, respectively), resulting in a shorter signature. This however requires careful analysis of the design because of multi-target attack that is applicable to the new design.

Multi-target attack was introduced in [32] in which the adversary makes d hash queries and succeeds if a second preimage for any of the queried values is found. It was shown that for a hash function with λ-bit output allowing d queries reduces the attack complexity from $\mathcal{O}\left(2^{\lambda }\right)$ to $\mathcal{O}(2^{\lambda }/d)$ and so for λ-bit security either the hash function output size must be increased, or different keyed hash functions for each call must be used [32]. Adapting DGMT design to reduce security to second pre-image resistance will be our future work.

5. Security Proofs

In this section, we prove that DGMT provides Correctness, Unforgeability, Anonymity, and Traceability.

Theorem 1. 

Let $\mathrm{DGMT}$ be the scheme described in Section 4. If (i) $\mathsf{H}$ is a randomly selected hash function from the collision-resistant hash function family $\mathcal{HF}$, (ii) $\mathcal{OTS}$ is an EU-CMA One-time Signature scheme, (iii) $\mathsf{f}:{\{0,1\}}^{\lambda }\times {\{0,1\}}^{\lambda }\to {\{0,1\}}^{\lambda }$ is a PRF, and (iv) ${\mathsf{g}}_1:{\{0,1\}}^{\lambda }\times {\{0,1\}}^{\lambda }\to {\{0,1\}}^{\lambda }$ and ${\mathsf{g}}_2:{\{0,1\}}^{\lambda }\times {\{0,1\}}^{\lambda }\to {\{0,1\}}^{\lambda }$ are two SPRPs, such that for any randomly selected tuple $(k,m,c)$ with $c\leftarrow {\mathsf{g}}_1(k,m)$ the probability of finding a key $k^{*}\ne k$ with $c\leftarrow {\mathsf{g}}_1(k^{*},m)$ is negligible, then $\mathrm{DGMT}$ satisfies Correctness, Unforgeability, Anonymity, and Traceability.

Proof. 

We follow the adversarial game model of [20,50] to establish that DGMT satisfies Correctness, Unforgeability, Anonymity, and Traceability. Below we provide sketches of the proofs for each case.

Correctness: To prove correctness of DGMT, we show that if an adversary $\mathcal{A}$ corrupt all but one user, the honest user can successfully enroll and create signatures that are accepted by the verification algorithm and will be traced back to the user.

In the correctness game ${\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Corr}}\left(\lambda \right)$, a PPT adversary $\mathcal{A}$ can use oracles $\mathsf{AddHU}$, and $\mathsf{Revoke}$ to add honest users and revoke the users, and $\mathsf{AddCU}$ to corrupt all but one user. In presence of such adversary, the honest user can still establish a secure channel to the (honest) group manager and securely receive $(\mathsf{id},c_{\mathsf{id}})$. Only this user and the group manager know $(\mathsf{id},c_{\mathsf{id}})$ and the user uses $(\mathsf{id},c_{\mathsf{id}})$ to receive ${\left\{{\mathsf{gsk}}_{i,j,k,l^{\prime }}^{\mathsf{id}}\right\}}_{i=1}^B$ from the manager through a secure channel and generates the correct signatures.

These keys are specifically allocated to this honest user, ensuring that for all $1\le i\le B$, we have $l\in {\mathcal{I}}_{\mathsf{id}}=[(\mathsf{id}-1)\beta ,\mathsf{id}\beta -1]$, where $(i,j,k,l^{\prime })$ represents the index of the leaf node $(i,j,k,l)$ after permutation by the SPRP ${\mathsf{g}}_1$ (See Algorithm 2). Let ${\mathsf{gsk}}_{i,j,k,l^{\prime }}^{\mathsf{id}}\in {\left\{{\mathsf{gsk}}_{i,j,k,l^{\prime }}^{\mathsf{id}}\right\}}_{i=1}^B$ and ${\sigma }_{DGMT}\leftarrow \mathsf{DGMT}.\mathsf{Sig}(m,{\mathsf{gsk}}_{i,j,k,l^{\prime }}^{\mathsf{id}})$ be as

$$\begin{array}{cc}\hfill {\sigma }_{\mathrm{DGMT}}=(& (i,j,k,l^{\prime }),{\sigma }_{i,j,k,l^{\prime }},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l},\hfill \\ & A.pat{h}_{i,j,k,l^{\prime }},{\sigma }_{i,j,k},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k},A.pat{h}_{i,j,k},A.pat{h}_i).\hfill \end{array}$$

By computing

$$\begin{array}{c}\hfill i\Vert j\Vert k\Vert l={\mathsf{g}}_2^{-1}(\mathsf{msk},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}),\end{array}$$

(5)

the manager finds $l\in {\mathcal{I}}_{\mathsf{id}}=[(\mathsf{id}-1)\beta ,\mathsf{id}\beta -1]$, i.e., $(\mathsf{id}-1)\beta \le l\le \mathsf{id}\beta -1$, so

$${\displaystyle \frac{\mathsf{id}\beta +(0.5-\beta )}{\beta }}\le {\displaystyle \frac{l+0.5}{\beta }}\le {\displaystyle \frac{\mathsf{id}\beta -0.5}{\beta }},$$

ensuring that computing $⌈{\displaystyle \frac{l+0.5}{\beta }}⌉$ yields the identifier $\mathsf{id}$ of the signer ($\lceil ·\rceil$ is the ceiling function).

Unforgeability: To prove the unforgeability property of DGMT, we show that if an adversary $\mathcal{A}$ can forge a signature, then it creates a contradiction to the assumptions of the theorem.

In the unforgeability security game ${\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Unforg}}\left(\lambda \right)$, a challenger first runs the $\mathsf{DGMT}.\mathsf{KG}$ to create the $\mathrm{IMT}/{\mathrm{SMT}}^{\mathrm{MT}}$ trees and the secret and public keys of the system. Then the challenger gives access to the oracles $\mathsf{AddHU}$, $\mathsf{AddCU}$, $\mathsf{SignHU}$, and $\mathsf{Revoke}$ to a PPT adversary $\mathcal{A}$. Therefore, $\mathcal{A}$ is allowed to obtain the signatures of every honest user on arbitrary messages. Each message-signature pair is stored in the signing list $\mathsf{SL}$, preventing $\mathcal{A}$ from using these signatures as forgeries for their corresponding messages. $\mathcal{A}$ can revoke users, so their signatures will not be verified. Additionally, $\mathcal{A}$ can corrupt users to obtain their $(\mathsf{id},c_{\mathsf{id}})$ and sign messages on their behalf, however, the generated signatures cannot be used as forgeries as those users are not honest.

We show that if $\mathcal{A}$ succeeds in forging a signature, i.e., it outputs a valid signature

$$\begin{array}{cc}\hfill {\sigma }_{DGMT}^{*}=& ((i,j,k,l^{\prime }),{\sigma }_{i,j,k,l^{\prime }}^{*},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}^{*},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}^{*},A.pat{h}_{i,j,k,l^{\prime }}^{*},{\sigma }_{i,j,k}^{*},\hfill \\ & \mathsf{OTS}.{\mathsf{pk}}_{i,j,k}^{*},A.pat{h}_{i,j,k}^{*},A.pat{h}_i^{*}),\hfill \end{array}$$

(6)

on a message m at the end of the query phase such that ${\mathsf{id}}^{*}\in \mathcal{H}$, where

$${\mathsf{id}}^{*}\leftarrow \mathsf{DGMT}.\mathsf{Op}({\sigma }_{DGMT}^{*},\mathsf{DGMT}.\mathsf{SK}),$$

and $(m,{\sigma }_{DGMT}^{*})\notin \mathsf{SL}$, then we can construct another PPT adversary $\mathcal{B}$ that simulates the role of the challenger for $\mathcal{A}$ to find a collision for the hash function $\mathsf{H}$, or forge a valid signature for $\mathcal{OTS}$, or can find a second-key for ${\mathsf{g}}_1$ that maps $F{k}_{i,j}$ to $F{n}_i$ for some $i,j$. Note that in each case, one of the assumptions of the theorem will cause a contradiction.

Let ${\sigma }_{DGMT}^{*}$ be a forged signature on message m. Since $(m,{\sigma }_{DGMT}^{*})$ is a valid signature then the index $(i,j,k,l^{\prime })$ of the ${\sigma }_{DGMT}^{*}$ must be a valid index, i.e., $1\le i<2^{h_I+1}-1$, $1\le j\le \gamma$, and $0\le k,l^{\prime }\le \alpha -1$. Let the index $(i,j,k,l^{\prime })$ belong to a user with identifier $\mathsf{id}$. As $\mathcal{B}$ simulates the role of the challenger, it knows

$$\begin{array}{cc}\hfill {\mathsf{gsk}}_{i,j,k,l^{\prime }}^{\mathsf{id}}=& ((i,j,k,l^{\prime }),\mathsf{OTS}.{\mathsf{sk}}_{i,j,k,l^{\prime }},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l},A.pat{h}_{i,j,k,l^{\prime }},\hfill \\ & {\sigma }_{i,j,k},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k},A.pat{h}_{i,j,k},A.pat{h}_i),\hfill \end{array}$$

(7)

and computes ${\sigma }_{DGMT}\leftarrow \mathsf{DGMT}.\mathsf{Sig}(m,{\mathsf{gsk}}_{i,j,k,l^{\prime }}^{\mathsf{id}}),$ where

$$\begin{array}{cc}\hfill {\sigma }_{\mathrm{DGMT}}=& ((i,j,k,l^{\prime }),{\sigma }_{i,j,k,l^{\prime }},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l},A.pat{h}_{i,j,k,l^{\prime }},{\sigma }_{i,j,k},\hfill \\ & \mathsf{OTS}.{\mathsf{pk}}_{i,j,k},A.pat{h}_{i,j,k},A.pat{h}_i).\hfill \end{array}$$

(8)

1.

Let $A.pat{h}_i\ne A.pat{h}_i^{*}$. However ${\sigma }_{DGMT}$ and ${\sigma }_{DGMT}^{*}$ are both valid signatures for the index $(i,j,k,l^{\prime })$. This implies that both paths lead to the same group public-key $\mathsf{DGMT}.\mathsf{gpk}$. Therefore, $\mathcal{B}$ found a collision for $\mathsf{H}$ that contradicts the fact that $\mathsf{H}$ is a collision-resistant hash function.

2.

Assume that $A.pat{h}_i=A.pat{h}_i^{*}$. Suppose that $A.pat{h}_{i,j,k}$ leads to ${\mathrm{SMT}}^{\mathrm{MT}}$ root node $r_{i,j}$ and $A.pat{h}_{i,j,k}^{*}$ leads to ${\mathrm{SMT}}^{\mathrm{MT}}$ root node $r_{i,j}^{*}$. In both cases, the $\left(\gamma \right(i-1)+j)$-th element of $\mathcal{FK}$, which is $F{k}_{i,j}$, will be used to verify the signatures. Then we have $F{n}_i\leftarrow {\mathsf{g}}_1^{-1}(r_{i,j},F{k}_{i,j})$ and $F{n}_i^{*}\leftarrow {\mathsf{g}}_1^{-1}(r_{i,j}^{*},F{k}_{i,j})$. Now we have three cases:

(i) Let $F{n}_i\ne F{n}_i^{*}$. Then $\mathcal{B}$ found a collision for $\mathsf{H}$ because $A.pat{h}_i=A.pat{h}_i^{*}$ and both of them leads to $\mathsf{DGMT}.\mathsf{gpk}$.

(ii) If $F{n}_i=F{n}_i^{*}$ and $r_{i,j}\ne r_{i,j}^{*}$. In this case, simulator $\mathcal{B}$ found two keys $r_{i,j}\ne r_{i,j}^{*}$ such that $F{K}_{i,j}\leftarrow {\mathsf{g}}_1(r_{i,j},F{n}_i)$ and $F{K}_{i,j}\leftarrow {\mathsf{g}}_1(r_{i,j}^{*},F{n}_i)$ which is a contradiction with the assumptions.

(iii) If $F{n}_i=F{n}_i^{*}$ and $r_{i,j}=r_{i,j}^{*}$ which is discussed in the next case.

3.

If $(F{n}_i,r_{i,j},A.pat{h}_i)=(F{n}_i^{*},r_{i,j}^{*},A.pat{h}_i^{*})$. We have two cases:

(i) If $A.pat{h}_{i,j,k}\ne A.pat{h}_{i,j,k}^{*}$. Since $r_{i,j}=r_{i,j}^{*}$, $\mathcal{B}$ found a collision for $\mathsf{H}$ and it forms a contradiction to the assumptions.

(ii) Next we discuss the case when $A.pat{h}_{i,j,k}=A.pat{h}_{i,j,k}^{*}$.

4.

If $A.pat{h}_{i,j,k}=A.pat{h}_{i,j,k}^{*}$ and $\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}\ne \mathsf{OTS}.{\mathsf{pk}}_{i,j,k}^{*}$. There are three possible cases.

(i) If $\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k})=\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}^{*})$, $\mathcal{B}$ found a collision for $\mathsf{H}$, that is a contradiction to the assumptions.

(ii) Let $\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k})\ne \mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}^{*})$. Since $A.pat{h}_{i,j,k}=A.pat{h}_{i,j,k}^{*}$ and $r_{i,j}=r_{i,j}^{*}$, $\mathcal{B}$ found a collision for the hash function $\mathsf{H}$, that is a contradiction.

(iii) Let $\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k})\ne \mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}^{*})$ and both the authentication path $A.pat{h}_{i,j,k}$ and $A.pat{h}_{i,j,k}^{*}$ leads to two different ${\mathrm{SMT}}^{\mathrm{MT}}$ root nodes $r_{i,j}$ and $r_{i,j}^{*}$ respectively. If $F{n}_i\ne F{n}_i^{*}$, then we are in case 2(i). If $F{n}_i=F{n}_i^{*}$, we are in the situation of case 2(ii).

5.

If $A.pat{h}_{i,j,k}=A.pat{h}_{i,j,k}^{*}$ and $\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}=\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}^{*}$. There are two cases:

(i) If ${\sigma }_{i,j,k}\ne {\sigma }_{i,j,k}^{*}$. This implies that $\mathcal{B}$ found a forgery for the $\mathcal{OTS}$ that contradicts the fact the $\mathcal{OTS}$ is EU-CMA secure.

(ii) If ${\sigma }_{i,j,k}={\sigma }_{i,j,k}^{*}$, which is discussed in the next case.

6.

If $({\sigma }_{i,j,k},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k},A.pat{h}_{i,j,k},F{n}_i,r_{i,j},A.pat{h}_i)=({\sigma }_{i,j,k}^{*},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}^{*},A.pat{h}_{i,j,k}^{*},F{n}_i^{*},r_{i,j}^{*}$, $A.pat{h}_i^{*})$. Assume that $A.pat{h}_{i,j,k,l^{\prime }}$ leads to a ${\mathrm{SMT}}^{\left(2\right)}$ root node $r_{i,j,k}$ and $A.pat{h}_{i,j,k,l^{\prime }}^{*}$ leads to a ${\mathrm{SMT}}^{\left(2\right)}$ root node $r_{i,j,k}^{*}$. We can divide this case into three subcases.

(i) If $r_{i,j,k}\ne r_{i,j,k}^{*}$, then $\mathcal{B}$ found a forgery $(r_{i,j,k}^{*},{\sigma }_{i,j,k},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k})$ of $\mathcal{OTS}$ that contradicts to that the $\mathcal{OTS}$ is EU-CMA secure.

(ii) Let $r_{i,j,k}=r_{i,j,k}^{*}$ and $A.pat{h}_{i,j,k,l^{\prime }}\ne A.pat{h}_{i,j,k,l^{\prime }}^{*}$. Then two different authentication paths of the same length $h_S$ lead to the same ${\mathrm{SMT}}^{\left(2\right)}$ root node $r_{i,j,k}$. Therefore, $\mathcal{B}$ found a collision for the hash function $\mathsf{H}$ and hence a contradiction.

(iii) If $r_{i,j,k}=r_{i,j,k}^{*}$ and $A.pat{h}_{i,j,k,l^{\prime }}=A.pat{h}_{i,j,k,l^{\prime }}^{*}$, which is discussed in the next case.

7.

If $(A.pat{h}_{i,j,k,l^{\prime }},r_{i,j,k},{\sigma }_{i,j,k},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k},A.pat{h}_{i,j,k},F{n}_{i,j},$$r_{i,j},A.pat{h}_i)=(A.pat{h}_{i,j,k,l^{\prime }}^{*},r_{i,j,k}^{*}$, ${\sigma }_{i,j,k}^{*},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}^{*},$$A.pat{h}_{i,j,k}^{*},F{n}_{i,j}^{*},r_{i,j}^{*},A.pat{h}_i^{*})$, there are two cases.

(i) Let $(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l})\ne (\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}^{*},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}^{*})$. If $\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}\parallel$$\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l})=\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}^{*}\parallel \mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}^{*})$, $\mathcal{B}$ found a collision for $\mathsf{H}$ that is a contradiction.

(ii) If $\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}\parallel$$\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l})$$\ne \mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}^{*}\parallel \mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}^{*})$, since

$A.pat{h}_{i,j,k,l^{\prime }}=A.pat{h}_{i,j,k,l^{\prime }}^{*}$ and $r_{i,j,k}=r_{i,j,k}^{*}$, $\mathcal{B}$ found a collision for $\mathsf{H}$ that is a contradiction.

8.

Lastly, we assume that all the components of ${\sigma }_{DGMT}$ and ${\sigma }_{DGMT}^{*}$ are the same except the components ${\sigma }_{i,j,k,l^{\prime }}$ and ${\sigma }_{i,j,k,l^{\prime }}^{*}$, that is ${\sigma }_{i,j,k,l^{\prime }}\ne {\sigma }_{i,j,k,l^{\prime }}^{*}$. Then $\mathcal{B}$ found a forgery on message m for the for $\mathcal{OTS}$, i.e., both $(m,{\sigma }_{i,j,k,l^{\prime }})$ and $(m,{\sigma }_{i,j,k,l^{\prime }}^{*})$ are valid, that contradicts the EU-CMA security of the $\mathcal{OTS}$.

Therefore, we can conclude that DGMT achieves unforgebility.

Traceability: In traceability game ${\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Trace}}\left(\lambda \right)$, the challenger runs the $\mathsf{DGMT}.\mathsf{KG}$ to create the $\mathrm{IMT}/{\mathrm{SMT}}^{\mathrm{MT}}$ tree and generate the secret and public keys of the system. The PPT adversary $\mathcal{A}$ has access to oracles $\mathsf{AddHU}$, $\mathsf{Revoke}$, $\mathsf{AddCU}$, and $\mathsf{SignHU}$ oracles and can add and revoke users, corrupt them and obtain their $(\mathsf{id},c_{\mathsf{id}})$, and obtain all signatures of honest users. At the end of the query phase, the adversary $\mathcal{A}$ has to output a valid signature

$$\begin{array}{cc}\hfill {\sigma }_{DGMT}^{*}=& ((i,j,k,l^{\prime }),{\sigma }_{i,j,k,l^{\prime }}^{*},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}^{*},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}^{*},A.pat{h}_{i,j,k,l^{\prime }}^{*},{\sigma }_{i,j,k}^{*},\hfill \\ & \mathsf{OTS}.{\mathsf{pk}}_{i,j,k}^{*},A.pat{h}_{i,j,k}^{*},A.pat{h}_i^{*}),\hfill \end{array}$$

on a message m with $\mathsf{DGMT}.\mathsf{Op}({\sigma }_{DGMT}^{*},\mathsf{DGMT}.\mathsf{SK})=\perp$. We will use this adversary to construct another PPT adversary $\mathcal{B}$ that simulates the role of the challenger for $\mathcal{A}$ to find a collision for the hash function $\mathsf{H}$, or forge a valid signature for $\mathcal{OTS}$, or can find a second-key for ${\mathsf{g}}_1$ that maps $F{k}_{i,j}$ to $F{n}_i$ for some $i,j$. Note that in each case, one of the assumptions of the theorem will cause a contradiction.

Let ${\sigma }_{DGMT}^{*}$ be a valid signature on m, with $\mathsf{DGMT}.\mathsf{Op}({\sigma }_{DGMT}^{*},\mathsf{DGMT}.\mathsf{SK})=\perp$. The $(i,j,k,l^{\prime })$ is a valid index, so it belongs to a user with identifier $\mathsf{id}$ and the manager knows its corresponding ${\mathsf{gsk}}_{i,j,k,l^{\prime }}^{\mathsf{id}}$ given in (7) and is able to compute ${\sigma }_{DGMT}\leftarrow \mathsf{DGMT}.\mathsf{Sig}(m,{\mathsf{gsk}}_{i,j,k,l^{\prime }}^{\mathsf{id}}),$ where

$$\begin{array}{cc}\hfill {\sigma }_{\mathrm{DGMT}}=& ((i,j,k,l^{\prime }),{\sigma }_{i,j,k,l^{\prime }},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l},A.pat{h}_{i,j,k,l^{\prime }},{\sigma }_{i,j,k},\hfill \\ & \mathsf{OTS}.{\mathsf{pk}}_{i,j,k},A.pat{h}_{i,j,k},A.pat{h}_i).\hfill \end{array}$$

The proof arguments are the same as the proof presented for Unforgeability. The only difference is that $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}^{*}\ne \mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}$ in the traceability proof because $\mathsf{DGMT}.\mathsf{Op}({\sigma }_{DGMT}^{*},\mathsf{DGMT}.\mathsf{SK})=\perp$ and $\mathsf{DGMT}.\mathsf{Op}({\sigma }_{DGMT},\mathsf{DGMT}.\mathsf{SK})=\mathsf{id}$. Therefore, we also have $\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}^{*}\Vert \mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}^{*}\ne \mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}\Vert \mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}.$

1.

If $\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}^{*}\Vert \mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}^{*})=\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}$$\Vert \mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l})$, then we found a collision for $\mathsf{H}$. If not, then we have the next cases.

2.

Let $\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}^{*}\Vert \mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l}^{*})\ne \mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l^{\prime }}$$\Vert \mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l})$, and $A.pat{h}_{i,j,k}$ and $A.pat{h}_{i,j,k}^{*}$ leads to ${\mathrm{SMT}}^{\left(2\right)}$ root nodes $r_{i,j,k}$ and $r_{i,j,k}^{*}$ respectively. If $r_{i,j,k}=r_{i,j,k}^{*}$, then $\mathcal{B}$ found a collision for $\mathsf{H}$. Otherwise, this leads to the next case.

3.

Let $r_{i,j,k}\ne r_{i,j,k}^{*}$. If $\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}=\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}^{*}$, then we found a forgery for the $\mathcal{OTS}$ scheme. However, if $\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}\ne \mathsf{OTS}.{\mathsf{pk}}_{i,j,k}^{*}$ then there are two cases:

(i) If $\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k})=\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}^{*})$, thus $\mathcal{B}$ found a collision for $\mathsf{H}$.

(ii) If $\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k})\ne \mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}^{*})$, we have the next case.

4.

Let $\mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k})\ne \mathsf{H}(\mathsf{OTS}.{\mathsf{pk}}_{i,j,k}^{*})$, and $A.pat{h}_{i,j}$ and $A.pat{h}_{i,j}^{*}$ leads to ${\mathrm{SMT}}^{\mathrm{MT}}$ root nodes $r_{i,j}$ and $r_{i,j}^{*}$ respectively. If $r_{i,j}=r_{i,j}^{*}$, then $\mathcal{B}$ found a collision for $\mathsf{H}$. Next, we consider the case $r_{i,j}\ne r_{i,j}^{*}$.

5.

Let $r_{i,j}\ne r_{i,j}^{*}$. Assume that $F{n}_i={\mathsf{g}}_1^{-1}(r_{i,j},F{K}_{i,j})$ and $F{n}_i^{*}={\mathsf{g}}_1^{-1}(r_{i,j}^{*},F{K}_{i,j})$. If $F{n}_i=F{n}_i^{*}$, then the adversary $\mathcal{B}$ can find a new key $r_{i,j}^{*}$ such that ${\mathsf{g}}_1(r_{i,j},F{n}_i)={\mathsf{g}}_1(r_{i,j}^{*},F{n}_i)$. Otherwise, that is if $F{n}_i\ne F{n}_i^{*}$, then $\mathcal{B}$ can find a collision for $\mathsf{H}$ using the authentication paths $A.pat{h}_i$ and $A.pat{h}_i^{*}$ because both the paths lead to the group public key $\mathsf{DGMT}.\mathsf{gpk}$.

Hence, we can conclude that DGMT achieves traceability.

Anonymity: We show that if $\mathcal{A}$ succeeds with a non-negligible advantage in distinguishing a signature generated by randomly selecting one of the two honest users with identifiers ${\mathsf{id}}_0$ and ${\mathsf{id}}_1$, then we can distinguish the outputs of the SPRP ${\mathsf{g}}_1$ or ${\mathsf{g}}_2$ from random permutations with non-negligible probability, which is a contradiction with our assumptions.

In the anonymity security game ${\mathbf{Exp}}_{\mathcal{FDGS},\mathcal{A}}^{\mathrm{Anon}-\mathrm{b}}\left(\lambda \right)$, a PPT adversary $\mathcal{A}$ has access to the oracles $\mathsf{AddHU}$, $\mathsf{AddCU}$, $\mathsf{Revoke}$, $\mathsf{SignHU}$, ${\mathsf{Ch}}_b$, and $\mathsf{Open}$. The adversary $\mathcal{A}$ is allowed to add honest users to the group and to revoke users from the group. It also can corrupt honest users to obtain their $(\mathsf{id},c_{\mathsf{id}})$s and sign messages on their behalf. Additionally, $\mathcal{A}$ can use the oracle $\mathsf{SignHU}$ to obtain signatures from honest users on arbitrary messages. Furthermore, $\mathcal{A}$ can use the oracle $\mathsf{Open}$ to find the identity of the signer for any message-signature pair.

At some stage of the game, $\mathcal{A}$ calls ${\mathsf{Ch}}_b$. $\mathcal{A}$ selects a message m along with two users with identifiers ${\mathsf{id}}_0$ and ${\mathsf{id}}_1$ and send them to the challenger. The challenger checks if ${\mathsf{id}}_0$ and ${\mathsf{id}}_1$ are honest or not. If they are honest, the challenger selects randomly a ${\mathrm{SMT}}^{\left(2\right)}$, say ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$, and a random bit b. According to Algorithm $\mathsf{DGMT}.\mathsf{KeyDist}$ in Algorithm 6, every user has at least one unused key in every ${\mathrm{SMT}}^{\left(2\right)}$. So, the manager can select two unused keys of the users with identifiers ${\mathsf{id}}_0$ and ${\mathsf{id}}_1$ in ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$. Let $(i,j,k,l_0^{\prime })$ and $(i,j,k,l_1^{\prime })$ be the indexes of the leaf nodes of these unused keys which belong to the users ${\mathsf{id}}_0$ and ${\mathsf{id}}_1$, respectively (i.e., these two unused keys are ${\mathsf{gsk}}_{i,j,k,l_0^{\prime }}^{{\mathsf{id}}_0}$ and ${\mathsf{gsk}}_{i,j,k,l_1^{\prime }}^{{\mathsf{id}}_1}$). The challenger generates $(m,{\sigma }_{DGMT}^b)$, where ${\sigma }_{DGMT}^b\leftarrow \mathsf{DGMT}.\mathsf{Sig}(m,{\mathsf{gsk}}_{i,j,k,l_b^{\prime }}^{{\mathsf{id}}_b})$ is

$$\begin{array}{cc}\hfill {\sigma }_{DGMT}^b=& ((i,j,k,l_b^{\prime }),{\sigma }_{i,j,k,l_b^{\prime }},\mathsf{OTS}.{\mathsf{pk}}_{i,j,k,l_b^{\prime }},\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l_b},A.pat{h}_{i,j,k,l_b^{\prime }},{\sigma }_{i,j,k},\hfill \\ & \mathsf{OTS}.{\mathsf{pk}}_{i,j,k},A.pat{h}_{i,j,k},A.pat{h}_i),\hfill \end{array}$$

with $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l_b}\leftarrow {\mathsf{g}}_2(\mathsf{msk},i\Vert j\Vert k\Vert l_b),$ and sends it back to the adversary $\mathcal{A}$ to determine whose signature it is. $\mathcal{A}$ has still access with oracles $\mathsf{AddHU}$, $\mathsf{Revoke}$, $\mathsf{SignHU}$, ${\mathsf{Ch}}_b$, and $\mathsf{Open}$. However, $\mathcal{A}$ cannot call the oracle $\mathsf{Open}$ on the signatures generated by ${\mathsf{Ch}}_b$, which are stored in the challenge list $\mathsf{CL}$. Also, $\mathcal{A}$ cannot invoke the oracle $\mathsf{Revoke}$ on users with identifiers ${\mathsf{id}}_0$ or ${\mathsf{id}}_1$, as this would allow $\mathcal{A}$ to distinguish the signer by searching $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l_b}$ in the revocation list before and after calling the oracle $\mathsf{Revoke}$ on one of these identifiers. Finally, $\mathcal{A}$ outputs a bit $b^{\prime }$ and wins the anonymity experiment if $b^{\prime }=b$.

Notice that $(i,j,k,l_b^{\prime })$ and $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l_b}$ are the only elements of the signature ${\sigma }_{DGMT}^b$ that allows $\mathcal{A}$ to distinguish the signer. We discuss both cases separately below.

1.

$\mathcal{A}$ breaks the anonymity with non-negligible probability using $(i,j,k,l_b^{\prime })$:

With the provided oracles, the adversary $\mathcal{A}$ can request signatures on arbitrary messages using all the leaf nodes of the selected ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$, except for the leaf nodes indexed by $(i,j,k,l_0^{\prime })$ and $(i,j,k,l_1^{\prime })$. Let $(i,j,k,l^{*})$ and $(i,j,k,l^{+})$ represent the tuples assigned to the leaf nodes indexed by $(i,j,k,l_0^{\prime })$ and $(i,j,k,l_1^{\prime })$ before permutation. According to the security model, $\mathcal{A}$ knows the values of ${\mathsf{g}}_1(\mathsf{shuffle}.\mathsf{key},i\Vert j\Vert k\Vert l)$, for all $l\ne l^{*},l^{+}$. Consequently, $\mathcal{A}$ knows the permutation of (at most) all the leaf nodes of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$ except two leaf nodes indexed by $(i,j,k,l^{*})$ and $(i,j,k,l^{+})$, and does not have any information on the values of ${\mathsf{g}}_1(\mathsf{shuffle}.\mathsf{key},i\Vert j\Vert k\Vert l^{*})$ and ${\mathsf{g}}_1(\mathsf{shuffle}.\mathsf{key},i\Vert j\Vert k\Vert l^{+})$. If $\mathcal{A}$ breaks the anonymity experiment by $(i,j,k,l_b^{\prime })$ with non-negligible probability, it means that $\mathcal{A}$ is able to extract information on the two values ${\mathsf{g}}_1(\mathsf{shuffle}.\mathsf{key},i\Vert j\Vert k\Vert l^{*})$ and ${\mathsf{g}}_1(\mathsf{shuffle}.\mathsf{key},i\Vert j\Vert k\Vert l^{+})$, and identify which one would be located at the position $(i,j,k,l_b^{\prime })$ with non-negligible probability. This would mean that $\mathcal{A}$ can distinguish the outputs of the SPRP ${\mathsf{g}}_1$ from a random function with non-negligible probability, which is a contradiction.

2.

$\mathcal{A}$ breaks the anonymity with non-negligible probability using $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l_b}$:

Using the notation of the previous case, $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l_b}$ is either ${\mathsf{g}}_2(\mathsf{msk},(i\Vert j\Vert k\Vert l^{*}\left)\right)$ or ${\mathsf{g}}_2(\mathsf{msk},(i\Vert j\Vert k\Vert l^{+}\left)\right)$. Hence, if the adversary $\mathcal{A}$ breaks the anonymity experiment using $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l_b}$ with non-negligible probability, it means that $\mathcal{A}$ is able to win the indistinguishability game of the SPRP ${\mathsf{g}}_2$ for two pairs $(i\Vert j\Vert k\Vert l^{*})$ and $(i\Vert j\Vert k\Vert l^{+})$ with non-negligible probability, which is a contradiction.

It is important to note that although $(i,j,k,l_b^{\prime })$ and $\mathsf{DGMT}.{\mathsf{pos}}_{i,j,k,l_b}$ are both related to the index $(i,j,k,l_b)$, they are generated using different SPRPs and keys. The former represents the location of $(i,j,k,l_b)$ after the permutation of the leaf nodes, determined by the SPRP ${\mathsf{g}}_1$ and the secret key $\mathsf{shuffle}.\mathsf{key}$ through the shuffling Algorithm 2. The latter is computed using the SPRP ${\mathsf{g}}_2$ and the key $\mathsf{msk}$. As a result, these values together do not reveal any information about the index $(i,j,k,l_b)$ and equivalently the identifier of the signer. □

6. Revocation in DGM and DGMT

One of the main contributions of DGM is the introduction of a new approach to revocation that uses $\mathcal{SPE}$ as its main building block. In the following, we review this approach and show that there is a significant hidden cost in using the approach, which makes the traditional revocation list a much better choice in practice for revocation. Moreover, in Appendix A, we describe how $\mathcal{SPE}$ decryption keys can be used to construct a revocation list, providing a more efficient approach to revocation than the original DGM. See Table A1 for the comparative study.

6.1. Revocation in DGM

DGM uses SPE-based approach to revocation. A DGM signature includes a unique tag that is the encryption of the index of the leaf node (called $\mathsf{DGM}.\mathsf{pos}$) whose associated OTS has been used to sign the message. The verifier checks if the OTS key is revoked or not by checking whether it is getting back the message of the signature by first encrypting it using the master secret key and then decrypting the encrypted message using the punctured decryption key while using $\mathsf{DGM}.\mathsf{pos}$ as the tag. If the OTS key is revoked, the decryption key $S{K}_d$ is punctured at the tag $\mathsf{DGM}.\mathsf{pos}$.

In the following, we use the description and parameters of $\mathcal{SPE}$ that was introduced in Section 2.1 to explain the revocation algorithm of DGM. Assume that there are $d^{\prime }$ punctured leaves in IMT/SMT structure at a certain point of time in DGM. If the manager wants to revoke a user to whom $d^{\prime \prime }$ signature positions are assigned, then the manager invokes the $\mathsf{SPE}.\mathsf{KeyGen}$ algorithm with $d=d^{\prime }+d^{\prime \prime }$ and receives the key $\mathrm{DGM}.rv{k}_0=msk$. Next, the manager punctures the $\mathrm{DGM}.rv{k}_0$ at all the previous $d^{\prime }$ positions and new $d^{\prime \prime }$ positions by calling the $\mathsf{SPE}.\mathsf{Punc}$ algorithm d times, and gets the punctured decryption key $\mathrm{DGM}.rv{k}_1=S{K}_d$. The manager replaces the old keys with the new key pair $(\mathrm{DGM}.rv{k}_0,\mathrm{DGM}.rv{k}_1)$ and publishes them. Here $\mathrm{DGM}.rv{k}_0$ is the new encryption key of the $\mathcal{SPE}$, and $\mathrm{DGM}.rv{k}_1$ is the new decryption key. The verifier checks whether a signature is revoked by checking,

$$m\stackrel{?}{=}\mathsf{SPE}.\mathsf{Dec}(\mathrm{DGM}.rv{k}_1,\mathsf{SPE}.\mathsf{Enc}(\mathrm{DGM}.rv{k}_0,m,t),t),$$

(9)

where $t=\mathsf{DGM}.\mathsf{pos}$ is the encrypted index of the leaf node associated with the signature and m is the received message. The tag space is the set of all possible leaf indices. If the $\mathrm{DGM}.rv{k}_1$ is punctured at the position t, then the key of $\mathsf{SPE}.\mathsf{Enc}$ derived from $(\mathrm{DGM}.rv{k}_0,t)$ is different from the key of $\mathsf{SPE}.\mathsf{Dec}$ derived from $(\mathrm{DGM}.rv{k}_1,t)$ and thus comparison (9) will fail. For checking if a signature is revoked, the verifier performs two computational steps: $\mathsf{SPE}.\mathsf{Enc}$ and $\mathsf{SPE}.\mathsf{Dec}$.

1. Encryption step $\mathsf{SPE}.\mathsf{Enc}$. Verifier first computes a chain of d keys: $s{k}_1,s{k}_2,\dots ,s{k}_d$ from $\mathrm{DGM}.rv{k}_0=msk=(s{k}_0,d)$. Then verifier applies the pseudorandom function $F^{\prime }$ on each of the $(d+1)$$s{k}_i$ for $i=0,1,\dots ,d$ along the tag t as described in Equation (9). DGM uses the construction of Pun-PRF in [48] and realizes SPE by constructing $F^{\prime }$ using GGM construction [53].

GGM-based construction of $F^{\prime }$. Let G be a length doubling pseudorandom generator defined as $G:{\{0,1\}}^{\lambda }\to {\{0,1\}}^{2\lambda }$. Let us denote the least significant $\lambda$ bits and most significant $\lambda$ bits of $G\left(seed\right)$ by $G_0\left(seed\right)$ and $G_1\left(seed\right)$ respectively. Let tag t be a $\lambda$-bit long binary-string $\{b_{\lambda -1}\dots b_1{b}_0\}$. We compute $F^{\prime }(s{k}_i,t)$ as

$$F^{\prime }(s{k}_i,t)=G_{b_{\lambda -1}}\left(\dots G_{b_1}\left(G_{b_0}\left(s{k}_i\right)\right)\dots \right).$$

We can view all executions of G as a binary tree of height $\lambda$ where $G_0\left(seed\right)$ and $G_1\left(seed\right)$ are the right and left child, respectively, of the parent node $seed$ and the tree is called GGM tree. Now the t-th leaf node of the GGM tree with root $s{k}_i$ is the $F^{\prime }(s{k}_i,t)$. Therefore, each $F^{\prime }(s{k}_i,t)$ computation needs $\lambda$ evaluations of G and, as a consequence, the verifier has to evaluate G $\lambda (d+1)$ times to compute the encryption key of $\mathsf{SE}.\mathsf{Enc}$, excluding the Xors and computation of hash functions.

2. Decryption step $\mathsf{SPE}.\mathsf{Dec}$. During the computation of the decryption key with d punctured tags, the verifier needs to evaluate $\mathsf{F}.\mathsf{Eval}$d times and $F^{\prime }$ once on the key $\mathrm{DGM}.rv{k}_1=S{K}_d$ and the tag t. Let $S{K}_d=\{(s{k}_d,d),ps{k}_1,ps{k}_2,\dots ,ps{k}_d\}$ which is punctured at tags $\{t_1,t_2,\dots ,t_d\}$. Each $ps{k}_i$ is the list of $\lambda$ sibling nodes of the path that leads to the $t_i$-th leaf node of the GGM tree with the root $s{k}_{i-1}$ and the j-th sibling node is

$$G_{{\overline{b}}_{i,j}}\left(G_{b_{i,j-1}}\left(\dots G_{i,b_0}\left(s{k}_{i-1}\right)\dots \right)\right)$$

where $t_i$ be a $\lambda$-bit binary string $t_i=\{b_{i,\lambda -1}\dots b_{i,1}{b}_{i,0}\}$ and ${\overline{b}}_{i,j}$ is bit-wise complement of $b_{i,j}$. Therefore, each puncture or revocation needs $\lambda$ evaluations of G and each puncture needs ${\lambda }^2$-bit storage. Notice that, given $ps{k}_i$, we can compute any leaf node of the GGM tree with root $s{k}_{i-1}$ except the leaf node at position $t_i$, that is we can compute $\mathsf{F}.\mathsf{Eval}(ps{k}_i,t)=F^{\prime }(s{k}_{i-1},t)$ as long as $t\ne t_i$. Evaluation of $\mathsf{F}.\mathsf{Eval}(ps{k}_i,t)$ needs the sibling node in $ps{k}_i$ which is the root of the GGM subtree containing the t-th leaf node. Then, $\mathsf{F}.\mathsf{Eval}(ps{k}_i,t)$ needs at most $\lambda -1$ and minimum 0 evaluations of G, that is, on average $(\lambda -1)/2$ evaluations of G is required. Therefore, the verifier has to perform on average $d(\lambda -1)/2+\lambda$ evaluations of G to compute the decryption key of $\mathsf{SE}.\mathsf{Dec}$ of $\mathsf{SPE}.\mathsf{Dec}$.

Total computation cost of revocation includes computation of $\mathcal{SPE}$ encryption key, evaluation of $\mathsf{SE}.\mathsf{Enc}$, computation of $\mathcal{SPE}$ decryption key, evaluation of $\mathsf{SE}.\mathsf{Dec}$, and string comparison which in total will be, $\lambda (d+1)+d(\lambda -1)/2+\lambda =(3\lambda -1)d/2+2\lambda$ evaluations of G, one evaluation of $\mathsf{SE}.\mathsf{Enc}$ and $\mathsf{SE}.\mathsf{Dec}$, and a string comparison on average.

6.2. Revocation in DGMT

In DGMT, for each revoked signature the manager appends $\mathsf{DGMT}.\mathsf{pos}$ of the revoked signature to the revocation list $\mathcal{RL}$, and so after revoking d signatures, the revocation list will require $d\lambda$ bits of storage. For verification of a signature when d signatures are revoked, the verifier needs to, at the most, traverse a list of d elements with a string comparison at each element.

In comparison, for each revocation in DGM, the manager appends $\lambda$ strings of length $\lambda$ bits to the list $\mathrm{DGM}.rv{k}_1$, and so when d signatures are revoked, DGM requires $d{\lambda }^2$ bits of storage. For verification of a signature, the verifier requires $(3\lambda -1)d/2+2\lambda$ evaluations of G, one evaluation of $\mathsf{SE}.\mathsf{Enc}$ and $\mathsf{SE}.\mathsf{Dec}$, and a string comparison.

Thus for both computation and storage, the DGMT revocation list approach outperforms the DGM SPE-based approach.

7. Implementation and Experiments

In this section, we present our implementation and experimental results. Our implementation is for all the algorithms in Section 4. The implementation provides all the functions required in a fully dynamic symmetric-key based group signature. The code is available at https://github.com/submissionOfCode/DGMT_ref, accessed on 19 November 2024.

In our experiment, we use a system with OS Ubuntu 18.04, and the code is compiled using GCC-8.4.0. The processor of the system is Intel^®Core^TMi7-9700 8-Core CPU @ 3.00 GHZ and it has 8 GB RAM. We use XMSS reference code, given in https://github.com/XMSS/xmss-reference, accessed on 16 March 2021, as the base of our software $\mathrm{DGMT}$ to comply with the fact the XMSS is a standard [16]. We use the AES functions in OpenSSL as a SPRP. We only use a single core without hyper-threading and turbo-boost. All the experimental results are listed in Table 7 and each reported timing is the average of 5 runs. Our experimental results show that DGMT is practical for large values of ${\mathsf{T}}_{\mathsf{tot}}$.

Table 7. Timings for different Group Signature Operations, and Sizes of Signatures, IMT and different files in all the directories for different group parameters for $B=8$. We use SHA-256 as the hash function and the Winternitz parameter w is 4. The column with $\gamma =1$ is used for comparison for DGM. (s, ms, B, KB, and MB stand for seconds, Milliseconds, Bytes, Kilobytes, and Megabytes respectively).

Parameters
$h_I$	4
$h_S$ (each layer of ${\mathrm{SMT}}^{\mathrm{MT}}$)	8			9			10
$\beta$ (leaf nodes/${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\mathrm{MT}}$/user)	4			4			8
$\gamma$ (number of ${\mathrm{SMT}}^{\mathrm{MT}}$s per IMT node)	1	2	4	1	2	4	1	2	4
${\mathsf{N}}_{\mathsf{max}}$ (group size)	${\mathbf{2}}^{\mathbf{6}}$	$2^6$	$2^6$	${\mathbf{2}}^{\mathbf{7}}$	$2^7$	$2^7$	${\mathbf{2}}^{\mathbf{7}}$	$2^7$	$2^7$
${\mathsf{T}}_{\mathsf{tot}}$ (approx.)	${\mathbf{2}}^{\mathbf{20}.\mathbf{54}}$	$2^{21.54}$	$2^{22.54}$	${\mathbf{2}}^{\mathbf{22}.\mathbf{54}}$	$2^{23.54}$	$2^{24.54}$	$2^{24.76}$	$2^{25.76}$	$2^{26.76}$
Timings
Setup (s)	7.784	15.412	30.843	15.425	31.179	61.765	31.006	61.639	123.259
Initial Key Distribution (s)	862.080	861.170	861.709	5283.238	4805.827	4508.836	20,679.256	17,393.360	20,903.315
Joining (s)	2.062	2.058	2.060	4.117	4.139	4.116	8.219	8.222	8.529
User Signing (ms)	0.468	0.495	0.428	0.429	0.445	0.455	0.402	0.429	0.399
Verification before any revocation (s)	1.026	1.010	1.104	1.161	1.099	1.095	1.123	1.121	1.183
Revocation (Min) (ms)	0.073	0.074	0.073	0.074	0.073	0.074	0.131	0.135	0.134
Verification after revocation (Min) (s)	1.045	1.031	1.123	1.180	1.118	1.114	1.160	1.161	1.223
Opening (ms)	0.0003	0.0003	0.0003	0.0003	0.0003	0.0003	0.0003	0.0003	0.0003
Sizes
Signature (average) (KB)	5.216	5.216	5.216	5.280	5.280	5.280	5.344	5.344	5.344
IMT size (B) (primary Memory)	960	960	960	960	960	960	960	960	960
FallBackKeys (KB)	0.960	1.920	3.840	0.960	1.920	3.840	0.960	1.920	3.840
Each file in m_user (B)	240	240	240	240	240	240	240	240	240
Each file in dgmt/manager/smt/smtU (B)	132	132	132	132	132	132	132	132	132
Each file in dgmt/manager/smt/smtD (MB)	0.637	0.637	0.637	1.291	1.291	1.291	2.614	2.614	2.614

There is a minor difference of ≈0.3 KB between the computed signature size of DGMT in (4), and the value shown in the table. This difference is because DGMT code uses XMSS code that incorporates additional data (e.g., index and public seed) in the signature. These date are not needed in DGMT.

In the following, we explain the parameters chosen for our experiments. Consider the height of the IMT trees and setup time. For ${\mathsf{T}}_{\mathsf{tot}}=2^{21}$ to $2^{27}$ signatures, we use an IMT of height $h_I=4$ and SMT of height $h_S=8,9,$ and 10. Thus the number of fallback keys is $(2^{h_I+1}-2)\gamma =30\gamma$ for $\gamma =1,2,4$. For $\approx 2^{23}$ signatures, DGM needs an IMT with $h_I=20$ and 524,286 fallback keys which is significantly larger than the corresponding numbers in DGMT. Furthermore, DGM needs 4 s for the setup phase for $\approx 2^{23}$ signatures (Figure 3 of [27]) while DGMT needs only 10 more extra seconds including the generation of all the fallback keys, and completely removes the interaction between the manager and the verifier. We have ${\mathsf{N}}_{\mathsf{max}}=2^{h_S}/\beta$, where $\beta$ is the total number of keys per user per $\mathrm{SMT}$. We used $\beta =4,8$ and so ${\mathsf{N}}_{\mathsf{max}}=2^{h_S-2}$ and $2^{h_S-3}$. The following discussion provides the rationale for the results of our experiments. Joining time in DGMT depends on $h_S$ and B only and does not depend on $\beta$ and $\gamma$. This is because during the join operation of a user, for any $\gamma$, the first unassigned node of the user (from the B randomly chosen nodes of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$) will be sent to the user. If $h_S$ increases by one then the joining time increases by a factor of 2. Because an increase in $h_S$ by one causes an increase in tree size by a factor of 2, and consequently the computation times of ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j}}^{\left(1\right)}$ and ${\mathrm{SMT}}_{\mathrm{i},\mathrm{j},\mathrm{k}}^{\left(2\right)}$ increase 2 times. Notice that, the user signing is of constant time but the verification time is variable and is larger than the user signing time. In a traditional MSS, the signing time includes the time required for computing both a WOTS and an authentication path. In DGMT however, the authentication paths are computed by the manager and sent privately to the user. Thus the user signing time is the time to compute a WOTS signature, and this takes a constant time. During verification, however, the verifier must check the signature against the revocation list to ensure it is not a revoked signature, and then recomputes the root of the IMT and compares it with the published root (public key). The time to check the signature against the revocation list depends on the size of the revocation list and the position of the corresponding encrypted label in the list, and for an unrevoked signature requires traversing the full revocation list. The recomputation time of the IMT root depends on the level of the fallback node in IMT and the $h_S$. Table 7 shows the average verification time for an empty revocation list, and when the B signatures of a single revoked user are included in the list. The signature opening is constant time because it only needs to decrypt the encrypted label which is a part of the signature. The revocation time depends on $\beta$ and $\gamma$. For $h_S=8,{\mathsf{N}}_{\mathsf{max}}=2^6$, and $h_S=9,{\mathsf{N}}_{\mathsf{max}}=2^7$, so we have $\beta =4$. For $h_S=10,{\mathsf{N}}_{\mathsf{max}}=2^7$, so $\beta =8$. In our experiments, we revoke a user after the initial joining. Therefore, in the first two cases, we encrypt $\beta \times B=32$ labels and add them to the revocation list. In third case, we have to encrypt and add 64 labels to the revocation list. Because of this, the revocation times for $h_S=8,{\mathsf{N}}_{\mathsf{max}}=2^6$, and $h_S=9,{\mathsf{N}}_{\mathsf{max}}=2^7$ are the same in Table 7, and $h_S=10,{\mathsf{N}}_{\mathsf{max}}=2^7$ shows doubled revocation time.

8. Concluding Remarks

We proposed DGMT, a post-quantum symmetric-key based fully dynamic group signature scheme that improves upon DGM by addressing two major shortcomings: (i) the need for interaction with the manager during signature verification, and (ii) the manager’s storage size that grows proportional to the total number of signatures. We defined, formalized and proved DGMT and its security, and implemented and evaluated the scheme. Our experiments were conducted for ${\mathsf{T}}_{\mathsf{tot}}\approx 2^{24}$, but our design can support a much larger number of signatures: the flexible structure allows the setup parameters to be chosen for a total number ${\mathsf{T}}_{\mathsf{tot}}$ of OTSs and ${\mathsf{N}}_{\mathsf{max}}$ users, where ${\mathsf{N}}_{\mathsf{max}}$ is upper bounded by half of the number of leaves of ${\mathrm{SMT}}^{\left(2\right)}$.

An important advantage of DGMT over other post-quantum fully dynamic group signature schemes is that the signature length of DGMT is the shortest among all other known schemes with the same security level. Compared to SiTH, the only other fully implemented fully dynamic symmetric-key based group signature scheme, DGMT’s signature size is approximately 100 times shorter (see Table 2).

Interesting directions for future work are: (i) design of a more efficient stateless fully dynamic symmetric-key based group signature scheme, and (ii) adapting DGMT for applications that use EPID applications where large group sizes (e.g., $2^{60}$ that is supported by SiTH) are supported but traceability (signature opening) is not required.