GM^MT: A Revocable Group Merkle Multi-tree Signature Scheme

Abstract

G-Merkle (GM) (PQCrypto 2018) is the first hash-based group signature scheme where it was stated that multi-tree approaches are not applicable, thus limiting the maximum number of supported signatures to $2^{20}$. DGM (ESORICS 2019) is a dynamic and revocable GM-based group signature scheme that utilizes a computationally expensive puncturable encryption for revocation and requires interaction between verifiers and the group manager for signature verification. In this paper, we propose GM^MT, a hash-based group signature scheme that provides solutions to the aforementioned challenges of the two schemes. GM^MT builds on GM and adopts a multi-tree construction that constructs new GM trees for new signing leaves assignment while keeping the group public key unchanged, Compared to a single GM instance which enables $2^{20}$ signature, GM^MT allows growing the multi-tree structure adaptively to support $2^{64}$ signatures under the same public key. Moreover, GM^MT has a revocation mechanism that attains linkable anonymity of revoked signatures and has a logarithmic verification computational complexity compared to the linear complexity of DGM. The group manager in GM^MT requires storage that is linear in the number of members while the corresponding storage in DGM is linear in the number of signatures supported by the system. Concretely, for a system that supports $2^{64}$ signatures with $2^{15}$ members and provides 256-bit security, the required storage of the group manager is 1 MB (resp. $10^{8.7}$ TB) in GM^MT(resp. DGM).

A Alternative Solution for a Large Revocation List

In this section, we provide a solution for the large revocation list of GM^MTwhich is suitable for some applications that do not require anonymity of revoked members. We propose the following modification to the leaf generation procedure.

• The group manager generates a secret key $sk^*_i$ for each group member, for $0 \le i \le N-1$. This key is different from the group member secret key $sk_i$ that is used to generate the WOTS signing keys.

• The encrypted label in GM^MT is replaced by the output of hashing the concatenation of the corresponding $WOTS.pk$ and the group member key $A^*= H(WOTS.pk||sk^*_i$).

The remaining procedures are the same as in GM^MTwith the following three differences in the revocation, verification and opening procedures.

• To revoke the j-th member, the group manager adds their key $sk^*_j$ to the revocation list, RevList.

• In the verification process, the verifier checks if the calculated WOTS from the signature and keys in the revocation list gives the value $A^*$ in the received signature (which means that the signature has been revoked), if not the verifier continues with the verification.

• In the opening process, the group manager checks which group member’s secret key $sk^*_i$ gives the value $A^*$ in the signature $A^*= H(WOTS.pk||sk^*_i$) for $0 \le i \le N-1$.

Applying the above modification has the following consequences.

• The revocation list size is linear in the number of revoked members, while in GM^MT it is linear in the number of revoked leaves.

• Revocation does not maintain the anonymity of revoked members.

• The verification complexity is linear in the number of revoked members, while GM^MT verification has logarithmic computational complexity with respect to the number of revoked leaves.

• The opening complexity is linear in the number of members, while GM^MT has a constant opening complexity, i.e., one decryption operation.