Robust Subgroup Multi-signatures for Consensus

Abstract

Multi-signatures are used to attest that a given collection of n parties, indexed by their respective public keys, have all signed a given message. A recent popular application of multi-signatures is to be found in consensus protocols to attest that a qualified subset of a global set of n validators have reached agreement. In this paper, we point out that the traditional security model for multi-signatures is insufficient for this new application, as it assumes that every party in the set participates in every multi-signature computation and that is honest. None of these assumptions hold in the typical adversarial scenarios in consensus protocols (aka. byzantine agreement), where malicious players can launch a denial-of-service attack by injecting malformed individual signatures and cause liveness to halt. We address this by introducing a new multi-signature variant called robust subgroup multi-signatures, whereby any eligible subgroup of signers from the global set can produce a multi-signature on behalf of the group, in the presence of a byzantine adversary. We provide syntax and security definitions thereof and argue that existing unforgeability security proofs for multi-signatures do not carry over to the consensus setting; a consequence of this observation is that many multi-signature based consensus protocols are left lacking a rigorous security proof for correctness. To remediate this we propose several constructions which we prove secure under widely held cryptographic assumptions using our newly introduced formal definitions and also improve upon multi-signature computation time. Finally, we report on benchmarks from a proof-of-concept implementation.

1 Introduction

A multi-signature protocol¹ enables n entities indexed by their respective public keys $\{pk_i\}_{i=1}^n$ to sign a message m and produce n individual signatures $\{s_i\}_{i=1}^n$ which are later compressed into a multi-signature $\sigma$. Recently there has been a renewed interest in multi-signatures for securing distributed ledgers, e.g., [14, 16, 23]. Multi-signatures can be used to build secure ledgers more efficiently, namely they can help reduce block storage and/or block correctness verification time or reduce the time to validate that consensus on a block has been reached [8, 14].

A multi-signature can be trivially obtained from any unforgeable signature scheme by concatenating every individuals’ signature on m, while verification simply checks that each atomic signature passes the individual signature verification test. Often designs that improve on that trivial construction in terms of the final signature length or the performance of the verification process are preferred. It is expected that multi-signature designs achieve compactness [8], that is, the length of the final multi-signature is independent of the number of signers. The verification of the short multi-signature $\sigma$ should convince a verifier that all the n entities signed the message m. Multi-signatures can be constructed, for example, from Schnorr signatures e.g. [23], and from BLS signatures [6, 8, 9]. Schnorr-based multi-signatures involve multiple rounds of communication, while pairing-based multi-signature schemes can be non-interactive. The latter is highly desirable for applications in distributed settings where the potential participants are unknown upfront and the network nodes are sparsely connected. The focus on this paper is therefore on non-interactive multi-signature protocols.

Despite the recent popularity gained by multi-signatures for the specific purpose of recording blockchain consensus, both in the literature [8, 14, 16, 23] and in actual platforms [1, 10, 15, 20, 28], the existing multi-signatures formal models fail to address the particularities of consensus protocols. Indeed, existing multi-signatures formal models apply in scenarios where the signing entities are controlled by a single party or where they are highly coordinated, so that the incoming individual signatures are assumed to be valid before being combined in a single multi-signature. Such is the case for instance in a scenario where a user owns multiple wallets that can transfer funds by generating a multi-signature that if correct shows every wallet sign the corresponding transfer (this actually constitutes their main usage so far in the cryptocurrency space).

Thus, existing (non-interactive) multi-signature schemes mechanics do not explicitly address the verification and selection of valid individual signatures before running the multi-signature creation process. However, in the context of signaling block agreement amongst a group of validators in Proof-of-Stake consensus protocols, it is not reasonable to assume that the individual signatures coming from consensus nodes are valid by default. This applies likewise in the case of aggregating transaction signatures. Therefore individual signatures need to be verified before being aggregated into a multi-signature, as we simply cannot assume they are valid when the combining party runs the combining process. To reflect this, we introduce a notion of robustness for multi-signatures which is a form of correctness but allowing the adversary to submit signatures to the signature combination algorithm.

A variant of multi-signatures that can be particularly useful for consensus applications is subgroup multi-signatures [6, 24]. Subgroup multi-signatures allow any eligible subgroup of signers from a global set to produce a multi-signature on behalf of the global group, as the right solution to recording consensus. This concept is most useful in scenarios where the group of entities that will participate in the signing process of a given message belong to a fixed set but is not fully determined. For example that is the case in t-out-of-n multi-signatures, where a combined multi-signature is valid if any t members out of a given n-member set have signed.

The current practice of using BLS-based multi-signatures with bitmaps as subgroup multi-signatures for blockchain consensus, for example [12, 15, 16, 20] is, however, not necessarily provably secure in a subgroup model. Elrond [15] uses a modified version of the multi-signature scheme MSP proposed in [8] for subgroup multi-signature. However, no security analysis is provided for their modified scheme. The unforgeability of the original MSP scheme [8] is proven based on a condition that each signer has a prior knowledge of all other entities that will definitely sign, which makes MSP unsuitable to be used as a subgroup multi-signatures. Technically this condition is crucial for defending against the notorious rogue-key attacks [27] and is guaranteed by hashing all the signers in the coefficients $a_i = H_1(\mathsf {pk}_i, \{\mathsf {pk}_1, \cdots , \mathsf {pk}_n\})$ during the signing process. In the security reduction of unforgeability, these coefficients enable the generalised forking lemma to output two different multi-signatures signed by the same set of signers after rewinding to the point where $a_i$ is chosen in order to extract the underlying secret key of the challenging signer. Elrond’s modified version breaks this condition by using the coefficients $a_i = H_1(\mathsf {pk}_i)$ instead which can no longer guarantee the signers are the same when using the generalised forking lemma, thus it cannot be proven secure using the techniques in [8]. Other consensus projects like [12, 16, 20] implement proof-of-possession (PoP) based multi-signatures MSP-pop originally proposed in [27], but MSP-pop has not yet been formalised and proven secure in a subgroup model.

Our contributions. We introduce robust subgroup multi-signature protocols, a multi-signature variant specially designed for consensus. We define robustness for multi-signatures, and present a rigorous definition of existential unforgeability for subgroup multi-signature protocols. The former evaluates the correctness of the signature combination algorithm in the presence of an adversary that may control a subset of the signers. As a side benefit of explicitly capturing the signature combination function, we are able to optimise the validation of individual signatures by using zero-knowledge proofs instead of time-consuming pairing operations, which improves upon the efficiency of signature combination algorithms of several existing multi-signatures. Regarding existential unforgeability, we point out that the previous syntax and security definitions for subgroup multi-signatures in [6] are incomplete and somewhat informal. This is undesirable from a scientific point of view, and in fact this lack of formality may explain why [6] presents a security proof for their construction while it is known to be insecure [8]. We believe that robust subgroup multi-signatures capture the variant of multi-signatures that best suits consensus applications.

We shall present four constructions of robust subgroup multi-signatures, i.e., $\mathsf {RSMSP},\mathsf {RSMSP}\text{- }\mathsf {zk}, \mathsf {RSMS}\text{- }\mathsf {pop}$ and $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ respectively. While $\mathsf {RSMS}\text{- }\mathsf {pop}$ is a natural adaption of MSP-pop scheme [27] to our subgroup model, the other three constructions $\mathsf {RSMSP},\mathsf {RSMSP}\text{- }\mathsf {zk}$ and $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ are new. Our $\mathsf {RSMSP}$ scheme is a twist to the MSP scheme [8]: the determination of the actual co-signers is deferred to the signature combination phase thanks to our explicit combine function, and we include the set of identities I of the co-signers in the hash values $a_i = H_2(\mathsf {pk}_i, I, \{\mathsf {pk}_1, \mathsf {pk}_2, \cdots , \mathsf {pk}_n\})$. This trick enables us to remove the restriction that the co-signers have to be fixed from the beginning. It also enables us to use the Generalised Forking Lemma to rewind the adversary to the point $a_i$ is generated and produce another multi-signature with the same set of cosigners I in order to prove existential unforgeability. The variants $\mathsf {RSMSP}\text{- }\mathsf {zk}$ (resp. $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$) optimise the combination of individual signatures in $\mathsf {RSMSP}$ (resp. $\mathsf {RSMS}\text{- }\mathsf {pop}$) by introducing NIZKs to validate individual signatures. Note that the combine function does not use any secret information and can be run by any entity, making it still a non-interactive process. Our experiments show that this optimisation makes the combination process 2x faster. Last but not least, by proving secure the construction $\mathsf {RSMS}\text{- }\mathsf {pop}$ using our refined subgroup multi-signature model, we provide the missing evidence that the multi-signatures protocols for consensus in [12, 16, 20] are indeed sound.

Related work. Sequential aggregate multi-signatures are studied in [7, 21, 22] where each signer modifies the aggregate signature in turn. Such signatures are suitable for applications like secure route attestation and ceritificate chains. Pixel [14] is a complex multi-signature scheme based on hierarchical identity-based encryption (HIBE), which involves a key update method in order to provide forward security. Plumo [16] implements a SNARK based validation for checking aggregated BLS signatures. Adhoc Threshold Multisignatures [17] extend pop-based multi-signatures with a Merkle tree commitment to validate the membership of the individual public keys.

Accountable-subgroup multi-signatures [8, 24] allow any subgroups to produce a multi-signature for a message in a provably secure way but involve an interactive key setup. This is mainly due to the requirement of not involving individual public keys for multi-signature verification. While this setting can be useful for some applications (e.g., multisig wallets with 2 or 3 addresses [2]), it is neither optimal nor flexible in general consensus setting. Indeed that would require validator nodes to run a joint setup phase which is expensive. In the decentralised consensus application, validator groups are formed ad hoc by the network nodes which are sparsely connected. An interactive key setup requires synchronisation among n participating nodes which is the top challenge for implementation of decentralised applications, especially when n is big, for example, Ethereum 2.0 requires a minimum of 128 validators for each committee. Moreover, the expensive interactive setup makes it difficult for nodes to join or leave dynamically. Therefore, we focus on non-interactive multi-signature schemes in this paper. The individual public keys are used in the verification of our multi-signatures but they are only stored in the blockchain once when nodes register themselves as validators.

2 Preliminaries

In this section we briefly recall some building blocks needed in the rest of the paper, such as the computational assumptions under which our constructions are proven secure, the equality of discrete logarithms proof system and the generalised forking lemma.

2.1 Bilinear Groups

Definition 1

(Asymmetric Pairing Groups). Let and $\mathbb {G}_T$ be (cyclic) groups of prime order q. A map $\mathbf {e}:\mathbb {G}_1\times \mathbb {G}_2\rightarrow \mathbb {G}_T$ to a group $\mathbb {G}_T$ is called a bilinear map, if it satisfies the following three properties:

• Bilinearity: $\mathbf {e}(g_1^x,g_2^y) = \mathbf {e}(g_1,g_2)^{xy}$ for all $x,y\in \mathbb {Z}_p$.

• Non-Degenerate: $\mathbf {e}(g_1,g_2)\ne 1$.

• Computable: $\mathbf {e}(g_1,g_2)$ can be efficiently computed.

We assume there exists an efficient bilinear pairing generator algorithm $\mathcal {IG}$ that on input a security parameter $1^\lambda$ outputs the description of $\left\langle \mathbf {e}(\cdot ,\cdot ),\mathbb {G}_1,\mathbb {G}_2,\mathbb {G}_T,q \right\rangle$.

Asymmetric pairing groups can be efficiently generated [18]. Pairing group exponentiations and pairing operations can also be efficiently computed [13].

2.2 Computational Assumptions

Definition 2

(Computational co-CDH assumption [8]). Let $X \leftarrow (\mathbb {G}_1, \mathbb {G}_2,q, g_1, g_2,g_1^\alpha , g_1^\beta , g_2^\alpha )$ where and are cyclic groups of prime order q, and $\alpha ,\beta {\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q^*$. We define the advantage $\mathbf {Adv}_{\mathcal {A}}^\mathrm{{co\texttt {-}CDH}}$ of an adversary $\mathcal {A}$ as

$$ \mathbf {Adv}_{\mathcal {A}}^\mathrm{{co\texttt {-}CDH}} := \mathrm {Pr}\left[ \mathcal {A}(X)=g_1^{\alpha \beta }\right] $$

We say $\mathcal {A}$ $(\tau , \epsilon )$-breaks the co-CDH problem if it runs in time at most $\tau$ and $\mathbf {Adv}_{\mathcal {A}}^\mathrm{{co\texttt {-}CDH}}\ge \epsilon$. co-CDH is $(\tau , \epsilon )$-hard if no such adversary exists.

Definition 3

(Computational $\psi$-co-CDH assumption [8]). Let $X \leftarrow (\mathbb {G}_1, \mathbb {G}_2, q, g_1, g_2, g_1^\alpha , g_1^\beta , g_2^\alpha )$ where and are cyclic groups of prime order q, and $\alpha , \beta {\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q^*$. Let $\mathcal {O}^\psi (\cdot )$ be an oracle that on input $g_2^\alpha \in \mathbb {G}_2$ returns $g_1^\alpha \in \mathbb {G}_1$. We define the advantage $\mathbf {Adv}_{\mathcal {A}}^{\psi \texttt {-}\mathrm {co\texttt {-}CDH}}$ of an adversary $\mathcal {A}$ as

$$ \mathbf {Adv}_{\mathcal {A}}^{\psi \texttt {-}\mathrm {co\texttt {-}CDH}}:= \mathrm {Pr}\left[ \mathcal {A}^{\mathcal {O}^\psi (\cdot )}(X)=g_1^{\alpha \beta }\right] $$

We say $\mathcal {A}$ $(\tau , \epsilon )$-breaks the $\psi$-co-CDH problem if it runs in time at most $\tau$ and $\mathbf {Adv}_{\mathcal {A}}^{\psi \texttt {-}\mathrm {co\texttt {-}CDH}}\ge \epsilon$. $\psi$-co-CDH is $(\tau , \epsilon )$-hard if no such adversary exists.

2.3 Equality of Discrete Logarithms

We need NIZK proof systems as an ingredient to our construction, namely the Equality of Discrete Logarithms proof system. Formally, given a cyclic group $\mathbb {G}$ of order q and $g,h\in \mathbb {G}$, the NIZK proof $(\mathsf {PrEq}_H,\mathsf {VerEq}_H)$ to show $k = \log _{g} x = \log _h y$ for $x,y\in \mathbb {G}$, $k \in \mathbb {Z}_q$ is described as below [11]:

• $\mathsf {PrEq}_H(g,h,x,y, k)$: choose $r{\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q$, compute $R_1=g^r, R_2= h^r$ and set $c \leftarrow H(g,h,x,y,R_1, R_2)$. Output is $(c, s=r+k\cdot c)$.

• $\mathsf {VerEq}_H(g,h,x,y, (c, s))$: compute $R_1\leftarrow g^{s}/x^{c}$ and $R_2 \leftarrow h^{s}/y^{c}$ and output $c {\mathop {=}\limits ^{?}} H(g,h, x,y, R_1,R_2)$.

The security of the above NIZK is random oracle (RO) based, rather than common reference string (CRS) based. CRS-based model assumes a trusted setup which embeds a secret trapdoor. The trapdoor, if known by any party, can be used to subvert the security of the system, which poses a challenge for decentralised applications. In contrast, our construction does not involve the generation of any trusted parameters. Moreover, the security of multi-signatures is based on RO-model, so it is natural to use RO-based model for NIZKs in our case.

2.4 Generalized Forking Lemma

The forking lemma [26] for proving the security of schemes based on Schnorr signatures was generalised to a wider class of schemes [3, 4]. Below we describe the version due to [3].

Consider an algorithm $\mathcal {A}$ that on input in interacts with a random oracle $H: \{0,1\}^*\mapsto \mathbb {Z}_q$. Let $f = (\rho , h_1, \dots , h_{q_H})$ be the randomness involved in an execution of $\mathcal {A}$, where $\rho$ is $\mathcal {A}$’s random tape, $h_i$ is the response to $\mathcal {A}$’s i-th query to H, and $q_H$ is its maximal number of random-oracle queries. Let $\varOmega$ be the space of all such vectors f and let $f|_i = (\rho , h_1, \dots , h_{i-1})$. We consider an execution of $\mathcal {A}$ on input in and randomness f, denoted by $\mathcal {A}({{ in}}, f)$, as successful if it outputs a pair $(J, \{{ out}_j\}_{j\in J})$, where J is a multi-set that is a non-empty subset of $\{1, \dots , q_H\}$ and $\{{ out}_j\}_{j\in J}$ is multi-set of side outputs. We say that $\mathcal {A}$ failed if it outputs $J=\emptyset$. Let p be the probability that $\mathcal {A}({ in}, f)$ is successful for fresh randomness $f{\mathop {\leftarrow }\limits ^{\$}}\varOmega$ and for an input ${ in}{\mathop {\leftarrow }\limits ^{\$}}\mathcal {IG}$ generated an input generator $\mathcal {IG}$.

For a given input in, the generalised forking algorithm $\mathcal {GF}$ is defined as shown in Fig. 1. We say that $\mathcal {GF}_\mathcal {A}$ succeeds if it doesn’t output $\mathtt {fail}$.

Fig. 1.

Algorithm $\mathcal {GF}$

Lemma 1

(Generalised Forking Lemma [3]). Let $\mathcal {IG}$ be a randomised algorithm and $\mathcal {A}$ be a randomised algorithm running in time $\tau$ making at most $q_H$ random-oracle queries that succeeds with probability $\epsilon$. If $q> 8nq_H/\epsilon$, then $\mathcal {GF}_\mathcal {A}({ in})$ runs in time at most $\tau \cdot 8n^2q_H/\epsilon \cdot \ln (8n/\epsilon )$ and succeeds with probability at least $\epsilon /8$, where the probability is over the choice of ${ in}{\mathop {\leftarrow }\limits ^{\$}}\mathcal {IG}$ and over the coins of $\mathcal {GF}_\mathcal {A}$.

3 Definitions of Robust Subgroup Multi-signatures

We now introduce syntax and security definitions for our robust subgroup multi-signatures. We describe a notion of robustness, a generalised notion of correctness, by allowing adversaries to participate in the signature combination process. Then we define unforgeability in a subgroup model where the adversary outputs a forgery $(J,\sigma ^\star )$ where J is a subset of indices of signers from a group $\mathcal {PK}$ chosen by the adversary and $\sigma ^\star$ is a multi-signature.

Definition 4

A robust subgroup multi-signature scheme ($\mathrm {RSMS}$) $\varPi = (\mathsf {KeyGen},\mathsf {KeyAgg},\mathsf {GroupSet}, \mathsf {Sign}, \mathsf {Combine}, \mathsf {VerifyMul})$ consists of the following algorithms:

• $\mathsf {KeyGen}(1^\lambda )$: this algorithm is used by each entity locally to output, on input a security parameter $\lambda$, their own key pair $(\mathsf {sk}, \mathsf {pk})$.

• $\mathsf {GroupSet}(\mathcal {PK})$: on input a set of public keys $\mathcal {PK}$, the algorithm forms a group and outputs a group public key $\mathsf {gpk}= (\mathsf {gtag}, \mathcal {PK})$, where $\mathsf {gtag}$ is a group tag that depends on the context where the subgroup multi-signature is used². When the algorithm fails to form the group, $\mathsf {gpk}= \bot$.

• $\mathsf {Sign}(m, \mathsf {sk}_i, \mathsf {pk}_i, \mathsf {gtag})$: on input a message m, a secret key $\mathsf {sk}_i$, a public key $\mathsf {pk}_i$, a group tag $\mathsf {gtag}$, the algorithm outputs an individual signature $s_i$.

• $\mathsf {Combine}(m, \mathcal {E}, \mathsf {gpk})$: on input a message, a set of individual signatures $\mathcal {E}= \{s_i\}_{i}$ created by $|\mathcal {E}|$ different signers, a group public key $\mathsf {gpk}$, the algorithm identifies an index set J of valid individual signatures and combines them into a single multi-signature $\sigma$ and outputs $(J,\sigma )$. When the algorithm fails to combine the individual signatures, $(J,\sigma ) = (\emptyset , \bot )$.

• $\mathsf {VerifyMul}(m, J, \sigma , \mathsf {gpk})$: on input a message m, an index set J, a group public key $\mathsf {gpk}$, the algorithm outputs 1 if $\sigma$ is a valid multi-signature and outputs 0 otherwise.

Sometimes we make use of the following auxiliary algorithm when describing particular instances:

• $\mathsf {KeyAgg}(J, \mathcal {PK})$: on input an index set J and a set of public keys $\mathcal {PK}$, this algorithm aggregates $\mathcal {PK}$ into a single aggregate public key $\mathsf {apk}$. Output $\mathsf {apk}$.

Definition 5

(Robustness). The robustness of a $\mathrm {RSMS}$ scheme $\varPi = (\mathsf {KeyGen}, \mathsf {GroupSet}, \mathsf {Sign}, \mathsf {Combine}, \mathsf {VerifyMul})$ is defined by a three-stage game:

• Setup. The challenger generates the system parameters $\mathsf {pp}$ and a challenge entity with key tuple $(\mathsf {sk}^\star ,\mathsf {pk}^\star )\leftarrow \mathsf {KeyGen}(1^\lambda )$. It gives $(\mathsf {pk}^\star , \mathsf {pp})$ to the adversary.

• Signature queries. $\mathcal {A}$ is allowed to make signature queries on any message m for any $\mathsf {gtag}$, meaning that it has access to oracle $\mathcal {O}^{\mathsf {Sign}(\cdot ,\mathsf {sk}^\star , \mathsf {pk}^\star , \cdot )}$ that simulates the honest signer signing a message m.

• Output. Finally, the challenger receives from the adversary a message $m^\star$ and a group public key $\mathsf {gpk}= (\mathsf {gtag}, \mathcal {PK}= \{\mathsf {pk}_i\}_{i\in U})$, and a set of individual signatures $\mathcal {E}= \{s_i\}_{i\in I}$ from |I| different entities such that $I\subseteq U$. The adversary wins if

  • 1. $\mathsf {pk}^\star = \mathsf {pk}_k$ for some $k\in U$ and $k\notin I$

  • 2. $\mathsf {gpk}\ne \bot$ and $\mathsf {gpk}= \mathsf {GroupSet}(\mathcal {PK})$

  • 3. $\mathsf {VerifyMul}(m^\star , J, \sigma ^\star , \mathsf {gpk}) = 0$, where $s^\star \leftarrow \mathsf {Sign}(m^\star , \mathsf {sk}^\star , \mathsf {pk}^\star ,\mathsf {gtag})$ and $(J,\sigma ^\star )\leftarrow \mathsf {Combine}(m^\star ,\mathcal {E}\cup \{s^\star \}, \mathsf {gpk})$.

We say $\mathcal {A}$ $(\tau , q_S, q_H, \epsilon )$-breaks the robustness of $\mathrm {RSMS}$ if $\mathcal {A}$ runs in time at most $\tau$, makes at most $q_S$ signing queries and at most $q_H$ random oracle queries, and the above game outputs 1 with probability at least $\epsilon$. $\mathrm {RSMS}$ is $(\tau , q_S, q_H, \epsilon )$-robust if no such adversary exists.

In the above definition, the challenger controls an honest signer $(\mathsf {sk}^\star , \mathsf {pk}^\star )$, while the adversary controls all other signers and is given access to the signing oracle for $\mathsf {sk}^\star$ to maximise its attacking capabilities. In the Output phase, the adversary forms and submits a group $\mathcal {PK}$ which consists of the honest signer $\mathsf {pk}^\star$ generated by the challenger and other signers generated by the adversary. The signatures $\mathcal {E}$ created by the adversary are combined with the signature $s^\star$ from the honest signer. Robustness demands that the output of the $\mathsf {Combine}$ function is a valid multi-signature in the presence of the adversary’s inputs.

Definition 6

(Unforgeability). The unforgeability of a $\mathrm {RSMS}$ scheme $\varPi = (\mathsf {KeyGen},\mathsf {GroupSet}, \mathsf {Sign}, \mathsf {Combine}, \mathsf {VerifyMul})$ is defined by a three-stage game:

• Setup. The challenger generates the system parameters $\mathsf {pp}$ and a challenge key pair $(\mathsf {sk}^\star ,\mathsf {pk}^\star )\leftarrow \mathsf {KeyGen}(1^\lambda )$. It gives $(\mathsf {pk}^\star , \mathsf {pp})$ to the adversary.

• Signature queries. $\mathcal {A}$ is allowed to make signature queries on any message m for any group tag $\mathsf {gtag}$, meaning that it has access to oracle $\mathcal {O}^{\mathsf {Sign}(\cdot , \mathsf {sk}^\star , \mathsf {pk}^\star , \cdot )}$ that simulates the honest signer signing a message m.

• Output. Finally, the adversary outputs a multi-signature forgery $(J, \sigma ^\star )$, a message $m^\star$, a group public key $\mathsf {gpk}= (\mathsf {gtag}^\star , \mathcal {PK}= \{\mathsf {pk}_i\}_{i\in U})$. The adversary wins if

  • 1. $\mathsf {gpk}\ne \bot$ and $\mathsf {gpk}= \mathsf {GroupSet}(\mathcal {PK})$

  • 2. $\mathsf {pk}^\star = \mathsf {pk}_k$ for some $k\in U\cap J$

  • 3. $\mathcal {A}$ made no signing queries on $(m^\star , \mathsf {gtag}^\star )$ and $\mathsf {VerifyMul}(m^\star , J, \sigma ^\star , \mathsf {gpk})= 1$

We say $\mathcal {A}$ is a $(\tau , q_S, q_H, \epsilon )$-forger for $\mathrm {RSMS}$ if $\mathcal {A}$ runs in time at most $\tau$, makes at most $q_S$ signing queries and at most $q_H$ random oracle queries, and wins the above game with probability at least $\epsilon$. $\mathrm {RSMS}$ is $(\tau , q_S, q_H, \epsilon )$-unforgeable if no such adversary exists.

Remark 1

(On including an explicit tag $\mathsf {gtag}$ when signing). Our unforgeability definition lets the adversary query the signing oracle $\mathcal {O}^{\mathsf {Sign}(\cdot , \mathsf {sk}^\star , \mathsf {pk}^\star , \cdot )}$ on the forged message $m^\star$ as long as it is queried on tags $\mathsf {gtag}\ne \mathsf {gtag}^\star$. We think that given the current trend of multi-chain frameworks, where the same signing key pair $(\mathsf {pk},\mathsf {sk})$ may be used to validate consensus simultaneously in different chains, embedding contextual information in the form of a tag $\mathsf {gtag}$ when signing, is of material importance given security issues with rogue key attacks and aggregation in a multi-chain setting are potentially more likely.

4 Our Pairing-Based Robust-Subgroup Multi-signature Scheme

Generally speaking, the major technical problem in constructing a secure multi-signature scheme is to prevent the rogue-key attack [23, 27] which enables an adversary to use a specially crafted public key to deprive all other entities of their signing right. We consider two ways to prevent rogue-key attacks for our robust subgroup multi-signatures: one is using techniques proposed in [8, 23] to combine individual signatures with hash values derived from the related public keys; the other way is called the proof-of-possession [8, 27] which introduces an additional public key $H(\mathsf {pk}_i)^{\mathsf {sk}_i}$ to show the knowledge of the secret key $\mathsf {sk}_i$. Moreover, we optimise the $\mathsf {Combine}$ process by introducing NIZKs to validate individual signatures to replace the checking based on time-consuming pairing equations. This optimisation can make the signature combination process x2 faster.

In this section, we present four constructions of robust-subgroup multi-signatures: $\mathsf {RSMSP}$ and its optimised version $\mathsf {RSMSP}\text{- }\mathsf {zk}$, and $\mathsf {RSMS}\text{- }\mathsf {pop}$ and its optimised version $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$.

4.1 Construction of $\mathsf {RSMSP}$

Our $\mathsf {RSMSP}$ is constructed based on $\mathsf {MSP}$ scheme proposed in [8]. As mentioned in the introduction, $\mathsf {MSP}$ in [8] cannot be used as a subgroup multi-signature scheme in the provably secure sense. Here we propose a twist to $\mathsf {MSP}$ in order to construct a secure robust-subgroup multi-signature: we defer the determination of the actual co-signers to the combine phase thanks to the explicit introduction of the $\mathsf {Combine}$ function in our robust subgroup multi-signature scheme, and we include the identities of the subset of co-signers in the hash values $H_2(\mathsf {pk}_j, J, \mathcal {PK})$ generated for each co-signer j. In the security proof, this twist allows us to determine the co-signers at the moment when the hash value $c_{j_f} = H_2(\mathsf {pk}^\star , J, \mathcal {PK})$ is generated so that we can use the generalised forking lemma to rewind the adversary to this point and produce another multi-signature with the same set of cosigners J in order to extract the underlying secret key $\mathsf {sk}^\star$ of $\mathsf {pk}^\star$. Note that the $\mathsf {Combine}$ function does not use any secret information and can be run by any entity, making it still a non-interactive process.

Construction of $\mathsf {RSMSP}$. Let $(q,\mathbb {G}_1, \mathbb {G}_2, \mathbb {G}_T,e, g_1, g_2)$ be a bilinear group with prime order q and $g_1\in \mathbb {G}_1, g_2\in \mathbb {G}_2$. Assume hash functions $H_1: \{0,1\}^*\mapsto \mathbb {Z}_q$, $H_2: \{0,1\}^* \mapsto \mathbb {G}_1$ and $H_3: \{0,1\}^*\mapsto \mathbb {G}_1$.

• $\mathsf {KeyGen}(1^\lambda )$: Choose $\mathsf {sk}{\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q$, compute $\mathsf {pk}= g_2^{\mathsf {sk}}$, and output $(\mathsf {sk}, \mathsf {pk})$. The public key $\mathsf {pk}$ is made public.

• $\mathsf {GroupSet}(\mathcal {PK})$: Compute $\mathsf {gtag}= H_1(\mathcal {PK})$. Output $\mathsf {gpk}= (\mathsf {gtag}, \mathcal {PK})$.

• $\mathsf {KeyAgg}(J, \mathcal {PK})$: Parse $\mathcal {PK}= \{\mathsf {pk}_i\}_{i\in I}$. Output $\bot$ if $J\not \subseteq I$. Compute $a_j = H_2(\mathsf {pk}_j, J, \mathcal {PK})$ for each $j\in J$. Output $\mathsf {apk}= \prod _{j\in J} \mathsf {pk}_j^{a_j}$.

• $\mathsf {Sign}(m, \mathsf {sk}_i, \mathsf {gtag})$: Output an individual signature $s_i = H_3(\mathsf {gtag},m)^{\mathsf {sk}_i}$.

• $\mathsf {Combine}(m, \mathcal {E}, \mathsf {gpk})$: Parse $\mathcal {E}= \{s_i\}_{i\in I}$ of individual signatures originating from |I| different entities, and $\mathsf {gpk}= (\mathsf {gtag}, \mathcal {PK})$. The combiner verifies each signature by checking $e(s_i, g_2) = e(H_3(\mathsf {gtag}, m), \mathsf {pk}_i)$. Assume the index set of valid signatures is $J\subseteq I$. The combiner computes the multi-signature as $\sigma = \prod _{j\in J} s_j^{a_j}$ with $a_j = H_2(\mathsf {pk}_j, J, \mathcal {PK})$ for $j\in J$. Output $(J,\sigma )$.

• $\mathsf {VerifyMul}(m, J, \sigma , \mathsf {gpk})$: Parse $\mathsf {gpk}= (\mathsf {gtag},\{\mathsf {pk}_i\}_{i\in I})$. If $J=\emptyset$ or $J\not \subseteq I$, then output 0. Otherwise, compute $\mathsf {apk}\leftarrow \mathsf {KeyAgg}(J, \mathcal {PK})$. Output 1 if $e(\sigma , g_2) = e(H_3(\mathsf {gtag}, m), \mathsf {apk})$; else output 0.

Remark 2

Note that when hashing the message m in the signing algorithm, it is a good practice to include the unique group tag $\mathsf {gtag}$ in the hash function $H_1(\mathsf {gtag}, m)$ since the same node may be able to join different committee groups at the same time using the same public key (e.g., [19]). In this way, in the security definition of unforgeability, the adversary is allowed to issue signing query on different combinations $(m^\star , \cdot )$ and $(\cdot , \mathsf {gtag}^\star )$ of the challenge message and the challenge group tag as long as it does not query $(m^\star , \mathsf {gtag}^\star )$.

Batch verification. As usual, n multi-signatures on n-distinct pairs of $(\mathsf {gtag}, m)$ can be verified as a batch faster than verifying them one by one:

• Compute an aggregate multi-signature $\varSigma = \sigma _1\cdots \sigma _n \in \mathbb {G}_1$

• Accept all n multisignatures as valid iff

  $$ e(\varSigma _n, g_2) = \prod _{1\le i\le n} e(H_3(\mathsf {gtag}_i, m_i), \mathsf {apk}_i) $$

Theorem 1

$\mathsf {RSMSP}$ is robust.

Proof

Suppose there exists an adversary $\mathcal {A}$ that $(\tau , q_S, q_H, \epsilon )$-breaks robustness of $\mathsf {RSMSP}$. We will show that this leads to a contradiction. At the end of the robustness game, the adversary outputs $(m^\star , \mathsf {gpk}= (\mathsf {gtag}^\star , \mathcal {PK}= \{\mathsf {pk}_i\}_{i\in U}), \mathcal {E}= \{s_i\}_{i\in I})$ with $\mathsf {pk}^\star = \mathsf {pk}_k$ for some $k\in U$. When the challenger outputs 1, we know that $e(\sigma ^\star , g_2) \ne e(H_3(\mathsf {gtag}^\star , m^\star ), \mathsf {apk})$ where $s \leftarrow \mathsf {Sign}(m^\star , \mathsf {sk}^\star , \mathsf {pk}^\star ,\mathsf {gtag}^\star )$, $(J,\sigma ^\star )\leftarrow \mathsf {Combine}(m^\star , \mathcal {E}\cup \{s\}, \mathsf {gpk})$ and $\mathsf {apk}\leftarrow \mathsf {KeyAgg}(J,\mathcal {PK})$. Thus there exists $j\in J$ such that $e(s_j, g_2) \ne e(H_3(\mathsf {gtag}^\star , m^\star ),\mathsf {pk}_j)$. We consider two cases. If $j = k$, then this is impossible because $s_j = H_3(\mathsf {gtag}^\star , m^\star )^{\mathsf {sk}^\star }$ and $\mathsf {pk}_j = g_2^{\mathsf {sk}^\star }$. If $j\ne k$, this directly contradicts to the verification $e(s_j, g_2) = e(H_3(\mathsf {gtag}^\star , m^\star ), \mathsf {pk}_j)$ performed in the $\mathsf {Combine}$ process. This completes the proof.

Theorem 2

$\mathsf {RSMSP}$ is unforgeable under the computational co-CDH assumption in the random oracle model. Formally, $\mathsf {RSMSP}$ is $(\tau , q_S, q_H, \epsilon )$-unforgeable if $q>8q_H/\epsilon$ and co-CDH is $((\tau + (q_H + q_S) \cdot \tau _{\exp _1} + \ell \cdot \tau _{\exp _2}) \cdot 8 q^2_H/\epsilon \cdot \ln (8q_H/\epsilon ), \epsilon /(8q_H))$-hard where $\ell$ is the maximum number of signers involved in a single multi-signature and $\tau _{\exp _1}$ is the time required to compute one exponentiation in $\mathbb {G}_1$.

Proof

Suppose $\mathcal {A}$ is a $(\tau , q_S, q_H, \epsilon )$ forger against $\mathsf {RSMSP}$. We shall first construct an adversary $\mathcal {B}$ using $\mathcal {A}$ as a subroutine and then construct another adversary $\mathcal {F}$ to run $\mathcal {GF}_\mathcal {B}$ to derive a solution to the co-CDH instance.

Given a co-CDH instance $(e, \mathbb {G}_1, \mathbb {G}_2, \mathbb {G}_T,q, g_1, g_2, g_1^\alpha , g_1^\beta , g_2^{\beta })$ with $g_1\in \mathbb {G}_1, g_2\in \mathbb {G}_2$, $\alpha , \beta {\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q$. The goal is to find the solution $g_1^{\alpha \beta }$ to the instance. We first construct $\mathcal {B}$ to run $\mathcal {A}$ as follows:

• 1. Give to $\mathcal {A}$ the public parameters $(e, \mathbb {G}_1,\mathbb {G}_2, \mathbb {G}_T, q, g_1, g_2)$ and the challenge public key $\mathsf {pk}^\star = g_2^\beta$ as input. $\mathcal {B}$ runs $\mathcal {A}$ on randomness $f = (\rho , c_1, \cdots , c_{q_H})$.

• 2. The random oracle $H_1$ is answered as follows: initialise a list ${\mathcal L}_{H_1} = \emptyset$. For a query on y, if there exists $(y,c)\in {\mathcal L}_{H_1}$ then output c; otherwise choose a random $c{\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q$, update ${\mathcal L}_{H_1} = {\mathcal L}_{H_1}\cup \{(y,c)\}$ and output c.

• 3. The random oracle $H_2$ is programmed as follows: Define a list ${\mathcal L}_{H_2}= \emptyset$. For a query on y, if there exists $(y, c)\in {\mathcal L}_{H_2}$, then output c; otherwise

  • (a) If $y = (\mathsf {pk}, J, \mathcal {PK})$ with $\mathsf {pk}\in \mathcal {PK}$ and $\mathsf {pk}^\star \in \mathcal {PK}$, assume this is the i-th query to $H_2$. For each $j\in J$ and $\mathsf {pk}_j\ne \mathsf {pk}^\star$, choose a random value $d_j{\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q$ and set $H_2(\mathsf {pk}_j, J, \mathcal {PK}) = d_j$. For $(\mathsf {pk}^\star , J, \mathcal {PK})$, it fixes $H_2(\mathsf {pk}^\star , J, \mathcal {PK}) = c_i$. Output $H_2(y)$.

  • (b) Else choose a random $d{\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q$ and set $H_2(y) = d$. Output d.

• 4. The random oracle $H_3$ is answered as follows: initialise ${\mathcal L}_{H_3} = \emptyset$. Let $q_{H}$ be the total number of distinct random oracle queries asked in this game. Choose an index $\eta ^\star {\mathop {\leftarrow }\limits ^{\$}}[q_{H}]$ uniformly at random.

  • If there exists a tuple $(x, r, h)\in {\mathcal L}_{H_3}$, output h.

  • Otherwise,

    • If this is the $\eta ^\star$-th distinct call, set $r = \bot$ and $h = g_1^\alpha$ where $g_1^\alpha$ is from the co-CDH problem.

    • Else choose a random $r{\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q$ and set $h = g_1^r$.

    • Update ${\mathcal L}_{H_3} = {\mathcal L}_{H_3}\cup (x, r, h)$ and output h.

• 5. To answer the sign query $\mathsf {Sign}(\cdot , \mathsf {sk}^\star , \mathsf {pk}^\star , \cdot )$ on a message x, call the $H_3$ oracle to obtain $(x,r,h)\in {\mathcal L}_{H_3}$,

  • If $r = \bot$, return $\bot$

  • Else output $g_1^{\beta \cdot r}$

Finally $\mathcal {A}$ outputs a forgery $(J, \sigma ^\star )$, a message $m^\star$, a group public key $\mathsf {gpk}= (\mathsf {gtag}^\star , \mathcal {PK})$. If $(\mathsf {gtag}^\star , m^\star )$ is not the $\eta ^\star$-th query to $H_3$, then $\mathcal {B}$ aborts. Since $\eta ^\star$ is randomly chosen, the probability that $\mathcal {B}$ does not abort is $1/q_{H}$. Let’s assume $\mathcal {B}$ does not abort. Parse $\mathcal {PK}= \{\mathsf {pk}_1, \dots , \mathsf {pk}_n\}$. Suppose $\mathsf {pk}^\star = \mathsf {pk}_k$ for some $1\le k\le n$. Let $j_f$ be the index such that $H_1(\mathsf {pk}^\star , J, \mathcal {PK}) = c_{j_f}$. Let $\mathsf {apk}\leftarrow \mathsf {KeyAgg}(J, \mathcal {PK})$ and $a_j = H_2(\mathsf {pk}_j, J, \mathcal {PK})$ for each $j\in J$. $\mathcal {B}$ outputs $(\{j_f\}, \{(\sigma ^\star , \mathcal {PK}, J, \mathsf {apk}, \{a_j\}_{j\in J})\})$.

The running time of $\mathcal {B}$ is that of $\mathcal {A}$ plus the additional computations that $\mathcal {B}$ makes. Let $\tau _{\exp _1}$ (resp. $\tau _{\exp _2}$) be the time required to compute one exponentiation in $\mathbb {G}_1$ (resp. $\mathbb {G}_2$). Let $q_{H}$ be the combined number of random oracle queries to $H_1, H_2, H_3$. To answer $q_H$ random oracle queries, $\mathcal {B}$ spends at most $q_H \cdot \tau _{\exp _1}$ time. To answer the signing queries, $\mathcal {B}$ spends at most $q_S \cdot \tau _{\exp _1}$ time. To construct $\mathsf {apk}$, it takes $\ell \cdot \tau _{\exp _2}$ time where $\ell$ is the maximum number of signers involved in a single multi-signature. In total, $\mathcal {B}$’s running time is therefore $\tau + (q_H + q_S) \cdot \tau _{\exp _1} + \ell \cdot \tau _{\exp _2}$. $\mathcal {B}$’s success rate $\epsilon _\mathcal {B}$ is the probability that $\mathcal {A}$ succeeds and that $\mathcal {B}$ correctly guesses the hash index of $\mathcal {A}$’s forgery, thus $\epsilon _\mathcal {B}= \epsilon /q_H$.

Now we construct another adversary $\mathcal {F}$ that on input a co-CDH instance and a forger $\mathcal {A}$, outputs a solution to the co-CDH instance. $\mathcal {F}$ runs the generalised forking lemma $\mathcal {GF}_\mathcal {B}$ with algorithm $\mathcal {B}$ constructed above. If $\mathcal {GF}_\mathcal {B}$ outputs $(\{j_f\}, \{out\}, \{out'\})$, then $\mathcal {B}$ proceeds as follows. $\mathcal {B}$ parses $out = (\sigma , \mathcal {PK}, J, \mathsf {apk},\{a_j\}_{j\in J})$ and $out' = (\sigma ', \mathcal {PK}', J', \mathsf {apk}', \{a'_j\}_{j\in J'})$. Let K be the index of $\mathsf {pk}^\star$ in $\mathcal {PK}$. Then we know $a_k = c_{j_f}$ and $a'_k = c'_{j_f}$ and $a_k\ne a'_k$. Since $out, out'$ are obtained from two executions of $\mathcal {B}$ with randomness $f, f'$ such that $f\mid _{j_f} = f'\mid _{j_f}$, we can derive that $\mathcal {PK}= \mathcal {PK}', J = J'$ and $a_j = a'_j$ for $j\in J\setminus \{k\}$. Therefore we have $\mathsf {apk}/\mathsf {apk}' = g_2^{\beta (a_k-a'_k)}$. Since $\mathcal {B}$’s output satisfies $e(\sigma , g_2) = e(g_1^\alpha , \mathsf {apk})$ and $e(\sigma ', g_2) = e(g_1^\alpha , \mathsf {apk}')$, we can compute $(\sigma /\sigma ')^{1/(a_k - a'_k)}$ as a solution to the co-CDH instance.

Using the generalised forking lemma, if $q > 8q_H/\epsilon$, $\mathcal {F}$ runs in time at most $(\tau + (q_H + q_S) \cdot \tau _{\exp _1} + \ell \cdot \tau _{\exp _2}) \cdot 8 q^2_H/\epsilon \cdot \ln (8q_H/\epsilon )$ and succeeds with probability at least $\epsilon /(8q_H)$.

4.2 Optimising $\mathsf {RSMSP}$ with NIZKs

We can use NIZKs validate individual signatures in order to speed up the verification of individual signatures in the $\mathsf {Combine}$ function in $\mathsf {RSMSP}$. We call this optimised scheme $\mathsf {RSMSP}\text{- }\mathsf {zk}$.

Construction of $\mathsf {RSMSP}\text{- }\mathsf {zk}$. The algorithms $\mathsf {KeyGen}, \mathsf {GroupSet},\mathsf {KeyAgg}$ and $\mathsf {VerifyMul}$ are implemented exactly the same as $\mathsf {RSMSP}$, but the algorithms $\mathsf {Sign}$ and $\mathsf {Combine}$ are optimised as below:

• $\mathsf {Sign}(m, \mathsf {sk}_i, \mathsf {gtag})$: Output $s_i = (v_i, \pi _i)$ where $v_i = H_3(\mathsf {gtag}, m)^{\mathsf {sk}_i}$ and $\pi _i \leftarrow \mathsf {PrEq}_{H_4}(g_2,H_3(\mathsf {gtag}, m),\mathsf {pk}_i,v_i; r)$ for randomness $r{\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q$.

• $\mathsf {Combine}(m, \mathcal {E}, \mathsf {gpk})$: Parse $\mathcal {E}= \{(v_i,\pi _i)\}_{i\in I}$ of individual signatures originating from |I| different entities, and $\mathsf {gpk}= (\mathsf {gtag}, \mathcal {PK})$. The combiner verifies each signature by checking $\mathsf {VerEq}_{H_4}((g_2, H_3(\mathsf {gtag}, m), \mathsf {pk}_i, v_i,\pi _i)=1$. Assume the index set of valid signatures is $J\subseteq I$. The combiner computes the multi-signature as $\sigma = \prod _{j\in J} v_j^{a_j}$ with $a_j = H_2(\mathsf {pk}_j, J, \mathcal {PK})$ for $j\in J$. Output $(J,\sigma )$.

Theorem 3

$\mathsf {RSMSP}\text{- }\mathsf {zk}$ is robust in the random oracle model.

Theorem 4

$\mathsf {RSMSP}\text{- }\mathsf {zk}$ is unforgeable under the computational co-CDH assumption in the random oracle model. Formally, $\mathsf {RSMSP}\text{- }\mathsf {zk}$ is $(\tau , q_S, q_H, \epsilon )$-unforgeable if $q>8q_H/\epsilon$ and co-CDH is $(\tau + (q_H + 3q_S)\cdot \tau _{\exp _1} + (2q_S + \ell )\cdot \tau _{\exp _2}) \cdot 8 q^2_H/\epsilon \cdot \ln (8q_H/\epsilon ), \epsilon /(8q_H))$-hard where $\ell$ is the maximum number of signers involved in a single multi-signature and $\tau _{\exp _1}$ (resp. $\tau _{\exp _2}$) is the time required to compute one exponentiation in $\mathbb {G}_1$ (resp. $\mathbb {G}_2$).

Proof

The analysis is similar to Theorem 2 except that the $\mathsf {Sign}$ queries are answered with simulated NIZKs generated by an additional random oracle $H_4: \{0,1\}^*\mapsto \mathbb {Z}_q$:

• The random oracle $H_4$ is programmed as follows: Define a list ${\mathcal L}_{H_4}= \emptyset$. For a query on y, if $(y,c)\in {\mathcal L}_{H_4}$, then output c. Otherwise choose a random $c{\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q$, update the list ${\mathcal L}_{H_4} = {\mathcal L}_{H_4}\cup (y,c)$ and output c.

• To answer the sign query $\mathsf {Sign}(\cdot , \mathsf {sk}^\star , \mathsf {pk}^\star , \cdot )$ on a message x, call the $H_3$ oracle to obtain $(x,r,h)\in {\mathcal L}_{H_3}$,

  • If $r = \bot$, return $\bot$

  • Else output $g_1^{\beta \cdot r}$ and a simulated NIZK proof $\pi$ using the random oracle $H_4$

To compute a simulated NIZK proof, it costs $\mathcal {B}$ $2(\tau _{\exp _1} + \tau _{\exp _2})$ time. Adding the time $\tau _{\exp _1}$ for computing each signature, $\mathcal {B}$ spends at most $q_S\cdot (3\tau _{\exp _1} + 2\tau _{\exp _2})$ time to answer all the signing queries. In total $\mathcal {B}$’s running time is at most $\tau + (q_H + 3q_S)\cdot \tau _{\exp _1} + (2q_S + \ell )\cdot \tau _{\exp _2}$ and success rate is $\epsilon /q_H$. The running time of the adversary $\mathcal {F}$ that runs $\mathcal {GF}_\mathcal {B}$ is $(\tau + (q_H + 3q_S)\cdot \tau _{\exp _1} + (2q_S + \ell )\cdot \tau _{\exp _2}) \cdot 8 q^2_H/\epsilon \cdot \ln (8q_H/\epsilon )$ and succeeds with probability at least $\epsilon /(8q_H)$.

4.3 Construction of $\mathsf {RSMS}\text{- }\mathsf {pop}$ from Proof-of-possession

In proof-of-possession (PoP) based multi-signatures, an additional public key is generated as a proof of knowledge of the secret key. Obviously the disadvantage of using PoPs is the extra storage and computation overhead introduced by the PoPs. However, PoPs offer a few competitive advantages as well. The aggregation of signatures and public keys in PoPs are simply multiplications without any exponentiation. The security argument of PoPs does not require the generalised forking lemma which gives much tighter reductions. Constructing secure robust-subgroup multi-signatures from PoPs [8, 27] turns out to be quite straightforward, since security reductions of PoPs do not require to fix the set of co-signers. For the completeness of this work, we describe the construction of $\mathsf {RSMS}\text{- }\mathsf {pop}$ and give security proofs below.

Construction of $\mathsf {RSMS}\text{- }\mathsf {pop}$. Let $(q,\mathbb {G}_1, \mathbb {G}_2, \mathbb {G}_T,e, g_1, g_2)$ be a bilinear group with prime order q and $g_1\in \mathbb {G}_1, g_2\in \mathbb {G}_2$. Assume hash functions $H_1: \mathbb {G}_2\mapsto \mathbb {G}_1$, $H_2: \{0,1\}^*\mapsto \mathbb {Z}_q$, $H_3: \{0,1\}^*\mapsto \mathbb {G}_1$.

• $\mathsf {KeyGen}(1^\lambda )$: Choose $\mathsf {sk}{\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q$, compute $\mathsf {pk}= (pk, pop)$ with $pk = g_2^\mathsf {sk}$ and $pop = H_1(pk)^\mathsf {sk}$, and output $(\mathsf {sk},\mathsf {pk})$. The public key $\mathsf {pk}$ is made public and its validity can be checked by $e(pop, g_2) = e(H_1(pk), pk)$.

• $\mathsf {GroupSet}(\mathcal {PK})$: Parse $\mathcal {PK}= \{(pk_i,pop_i)\}_{i\in I}$. For each $i\in I$, check if $e(pop_i, g_2) = e(H_1(pk_i),pk_i)$. If all successful, compute $\mathsf {gtag}= H_2(\mathcal {PK})$ and output $\mathsf {gpk}= (\mathsf {gtag}, \mathcal {PK})$; else output $\bot$.

• $\mathsf {KeyAgg}(J, \mathcal {PK})$: Parse $\mathcal {PK}= \{(pk_{i}, pop_{i} )\}_{i\in I}$. If $J\not \subseteq I$, then output $\bot$. Compute and output $\mathsf {apk}= \prod _{j\in J} pk_{j}$.

• $\mathsf {Sign}(m, \mathsf {sk}_i, \mathsf {pk}_i, \mathsf {gtag})$: Output signature $s_i = H_3(\mathsf {gtag}, m)^{\mathsf {sk}_i}$.

• $\mathsf {Combine}(m, \mathcal {E}, \mathsf {gpk})$: Parse $\mathsf {gpk}= (\mathsf {gtag},\{\mathsf {pk}_i\}_{i\in U})$ and the set $\mathcal {E}= \{s_i\}_{i\in I}$ of individual signatures originating from |I| different entities such that $I\subseteq U$. The combiner verifies each signature in $\mathcal {E}$ by checking $e(s_i, g_2)= e(H_3(\mathsf {gtag},m), pk_i)$ where $\mathsf {pk}_i = (pk_i, pop)$. Assume the index set of valid signatures is $J\subseteq I$. The combiner computes the multi-signature as $\sigma = \prod _{j\in J} \sigma _j$ and outputs $(J,\sigma )$.

• $\mathsf {VerifyMul}(m, J, \sigma , \mathsf {gpk})$: Parse $\mathsf {gpk}= (\mathsf {gtag},\mathcal {PK}= \{\mathsf {pk}_i\}_{i\in I})$. If $J=\emptyset$ or $J\not \subseteq I$, then output 0. Otherwise, compute $\mathsf {apk}\leftarrow \mathsf {KeyAgg}(J, \mathcal {PK})$. Output 1 if $e(\sigma , g_2) = e(H_3(\mathsf {gtag}, m), \mathsf {apk})$; else output 0.

Theorem 5

$\mathsf {RSMS}\text{- }\mathsf {pop}$ is robust.

Proof

Suppose there exists an adversary $\mathcal {A}$ $(\tau , q_S, q_H, \epsilon )$-breaks robustness. We will show that this leads to a contradiction. At the end of the robustness game, the adversary outputs $(m^\star , \mathsf {gpk}= (\mathsf {gtag}^\star , \mathcal {PK}= \{\mathsf {pk}_i\}_{i\in U}), \mathcal {E}= \{s_i\}_{i\in I})$ with $\mathsf {pk}_i = (pk_i, pop_i)$ for each $i\in U$ and $\mathsf {pk}^\star = \mathsf {pk}_k$ for some $k\in U$. When the challenger outputs 1, we know $e(\sigma ^\star , g_2) \ne e(H_3(\mathsf {gtag}^\star , m^\star ), \prod _{j\in J\cup \{k\}} pk_j)$ where $s\leftarrow \mathsf {Sign}(m^\star , \mathsf {sk}^\star , \mathsf {pk}^\star , \mathsf {gtag}^\star )$, $(J,\sigma ^\star )\leftarrow \mathsf {Combine}(m^\star , \mathcal {E}\cup \{s\}, \mathsf {gpk}^\star )$. This means there exists $j\in J$ such that $e(s_j, g_2) \ne e(H_3(\mathsf {gtag}^\star , m^\star ), pk_j)$ and $\mathsf {pk}_j = (pk_j, pop_j)$. This contradicts to the fact that all the individual signatures with indices included in $J^\star$ satisfy $e(s_j, g_2) = e(H_3(\mathsf {gtag}^\star , m^\star ), pk_j)$ for $j\in J$.

Theorem 6

$\mathsf {RSMS}\text{- }\mathsf {pop}$ is unforgeable under the computational co-CDH assumption in the random oracle model. Formally, $\mathsf {RSMS}\text{- }\mathsf {pop}$ is $(\tau , q_S, q_H, \epsilon )$-unforgeable if co-CDH is $(\tau + (q_H + q_S + \ell )\cdot \tau _{\exp _1}, \epsilon /q_H)$-hard where $\ell$ is the maximum number of signers involved in a single multi-signature and $\tau _{\exp _1}$ is the time required to compute one exponentiation in $\mathbb {G}_1$.

Proof

Given a co-CDH problem $(e, \mathbb {G}_1, \mathbb {G}_2, \mathbb {G}_T, q, g_1, g_2, g_1^\alpha , g_1^\beta , g_2^{\beta })$ with $g_1\in \mathbb {G}_1, g_2\in \mathbb {G}_2$, $\alpha , \beta {\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q$. $\mathcal {B}$’s goal is to output $g_1^{\alpha \beta }$:

• 1. Give to $\mathcal {A}$ the public parameters $(e, \mathbb {G}_1, \mathbb {G}_2,\mathbb {G}_T, q, g_1, g_2)$, the challenge public key $\mathsf {pk}^\star = (pk^\star , pop^\star )$ where $pk^\star = g_2^\beta$ and $pop^\star = g_1^{\beta \cdot r^\star }$ with $r^\star {\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_p$.

• 2. The random oracle $H_1$ is answered as follows: initialise a list ${\mathcal L}_{H_1} = \emptyset$.

  • If there exists a tuple $(x, r, h)\in {\mathcal L}_{H_1}$, output h.

  • Otherwise,

    • If $x = pk^\star$, set $h = g_1^{r^\star }$ and update ${\mathcal L}_{H_1} = {\mathcal L}_{H_1}\cup (x, r^\star , h)$ and output h.

    • Else choose a random $r{\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q$ and set $h = g_1^{\alpha \cdot r}$ where $g_1^\alpha$ is from the co-CDH problem, update ${\mathcal L}_{H_1} = {\mathcal L}_{H_1}\cup (x, r, h)$ and output h.

• 3. The random oracle $H_2$ is programmed as follows: Define a list ${\mathcal L}_{H_2}= \emptyset$. For a query on y, if $(y,c)\in {\mathcal L}_{H_2}$, then output c. Otherwise choose a random $c{\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q$, update the list ${\mathcal L}_{H_2} = {\mathcal L}_{H_2}\cup (y,c)$ and output c.

• 4. The random oracle $H_3$ is answered as follows: initialise ${\mathcal L}_{H_3} = \emptyset$. Let $q_{H_3}$ be the total number of distinct random oracle queries asked in this game. Choose an index $\eta ^\star {\mathop {\leftarrow }\limits ^{\$}}[q_{H_3}]$ uniformly at random.

  • If there exists a tuple $(x, r, h)\in {\mathcal L}_{H_3}$, output h.

  • Otherwise,

    • If this is the $\eta ^\star$-th distinct call, set $r = \bot$ and $h = g_1^\alpha$ where $g_1^\alpha$ is from the co-CDH problem.

    • Else choose a random $r{\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q$ and set $h = g_1^r$.

    • Update ${\mathcal L}_{H_3} = {\mathcal L}_{H_3}\cup (x, r, h)$ and output h.

• 5. To answer the sign query $\mathsf {Sign}(\cdot , \mathsf {sk}^\star , \mathsf {pk}^\star , \cdot )$ on a message x, call the $H_3$ oracle to obtain $(x,r,h)\in {\mathcal L}_{H_3}$,

  • If $r = \bot$, return $\bot$

  • Else output $g_1^{\beta \cdot r}$

Finally $\mathcal {A}$ outputs a forgery $(J, \sigma ^\star )$, a message $m^\star$, a group public key $\mathsf {gpk}^\star = (\mathsf {gtag}^\star , \mathcal {PK})$. If $(m^\star , \mathsf {gtag}^\star )$ is not the $\eta ^\star$-th query to $H_3$, then $\mathcal {B}$ aborts. Since $\eta ^\star$ is randomly chosen, the probability that $\mathcal {B}$ does not abort is $1/q_{H_3}$. Let’s assume $\mathcal {B}$ does not abort. Parse $\mathcal {PK}= \{\mathsf {pk}_i\}_{i\in U}$ with each $\mathsf {pk}_i = (pk_i, pop_i)$. Suppose $\mathsf {pk}^\star = \mathsf {pk}_k$ for some $k\in U$. Based on the construction of $H_1$, we have $H_1(pk_i)= g_1^{\alpha \cdot r_i}$ for each $i\in U\setminus \{k\}$. Combing with $e(H_1(pk_i), pk_i) = e(pop_i, g_2)$ obtained from Condition 1 in Definition 6, we have $e(g_1^{\alpha }, pk_i) = e(pop_i^{r_i^{-1}}, g_2)$ for each $i\in U\setminus \{k\}$. Because $e(\sigma ^\star , g_2) = e(H_3(\mathsf {gtag}^\star , m^\star ), \prod _{i\in J} pk_i)$ by the Condition 3 in Definition 6, we can derive $e(\sigma ^\star , g_2) = e(g_1^\alpha , g_2^\beta \cdot \prod _{i\in J}^{i\ne k} pk_i) = e(g_1^\alpha ,g_2^\beta )\cdot e(g_1^\alpha , \prod _{i\in J}^{i\ne k} pk_i)= e(g_1^\alpha ,g_2^\beta )\cdot e(\prod _{i\in J}^{i\ne k} pop_i^{r_i^{-1}},g_2)$. Let $\delta = \sigma ^\star \cdot \prod _{i\in J}^{i\ne k} pop_i^{- r_i^{-1}}$. Then we have $e(\delta , g_2)= e(\sigma ^\star \cdot \prod _{i\in J}^{i\ne k} pop_i^{- r_i^{-1}}, g_2) = e(\sigma ^\star , g_2)/e(\prod _{i\in J}^{i\ne k} pop_i^{r_i^{-1}}, g_2)= e(g_1^\alpha , g_2^\beta )$. Therefore, $\mathcal {B}$ can return $\delta$ as a solution to the co-CDH problem with a success probability at least $\epsilon /q_H$.

The running time of $\mathcal {B}$ is that of $\mathcal {A}$ plus the additional computations that $\mathcal {B}$ makes. Let $\tau _{\exp _1}$ be the time required to compute one exponentiation in $\mathbb {G}_1$. The setup of the challenge verification key costs $\tau _{\exp _1}$. Let $q_{H}$ be the combined number of random oracle queries to $H_1, H_2, H_3, H_4$. To answer $q_H$ random oracle queries, $\mathcal {B}$ spends at most $(q_H - 1) \cdot \tau _{\exp _1}$ time. $\mathcal {B}$ spends at most $q_S \cdot \tau _{\exp _1}$ to answer all the signing queries. To construct the solution $\delta$, it takes at most $\ell \cdot \tau _{\exp _1}$ time where $\ell$ is the maximum number of signers involved in a single multi-signature. In total, $\mathcal {B}$’s running time is $\tau + (q_H + q_S + \ell )\cdot \tau _{\exp _1}$.

Remark 3

Theorems 5 and 6 validate the correctness of using the multi-signatures protocols for achieving consensus in [12, 16, 20].

In the next subsection, we shall discuss how to optimise $\mathsf {RSMS}\text{- }\mathsf {pop}$ with NIZKs to obtain a more efficient scheme $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$. The performance evaluation given in Sect. 6 will show our construction $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ is 2x faster than $\mathsf {RSMS}\text{- }\mathsf {pop}$ in terms of combination of individual signatures.

4.4 Optimising $\mathsf {RSMS}\text{- }\mathsf {pop}$ with NIZKs

Construction of $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$. The $\mathsf {KeyGen}, \mathsf {KeyAgg}, \mathsf {GroupSet},\mathsf {VerifyMul}$ algorithms are instantiated in the same way as $\mathsf {RSMS}\text{- }\mathsf {pop}$, but the algorithms $\mathsf {Sign}$ and $\mathsf {Combine}$ now use NIZKs to validate individual signatures:

• $\mathsf {Sign}(m, \mathsf {sk}_i, \mathsf {pk}_i, \mathsf {gtag})$: Parse $\mathsf {pk}_i = (pk_i, pop_i)$. Compute $v_i = H_3(\mathsf {gtag}, m)^{\mathsf {sk}_i}$ and $\pi _i \leftarrow \mathsf {PrEq}_{H_4}(H_1(pk_i), H_3(\mathsf {gtag}, m),pop_i, v_i; r)$ for randomness $r{\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q$. Output $s_i = (v_i,\pi _i)$.

• $\mathsf {Combine}(m, \mathcal {E}, \mathsf {gpk})$: Parse $\mathsf {gpk}= (\mathsf {gtag},\{(pk_i,pop_i)\}_{i\in U})$ and $\mathcal {E}= \{(v_i,\pi _i)\}_{i\in I}$ the set of individual signatures originating from |I| different entities such that $I\subseteq U$. The combiner verifies each signature in $\mathcal {E}$ by checking

  $$\mathsf {VerEq}_{H_4}(H_1(pk_i), pop_i, H_3(\mathsf {gtag}, m), v_i,\pi _i) =1.$$

  Assume the index set of valid signatures is $J\subseteq I$. The combiner computes the multi-signature as $\sigma = \prod _{j\in J} v_j$ and outputs $(J,\sigma )$.

Theorem 7

Our $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ scheme is robust in the random oracle model.

Theorem 8

$\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ is unforgeable under the computational co-CDH assumption in the random oracle model. Formally, $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ is $(\tau , q_S, q_H, \epsilon )$-unforgeable if co-CDH is $(\tau + (q_H + 5q_S + \ell )\cdot \tau _{\exp _1}, \epsilon /q_H)$-hard where $\ell$ is the maximum number of signers involved in a single multi-signature and $\tau _{\exp _1}$ is the time required to compute one exponentiation in $\mathbb {G}_1$.

Proof

The analysis is the same as Theorem 6 except that $\mathsf {Sign}$ queries are answered with simulated NIZKs generated by an additional random oracle $H_4: \{0,1\}^*\mapsto \mathbb {Z}_q$:

• The random oracle $H_4$ is programmed as follows: Define a list ${\mathcal L}_{H_4}= \emptyset$. For a query on y, if $(y,c)\in {\mathcal L}_{H_4}$, then output c. Otherwise choose a random $c{\mathop {\leftarrow }\limits ^{\$}}\mathbb {Z}_q$, update the list ${\mathcal L}_{H_4} = {\mathcal L}_{H_4}\cup (y,c)$ and output c.

• To answer the sign query $\mathsf {Sign}(\cdot , \mathsf {sk}^\star , \mathsf {pk}^\star , \cdot )$ on a message x, call the $H_3$ oracle to obtain $(x,r,h)\in {\mathcal L}_{H_3}$,

  • If $r = \bot$, return $\bot$

  • Else output $g_1^{\beta \cdot r}$ and a simulated NIZK proof $\pi$ using the random oracle $H_4$

For each $\mathsf {Sign}$ query, $\mathcal {B}$ needs to generate a simulated NIZK proof which takes $4\tau _{\exp _1}$ time for each proof. Adding the time $\tau _{\exp _1}$ for computing each signature, $\mathcal {B}$ spends at most $q_S \cdot 5\tau _{\exp _1}$ to answer all the signing queries. Therefore, $\mathcal {B}$’s total running time is at most $\tau + (q_H + 5q_S + \ell )\cdot \tau _{\exp _1}$ and $\mathcal {B}$’s success probability is $\epsilon /q_H$.

5 Extensions

In this section, we extend our robust subgroup multi-signatures with two useful functions: compression and aggregation. We give formal definitions and security analysis for the extended multi-signatures.

5.1 Compressing Two Multi-signatures on the Same Message

It is possible to compress two multi-signatures on the same message if signed by disjoint subgroups. In practice, this enables any entity to start the signature combination process without the need of waiting until the entity gets all the individual signatures. It is a type of incremental aggregation mentioned in [14] but was never formalised. Below we shall extend our definition of robust subgroup multi-signature scheme $\mathrm {RSMS}$ with an additional algorithm called $\mathsf {Compress}$:

• $\mathsf {Compress}(m, J_1, \sigma _1, J_2, \sigma _2, \mathsf {gpk})$: on input a message m, two multi-signatures $(J_1,\sigma _1),(J_2, \sigma _2)$, and a group public key $\mathsf {gpk}$, the algorithm compress two multi-signatures into a single multi-signature and outputs $(J, \sigma )$ with $J = J_1\cup J_2$. When the algorithm fails to compress the multi-signatures, output $(J, \sigma ) = (\emptyset , \bot )$.

Robustness. We extend the robustness in Definition 5 to include compressibility: for any $m, J_1, J_2, \sigma _1,\sigma _2, \mathsf {gpk}$ such that $J_1\cap J_2 = \emptyset$ and $J_1,J_2\ne \emptyset$, if $\mathsf {VerifyMul}(m, J_b, \sigma _b, \mathsf {gpk}) = 1$ for $b=1,2$, then $\mathsf {VerifyMul}(m, J, \sigma , \mathsf {gpk}) = 1$ where $(J,\sigma )\leftarrow \mathsf {Compress}(m, J_1, \sigma _1, J_2,\sigma _2, \mathsf {gpk})$.

Unforgeability. The definition of unforgeability does not change since $\mathsf {Compress}$ does not involve any secret information and the adversary can run this algorithm by itself.

Instantiations. Unfortunately, $\mathsf {RSMSP}$ and $\mathsf {RSMSP}\text{- }\mathsf {zk}$ are not compressible, because two multi-signatures $\sigma _b = \prod _{i\in J_b} s_i^{a_{i,b}}$ with coefficients $a_{i,b} = H_2(\mathsf {pk}_i, J_b, \mathcal {PK})$ and $b=0,1$, cannot be compressed into $\sigma = \prod _{i\in J_1\cup J_2} s_i^{a_i}$ with coefficients $a_i = H_2(\mathsf {pk}_i, J_1\cup J_2, \mathcal {PK})$. In comparison, the PoP-based schemes $\mathsf {RSMS}\text{- }\mathsf {pop}$ and $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ can be extended with $\mathsf {Compress}$ as follows:

• $\mathsf {Compress}(m, J_1, \sigma _1, J_2, \sigma _2, \mathsf {gpk})$: Check if $J_1\cap J_2 = \emptyset$, $\mathsf {VerifyMul}(m, J_b, \sigma _b, \mathsf {gpk}) = 1$ for $b=0,1$. If successful, output $(J_1\cup J_2, \sigma _1\cdot \sigma _2)$. Otherwise output $(\emptyset , \bot )$.

Theorem 9

The extended $\mathsf {RSMS}\text{- }\mathsf {pop}$ and $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ are robust in the random oracle model.

Proof

We only need to show the compressibility defined above. Since $e(\sigma _i, g_2) = e(H_2(\mathsf {gtag}, m), \mathsf {apk}_i)$ for $i=1,2$, we know that $e(\sigma , g_2) = e(H_2(\mathsf {gtag}, m), \mathsf {apk})$ where $\sigma = \sigma _1\cdot \sigma _2$ and $\mathsf {apk}= \mathsf {apk}_1\cdot \mathsf {apk}_2$.

Theorem 10

The extended $\mathsf {RSMS}\text{- }\mathsf {pop}$ and $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ are unforgeable under the computational co-CDH problem in the random oracle model.

Proof

As mentioned above, adding $\mathsf {Compress}$ algorithm does not change the definition of unforgeability since the adversary can run $\mathsf {Compress}$ himself. The proofs of unforgeability of $\mathsf {RSMS}\text{- }\mathsf {pop}$ (resp. $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$) are therefore the same as Theorem 6 (resp. 8) and are omitted.

5.2 Aggregating Multi-signatures on Different Messages

Multi-signatures on different messages can be further aggregated into a single aggregate signature, e.g., [8]. In this section, we show that the multi-signatures on different messages signed by different groups in our robust-subgroup multi-signature schemes can also be aggregated, and we call this extension aggregate robust-subgroup multi-signatures ($\mathrm {ARSMS}$).

Definition 7

(Aggregate Robust-Subgroup Multi-signature). An aggregate robust-subgroup multi-signature ($\mathrm {ARSMS}$) scheme consists of the following algorithms $\varPi = (\mathsf {KeyGen}, \mathsf {GroupSet}, \mathsf {Sign}, \mathsf {Combine}, \mathsf {VerifyMul}, \mathsf {Aggregate}, \mathsf {VerifyAgg})$, where algorithms $\mathsf {KeyGen},\mathsf {GroupSet}, \mathsf {Sign}, \mathsf {Combine}$ and $\mathsf {VerifyMul}$ are exactly the same as $\mathrm {RSMS}$ in Definition 4, and

• $\mathsf {Aggregate}(\{(m_i, J_i, \sigma _i, \mathsf {gpk}_i)\}_{i\in I})$: on input a set of tuples of message, multi-signature and group public key, the algorithm identifies an index set $K\subseteq I$ of valid multi-signatures and aggregates them into a single aggregate signature $\varSigma$ and outputs $(\{J_i\}_{i\in K},\varSigma )$. When the algorithm fails to aggregate signatures, output $\bot$.

• $\mathsf {VerifyAgg}(\{(m_i, J_i, \mathsf {gpk}_i)\}_{i\in K}, \varSigma )$: on input tuples of messages, indices and group public keys, and an aggregate signature $\varSigma$, the algorithm outputs 1 if $\varSigma$ is a valid aggregate signature and outputs 0 otherwise.

Robustness of $\mathrm {ARSMS}$. We define robustness for an $\mathrm {ARSMS}$ scheme by extending Definition 5 with the robustness for aggregate signatures: if $\mathsf {VerifyMul}(m_i, J_i,\sigma _i, \mathsf {gpk}_i) = 1$ for each $i\in I$, and $\varSigma \leftarrow \mathsf {Aggregate}(\{(m_i, J_i, \sigma _i, \mathsf {gpk}_i)\}_{i\in I})$, then $\mathsf {VerifyAgg}(\{(m_i, J_i, \mathsf {gpk}_i)\}_{i\in I},\varSigma ) = 1$.

Definition 8

(Unforgeability of $\mathrm {ARSMS}$). The unforgeability of an $\mathrm {ARSMS}$ scheme $\varPi = (\mathsf {KeyGen}, \mathsf {GroupSet}, \mathsf {Sign}, \mathsf {Combine}, \mathsf {VerifyMul}, \mathsf {Aggregate}, \mathsf {VerifyAgg})$ is defined by a three-stage game:

• Setup. The challenger generates the system parameters $\mathsf {pp}$ and a challenge key pair $(\mathsf {sk}^\star ,\mathsf {pk}^\star )\leftarrow \mathsf {KeyGen}(1^\lambda )$. It gives $(\mathsf {pk}^\star , \mathsf {pp})$ to the adversary.

• Signature queries. $\mathcal {A}$ is allowed to make signature queries on any message m for any group tag $\mathsf {gtag}$, meaning that it has access to oracle $\mathcal {O}^{\mathsf {Sign}(\cdot , \mathsf {sk}^\star , \mathsf {pk}^\star , \cdot )}$ that simulates the honest signer signing a message m.

• Output. Finally, the adversary outputs an aggregate signature forgery $(\{m_i, J_i, \mathsf {gpk}_i = (\mathsf {gtag}_i, \mathcal {PK}_i)\}_{i\in K}, \varSigma ^\star )$. The adversary wins if

  • 1. For each $i\in K$, $\mathsf {gpk}_i\ne \bot$ and $\mathsf {gpk}_i = \mathsf {GroupSet}(\mathcal {PK}_i)$

  • 2. For each $i\in K$, let $\mathcal {PK}_i = \{\mathsf {pk}_{i, j}\}_{j\in I_i}$, then $J_i\subseteq I_i$. $\mathsf {pk}^\star = \mathsf {pk}_{k^\star ,j^\star }$ for some $k^\star \in K$ and $j^\star \in J_{k^\star }$.

  • 3. The pairs $(\mathsf {gtag}_i, m_i)$ with $i\in K$ are pairwise-distinct. $\mathcal {A}$ made no signing queries on $(m_{k^\star },\mathsf {gtag}_{k^\star })$.

  • 4. $\mathsf {VerifyAgg}(\{(m_i, J_i, \mathsf {gpk}_i)\}_{i\in K},\varSigma ^\star )= 1$.

We say $\mathcal {A}$ is a $(\tau , q_S, q_H, \epsilon )$-forger for $\mathrm {ARSMS}$ if $\mathcal {A}$ runs in time at most $\tau$, makes at most $q_S$ signing queries and at most $q_H$ random oracle queries, and wins the above game with probability at least $\epsilon$. $\mathrm {ARSMS}$ is $(\tau , q_S, q_H, \epsilon )$-unforgeable if no such adversary exists.

Instantiations. Our robust-subgroup multi-signatures, i.e., $\mathsf {RSMSP}, \mathsf {RSMSP}\text{- }\mathsf {zk},\mathsf {RSMS}\text{- }\mathsf {pop},$ and $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ can be extended with the following algorithms:

• $\mathsf {Aggregate}(\{(m_i, J_i, \sigma _i, \mathsf {gpk}_i)\}_{i\in I})$: Output $\varSigma \leftarrow \prod _{i\in I} \sigma _i$.

• $\mathsf {VerifyAgg}(\{(m_i, J_i, \mathsf {gpk}_i)\}_{i\in I}, \varSigma )$: For each $i\in I$, parse $\mathsf {gpk}_i = (\mathsf {gtag}_i,\mathcal {PK}_i)$ and compute $\mathsf {apk}_i\leftarrow \mathsf {KeyAgg}(J_i, \mathcal {PK}_i)$. If $e(\varSigma , g_2)= \prod _{i\in I} e(H_3(\mathsf {gtag}_i, m_i), \mathsf {apk}_i)$ output 1; else output 0.

We call the extended schemes $\mathsf {ARSMSP}, \mathsf {ARSMSP}\text{- }\mathsf {zk}, \mathsf {ARSMS}\text{- }\mathsf {pop}, \mathsf {ARSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$, respectively.

Theorem 11

The schemes $\mathsf {ARSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}, \mathsf {ARSMSP}\text{- }\mathsf {zk}, \mathsf {ARSMS}\text{- }\mathsf {pop}$ and finally $\mathsf {ARSMSP}$ are robust in the random oracle model.

Proof

To show robustness, we only need to prove the robustness for aggregate signatures. Let $(\{J_i\}_{i\in K},\varSigma )\leftarrow \mathsf {Aggregate}(\{(m_i,J_i, \sigma _i, \mathsf {gpk}_i)\}_{i\in I})$. From the instantiation of $\mathsf {Aggregate}$ and definition of robustness, we have $\varSigma = \prod _{i\in K}\sigma _i$, and for each $i\in K$, $\mathsf {VerifyMul}(m_i, J_i, \sigma _i, \mathsf {gpk}_i)= 1$. From the instantiation of $\mathsf {VerifyMul}$, we have $e(\sigma _i, g_2) = e(H_3(\mathsf {gtag}_i, m_i), \mathsf {apk}_i)$ where $\mathsf {gpk}_i = (\mathsf {gtag}_i, \mathcal {PK}_i)$ and $\mathsf {apk}_i\leftarrow \mathsf {KeyAgg}(J_i, \mathcal {PK}_i)$ for $i\in K$. Therefore

$$e(\varSigma , g_2) = \prod _{i\in K} e(H_3(\mathsf {gtag}_i, m_i),\mathsf {apk}_i),$$

which completes the proof.

Theorem 12

$\mathsf {ARSMSP}$ and $\mathsf {ARSMSP}\text{- }\mathsf {zk}$ are unforgeable under the computational $\psi$-co-CDH assumption in the random oracle model. Formally,

• 1. $\mathsf {ARSMSP}$ is $(\tau , q_S, q_H, \epsilon )$-unforgeable if $q>8q_H/\epsilon$ and $\psi$-co-CDH is $((\tau + (q_H + q_S + n) \cdot \tau _{\exp _1} + \ell \cdot \tau _{\exp _2}) \cdot 8 q^2_H/\epsilon \cdot \ln (8q_H/\epsilon ), \epsilon /(8q_H))$-hard;

• 2. $\mathsf {ARSMSP}\text{- }\mathsf {zk}$ is $(\tau , q_S, q_H, \epsilon )$-unforgeable if $q>8q_H/\epsilon$ and $\psi$-co-CDH is $(\tau + (q_H + 3q_S + n)\cdot \tau _{\exp _1} + (2q_S + \ell )\cdot \tau _{\exp _2}) \cdot 8 q^2_H/\epsilon \cdot \ln (8q_H/\epsilon ), \epsilon /(8q_H))$-hard.

where $\ell$ is the maximum number of signers involved in an aggregate signature, n is the maximum number of multi-signatures involved in an aggregate signature, and $\tau _{\exp _1}$ (resp. $\tau _{\exp _2}$) is the time required to compute one exponentiation in $\mathbb {G}_1$ (resp. $\mathbb {G}_2$).

Theorem 13

$\mathsf {ARSMS}\text{- }\mathsf {pop}$ and $\mathsf {ARSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ are unforgeable under the computational co-CDH assumption in the random oracle model. Formally,

• 1. $\mathsf {ARSMS}\text{- }\mathsf {pop}$ is $(\tau , q_S, q_H, \epsilon )$-unforgeable if $\psi$-co-CDH is $(\tau + (q_H + q_S + \ell + n)\cdot \tau _{\exp _1}, \epsilon /q_H)$-hard.

• 2. $\mathsf {ARSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ is $(\tau , q_S, q_H, \epsilon )$-unforgeable if $\psi$-co-CDH is $(\tau + (q_H + 5q_S + \ell + n)\cdot \tau _{\exp _1}, \epsilon /q_H)$-hard

where $\ell$ is the maximum number of signers involved in a single multi-signature, n is the maximum number of multi-signatures involved in an aggregate signature, and $\tau _{\exp _1}$ is the time required to compute one exponentiation in $\mathbb {G}_1$.

Compressibility. Apparently, $\mathsf {ARSMS}\text{- }\mathsf {pop}$ and $\mathsf {ARSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ are compressible and can be extended with the same $\mathsf {Compress}$ algorithm for $\mathsf {RSMS}\text{- }\mathsf {pop}$ and $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$.

6 Performance Evaluation

We implement the four multi-signature schemes, namely$\mathsf {RSMSP}$, $\mathsf {RSMSP}\text{- }\mathsf {zk}$, $\mathsf {RSMS}\text{- }\mathsf {pop}$ and $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$, using MCL library [25]. $\mathsf {RSMSP}$ and $\mathsf {RSMSP}\text{- }\mathsf {zk}$ are implemented by swapping $\mathbb {G}_1$ and $\mathbb {G}_2$, i.e., putting the public keys on $\mathbb {G}_1$ and the signatures on $\mathbb {G}_2$. This is because $\mathsf {VerifyMul}$ and $\mathsf {VerifyAgg}$ involve re-construction of the aggregate public keys which contains time-consuming exponentiation operations on the public keys. Putting public keys on $\mathbb {G}_1$ can mitigate this issue since the exponentiations on $\mathbb {G}_1$ are typically faster than the ones on $\mathbb {G}_2$. However, this will make $\mathsf {Combine}$ slower because the signature aggregations are now performed on $\mathbb {G}_2$. We note that $\mathsf {Combine}$ only needs to be run by a limited set of nodes like validators, but $\mathsf {VerifyMul}$ and $\mathsf {VerifyAgg}$ need to be run by any node that first obtains the multi-signatures. In addition, our $\mathsf {RSMSP}\text{- }\mathsf {zk}$ scheme has optimised $\mathsf {Combine}$ using NIZKs which significantly improves the efficiency of $\mathsf {Combine}$ and offsets the loss. Therefore, switching $\mathbb {G}_1$ and $\mathbb {G}_2$ can provide better overall performance.

Performance evaluation of the Combine function. The algorithm $\mathsf {Combine}$ can be executed by any node in the network since it does not require any secret information. $\mathsf {Combine}$ only needs to be run once when computing the multi-signature from a set of individual signatures. Table 1 gives timing for combining a majority number $\lfloor \ell /2\rfloor +1$ of individual signatures from a group of size $\ell$ with $\ell = 64,128,256$. $\mathsf {RSMSP}\text{- }\mathsf {zk}$ (resp. $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$) is the optimised version of $\mathsf {RSMSP}$ (resp. $\mathsf {RSMS}\text{- }\mathsf {pop}$) by validating an individual signature using NIZK proofs instead of pairing equations. This optimisation makes $\mathsf {Combine}$ in $\mathsf {RSMSP}\text{- }\mathsf {zk}$ (resp. $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$)  2x faster than $\mathsf {RSMSP}$ (resp. $\mathsf {RSMS}\text{- }\mathsf {pop}$).

Table 1. Performance evaluation and comparison of the $\mathsf {Combine}$ function. The columns of $\mathsf {Combine}$ give the timings for combining a threshold number $\lfloor \ell /2\rfloor +1$ of individual signatures from a group of size $\ell$ with $\ell = 64, 128, 256$. That is, 33 (resp. 65, 129) individual signatures from a group of 64 (resp. 128, 256) members.

Performance comparison with ECDSA. We shall compare the performance of the four multi-signature schemes with ECDSA signatures, in order to show that it is feasible to replace ECDSA with multi-signatures. The performance of ECDSA depends on the optimisations implemented in different libraries. The secp256k1 curve is used in Bitcoin for ECDSA signatures. The OpenSSL implementation of secp256k1 is not well optimised which leads to the low efficiency of ECDSA signing and verification operations. The Sodium library [5] provides a particularly efficient implementation of ECDSA over the curve Ed25519.

As shown in Table 2, the size of a multi-signature that combines/aggregates n individual signatures are constant, regardless of n. In comparison, n ECDSA signatures is of 64n bytes. We take consensus as an example. Suppose each committee has 200 validators and a notarisation of a new block requires at least 101 signatures. With ECDSA signatures, this accounts for 6.464 KB storage overhead for each block, while it is 48 Byte for $\mathsf {RSMS}\text{- }\mathsf {pop}/\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ and 96 bytes for $\mathsf {RSMSP}/\mathsf {RSMSP}\text{- }\mathsf {zk}$.

In terms of the size of the public key for each entity, the constructions $\mathsf {RSMS}\text{- }\mathsf {pop}$ and $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ incurs the extra overhead introduced by the use of proof-of-possession for preventing rogue-key attacks. The public keys and PoPs only need to be verified once and stored in the blockchain for future reference. In comparison, the public keys in $\mathsf {RSMSP}$ and $\mathsf {RSMSP}\text{- }\mathsf {zk}$ are 66% smaller than $\mathsf {RSMS}\text{- }\mathsf {pop}$ and $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$. For 200 validators, this means saving 19.2 KB for storing public keys.

Table 2. Signature size comparison between multi-signatures and ECDSA. The Multi-signature column gives the size of the multi-signature that combines n signatures.

In Table 3, we compare the efficiency of the four multi-signature schemes with ECDSA. The $\mathsf {Sign}$ column measures the timing for creating an individual signature which are less than 1 ms for all four multi-signature schemes.

The $\mathsf {VerifyMul}$ columns in Table 3 present the timings for verifying a multi-signature signed by a threshold (or majority) number of members from a group of $\ell$ members with $\ell = 64, 128, 256$. The threshold is set to be $\lfloor \ell /2\rfloor +1$. When using ECDSA for the same purpose as multi-signatures, this is equivalent to $\lfloor \ell /2\rfloor +1$ ECDSA signatures. From the table we can see that $\mathsf {RSMS}\text{- }\mathsf {pop}$ and $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ outperforms ECDSA and $\mathsf {RSMSP}$ and $\mathsf {RSMSP}\text{- }\mathsf {zk}$ in terms of the verification time for a multi-signature. This is because $\mathsf {VerifyMul}$ in $\mathsf {RSMS}\text{- }\mathsf {pop}$ and $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ mainly involves computing two pairings which is almost constant. In comparison, $\mathsf {VerifyMul}$ in $\mathsf {RSMS}\text{- }\mathsf {pop}$ and $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ requires computing a sequence of exponentiations on the public keys in order to reconstruct the aggregate public keys for the subgroup.

Table 3. Performance comparison between multi-signatures and ECDSA. The $\mathsf {Sign}$ column gives the timings for generating an individual signature. The columns of $\mathsf {VerifyMul}$ give the timings for verifying a multi-signature signed by a threshold number of members from a group of size $\ell$ with $\ell = 64, 128, 256$. The threshold number is set to be $\lfloor \ell /2\rfloor +1$. That is, 33 (resp. 65, 129) members from a group of 64 (resp. 128, 256) members. The columns of $\mathsf {VerifyAgg}$ give the timings for verifying an aggregate signature signed by 64 (or 128, 256) groups where each group consists of 128 members and a threshold number (i.e., 65) of members signed.

The $\mathsf {VerifyAgg}$ columns in Table 3 give the timings for verifying an aggregate signature signed by k groups ($k\,=\,64, 128, 256$) where each group consists of 128 members and a majority number (i.e., 65) of members signed. When using ECDSA for the same purpose, this corresponds to $65\cdot k$ ECDSA signatures. For all four multi-signature schemes, the timing for verifying k multi-signatures using $\mathsf {VerifyAgg}$ is less than $k\cdot t$ where t is the time for verifying a multi-signature using $\mathsf {VerifyMul}$. This is because $\mathsf {VerifyAgg}$ functions as a batch verification which saves $k-1$ pairing computations. Similar to $\mathsf {VerifyMul}$, $\mathsf {RSMS}\text{- }\mathsf {pop}$ and $\mathsf {RSMS}\text{- }\mathsf {pop}\text{- }\mathsf {zk}$ outperforms $\mathsf {RSMSP}$ and $\mathsf {RSMSP}\text{- }\mathsf {zk}$ and ECDSA in terms of the verification of aggregate signatures.