# A Multi-Party Functional Signatures Scheme for Private Blockchain

^{1}

^{2}

^{*}

## Abstract

**:**

## 1. Introduction

- This paper proposes a novel scheme that combines functional signatures and multi-party ECDSA signatures to create a multi-party functional signature for private blockchains. Compared to the previous scheme, the proposed scheme ensures that each part of the transaction is verified. Moreover, in cases where the aggregate signature of the entire transaction cannot be verified, this scheme identifies the precise portion of the transaction where signature authentication fails rather than rejecting the transaction in its entirety.
- This paper ensures the security and authenticity of function f in the function signature by embedding it in a smart contract using blockchain’s smart contract technology.
- This paper provides proof of the security of the constructed scheme. Under the existence of the unforgeability of ECDSA signatures, the proposed scheme is secure even if it is corrupted in $n-1$ parties (assuming a total of n parties).

## 2. Related Work

## 3. Preliminaries

#### 3.1. ECDSA Signature

- Setup: On inputting the security parameter, the system outputs public parameters param = {E, ${F}_{p}$, G, P, p, q, H}, where E is an elliptic curve defined over a finite field ${F}_{p}$, p is a prime and G is an additive cyclic group consisting of all points in E; P is the generator of the group G, and q is the prime order of the group G. Finally, H is a cryptographic hash function denoted as $H:{\{0,1\}}^{*}\to {Z}_{q}^{*}$ and Z${}_{q}^{*}$ is the field consisting of the set of integers {1, 2, …, q − 1}.

- KeyGen: On inputting the public parameter param, the following two steps generate the signed public–private key pair.

- Choose a random integer $d\in {Z}_{q}^{*}$ as secret key.
- Compute the $Q=d\xb7P$ as public key.

- SigGen: On inputting the public parameter param, the signing secret key d, and the message m, output the signature of message m $\delta \phantom{\rule{3.33333pt}{0ex}}=(r,s)$. The steps for generating a signature are as follows.

- Randomly select integer $k\in {Z}_{q}^{*}$.
- Compute $R=k\xb7P=({r}_{x},{r}_{y})$, where R is a point on the elliptic curve E.
- Compute $r={r}_{x}\phantom{\rule{0.222222em}{0ex}}mod\phantom{\rule{4pt}{0ex}}q$, and if/when r is 0, return to the first step to reselect k.
- Compute ${s}_{1}={k}^{-1}(e+dr)\phantom{\rule{0.222222em}{0ex}}mod\phantom{\rule{4pt}{0ex}}q$, where $e=H\left(m\right)$.
- Output the generated signature $\delta =(r,s)$, where $s=min\{q-{s}_{1},{s}_{1}\}$.

- Verify: On inputting the message m to be verified and it’s signature $\delta $, output 0 or 1 (0 means failure, 1 means success). The steps for verifying a signature are as follows.

- Check whether the integers r and s belong to ${Z}_{q}^{*}$. If they do not belong, terminate the verification; otherwise, execute next step.
- Compute $e=H\left(m\right)$.
- Compute ${R}^{\prime}={s}^{-1}(eP+rQ)=({r}_{{x}^{\prime}},{r}_{{y}^{\prime}})$ to verify signature.
- When $r={r}_{{x}^{\prime}}\phantom{\rule{0.222222em}{0ex}}mod\phantom{\rule{4pt}{0ex}}q$, output 1, otherwise output 0.

#### 3.2. Functional Signatures

**Definition**

**1.**

- FS.Setup (${1}^{\lambda}$) $\to (Msk,Mvk):$ On inputting a parameter ${1}^{\lambda}$, it can output the master signing key Msk and the master verification key Mvk.
- FS.KeyGen(Msk,f) $\to s{k}_{f}:$ On inputting the master signing key and a function $f\in \mathcal{F}$, it outputs the signing key $s{k}_{f}$ for f.
- FS.Sign(f,$s{k}_{f}$,m) $\to \left(f\right(m),\sigma ):$ On inputting the function $f\in \mathcal{F}$, generated signing key $s{k}_{f}$, and the message $m\in {\mathcal{D}}_{f}$ that needs to be signed, it outputs the pair signature $\left(f\right(m),\sigma )$.
- FS.Verify(Mvk,${m}^{*}$,$\sigma $) $\to \{0,1\}:$ On inputting the master verification key Mvk, a message ${m}^{*}$ and a signature $\sigma $, where ${m}^{*}=f\left(m\right)$, it outputs 1 or 0, where 1 indicates that the signature is valid.

#### 3.3. Security Definition

**Definition**

**2.**

- The challenger runs $(Msk,Mvk)\leftarrow $ FS.Setup(${1}^{\lambda}$) and sends Mvk to adversary $\mathcal{A}$.
- Adversary $\mathcal{A}$ is allowed to query the key generation oracle and a signing oracle; they are noted as ${\mathcal{O}}_{k}$ and ${\mathcal{O}}_{sig}$. The challenger initializes a dictionary indexed by tuples $(f,i)\in \mathcal{F}\times \mathcal{N}$, which contained the signing keys: $s{k}_{f}^{i}\leftarrow $FS.KeyGen(Msk,f). This dictionary records the keys that were previously generated in the Unforgivability game. ${\mathcal{O}}_{k}$ and ${\mathcal{O}}_{sig}$ are defined as follows:
- -
- ${\mathcal{O}}_{k}$: On inputting $(f,i)$, the challenger runs as follows:
- 1.
- If there is an entry for $(f,i)$ in the dictionary, then the corresponding key $s{k}_{f}^{i}$ is output.
- 2.
- Otherwise, by $s{k}_{f}^{i}\leftarrow $ FS.KeyGen(Msk,f) sample a fresh key, add the $(f,i)\to $$s{k}_{f}^{i}$ to the dictionary in order to update it, and output $s{k}_{f}^{i}$.

- -
- ${\mathcal{O}}_{sig}$: On inputting $(f,i,m)$, the challenger runs as follows:
- 1.
- If there is an entry for $(f,i,m)$ in the dictionary, then the corresponding signature $\sigma \to $ FS.Sign(f,$s{k}_{f}^{i}$,m) is output.
- 2.
- Otherwise, by $s{k}_{f}^{i}\leftarrow $ FS.KeyGen(Msk,f) sample a fresh key, add the $(f,i)\to $$s{k}_{f}^{i}$ to the dictionary, and the corresponding signature $\sigma \to $ FS.Sign(f,$s{k}_{f}^{i}$,m) is output.

- -
- The adversary wins the game if it can output a signature $({m}^{*},\sigma )$ such that:
- 1.
- FS.Verify(Mvk,${m}^{*},\sigma $) = 1.
- 2.
- There does not exist m such that ${m}^{*}=f\left(m\right)$ for any f that was sent as a query to the key generation oracle ${\mathcal{O}}_{k}$.
- 3.
- There does not exist a $(f,m)$ that was queried to the signing oracle ${\mathcal{O}}_{sig}$ and ${m}^{*}=f\left(m\right)$.

#### 3.4. Smart Contract

## 4. Proposed System Model and Multi-Party Functional Signatures Method

#### 4.1. System Model Framework

- Gateway nodes manage the function f of functional signatures using smart contracts.
- Each mining node checks different $Dat{a}_{i}$ of $Data$, divided by function f of functional signatures. After that, the signature $signatur{e}_{i}$ corresponding to the respective $Dat{a}_{i}$ is generated. Gateway nodes manage the function f of functional signatures using smart contracts.
- After receiving all partial transaction signatures $signatur{e}_{i}$, an aggregated signature $Signature$ is generated and stored in the block header.
- Full nodes can search for all the transaction signatures stored in the blockchain.
- Validator nodes check the correctness of the queried signature. Once an error occurs in the signature stored in the block header, the partial transaction signature $signatur{e}_{i}$ stored in the block body can be queried and checked.

#### 4.2. Smart Contract Settings and Proposed Concrete Scheme

#### 4.2.1. Smart Contract Design

- authorizeAccount: When deploying the smart contract, the gateway nodes collect all legal account identity information. All these accounts consist of authorizeAccount.
- functionSet: The set stores all the functions f of functional signatures. Functions f of functional signatures that do not belong to functionSet are prohibited from being invoked.
- ct.sender: This invokes the contract’s account.
- f.Set: All functions that are stored in functionSet have a set f.Set, and some accounts are stored in it. If ct.sender does not belong to f.Set, it cannot use f.

Algorithm 1: invokeF$\left(f\right)$ |

Input: fOutput: boolif ct.sender does not exist in authorizeAccount thenendif f does not exist in functionSet then$\phantom{(}$return false;elseif ct.sender does not exist in f.Set thenreturn false;elsereturn true;endend |

Algorithm 2: addUser(f,$ct.sender$) |

Input: f,$ct.sender$Output: boolif f does not exist in functionSetthenreturn false;elseif ct.sender has exist in f.Set thenreturn false;else f.set[ct.sender] ⇐ true return true;endend |

Algorithm 3: deleteUser(f,$ct.sender$) |

Input: f,$ct.sender$Output: boolif f does not exist in functionSet thenreturn false;elseif ct.sender has not exist in f.Set thenreturn false;else f.set[ct.sender] ⇐ false return true;endend |

#### 4.2.2. Concrete Multi-Party Functional Signatures Scheme

- MFS.Setup: The full node first selects the security parameter $\lambda $ and runs the Setup algorithm of the ECDSA signature to generate public parameters $param$ = {E, ${F}_{p}$, G, P, p, q, H}, then randomly selects $d\leftarrow {Z}_{q}^{*}$ as the master private key Msk and computes the master public key $d\xb7P$ as Mvk. The full node chooses n random numbers ${d}_{i}$ and computes ${d}_{n+1}=d-{\sum}_{i=1}^{n}{d}_{i}$, where satisfies ${\sum}_{i=1}^{n+1}{d}_{i}=d$.
- MFS.KeyGen: Each mining node ${A}_{i}$ initiates a request to the full node, and then the full node sends the ${d}_{i}$ to mining node ${A}_{i}$ by a secure channel. Each mining node ${A}_{i}$ selects ${k}_{i}\leftarrow {Z}_{q}^{*}$ randomly to send to the full node by Diffie–Hellman key exchange. The full node computes $k={\prod}_{i=1}^{n}{k}_{i}$ and $k\xb7P=({r}_{x},{r}_{y})$, where k is stored in the full node and $k\xb7P$ is sent to each mining node ${A}_{i}$. Let $\{{v}_{1},{v}_{2},\cdots ,{v}_{n-1}\}$ be chosen randomly by the full node, and ${v}_{n}$ is computed by$${v}_{n}={k}^{-1}-\sum _{i=1}^{n-1}{v}_{i}.$$Each mining node sends H($Ai{d}_{i}$) to the full node, where $Ai{d}_{i}$ is the identification information of node ${A}_{i}$. The full node stores ${\{{d}_{i},{v}_{i},H\left(Ai{d}_{i}\right)\}}_{i\in [1,n]}$ securely. The full node randomly selects ${X}_{ji}\leftarrow {Z}_{q}^{*}$ and computes ${X}_{ij}={d}_{i}{v}_{j}+{d}_{j}{v}_{i}-{X}_{ji}$. Two nodes ${A}_{i}$ and ${A}_{j}$ receive ${X}_{ij}$ and ${X}_{ji}$, respectively, by Diffie–Hellman key exchange, where they satisfy$${X}_{ij}+{X}_{ji}={d}_{i}{v}_{j}+{d}_{j}{v}_{i}.$$Each mining node computes$${X}_{i}={d}_{i}{v}_{i}+\sum _{j=1,j\ne i}^{n}{X}_{ij}.$$The public key of mining node ${A}_{i}$ is ${X}_{i}P$. Each mining node ${A}_{i}$ gets ${v}_{i}$ by Diffie–Hellman key exchange as a part of the private key sk and invokes a smart contract to verify the authenticity of ${f}_{i}$. The full node signs for ${f}_{i}|v{k}_{i}$ by the Msk and SigGen algorithms of the ECDSA signature, the signature of ${f}_{i}|v{k}_{i}$ is noted as ${\sigma}_{v{k}_{i}}$. Creating the certificate ${c}_{i}=({f}_{i},v{k}_{i},{\sigma}_{v{k}_{i}})$, the private key $s{k}_{f}^{i}$ of node ${A}_{i}$ is $s{k}_{f}^{i}=({X}_{i},{c}_{i})$.
- MFS.Sign: To sign the message m, all the nodes start to get e = H(m) and compute$$si{g}_{i}=e\xb7{v}_{i}+{r}_{x}\xb7{X}_{i}.$$The signature generated by each mining node ${A}_{i}$ is ${\sigma}_{i}=({m}_{i}^{*},m,{c}_{i},si{g}_{i})$, where ${m}_{i}^{*}={f}_{i}\left(m\right)$. The full node receives $si{g}_{i}$ from all nodes and calculates $si{g}_{n+1}={k}^{-1}{r}_{x}{d}_{n+1}$ using the internally saved ${d}_{n+1}$. Finally, the output is the $Sig={\sum}_{i=1}^{n+1}si{g}_{i}$.
- MFS.Verify: For overall transactions, the data of the transactions verifier can verify signature Sig by using the Verify algorithm of the ECDSA signature. If the data of transactions verifier needs to check the authenticity of the signature of node ${A}_{i}$, he can check that:
- 1.
- ${m}^{*}\stackrel{?}{=}{f}_{i}\left(m\right)$;
- 2.
- Whether ${\sigma}_{v{k}_{i}}$ is valid by the Verify algorithm of the ECDSA signature and Mvk.

- Correctness: The correctness of the signature for node ${A}_{i}$ is guaranteed by the ECDSA signature algorithm. The following equation determines the correctness of Sig:$$\begin{array}{cc}\hfill Sig& =\sum _{i=1}^{n+1}si{g}_{i}\hfill \\ \hfill \phantom{\rule{1.em}{0ex}}& =\sum _{i=1}^{n}(e\xb7{v}_{i}+{r}_{x}\xb7{X}_{i})+si{g}_{n+1}\hfill \\ \hfill \phantom{\rule{1.em}{0ex}}& =e\sum _{i=1}^{n}{v}_{i}+{r}_{x}\sum _{i=1}^{n}{X}_{i}+si{g}_{n+1}\hfill \\ \hfill \phantom{\rule{1.em}{0ex}}& =e{k}^{-1}+{r}_{x}\sum _{i=1}^{n}({d}_{i}{v}_{i}+\sum _{j=1,j\ne i}^{n}{X}_{ij})+si{g}_{n+1}\hfill \\ \hfill \phantom{\rule{1.em}{0ex}}& =e{k}^{-1}+{r}_{x}\sum _{i=1}^{n}{d}_{i}{k}^{-1}+si{g}_{n+1}\hfill \\ \hfill \phantom{\rule{1.em}{0ex}}& ={k}^{-1}(e+{r}_{x}\sum _{i=1}^{n}{d}_{i})+{k}^{-1}{r}_{x}{d}_{n+1}\hfill \\ \hfill \phantom{\rule{1.em}{0ex}}& ={k}^{-1}(e+{r}_{x}d)\hfill \end{array}$$

## 5. Security Analysis

**Theorem**

**1.**

**Proof**

**of**

**Theorem**

**1.**

- For each ${A}_{i}\in {\mathcal{S}}^{\prime}$, $si{g}_{i}$ is a valid signature of m under the verification key $v{k}_{i}$.
- For each ${A}_{i}\in {\mathcal{S}}^{\prime}$, ${\sigma}_{v{k}_{i}}$ is a valid signature of ${f}_{i}|v{k}_{i}$ under the master public key Mvk.
- ${f}_{i}\left(m\right)={m}^{*}$ for all i.
- ${\mathcal{A}}_{MS}$ has not sent a query of form ${({f}_{i}^{\prime},i)}_{i\in \left\{i\right|({A}_{i}\in \mathcal{S})\}}$ for all i to the oracle ${\mathcal{O}}_{k}$, and ${m}^{*}$ is in the range of the ${f}_{i}^{\prime}$.
- ${\mathcal{A}}_{MS}$ has not sent a query of form ${({f}_{i}^{\prime},i,{m}^{\prime})}_{i\in \left\{i\right|({A}_{i}\in \mathcal{S})\}}$ for all i to the oracle ${\mathcal{O}}_{sig}$.

- Type I forgery: The tuples $({f}_{{i}^{*}},v{k}_{{i}^{*}})$ satisfy that ${f}_{{i}^{*}}|v{k}_{{i}^{*}}$ has not already been signed under the master key Mvk for queries from ${\mathcal{A}}_{MS}$ to the oracles ${\mathcal{O}}_{k}$ and ${\mathcal{O}}_{sig}$.
- Type II forgery: The tuples $({f}_{{i}^{*}},v{k}_{{i}^{*}})$ satisfy that ${f}_{{i}^{*}}|v{k}_{{i}^{*}}$ has been signed under the master key Mvk for queries from ${\mathcal{A}}_{MS}$ to the oracles ${\mathcal{O}}_{k}$ and ${\mathcal{O}}_{sig}$.

- Case 1: b = 1: ${\mathcal{B}}_{MS}$ guesses that ${\mathcal{A}}_{MS}$ will produce a Type I forgery:

- ${\mathcal{O}}_{k}\left({({f}_{i},i)}_{i\ne {i}^{*}}\right)$:
- -
- If there exists an entry for the tuple $({f}_{i},i)$ in the dictionary, then output the corresponding value $s{k}_{f}^{{i}^{*}}$.
- -
- Otherwise, ${\mathcal{B}}_{MS}$ randomly selects ${d}_{{i}^{*}}\leftarrow {Z}_{q}^{*}$ as $s{k}_{{i}^{*}}$, and computes ${d}_{{i}^{*}}P$ as $v{k}_{{i}^{*}}$; ${\mathcal{B}}_{MS}$ obtains ${\sigma}_{v{k}_{{i}^{*}}}\leftarrow {\mathcal{O}}_{Re{g}_{sig}}$ from his oracle, and return $s{k}_{f}^{i}=(s{k}_{{i}^{*}},{\sigma}_{v{k}_{i}})$ to ${\mathcal{A}}_{MS}$. He also updates the dictionary by adding the entry $({f}_{i},i)$.

- ${\mathcal{O}}_{sig}\left({(f,i,m)}_{i\ne {i}^{*}}\right)$:
- -
- If there exists an entry for the tuple $({f}_{i},i)$ in the dictionary, it has the $s{k}_{f}^{i}=(s{k}_{i},{\sigma}_{v{k}_{i}})$. He can generate a signature $Sig\leftarrow {\mathcal{O}}_{Re{g}_{sig}}$. Because he knows all about the corrupted nodes, he can output ${\sigma}_{i}=({m}_{i}^{*},m,{c}_{i},si{g}_{i})$, where ${c}_{i}=({f}_{i},v{k}_{i},{\sigma}_{v{k}_{i}})$ and $si{g}_{i}=Sig-{\sum}_{j=1,j\ne {i}^{*}}^{n}si{g}_{j}$.
- -
- Otherwise, ${\mathcal{B}}_{MS}$ randomly selects ${d}_{{i}^{*}}\leftarrow {Z}_{q}^{*}$ as $s{k}_{{i}^{*}}$, and computes ${d}_{{i}^{*}}P$ as $v{k}_{{i}^{*}}$; ${\mathcal{B}}_{MS}$ obtains ${\sigma}_{v{k}_{{i}^{*}}}\leftarrow {\mathcal{O}}_{Re{g}_{sig}}$ from his oracle, and updates the dictionary by adding the entry $({f}_{i},i)$. He then generates Sig by ${\mathcal{O}}_{Re{g}_{sig}}$, and outputs ${\sigma}_{{i}^{*}}=({m}_{{i}^{*}}^{*},{c}_{{i}^{*}},si{g}_{{i}^{*}})$, where ${c}_{{i}^{*}}=({f}_{{i}^{*}},v{k}_{{i}^{*}},{\sigma}_{v{k}_{{i}^{*}}})$ and $si{g}_{{i}^{*}}=Sig-{\sum}_{i=1,i\ne {i}^{*}}^{n}si{g}_{i}$.

- Case 2: b = 0: ${\mathcal{B}}_{MS}$ guesses that ${\mathcal{A}}_{MS}$ will produce a Type II forgery:

- ${\mathcal{O}}_{k}({f}_{i},i)$:
- -
- If there exists an entry for the tuple $({f}_{i},i)$ in the dictionary with the value CHA, abort.
- -
- If there exists an entry for the tuple $({f}_{i},i)$ in the dictionary with a value that is not CHA, output the key $s{k}_{f}^{i}$.
- -
- Otherwise, ${\mathcal{B}}_{MS}$ randomly selects ${d}_{i}\leftarrow {Z}_{q}^{*}$ as $s{k}_{i}$, and computes ${d}_{i}P$ as $v{k}_{i}$; ${\mathcal{B}}_{MS}$ generates the ${\sigma}_{v{k}_{i}}$ by himself and returns $s{k}_{f}^{i}=(s{k}_{i},{\sigma}_{v{k}_{i}})$ to ${\mathcal{A}}_{MS}$. He also updates the dictionary by adding the entry $({f}_{i},i)$.

- ${\mathcal{O}}_{sig}(f,i,m)$:
- -
- If there exists an entry for the tuple $({f}_{i},i)$ in the dictionary, $s{k}_{f}^{i}=(s{k}_{i},{\sigma}_{v{k}_{i}})$. He generates a signature Sig by himself, and outputs ${\sigma}_{i}=({m}_{i}^{*},m,{c}_{i},si{g}_{i})$, where ${c}_{i}=({f}_{i},v{k}_{i},{\sigma}_{v{k}_{i}})$ and $si{g}_{i}=Sig-{\sum}_{j=1,j\ne {i}^{*}}^{n}si{g}_{j}$.
- -
- If there is no the tuple $({f}_{i},i)$ in the dictionary, and $Numkeys\ne {i}^{*}$, ${\mathcal{B}}_{MS}$ generates a new key pair by randomly choosing the ${d}_{i}\leftarrow {Z}_{q}^{*}$ as $s{k}_{i}$ and computing ${d}_{i}P$ as $v{k}_{i}$; ${\mathcal{B}}_{MS}$ signs ${f}_{i}|v{k}_{i}$ to generate ${\sigma}_{v{k}_{i}}$ by using Msk, and sets tuple $({f}_{i},i)$ in his dictionary to $s{k}_{f}^{i}$. He then generates the signature Sig on message m by using Msk, outputs ${\sigma}_{i}=({m}_{i}^{*},m,{c}_{i},si{g}_{i})$, where ${c}_{i}=({f}_{i},v{k}_{i},{\sigma}_{v{k}_{i}})$ and $si{g}_{i}=Sig-{\sum}_{j=1,j\ne {i}^{*}}^{n}si{g}_{j}$, and sets $Numkeys=Numkeys+1$.
- -
- If there is no tuple $({f}_{i},i)$ in the dictionary and $Numkeys={i}^{*}$, or if the tuple $({f}_{i},i)$ in the dictionary is set to CHA, ${\mathcal{B}}_{MS}$ then generates the signature of m under $Mv{k}^{\prime}$ by oracle ${\mathcal{O}}_{Re{g}_{sig}}$, $Sig\leftarrow {\mathcal{O}}_{Re{g}_{sig}}$, computes ${\sigma}_{v{k}_{i}}$ by using Msk, and outputs ${\sigma}_{i}=({m}_{i}^{*},m,{c}_{i},si{g}_{i})$, where ${c}_{i}=({f}_{i},v{k}_{i},{\sigma}_{v{k}_{i}})$ and $si{g}_{i}=Sig-{\sum}_{j=1,j\ne {i}^{*}}^{n}si{g}_{j}$. If there is no tuple $({f}_{i},i)$ in the dictionary, ${\mathcal{B}}_{MS}$ sets it to CHA. Then $Numkeys=Numkeys+1$.

**Theorem**

**2.**

**Proof**

**of**

**Theorem**

**2.**

## 6. Results

#### 6.1. Complexity Analysis

- ${T}_{h}$: Time costs to run one hash function;
- ${T}_{Gmul}$: Time costs of running one multiplication operation in additive group G;
- ${T}_{Zmul}$: Time costs of running one multiplication operation in field ${Z}_{q}^{*}$;
- ${T}_{Zadd}$: Time costs of running one addition operation in field ${Z}_{q}^{*}$;
- ${T}_{f}$: Time costs of running one $f\left(m\right)$;
- ${T}_{com}$: Time costs for full node to communicate with nodes;
- ${T}_{inv}$: Time costs of running one extended Euclidean algorithm;
- ${T}_{sc}$: Time costs of running one smart contract;
- ${T}_{dh}$: Time costs of running one Diffie–Hellman key exchange.

#### 6.2. Implement

#### 6.3. The Limitations of the Study

## 7. Conclusions

## Author Contributions

## Funding

## Institutional Review Board Statement

## Informed Consent Statement

## Data Availability Statement

## Conflicts of Interest

## References

- Fanning, K.; Centers, D.P. Blockchain and its coming impact on financial services. J. Corp. Account. Financ.
**2016**, 27, 53–57. [Google Scholar] [CrossRef] - Nguyen, Q.K. Blockchain-a financial technology for future sustainable development. In Proceedings of the 2016 3rd International Conference on Green Technology and Sustainable Development (GTSD), Kaohsiung, Taiwan, 24–25 November 2016; pp. 51–54. [Google Scholar]
- Treleaven, P.; Brown, R.G.; Yang, D. Blockchain technology in finance. Computer
**2017**, 50, 14–17. [Google Scholar] [CrossRef] - Saxena, S.; Bhushan, B.; Ahad, M.A. Blockchain based solutions to secure IoT: Background, integration trends and a way forward. J. Netw. Comput. Appl.
**2021**, 181, 103050. [Google Scholar] [CrossRef] - Shaukat, K.; Alam, T.M.; Hameed, I.A.; Khan, W.A.; Abbas, N.; Luo, S. A review on security challenges in internet of things (IoT). In Proceedings of the 2021 26th International Conference on Automation and Computing (ICAC), Portsmouth, UK, 2–4 September 2021; pp. 1–6. [Google Scholar]
- Benisi, N.Z.; Aminian, M.; Javadi, B. Blockchain-based decentralized storage networks: A survey. J. Netw. Comput. Appl.
**2020**, 162, 102656. [Google Scholar] [CrossRef] - Nasir, A.; Shaukat, K.; Khan, K.I.; Hameed, I.A.; Alam, T.M.; Luo, S. What is core and what future holds for blockchain technologies and cryptocurrencies: A bibliometric analysis. IEEE Access
**2020**, 9, 989–1004. [Google Scholar] [CrossRef] - Nakamoto, S.; Bitcoin, A. A peer-to-peer electronic cash system. Bitcoin
**2008**, 4. Available online: https://bitcoin.org/bitcoin.pdf (accessed on 11 March 2023). - Wood, G. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Proj. Yellow Pap.
**2014**, 151, 1–32. [Google Scholar] - Shaukat, K.; Alam, T.M.; Luo, S.; Shabbir, S.; Hameed, I.A.; Li, J.; Abbas, S.K.; Javed, U. A review of time-series anomaly detection techniques: A step to future perspectives. In Advances in Information and Communication: Proceedings of the 2021 Future of Information and Communication Conference (FICC); Springer International Publishing: Vancouver, BC, Canada, 2021. [Google Scholar]
- Javed, U.; Shaukat, K.; Hameed, I.A.; Iqbal, F.; Alam, T.M.; Luo, S. A review of content-based and context-based recommendation systems. Int. J. Emerg. Technol. Learn.
**2021**, 16, 274–306. [Google Scholar] [CrossRef] - Shaukat, K.; Luo, S.; Varadharajan, V. A novel deep learning-based approach for malware detection. Eng. Appl. Artif. Intell.
**2023**, 122, 106030. [Google Scholar] [CrossRef] - Perez, A.T.E.; Rossit, D.A.; Tohme, F.; Vasquez, O.C. Mass customized/personalized manufacturing in Industry 4.0 and blockchain: Research challenges, main problems, and the design of an information architecture. Inf. Fusion
**2022**, 79, 44–57. [Google Scholar] [CrossRef] - Kushwaha, S.S.; Joshi, S.; Singh, D.; Kaur, M.; Lee, H.N. Systematic review of security vulnerabilities in ethereum blockchain smart contract. IEEE Access
**2022**, 10, 6605–6621. [Google Scholar] [CrossRef] - Shaukat, K.; Luo, S.; Varadharajan, V. A novel method for improving the robustness of deep learning-based malware detectors against adversarial attacks. Eng. Appl. Artif. Intell.
**2022**, 116, 105461. [Google Scholar] [CrossRef] - Boyle, E.; Goldwasser, S.; Ivan, I. Functional signatures and pseudorandom functions. In Proceedings of the Public-Key Cryptography–PKC 2014: 17th International Conference on Practice and Theory in Public-Key Cryptography, Buenos Aires, Argentina, 26–28 March 2014; Proceedings 17. pp. 501–519. [Google Scholar]
- Backes, M.; Meiser, S.; Schröder, D. Delegatable functional signatures. In Proceedings of the Public-Key Cryptography–PKC 2016: 19th IACR International Conference on Practice and Theory in Public-Key Cryptography, Taipei, Taiwan, 6–9 March 2016; Proceedings, Part I. pp. 357–386. [Google Scholar]
- Okamoto, T.; Takashima, K. Decentralized Attribute-Based Signatures. In Proceedings of the Public Key Cryptography, Nara, Japan, 26 Feburary–1 March 2013; pp. 125–142. [Google Scholar]
- Lu, H.; Jin, C.; Helu, X.; Zhu, C.; Guizani, N.; Tian, Z. AutoD: Intelligent blockchain application unpacking based on JNI layer deception call. IEEE Netw.
**2020**, 35, 215–221. [Google Scholar] [CrossRef] - MacKenzie, P.; Reiter, M.K. Two-party generation of DSA signatures. In Proceedings of the Advances in Cryptology–CRYPTO 2001: 21st Annual International Cryptology Conference, Santa Barbara, CA, USA, 19–23 August 2001; Proceedings 21. pp. 137–154. [Google Scholar]
- Lindell, Y. Fast secure two-party ECDSA signing. In Proceedings of the Advances in Cryptology–CRYPTO 2017: 37th Annual International Cryptology Conference, Santa Barbara, CA, USA, 20–24 August 2017; Proceedings, Part II 37. pp. 613–644. [Google Scholar]
- Castagnos, G.; Catalano, D.; Laguillaumie, F.; Savasta, F.; Tucker, I. Two-party ECDSA from hash proof systems and efficient instantiations. In Proceedings of the Advances in Cryptology–CRYPTO 2019: 39th Annual International Cryptology Conference, Santa Barbara, CA, USA, 18–22 August 2019; Proceedings, Part III 39. pp. 191–221. [Google Scholar]
- Lindell, Y.; Nof, A. Fast secure multiparty ECDSA with practical distributed key generation and applications to cryptocurrency custody. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, Toronto, ON, Canada, 15–19 October 2018; pp. 1837–1854. [Google Scholar]
- Doerner, J.; Kondi, Y.; Lee, E.; Shelat, A. Threshold ECDSA from ECDSA assumptions: The multiparty case. In Proceedings of the 2019 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 19–23 May 2019; pp. 1051–1066. [Google Scholar]
- Gennaro, R.; Goldfeder, S. Fast multiparty threshold ECDSA with fast trustless setup. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, Toronto, ON, Canada, 15–19 October 2018; pp. 1179–1194. [Google Scholar]
- Shaukat, K.; Luo, S.; Varadharajan, V.; Hameed, I.A.; Chen, S.; Liu, D.; Li, J. Performance comparison and current challenges of using machine learning techniques in cybersecurity. Energies
**2020**, 13, 2509. [Google Scholar] [CrossRef] - Shaukat, K.; Luo, S.; Varadharajan, V.; Hameed, I.A.; Xu, M. A survey on machine learning techniques for cyber security in the last decade. IEEE Access
**2020**, 8, 222310–222354. [Google Scholar] [CrossRef] - Halpin, H.; Piekarska, M. Introduction to Security and Privacy on the Blockchain. In Proceedings of the 2017 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), Paris, France, 26–28 April 2017; pp. 1–3. [Google Scholar]
- Li, X.; Xu, J.; Fan, X.; Wang, Y.; Zhang, Z. Puncturable signatures and applications in proof-of-stake blockchain protocols. IEEE Trans. Inf. Forensics Secur.
**2020**, 15, 3872–3885. [Google Scholar] [CrossRef] - Zhu, Y.; Guo, R.; Gan, G.; Tsai, W.T. Interactive incontestable signature for transactions confirmation in bitcoin blockchain. In Proceedings of the 2016 IEEE 40th Annual Computer Software and Applications Conference (COMPSAC), Atlanta, GA, USA, 10–14 June 2016; Volume 1, pp. 443–448. [Google Scholar]
- Mercer, R. Privacy on the blockchain: Unique ring signatures. arXiv
**2016**, arXiv:1612.01188. [Google Scholar] - Gong, B.; Cui, C.; Hu, M.; Guo, C.; Li, X.; Ren, Y. Anonymous traceability protocol based on group signature for blockchain. Future Gener. Comput. Syst.
**2022**, 127, 160–167. [Google Scholar] [CrossRef] - Kokoris Kogias, E.; Jovanovic, P.; Gailly, N.; Khoffi, I.; Gasser, L.; Ford, B. Enhancing Bitcoin Security and Performance with Strong Consistency via Collective Signing; USENIX Association: Berkeley, CA, USA, 2016. [Google Scholar]
- Zhou, X.; Wu, Q.; Qin, B.; Huang, X.; Liu, J. Distributed bitcoin account management. In Proceedings of the 2016 IEEE Trustcom/BigDataSE/ISPA, Tianjin, China, 23–26 August 2016; pp. 105–112. [Google Scholar]
- Alangot, B.; Suresh, M.; Raj, A.S.; Pathinarupothi, R.K.; Achuthan, K. Reliable collective cosigning to scale blockchain with strong consistency. In Proceedings of the Network and Distributed System Security Symposium (DISS’18), San Diego, CA, USA, 18–21 February 2018; pp. 1932–4537. [Google Scholar]
- Yu, M.; Zhang, J.; Wang, J.; Gao, J.; Xu, T.; Deng, R.; Zhang, Y.; Yu, R. Internet of Things security and privacy-preserving method through nodes differentiation, concrete cluster centers, multi-signature, and blockchain. Int. J. Distrib. Sens. Netw.
**2018**, 14, 1550147718815842. [Google Scholar] [CrossRef] - Maxwell, G.; Poelstra, A.; Seurin, Y.; Wuille, P. Simple schnorr multi-signatures with applications to bitcoin. Des. Codes Cryptogr.
**2019**, 87, 2139–2164. [Google Scholar] [CrossRef] - Yu, H.; Wang, H. Elliptic curve threshold signature scheme for blockchain. J. Inf. Secur. Appl.
**2022**, 70, 103345. [Google Scholar] [CrossRef] - Xiao, Y.; Zhang, P.; Liu, Y. Secure and efficient multi-signature schemes for fabric: An enterprise blockchain platform. IEEE Trans. Inf. Forensics Secur.
**2020**, 16, 1782–1794. [Google Scholar] [CrossRef] - Uganya, G.; Baskar, R. Modified Elliptic Curve Cryptography Multi-Signature Scheme to Enhance Security in Cryptocurrency. Comput. Syst. Sci. Eng.
**2023**, 45, 641–658. [Google Scholar] [CrossRef]

Scheme | Efficiency | Blockchain | Provable Security | Against Collusion Attack |
---|---|---|---|---|

[24] | low | no | yes | no |

[33] | low | yes | uncertain | no |

[34] | low | yes | uncertain | yes |

[37] | high | yes | yes | yes |

[38] | high | yes | yes | no |

[39] | high | yes | yes | yes |

[40] | high | yes | yes | yes |

Mining Node | Full Node | |
---|---|---|

Time costs | ${T}_{{A}_{i}}={T}_{h}+{T}_{Gmul}+3{T}_{Zmul}+\phantom{\rule{0ex}{0ex}}(n+1){T}_{Zadd}+{T}_{sc}+n{T}_{dh}$ | ${T}_{S}=n{T}_{h}+2{T}_{Gmul}+\phantom{\rule{0ex}{0ex}}({n}^{2}+2n-1){T}_{Zmul}+\frac{{n}^{2}+3n}{2}{T}_{Zadd}+\phantom{\rule{0ex}{0ex}}(n+1){T}_{inv}+n{T}_{dh}$ |

Scheme | Blockchain | Provable Security | Against Collusion Attack | Fine-Grained |
---|---|---|---|---|

[24] | no | yes | no | no |

[33] | yes | uncertain | no | no |

[38] | yes | yes | no | no |

[39] | yes | yes | yes | no |

[40] | yes | yes | yes | no |

our | yes | yes | yes | yes |

Length of FunctionSet | Gas Used | USD ($) |
---|---|---|

5 | 948,328 | 0.973 |

10 | 1,115,115 | 1.144 |

15 | 1,281,915 | 1.315 |

20 | 1,448,660 | 1.486 |

**Table 5.**Cost of smart contract under different lengths of functionSet ($gasprice$ = 1.49 $Gwei$ and 1 $ether$ = $1026).

Length of FunctionSet | Function | Gas Used | USD ($) |
---|---|---|---|

5 | invokeF | 64,445 | 0.066 |

addUser | 94,981 | 0.097 | |

deleteUser | 55,675 | 0.057 | |

10 | invokeF | 83,965 | 0.086 |

addUser | 114,502 | 0.117 | |

deleteUser | 75,195 | 0.077 | |

15 | invokeF | 103,486 | 0.106 |

addUser | 134,023 | 0.138 | |

deleteUser | 94,716 | 0.097 | |

20 | invokeF | 123,007 | 0.126 |

addUser | 153,543 | 0.158 | |

deleteUser | 114,237 | 0.117 |

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |

© 2023 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

Zhou, Q.; Zheng, Y.; Wei, K.; Chen, M.; Zeng, Z.
A Multi-Party Functional Signatures Scheme for Private Blockchain. *Cryptography* **2023**, *7*, 21.
https://doi.org/10.3390/cryptography7020021

**AMA Style**

Zhou Q, Zheng Y, Wei K, Chen M, Zeng Z.
A Multi-Party Functional Signatures Scheme for Private Blockchain. *Cryptography*. 2023; 7(2):21.
https://doi.org/10.3390/cryptography7020021

**Chicago/Turabian Style**

Zhou, Quan, Yulong Zheng, Kaijun Wei, Minhui Chen, and Zhikang Zeng.
2023. "A Multi-Party Functional Signatures Scheme for Private Blockchain" *Cryptography* 7, no. 2: 21.
https://doi.org/10.3390/cryptography7020021