<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD Journal Publishing DTD v2.3 20070202//EN" "journalpublishing.dtd">
<article article-type="research-article" dtd-version="2.3" xml:lang="EN" xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">
<front>
<journal-meta>
<journal-id journal-id-type="publisher-id">Front. Phys.</journal-id>
<journal-title>Frontiers in Physics</journal-title>
<abbrev-journal-title abbrev-type="pubmed">Front. Phys.</abbrev-journal-title>
<issn pub-type="epub">2296-424X</issn>
<publisher>
<publisher-name>Frontiers Media S.A.</publisher-name>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="publisher-id">739259</article-id>
<article-id pub-id-type="doi">10.3389/fphy.2021.739259</article-id>
<article-categories>
<subj-group subj-group-type="heading">
<subject>Physics</subject>
<subj-group>
<subject>Original Research</subject>
</subj-group>
</subj-group>
</article-categories>
<title-group>
<article-title>An Ownership Verification Mechanism Against Encrypted Forwarding Attacks in Data-Driven Social Computing</article-title>
<alt-title alt-title-type="left-running-head">Sun et&#x20;al.</alt-title>
<alt-title alt-title-type="right-running-head">Ownership Verification of Encrypted Data</alt-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<name>
<surname>Sun</surname>
<given-names>Zhe</given-names>
</name>
<xref ref-type="aff" rid="aff1">
<sup>1</sup>
</xref>
<uri xlink:href="https://loop.frontiersin.org/people/1390658/overview"/>
</contrib>
<contrib contrib-type="author">
<name>
<surname>Wan</surname>
<given-names>Junping</given-names>
</name>
<xref ref-type="aff" rid="aff1">
<sup>1</sup>
</xref>
</contrib>
<contrib contrib-type="author" corresp="yes">
<name>
<surname>Wang</surname>
<given-names>Bin</given-names>
</name>
<xref ref-type="aff" rid="aff2">
<sup>2</sup>
</xref>
<xref ref-type="corresp" rid="c001">&#x2a;</xref>
</contrib>
<contrib contrib-type="author">
<name>
<surname>Cao</surname>
<given-names>Zhiqiang</given-names>
</name>
<xref ref-type="aff" rid="aff1">
<sup>1</sup>
</xref>
<uri xlink:href="https://loop.frontiersin.org/people/1402981/overview"/>
</contrib>
<contrib contrib-type="author">
<name>
<surname>Li</surname>
<given-names>Ran</given-names>
</name>
<xref ref-type="aff" rid="aff1">
<sup>1</sup>
</xref>
</contrib>
<contrib contrib-type="author">
<name>
<surname>He</surname>
<given-names>Yuanyuan</given-names>
</name>
<xref ref-type="aff" rid="aff3">
<sup>3</sup>
</xref>
</contrib>
</contrib-group>
<aff id="aff1">
<label>
<sup>1</sup>
</label>Cyberspace Institute of Advanced Technology, Guangzhou University, <addr-line>Guangzhou</addr-line>, <country>China</country>
</aff>
<aff id="aff2">
<label>
<sup>2</sup>
</label>College of Electrical Engineering, Zhejiang University, <addr-line>Hangzhou</addr-line>, <country>China</country>
</aff>
<aff id="aff3">
<label>
<sup>3</sup>
</label>School of Cyber Science and Engineering, Huazhong University of Science and Technology, <addr-line>Wuhan</addr-line>, <country>China</country>
</aff>
<author-notes>
<fn fn-type="edited-by">
<p>
<bold>Edited by:</bold> <ext-link ext-link-type="uri" xlink:href="https://loop.frontiersin.org/people/1024765/overview">Peican Zhu</ext-link>, Northwestern Polytechnical University, China</p>
</fn>
<fn fn-type="edited-by">
<p>
<bold>Reviewed by:</bold> <ext-link ext-link-type="uri" xlink:href="https://loop.frontiersin.org/people/1406937/overview">Wei Du</ext-link>, University of Arkansas, United&#x20;States</p>
<p>
<ext-link ext-link-type="uri" xlink:href="https://loop.frontiersin.org/people/1406932/overview">Cheng Huang</ext-link>, University of Waterloo, Canada</p>
</fn>
<corresp id="c001">&#x2a;Correspondence: Bin Wang, <email>bin_wang@zju.edu.cn</email>
</corresp>
<fn fn-type="other">
<p>This article was submitted to Social Physics, a section of the journal Frontiers in Physics</p>
</fn>
</author-notes>
<pub-date pub-type="epub">
<day>07</day>
<month>09</month>
<year>2021</year>
</pub-date>
<pub-date pub-type="collection">
<year>2021</year>
</pub-date>
<volume>9</volume>
<elocation-id>739259</elocation-id>
<history>
<date date-type="received">
<day>10</day>
<month>07</month>
<year>2021</year>
</date>
<date date-type="accepted">
<day>05</day>
<month>08</month>
<year>2021</year>
</date>
</history>
<permissions>
<copyright-statement>Copyright &#xa9; 2021 Sun, Wan, Wang, Cao, Li and He.</copyright-statement>
<copyright-year>2021</copyright-year>
<copyright-holder>Sun, Wan, Wang, Cao, Li and He</copyright-holder>
<license xlink:href="http://creativecommons.org/licenses/by/4.0/">
<p>This is an open-access article distributed under the terms of the Creative Commons Attribution License (CC BY). The use, distribution or reproduction in other forums is permitted, provided the original author(s) and the copyright owner(s) are credited and that the original publication in this journal is cited, in accordance with accepted academic practice. No use, distribution or reproduction is permitted which does not comply with these&#x20;terms.</p>
</license>
</permissions>
<abstract>
<p>Data-driven deep learning has accelerated the spread of social computing applications. To develop a reliable social application, service providers need massive data on human behavior and interactions. As the data is highly relevant to users&#x2019; privacy, researchers have conducted extensive research on how to securely build a collaborative training model. Cryptography methods are an essential component of collaborative training which is used to protect privacy information in gradients. However, the encrypted gradient is semantically invisible, so it is difficult to detect malicious participants forwarding other&#x2019;s gradient to profit unfairly. In this paper, we propose a data ownership verification mechanism based on &#x3a3;-protocol and Pedersen commitment, which can help prevent gradient stealing behavior. We deploy the Paillier algorithm on the encoded gradient to protect privacy information in collaborative training. In addition, we design a united commitment scheme to complete the verification process of commitments in batches, and reduce verification consumption for aggregators in large-scale social computing. The evaluation of the experiments demonstrates the effectiveness and efficiency of our proposed mechanism.</p>
</abstract>
<kwd-group>
<kwd>ownership verification</kwd>
<kwd>cryptography-based privacy-preserving</kwd>
<kwd>pedersen commitment</kwd>
<kwd>&#x3a3;-protocol</kwd>
<kwd>social computing</kwd>
</kwd-group>
<contract-sponsor id="cn001">National Key Research and Development Program of China<named-content content-type="fundref-id">10.13039/501100012166</named-content>
</contract-sponsor>
<contract-sponsor id="cn002">China Postdoctoral Science Foundation<named-content content-type="fundref-id">10.13039/501100002858</named-content>
</contract-sponsor>
</article-meta>
</front>
<body>
<sec id="s1">
<title>Introduction</title>
<p>Social computing, a field highly relevant to human behavior, has made considerable progress in recent years. With the proliferation of cell phones and IoT devices, information about humans, behaviors, and interactions is being recorded in unprecedented detail. Combined with deep learning models, the application of social computing can profoundly solve various industry challenges such as epidemic prediction [<xref ref-type="bibr" rid="B1">1</xref>, <xref ref-type="bibr" rid="B2">2</xref>], social network service [<xref ref-type="bibr" rid="B3">3</xref>], and hot topic recommendations [<xref ref-type="bibr" rid="B4">4</xref>]. For example, data-driven epidemic propagation can help governments and hospitals prepare resources in advance [<xref ref-type="bibr" rid="B1">1</xref>]. Moreover, some well-designed pre-diagnosis models of COVID-19 may alleviate physician shortages&#x20;[<xref ref-type="bibr" rid="B2">2</xref>].</p>
<p>As a data-driven technology, deep learning has a natural desire for data to be more accurate and higher-quality. Since user data in social computing is closely tied to privacy, providing the data directly would cause extremely serious privacy damage. Google [<xref ref-type="bibr" rid="B5">5</xref>] proposed the concept of federated learning in 2016, which is an innovation in collaborative training. Without directly obtaining local data from multiple parties, it can take full advantage of the value of the data by sharing gradients. However, transmitted gradients are subject to model inversion attacks, attribute inference attacks, membership inference attacks, etc. Thus, the privacy of users requires further protection.</p>
<p>To resolve the problem of privacy leakage in transmitted gradients, researchers have proposed a wide range of solutions that can be roughly divided into two categories: differential privacy [<xref ref-type="bibr" rid="B6">6</xref>] and cryptographic algorithms [<xref ref-type="bibr" rid="B7">7</xref>]. Differential privacy is a method of adding noise so that the attacker cannot determine the user&#x2019;s exact gradient. However, the differential privacy-based method modifies the original data, resulting in a loss of model accuracy. Unlike differential privacy methods, cryptographic algorithms such as homomorphic encryption do not alter the value of the gradient. But instead, they prevent third parties and model aggregators from obtaining a single participant&#x2019;s model parameters by encryption or concealment. Most cryptography-based parameter protection methods have a higher arithmetic overhead and many researchers are committed to optimizing their overhead.</p>
<p>Apart from performance issues, cryptography-based privacy-preserving methods will also introduce a derivative problem. Because of the semantic invisibility of encrypted data, data aggregators cannot judge whether a problem exists. The most obvious problem associated with data invisibility is that data tampering is difficult to detect, and some work has been done to try to resolve this. Li et&#x20;al. [<xref ref-type="bibr" rid="B8">8</xref>] proposed to store verification tags on the blockchain and generate a Merkle tree as proof. The transaction information must be uploaded to the blockchain, which prevents malicious users from tampering during the training process. Weng et&#x20;al. [<xref ref-type="bibr" rid="B9">9</xref>] proposed a blockchain-based auditing model called Deepchain that considers the malicious behavior of model aggregators.</p>
<p>However, another problem of semantic invisibility in encrypted data was left behind. Cryptography methods blur the user&#x2019;s ownership of the real information corresponding to the ciphertext data during the transaction. Malicious users can steal historically encrypted gradients from publicly audited information or previous transactions, and upload them elsewhere to gain benefits, in what we call an encrypted forwarding attack. The attack will destroy the fairness of the entire system, and make fewer users willing to participate in collaborative training. Recently, researchers have proposed extracting user data features through the first few layers of deep neural networks, making them adaptable to multiple uncertain deep learning tasks [<xref ref-type="bibr" rid="B10">10</xref>, <xref ref-type="bibr" rid="B11">11</xref>]. This will lead to a change in traditional collaborative training from focusing on a single defined task to completing multiple uncertain tasks, further expanding the reach of encrypted forwarding attacks.</p>
<p>In this paper, we aim to resolve the problem of encrypted forwarding attacks in collaborative training. To prevent users from submitting others&#x2019; encrypted gradients maliciously, users need to use Pedersen commitment to commit on the uploaded gradient. The model aggregator can verify the ownership of the encrypted gradient by determining whether the user has plaintext. Our main contributions are as follows:<list list-type="simple">
<list-item>
<p>&#x2022; We propose a data ownership verification mechanism to counter encrypted forwarding attacks caused by cryptography-based privacy-preserving methods. We use an interactive &#x3a3;-protocol and Pedersen commitment algorithm to prove that the user has the plaintext corresponding to the encrypted gradients.</p>
</list-item>
<list-item>
<p>&#x2022; We design a united commitment scheme to complete the verification process of commitments in batches, thereby reducing verification consumption for the aggregator.</p>
</list-item>
<list-item>
<p>&#x2022; We verify the effectiveness of the model on a social face dataset CelebA and a digital recognition dataset MNIST, then provide a safety analysis. The experimental results demonstrate that the commitment scheme does not impose an additional burden on secure aggregation of social applications.</p>
</list-item>
</list>
</p>
<p>The rest of this paper is organized as follows. In <italic>Related Work</italic>, we introduce the existing work of cryptography-based privacy-preserving methods and derivative audits approaches of encrypted data. <italic>Preliminaries</italic> introduces the relevant background knowledge of the &#x3a3;-protocol, Pedersen commitment, and attack models. <italic>System Design</italic> elaborates the details of the ownership verification mechanism. In <italic>Security Analysis</italic>, we analyze the correctness and safety of our mechanism. <italic>Experimental Results</italic> evaluates and analyses the performance of Paillier algorithm and Pedersen commitment in our mechanism. Finally, we conclude our paper in <italic>Conclusion</italic>.</p>
</sec>
<sec id="s2">
<title>Related Work</title>
<sec id="s2-1">
<title>Cryptography-Based Privacy-Preserving Methods in Collaborative Training</title>
<p>Privacy concern is one of the main problems in collaborative training. Although some collaborative training allows collaborative participants to only share model updates rather than raw training data, such as federated learning. There are still some privacy problems that are not completely solved [<xref ref-type="bibr" rid="B12">12</xref>&#x2013;<xref ref-type="bibr" rid="B14">14</xref>]. Attackers may infer whether a sample exists in the training dataset or contain certain privacy attributes from the user gradient, called member inference attacks [<xref ref-type="bibr" rid="B15">15</xref>] and attribute inference attacks&#x20;[<xref ref-type="bibr" rid="B16">16</xref>].</p>
<p>Secure aggregation [<xref ref-type="bibr" rid="B17">17</xref>] is a cryptography-based privacy-preserving method that prevents aggregators from gaining direct access to individual participants&#x2019; gradients and committing privacy attacks. Homomorphic encryption is a common security aggregation algorithm that allows users to operate on ciphertext and decrypt the results of operations, where the decryption result is the same as for operating on plaintext. Participants can first encrypt the gradient <italic>via</italic> homomorphic encryption. The parameter aggregator then aggregates all encrypted gradients and decrypts the aggregated result, thereby indirectly obtaining a global model update contributed by the participants. The existing homomorphic encryption methods are mainly based on full-homomorphic encryption [<xref ref-type="bibr" rid="B18">18</xref>] and semi-homomorphic encryption&#x20;[<xref ref-type="bibr" rid="B19">19</xref>].</p>
<p>Fully homomorphic encryption is mainly based on ideal lattices theory [<xref ref-type="bibr" rid="B20">20</xref>]. It relies on a large number of polynomial-based power operations and modulo operations, which greatly increases the consumption of implementation. It is still difficult to apply directly in the existing&#x20;work.</p>
<p>Paillier encryption [<xref ref-type="bibr" rid="B19">19</xref>] is a representative work of semi-homomorphism that is widely used because of its simple structure. Phong et&#x20;al. [<xref ref-type="bibr" rid="B21">21</xref>] proposed the method combining asynchronous stochastic gradient descent and Paillier homomorphic encryption. They proved that the system could prevent the aggregator from learning the data privacy of the participants, and ensure the availability of the model training with the acceptable system overhead. Zhou et&#x20;al. [<xref ref-type="bibr" rid="B22">22</xref>] applied a homomorphic encryption scheme to fog computing. They proposed a scheme that combines Paillier encryption and blindness technology, which can resist collusion attacks by multiple malicious entities.</p>
<p>In order to improve the efficiency of the homomorphic encryption system, Zhang et&#x20;al. [<xref ref-type="bibr" rid="B23">23</xref>] proposed a federated learning model called BatchCrypt. They encoded batches of gradients and perform homomorphic encryption with less time, which greatly reduces the overhead of the whole system. LWE has more extensive applicability because of its full-homomorphism. Hao et&#x20;al. [<xref ref-type="bibr" rid="B24">24</xref>] utilized and improved the BGV algorithm based on LWE, which achieves the secure aggregation of gradients to prevent privacy disclosure. It makes the scheme based on homomorphic encryption practical.</p>
<p>The above works complete the data privacy protection for the participants and make the system feasible, but another potential problem has appeared: it is difficult for the aggregator to determine whether a problem exists due to the semantic invisibility of the encrypted&#x20;data.</p>
</sec>
<sec id="s2-2">
<title>Verification of Secure Aggregation</title>
<p>Semantic invisibility of encrypted data presents numerous challenges, including transmission errors, malicious tampering by intermediaries, and the exclusion of some user-generated gradients by dishonest aggregators.</p>
<p>The correctness audit of the transmission gradient becomes very difficult in the encrypted state. Weng et&#x20;al. [<xref ref-type="bibr" rid="B9">9</xref>] provided an audit mechanism based on &#x2211;-protocol [<xref ref-type="bibr" rid="B25">25</xref>] which generates proofs of correctness for each gradient. Guo et&#x20;al. [<xref ref-type="bibr" rid="B26">26</xref>] proposed a Paillier-based zero-knowledge proof algorithm. The server and users can jointly calculate the statement of encrypted gradients to prove the correctness of gradients.</p>
<p>To ensure that the gradients provided by each participant are indeed aggregated correctly, Xu et&#x20;al. [<xref ref-type="bibr" rid="B27">27</xref>] use a homomorphic hash technique combined with pseudorandom function to help users verify the correctness of aggregation. To extend the applicability of the algorithm, Guo et&#x20;al. [<xref ref-type="bibr" rid="B28">28</xref>] proposed a commitment scheme based on linearly homomorphic hash to verify the integrity of aggregation. Before sending gradient to the server, the users need to generate and exchange the hash value of their gradient. The users can verify whether the gradient is tampered with by checking hash values.</p>
<p>Despite the foregoing, there is a serious problem that has not been addressed. Encrypted data may be accessed by multiple users as public data. Malicious users can forward them to other collaborative tasks with the same purpose for improper profit. There are even cases where multiple users claim ownership of ciphertext in the same task. This will undermine the willingness of honest users to engage in collaborative training and thus lead to a shortage of training data for social applications. In this paper, we propose an ownership verification mechanism based on the Patterson commitment that can prove that the user owns the plaintext of the data without providing the plaintext.</p>
</sec>
</sec>
<sec id="s3">
<title>Preliminaries</title>
<p>In this section, we briefly recall the definition of &#x3a3;-protocol and Pedersen commitment, and introduce the attack models.</p>
<sec id="s3-1">
<title>&#x3a3;-protocol</title>
<p>&#x3a3;-protocol [<xref ref-type="bibr" rid="B25">25</xref>] is a two-party interaction protocol in zero-knowledge proof field. It is used to prove that someone knows a secret without disclosing it. There are many classic examples such as Schnorr&#x2019;s protocol [<xref ref-type="bibr" rid="B29">29</xref>], which is used for authentication.</p>
<p>Consider a binary relation <inline-formula id="inf1">
<mml:math id="m1">
<mml:mi>R</mml:mi>
</mml:math>
</inline-formula> and an element <inline-formula id="inf2">
<mml:math id="m2">
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mi>x</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>y</mml:mi>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>&#x2208;</mml:mo>
<mml:mi>R</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, and we have <inline-formula id="inf3">
<mml:math id="m3">
<mml:mrow>
<mml:mi>f</mml:mi>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mi>x</mml:mi>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:mi>y</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, where <inline-formula id="inf4">
<mml:math id="m4">
<mml:mi>x</mml:mi>
</mml:math>
</inline-formula> is called the pre-image of <inline-formula id="inf5">
<mml:math id="m5">
<mml:mi>y</mml:mi>
</mml:math>
</inline-formula> under a mapping <inline-formula id="inf6">
<mml:math id="m6">
<mml:mi>f</mml:mi>
</mml:math>
</inline-formula>. In &#x3a3;-protocol, we think of <inline-formula id="inf7">
<mml:math id="m7">
<mml:mi>x</mml:mi>
</mml:math>
</inline-formula> as a witness and <inline-formula id="inf8">
<mml:math id="m8">
<mml:mi>y</mml:mi>
</mml:math>
</inline-formula> as the corresponding instance for <inline-formula id="inf9">
<mml:math id="m9">
<mml:mi>x</mml:mi>
</mml:math>
</inline-formula>, where <inline-formula id="inf10">
<mml:math id="m10">
<mml:mi>x</mml:mi>
</mml:math>
</inline-formula> and <inline-formula id="inf11">
<mml:math id="m11">
<mml:mi>y</mml:mi>
</mml:math>
</inline-formula> are finite values.</p>
<p>Suppose that there are two parties, one of which is prover, and the other is verifier. Without exposing <inline-formula id="inf12">
<mml:math id="m12">
<mml:mi>x</mml:mi>
</mml:math>
</inline-formula>, the prover wants to prove to the verifier that he knows the pre-image value <inline-formula id="inf13">
<mml:math id="m13">
<mml:mi>x</mml:mi>
</mml:math>
</inline-formula> of <inline-formula id="inf14">
<mml:math id="m14">
<mml:mi>y</mml:mi>
</mml:math>
</inline-formula> under the mapping <inline-formula id="inf15">
<mml:math id="m15">
<mml:mi>f</mml:mi>
</mml:math>
</inline-formula>. As shown in <xref ref-type="fig" rid="F1">Figure&#x20;1</xref>, they need to follow &#x3a3;-protocol with the steps below:</p>
<fig id="F1" position="float">
<label>FIGURE 1</label>
<caption>
<p>The general process of &#x3a3;-protocols.</p>
</caption>
<graphic xlink:href="fphy-09-739259-g001.tif"/>
</fig>
<p>Step 1: Prover computes a commitment <inline-formula id="inf16">
<mml:math id="m16">
<mml:mi>c</mml:mi>
</mml:math>
</inline-formula> with the value of, and sends it to verifier.</p>
<p>Step 2: Verifier returns a random value <inline-formula id="inf17">
<mml:math id="m17">
<mml:mi>e</mml:mi>
</mml:math>
</inline-formula> called challenge to prover.</p>
<p>Step 3: Prover sends a response <inline-formula id="inf18">
<mml:math id="m18">
<mml:mi>z</mml:mi>
</mml:math>
</inline-formula> to verifier. It is computed with <inline-formula id="inf19">
<mml:math id="m19">
<mml:mi>x</mml:mi>
</mml:math>
</inline-formula> and&#x20;<inline-formula id="inf20">
<mml:math id="m20">
<mml:mi>e</mml:mi>
</mml:math>
</inline-formula>.</p>
<p>Step 4: Verifier uses instance <inline-formula id="inf21">
<mml:math id="m21">
<mml:mi>y</mml:mi>
</mml:math>
</inline-formula> and the message <inline-formula id="inf22">
<mml:math id="m22">
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mi>c</mml:mi>
<mml:mo>,</mml:mo>
<mml:mo>&#xa0;</mml:mo>
<mml:mi>e</mml:mi>
<mml:mo>,</mml:mo>
<mml:mo>&#xa0;</mml:mo>
<mml:mi>z</mml:mi>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> generated in previous steps to compute the verification result.</p>
<p>Since the challenge <inline-formula id="inf23">
<mml:math id="m23">
<mml:mi>e</mml:mi>
</mml:math>
</inline-formula> is randomly selected, if the prover does not know the witness x, he cannot use challenge <inline-formula id="inf24">
<mml:math id="m24">
<mml:mi>e</mml:mi>
</mml:math>
</inline-formula> to compute a correct response <inline-formula id="inf25">
<mml:math id="m25">
<mml:mi>z</mml:mi>
</mml:math>
</inline-formula> in Step 3. When the verification passes, the verifier is convinced that the prover knows the witness <inline-formula id="inf26">
<mml:math id="m26">
<mml:mi>x</mml:mi>
</mml:math>
</inline-formula>. The witness in our ownership verification mechanism can be a secret gradient used for social computing. A user can prove that it knows the secret gradient <inline-formula id="inf27">
<mml:math id="m27">
<mml:mi>x</mml:mi>
</mml:math>
</inline-formula> corresponding to the commitment<inline-formula id="inf28">
<mml:math id="m28">
<mml:mi>c</mml:mi>
</mml:math>
</inline-formula>
</p>
</sec>
<sec id="s3-2">
<title>Pedersen Commitment</title>
<p>Pedersen commitment [<xref ref-type="bibr" rid="B30">30</xref>] is a homomorphic commitment scheme, in which one computes a commitment bound to a chosen value. Pedersen commitment scheme can be used to prove that a committed value is not tampered with. According to its homomorphism, it is usually used to prove that the secret committed data satisfies certain binding relationships. The scheme consists of a commitment phase and a verification phase. In the beginning, A trusted third party selects a multiplicative group <inline-formula id="inf29">
<mml:math id="m29">
<mml:mi>G</mml:mi>
</mml:math>
</inline-formula> with the order of large prime <inline-formula id="inf30">
<mml:math id="m30">
<mml:mi>q</mml:mi>
</mml:math>
</inline-formula>, then selects two prime elements <inline-formula id="inf31">
<mml:math id="m31">
<mml:mi>g</mml:mi>
</mml:math>
</inline-formula> and <inline-formula id="inf32">
<mml:math id="m32">
<mml:mi>h</mml:mi>
</mml:math>
</inline-formula> of group <inline-formula id="inf33">
<mml:math id="m33">
<mml:mi>G</mml:mi>
</mml:math>
</inline-formula>, where no one knows the value <inline-formula id="inf34">
<mml:math id="m34">
<mml:mi>x</mml:mi>
</mml:math>
</inline-formula> to make <inline-formula id="inf35">
<mml:math id="m35">
<mml:mrow>
<mml:mi>g</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mi>x</mml:mi>
<mml:mi>&#x2217;</mml:mi>
<mml:mi>h</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>. After the committer and verifier agree on two elements <inline-formula id="inf36">
<mml:math id="m36">
<mml:mi>g</mml:mi>
</mml:math>
</inline-formula> and <inline-formula id="inf37">
<mml:math id="m37">
<mml:mi>h</mml:mi>
</mml:math>
</inline-formula>, they follow the process as follows:</p>
<p>
<bold>Commitment:</bold> To commit to secret value <inline-formula id="inf38">
<mml:math id="m38">
<mml:mi>v</mml:mi>
</mml:math>
</inline-formula>, the committer chooses a random value <inline-formula id="inf39">
<mml:math id="m39">
<mml:mi>r</mml:mi>
</mml:math>
</inline-formula>, computes commitment <inline-formula id="inf40">
<mml:math id="m40">
<mml:mrow>
<mml:mi mathvariant="italic">comm</mml:mi>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mi>v</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:mi>v</mml:mi>
<mml:mi>&#x2217;</mml:mi>
<mml:mi>g</mml:mi>
<mml:mo>&#x2b;</mml:mo>
<mml:mi>r</mml:mi>
<mml:mi>&#x2217;</mml:mi>
<mml:mi>h</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> and sends it to verifier.</p>
<p>
<bold>Verification:</bold> Committer sends <inline-formula id="inf41">
<mml:math id="m41">
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mi>v</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> to verifier. Verifier use <inline-formula id="inf42">
<mml:math id="m42">
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mi>v</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> to computes <inline-formula id="inf43">
<mml:math id="m43">
<mml:mrow>
<mml:mi>c</mml:mi>
<mml:mi>o</mml:mi>
<mml:mi>m</mml:mi>
<mml:msup>
<mml:mi>m</mml:mi>
<mml:mo>&#x2032;</mml:mo>
</mml:msup>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mi>v</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>r</mml:mi>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:mi>v</mml:mi>
<mml:mi>&#x2217;</mml:mi>
<mml:mi>g</mml:mi>
<mml:mo>&#x2b;</mml:mo>
<mml:mi>r</mml:mi>
<mml:mi>&#x2217;</mml:mi>
<mml:mi>h</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> and checks whether it is equal to <inline-formula id="inf44">
<mml:math id="m44">
<mml:mrow>
<mml:mi>c</mml:mi>
<mml:mi>o</mml:mi>
<mml:mi>m</mml:mi>
<mml:mi>m</mml:mi>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mi>v</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>r</mml:mi>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>. If the verification passed, it means that <inline-formula id="inf45">
<mml:math id="m45">
<mml:mi>v</mml:mi>
</mml:math>
</inline-formula> is not tampered&#x20;with.</p>
<p>Pedersen commitment scheme is designed that the sum of two commitments can also be seen as a commitment. It can be represented by <inline-formula id="inf46">
<mml:math id="m46">
<mml:mrow>
<mml:mi>c</mml:mi>
<mml:mi>o</mml:mi>
<mml:mi>m</mml:mi>
<mml:mi>m</mml:mi>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>v</mml:mi>
<mml:mn>3</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>r</mml:mi>
<mml:mn>3</mml:mn>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:mi>c</mml:mi>
<mml:mi>o</mml:mi>
<mml:mi>m</mml:mi>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>v</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>r</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>&#x2b;</mml:mo>
<mml:mi>c</mml:mi>
<mml:mi>o</mml:mi>
<mml:mi>m</mml:mi>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>v</mml:mi>
<mml:mn>2</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>r</mml:mi>
<mml:mn>2</mml:mn>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>, where <inline-formula id="inf47">
<mml:math id="m47">
<mml:mrow>
<mml:msub>
<mml:mi>v</mml:mi>
<mml:mn>3</mml:mn>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:msub>
<mml:mi>v</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo>&#x2b;</mml:mo>
<mml:msub>
<mml:mi>v</mml:mi>
<mml:mn>2</mml:mn>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>, <inline-formula id="inf48">
<mml:math id="m48">
<mml:mrow>
<mml:msub>
<mml:mi>r</mml:mi>
<mml:mn>3</mml:mn>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:msub>
<mml:mi>r</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo>&#x2b;</mml:mo>
<mml:msub>
<mml:mi>r</mml:mi>
<mml:mn>2</mml:mn>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>. It seems like someone use a random value <inline-formula id="inf49">
<mml:math id="m49">
<mml:mrow>
<mml:msub>
<mml:mi>r</mml:mi>
<mml:mn>3</mml:mn>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> to commit to&#x20;<inline-formula id="inf50">
<mml:math id="m50">
<mml:mrow>
<mml:msub>
<mml:mi>v</mml:mi>
<mml:mn>3</mml:mn>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>.</p>
<p>Pedersen commitment scheme has the following properties: 1) Perfectly hiding: the <inline-formula id="inf51">
<mml:math id="m51">
<mml:mi>r</mml:mi>
</mml:math>
</inline-formula> in the commitment computation is randomly chosen, so two commitments to one value will be different. No one can find a correlation between commitment and committed value. 2) Computationally binding: the commitments on different messages are different, which means that the malicious party cannot deny the value he committed. A more detailed introduction and proof can be seen in&#x20;[<xref ref-type="bibr" rid="B30">30</xref>].</p>
<p>Different from &#x3a3;-protocol, the committed value in Pedersen commitment scheme needs to be revealed in the verification phase. It cannot be directly used to prove that the single encrypted gradient is not tampered with. In our scheme, we use the homomorphism of Pedersen commitment scheme to check whether the aggregated commitment is correctly corresponding to the aggregated gradient, further confirming the binding relationship between the commitment and encrypted gradient.</p>
</sec>
<sec id="s3-3">
<title>Threat Models</title>
<p>As we attempt to solve the problem of data silos in social computing through cooperative training, privacy protection and data ownership have become unavoidable difficulties. Cryptography-based secure aggregation methods can be a good solution to keep private information from being accessed by unauthorized users, but they also make it more difficult to verify data ownership. Two main roles are included in the current collaborative training:</p>
<p>Model Aggregator is a service provider that publishes the request for data training. It asks multiple users to provide trained gradients to conduct social computing.</p>
<p>Data Owners are users who have datasets and are willing to participate in collaborative training. They submit the trained models or gradients to the model aggregator for model updating.</p>
<p>Once we use a cryptography-based secure aggregation algorithm that prevents model aggregators from obtaining plaintext data from a single data owner. It is difficult to distinguish whether the user who submits encrypted data is its real owner or not. As shown in <xref ref-type="fig" rid="F2">Figure&#x20;2</xref>, attackers can download encrypted data from elsewhere or historically, and then participate in the current cooperative training for improper profit, which we call encrypted forwarding attacks. In addition, we present several threat scenarios for encrypted forwarding attacks.</p>
<fig id="F2" position="float">
<label>FIGURE 2</label>
<caption>
<p>Encrypted forwarding attacks in cooperative training.</p>
</caption>
<graphic xlink:href="fphy-09-739259-g002.tif"/>
</fig>
<p>
<bold>Threat 1. Attackers can only obtain encrypted data and claim ownership of the encrypted data</bold>. Malicious users access encrypted data through public channels, such as the&#x20;available audit information or publicly accessible blocks on the blockchain. The encrypted data is being downloaded by attackers and forwarded to similar tasks for unfair&#x20;gain.</p>
<p>
<bold>Threat 2. Attackers can obtain encrypted data as well as its verification information</bold>. As an intermediate forwarder, a&#x20;malicious user receives not only the encrypted data but also&#x20;the previous verification information. By masquerading as a data owner and participating in social computing, traditional mechanisms of ownership verification may be bypassed.</p>
<p>
<bold>Security Goal:</bold> To prevent encrypted forwarding attacks by malicious attackers, we need an ownership verification mechanism for encrypted data. For privacy reasons, it can conclusively confirm ownership of data without directly obtaining the plaintext of user&#x2019;s data. In addition, verification information must be real-time to prevent falsification by forwarding historical verification information.</p>
</sec>
</sec>
<sec id="s4">
<title>System Design</title>
<p>In this section, we present the specific construction of our data ownership verification mechanism. Our mechanism prevents the leakage of user information to curious aggregators while resisting encrypted forwarding attacks by malicious users, as detailed in the threat&#x20;model.</p>
<sec id="s4-1">
<title>System Overview</title>
<p>We suppose that there exist many users who possess private training data in a community. They all agree on the structure and configuration of a common task model. When a user wants to update its model, it claims to be a model aggregator and requests collaborative training from other users. Other data owners will respond to the model aggregator. We denote the model aggregator as <inline-formula id="inf52">
<mml:math id="m52">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> and data owners as <inline-formula id="inf53">
<mml:math id="m53">
<mml:mrow>
<mml:mi>o</mml:mi>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>,<inline-formula id="inf54">
<mml:math id="m54">
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x2208;</mml:mo>
<mml:mrow>
<mml:mo>{</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>,</mml:mo>
<mml:mo>&#x22ef;</mml:mo>
<mml:mo>,</mml:mo>
<mml:mi>N</mml:mi>
<mml:mo>}</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>
</p>
<p>The aggregator <inline-formula id="inf55">
<mml:math id="m55">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> then collects gradients from these data owners to update its task model. The process of gradient collecting is shown in <xref ref-type="fig" rid="F3">Figure&#x20;3</xref>.</p>
<fig id="F3" position="float">
<label>FIGURE 3</label>
<caption>
<p>The workflow of our system.</p>
</caption>
<graphic xlink:href="fphy-09-739259-g003.tif"/>
</fig>
<sec id="s4-1-1">
<title>Phase 1. Initialization</title>
<p>A user claims to be an aggregator to all other users in the community. Others will respond to the claim and form a group with the aggregator by some means [<xref ref-type="bibr" rid="B31">31</xref>]. After that, a trusted institution executes the initialization of threshold Paillier algorithm and Pedersen commitment scheme for the&#x20;group.</p>
</sec>
<sec id="s4-1-2">
<title>Phase 2. Gradient Aggregation</title>
<p>After each data owner <inline-formula id="inf56">
<mml:math id="m56">
<mml:mrow>
<mml:mi>o</mml:mi>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> gets gradient <inline-formula id="inf57">
<mml:math id="m57">
<mml:mrow>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> through local training, it uses the threshold Paillier algorithm to encrypt it to cipher <inline-formula id="inf58">
<mml:math id="m58">
<mml:mrow>
<mml:msub>
<mml:mi>c</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>, then uploads it to the aggregator <inline-formula id="inf59">
<mml:math id="m59">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>. The aggregator <inline-formula id="inf60">
<mml:math id="m60">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> will aggregate the gradients.</p>
</sec>
<sec id="s4-1-3">
<title>Phase 3. Commitment Submission</title>
<p>Each data owner <inline-formula id="inf61">
<mml:math id="m61">
<mml:mrow>
<mml:mi>o</mml:mi>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> who has uploaded gradient uses gradient <inline-formula id="inf62">
<mml:math id="m62">
<mml:mrow>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mtext>&#xa0;</mml:mtext>
</mml:mrow>
</mml:math>
</inline-formula>to compute a commitment <inline-formula id="inf63">
<mml:math id="m63">
<mml:mrow>
<mml:mi>c</mml:mi>
<mml:mi>o</mml:mi>
<mml:mi>m</mml:mi>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> based on Pedersen commitment scheme and uploads it to the aggregator&#x20;<inline-formula id="inf64">
<mml:math id="m64">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>.</p>
</sec>
<sec id="s4-1-4">
<title>Phase 4. Verification and Decryption</title>
<p>The aggregator <inline-formula id="inf65">
<mml:math id="m65">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> conducts the verification of commitment with each data owner<inline-formula id="inf66">
<mml:math id="m66">
<mml:mrow>
<mml:mo>&#xa0;</mml:mo>
<mml:mi>o</mml:mi>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>. If the verification passes, the aggregator <inline-formula id="inf67">
<mml:math id="m67">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> asks data owners to collaboratively decrypt the aggregated gradient. At last, the aggregator <inline-formula id="inf68">
<mml:math id="m68">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> confirms the ownership of gradients by checking commitments and gradients.</p>
<p>After the aggregator <inline-formula id="inf69">
<mml:math id="m69">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> and all data owners have finished the process as above, the aggregator will pay each data owner for the model update. We can think that they have finished a round of secure aggregation.</p>
</sec>
</sec>
<sec id="s4-2">
<title>Gradient Aggregation Based on Paillier Algorithm</title>
<p>
<bold>
<italic>Initialization:</italic>
</bold> After the aggregator and data owners form a group together, a trusted institution will execute the initialization process. Concretely, it confirms the scale of the group and initializes the <inline-formula id="inf70">
<mml:math id="m70">
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mi>l</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>N</mml:mi>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> threshold Paillier algorithm, where <inline-formula id="inf71">
<mml:math id="m71">
<mml:mi>N</mml:mi>
</mml:math>
</inline-formula> is the number of data owners and <inline-formula id="inf72">
<mml:math id="m72">
<mml:mrow>
<mml:mi>l</mml:mi>
<mml:mo>&#x2208;</mml:mo>
<mml:mrow>
<mml:mo>{</mml:mo>
<mml:mrow>
<mml:mfrac>
<mml:mi>N</mml:mi>
<mml:mn>3</mml:mn>
</mml:mfrac>
<mml:mo>&#x2b;</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>,</mml:mo>
<mml:mo>&#xa0;</mml:mo>
<mml:mn>...</mml:mn>
<mml:mo>,</mml:mo>
<mml:mo>&#xa0;</mml:mo>
<mml:mi>N</mml:mi>
</mml:mrow>
<mml:mo>}</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> is the least number of data owners together to decrypt a cipher. The concrete process is shown in <xref ref-type="other" rid="Algorithm_1">Algorithm&#x20;1</xref>.</p>
<p>
<statement content-type="algorithm" id="Algorithm_1">
<label>
</label>
<p>
<inline-graphic xlink:href="fphy-09-739259-fx1.tif"/>
</p>
<p>The trusted institution publishes the public key <inline-formula id="inf96">
<mml:math id="m96">
<mml:mrow>
<mml:mi>P</mml:mi>
<mml:mi>K</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mrow>
<mml:mover accent="true">
<mml:mi>g</mml:mi>
<mml:mo>&#xaf;</mml:mo>
</mml:mover>
</mml:mrow>
<mml:mo>,</mml:mo>
<mml:mi>n</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>&#x3b8;</mml:mi>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>. It also distributes shares of private key <inline-formula id="inf97">
<mml:math id="m97">
<mml:mrow>
<mml:mi>S</mml:mi>
<mml:msub>
<mml:mi>K</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> and verification key <inline-formula id="inf98">
<mml:math id="m98">
<mml:mrow>
<mml:mi>V</mml:mi>
<mml:msub>
<mml:mi>K</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> to each data owner <inline-formula id="inf99">
<mml:math id="m99">
<mml:mrow>
<mml:mi>o</mml:mi>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>, respectively.</p>
<p>
<bold>
<italic>Encoding of gradient:</italic>
</bold> The homomorphism of Paillier algorithm can be represented as <inline-formula id="inf100">
<mml:math id="m100">
<mml:mrow>
<mml:munder>
<mml:mstyle displaystyle="true">
<mml:mo>&#x220f;</mml:mo>
</mml:mstyle>
<mml:mi>i</mml:mi>
</mml:munder>
<mml:mi>E</mml:mi>
<mml:mi>n</mml:mi>
<mml:mi>c</mml:mi>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:mi mathvariant="italic">Enc</mml:mi>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mstyle displaystyle="true">
<mml:munder>
<mml:mo>&#x2211;</mml:mo>
<mml:mi>i</mml:mi>
</mml:munder>
<mml:mrow>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mstyle>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>, where <inline-formula id="inf101">
<mml:math id="m101">
<mml:mrow>
<mml:mi>E</mml:mi>
<mml:mi>n</mml:mi>
<mml:mi>c</mml:mi>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> denotes the encryption. The aggregator <inline-formula id="inf102">
<mml:math id="m102">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> can aggregate encrypted gradients <inline-formula id="inf103">
<mml:math id="m103">
<mml:mrow>
<mml:mi>E</mml:mi>
<mml:mi>n</mml:mi>
<mml:mi>c</mml:mi>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> and decrypt it to obtain aggregated gradient <inline-formula id="inf104">
<mml:math id="m104">
<mml:mrow>
<mml:mstyle displaystyle="true">
<mml:munder>
<mml:mo>&#x2211;</mml:mo>
<mml:mi>i</mml:mi>
</mml:munder>
<mml:mrow>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mstyle>
</mml:mrow>
</mml:math>
</inline-formula>. Suppose that a data owner <inline-formula id="inf105">
<mml:math id="m105">
<mml:mrow>
<mml:mi>o</mml:mi>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> has the gradient <inline-formula id="inf106">
<mml:math id="m106">
<mml:mrow>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mtext>i</mml:mtext>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mn>1</mml:mn>
<mml:mo>,</mml:mo>
</mml:mrow>
</mml:msub>
<mml:mo>&#x22ef;</mml:mo>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mi>j</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mo>&#x22ef;</mml:mo>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mi>n</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> to upload. Each element <inline-formula id="inf107">
<mml:math id="m107">
<mml:mrow>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mi>j</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> represents the gradient of the <inline-formula id="inf108">
<mml:math id="m108">
<mml:mrow>
<mml:mi>j</mml:mi>
<mml:mo>&#x2212;</mml:mo>
<mml:mi>t</mml:mi>
<mml:mi>h</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> component of the model. First of all, each data owner <inline-formula id="inf109">
<mml:math id="m109">
<mml:mrow>
<mml:mi>o</mml:mi>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> encodes the gradient. They divide each element <inline-formula id="inf110">
<mml:math id="m110">
<mml:mrow>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mi>j</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> into several vectors <inline-formula id="inf111">
<mml:math id="m111">
<mml:mrow>
<mml:msubsup>
<mml:mi>g</mml:mi>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mi>j</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mtext>k</mml:mtext>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:msubsup>
</mml:mrow>
</mml:math>
</inline-formula> and encode them into a specific format which can be encrypted by Paillier algorithm. The data owner <inline-formula id="inf112">
<mml:math id="m112">
<mml:mrow>
<mml:mi>o</mml:mi>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> encrypts the gradient by encrypting each vector <inline-formula id="inf113">
<mml:math id="m113">
<mml:mrow>
<mml:msubsup>
<mml:mi>g</mml:mi>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mi>j</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mtext>k</mml:mtext>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:msubsup>
</mml:mrow>
</mml:math>
</inline-formula>. To explain the encryption of gradients briefly, we use <inline-formula id="inf114">
<mml:math id="m114">
<mml:mrow>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mtext>i</mml:mtext>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> to represent the gradient encrypted by Paillier algorithm.</p>
<p>
<bold>
<italic>Encryption and aggregation:</italic>
</bold> We assume that there is a group composed of <inline-formula id="inf115">
<mml:math id="m115">
<mml:mi>k</mml:mi>
</mml:math>
</inline-formula> data owners. Given the public parameter <inline-formula id="inf116">
<mml:math id="m116">
<mml:mrow>
<mml:mi>P</mml:mi>
<mml:mi>K</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mrow>
<mml:mover accent="true">
<mml:mi>g</mml:mi>
<mml:mo>&#xaf;</mml:mo>
</mml:mover>
</mml:mrow>
<mml:mo>,</mml:mo>
<mml:mi>n</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>&#x3b8;</mml:mi>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> and threshold <inline-formula id="inf117">
<mml:math id="m117">
<mml:mi>l</mml:mi>
</mml:math>
</inline-formula>, each data owner<inline-formula id="inf118">
<mml:math id="m118">
<mml:mrow>
<mml:mi>o</mml:mi>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> encrypts its gradient <inline-formula id="inf119">
<mml:math id="m119">
<mml:mrow>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mtext>i</mml:mtext>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> by computing <inline-formula id="inf120">
<mml:math id="m120">
<mml:mrow>
<mml:msub>
<mml:mi>c</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:msup>
<mml:mrow>
<mml:mover accent="true">
<mml:mi>g</mml:mi>
<mml:mo>&#xaf;</mml:mo>
</mml:mover>
</mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:msup>
<mml:msubsup>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi>
<mml:mi>n</mml:mi>
</mml:msubsup>
<mml:mi>mod</mml:mi>
<mml:msup>
<mml:mi>n</mml:mi>
<mml:mn>2</mml:mn>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula>, where <inline-formula id="inf121">
<mml:math id="m121">
<mml:mrow>
<mml:msub>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> is a random element chosen from <inline-formula id="inf122">
<mml:math id="m122">
<mml:mrow>
<mml:msubsup>
<mml:mi>Z</mml:mi>
<mml:mi>n</mml:mi>
<mml:mo>&#x2217;</mml:mo>
</mml:msubsup>
</mml:mrow>
</mml:math>
</inline-formula>. Then they together upload the cipher <inline-formula id="inf123">
<mml:math id="m123">
<mml:mrow>
<mml:msub>
<mml:mi>c</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> to the aggregator <inline-formula id="inf124">
<mml:math id="m124">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>. The aggregator <inline-formula id="inf125">
<mml:math id="m125">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> will aggregate all the encrypted gradient <inline-formula id="inf126">
<mml:math id="m126">
<mml:mrow>
<mml:msub>
<mml:mi>c</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> by computing <inline-formula id="inf127">
<mml:math id="m127">
<mml:mrow>
<mml:mi>c</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:munderover>
<mml:mstyle displaystyle="true">
<mml:mo>&#x220f;</mml:mo>
</mml:mstyle>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>k</mml:mi>
</mml:munderover>
<mml:msub>
<mml:mi>c</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> and return the aggregation result <inline-formula id="inf128">
<mml:math id="m128">
<mml:mi>c</mml:mi>
</mml:math>
</inline-formula> to each data owner <inline-formula id="inf129">
<mml:math id="m129">
<mml:mrow>
<mml:mi>o</mml:mi>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> to request the decryption. To ensure that the aggregator <inline-formula id="inf130">
<mml:math id="m130">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> correctly aggregates all the encrypted gradient <inline-formula id="inf131">
<mml:math id="m131">
<mml:mrow>
<mml:msub>
<mml:mi>c</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>, we introduce the commitment scheme in&#x20;[<xref ref-type="bibr" rid="B28">28</xref>].</p>
<p>
<bold>
<italic>Decryption and update:</italic>
</bold> In the decryption phase, each data owner <inline-formula id="inf132">
<mml:math id="m132">
<mml:mrow>
<mml:mi>o</mml:mi>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> provides his decryption share <inline-formula id="inf133">
<mml:math id="m133">
<mml:mrow>
<mml:msub>
<mml:mi>d</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:msup>
<mml:mi>c</mml:mi>
<mml:mrow>
<mml:mn>2</mml:mn>
<mml:mi>&#x394;</mml:mi>
<mml:msub>
<mml:mi>s</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:msup>
<mml:mi>mod</mml:mi>
<mml:msup>
<mml:mi>n</mml:mi>
<mml:mn>2</mml:mn>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula>, where <inline-formula id="inf134">
<mml:math id="m134">
<mml:mrow>
<mml:msub>
<mml:mi>s</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> is its share of the private key. In addition, each data owner <inline-formula id="inf135">
<mml:math id="m135">
<mml:mrow>
<mml:mi>o</mml:mi>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>will also publish the proof <inline-formula id="inf136">
<mml:math id="m136">
<mml:mrow>
<mml:msub>
<mml:mi>s</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mi>log</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:msup>
<mml:mi>v</mml:mi>
<mml:mi>&#x394;</mml:mi>
</mml:msup>
</mml:mrow>
</mml:msub>
<mml:mi>V</mml:mi>
<mml:msub>
<mml:mi>K</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mi>log</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:msup>
<mml:mi>c</mml:mi>
<mml:mrow>
<mml:mn>4</mml:mn>
<mml:mi>&#x394;</mml:mi>
</mml:mrow>
</mml:msup>
</mml:mrow>
</mml:msub>
<mml:msup>
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>d</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
<mml:mn>2</mml:mn>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula>. If&#x20;at least <inline-formula id="inf137">
<mml:math id="m137">
<mml:mi>l</mml:mi>
</mml:math>
</inline-formula> data owners are verified to provide correct decryption&#x20;shares, the aggregator <inline-formula id="inf138">
<mml:math id="m138">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> can obtain the decryption result by computing <inline-formula id="inf139">
<mml:math id="m139">
<mml:mrow>
<mml:mi>m</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mi>L</mml:mi>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:munder>
<mml:mstyle displaystyle="true">
<mml:mo>&#x220f;</mml:mo>
</mml:mstyle>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x2208;</mml:mo>
<mml:mi>S</mml:mi>
</mml:mrow>
</mml:munder>
<mml:msubsup>
<mml:mi>d</mml:mi>
<mml:mi>i</mml:mi>
<mml:mrow>
<mml:mn>2</mml:mn>
<mml:msub>
<mml:mi>u</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:msubsup>
<mml:mi>mod</mml:mi>
<mml:msup>
<mml:mi>n</mml:mi>
<mml:mn>2</mml:mn>
</mml:msup>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>&#xd7;</mml:mo>
<mml:mfrac>
<mml:mn>1</mml:mn>
<mml:mrow>
<mml:mn>4</mml:mn>
<mml:msup>
<mml:mi>&#x394;</mml:mi>
<mml:mn>2</mml:mn>
</mml:msup>
<mml:mi>&#x3b8;</mml:mi>
</mml:mrow>
</mml:mfrac>
<mml:mi>mod</mml:mi>
<mml:mi>n</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, where <inline-formula id="inf140">
<mml:math id="m140">
<mml:mrow>
<mml:msub>
<mml:mi>u</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:mi>&#x394;</mml:mi>
<mml:mo>&#xd7;</mml:mo>
<mml:msubsup>
<mml:mi>&#x3bb;</mml:mi>
<mml:mrow>
<mml:mn>0</mml:mn>
<mml:mo>,</mml:mo>
<mml:mi>i</mml:mi>
</mml:mrow>
<mml:mi>S</mml:mi>
</mml:msubsup>
<mml:mo>&#x2208;</mml:mo>
<mml:mi>Z</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, <inline-formula id="inf141">
<mml:math id="m141">
<mml:mrow>
<mml:msubsup>
<mml:mi>&#x3bb;</mml:mi>
<mml:mrow>
<mml:mi>x</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>i</mml:mi>
</mml:mrow>
<mml:mi>S</mml:mi>
</mml:msubsup>
<mml:mo>&#x3d;</mml:mo>
<mml:munder>
<mml:mstyle displaystyle="true">
<mml:mo>&#x220f;</mml:mo>
</mml:mstyle>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x27;</mml:mo>
<mml:mo>&#x2208;</mml:mo>
<mml:mi>S</mml:mi>
<mml:mo>\</mml:mo>
<mml:mrow>
<mml:mo>{</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo>}</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:munder>
<mml:mfrac>
<mml:mrow>
<mml:mi>x</mml:mi>
<mml:mo>&#x2212;</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo>&#x27;</mml:mo>
</mml:mrow>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x2212;</mml:mo>
<mml:mi>i</mml:mi>
<mml:mo>&#x27;</mml:mo>
</mml:mrow>
</mml:mfrac>
</mml:mrow>
</mml:math>
</inline-formula> and <inline-formula id="inf142">
<mml:math id="m142">
<mml:mrow>
<mml:mi>L</mml:mi>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mi>u</mml:mi>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mi>u</mml:mi>
<mml:mo>&#x2212;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>N</mml:mi>
</mml:mfrac>
</mml:mrow>
</mml:math>
</inline-formula>. The proof of&#x20;correctness can be seen in [<xref ref-type="bibr" rid="B32">32</xref>]. To request data owners&#x20;to&#x20;join&#x20;in&#x20;the decryption process, the aggregator <inline-formula id="inf143">
<mml:math id="m143">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> should pay for the gradients to them. According to the addictive homomorphism of Paillier algorithm, the decryption result <inline-formula id="inf144">
<mml:math id="m144">
<mml:mi>m</mml:mi>
</mml:math>
</inline-formula> is equal to <inline-formula id="inf145">
<mml:math id="m145">
<mml:mrow>
<mml:mstyle displaystyle="true">
<mml:munderover>
<mml:mo>&#x2211;</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>k</mml:mi>
</mml:munderover>
<mml:mrow>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mstyle>
</mml:mrow>
</mml:math>
</inline-formula>. The aggregator <inline-formula id="inf146">
<mml:math id="m146">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> will use it to update the task&#x20;model.</p>
</statement>
</p>
</sec>
<sec id="s4-3">
<title>Ownership Verification</title>
<p>In the collaborative training based on homomorphic encryption such as Paillier encryption, the aggregator is set to obtain only the decrypted aggregation result but not any gradient from individual data owner. Only in this way, the privacy in gradients will not be directly obtained by the aggregator. If a malicious user obtains an encrypted gradient, he may forward the encrypted gradient to another aggregator to profit. To solve the forwarding problem, the aggregator is required to verify the ownership of each received encrypted gradient.</p>
<p>The verification mechanism is based on &#x3a3;-protocol and Pedersen commitment scheme. As for Pedersen commitment scheme, a trusted institution is required to select two prime elements <inline-formula id="inf147">
<mml:math id="m147">
<mml:mrow>
<mml:mi>g</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>h</mml:mi>
<mml:mo>&#x2208;</mml:mo>
<mml:mi>G</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, where G is a cyclic group and <inline-formula id="inf148">
<mml:math id="m148">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>log</mml:mi>
</mml:mrow>
<mml:mi>g</mml:mi>
</mml:msub>
<mml:mi>h</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> is unknown to others. The process of verification is shown in <xref ref-type="other" rid="Algorithm_2">Algorithm&#x20;2</xref>:</p>
<p>
<bold>Commitment submission:</bold> After data owner <inline-formula id="inf149">
<mml:math id="m149">
<mml:mrow>
<mml:mi>o</mml:mi>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> has uploaded the encrypted gradient <inline-formula id="inf150">
<mml:math id="m150">
<mml:mrow>
<mml:msub>
<mml:mi>c</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> to the aggregator <inline-formula id="inf151">
<mml:math id="m151">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, it computes a commitment <inline-formula id="inf152">
<mml:math id="m152">
<mml:mrow>
<mml:mi>c</mml:mi>
<mml:mi>o</mml:mi>
<mml:mi>m</mml:mi>
<mml:mi>m</mml:mi>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>r</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>:</mml:mo>
<mml:mo>&#x3d;</mml:mo>
<mml:msub>
<mml:mi>C</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:msup>
<mml:mi>g</mml:mi>
<mml:mrow>
<mml:msub>
<mml:mi>r</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:msup>
<mml:msup>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula>, where <inline-formula id="inf153">
<mml:math id="m153">
<mml:mrow>
<mml:msub>
<mml:mi>r</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> is a random value and <inline-formula id="inf154">
<mml:math id="m154">
<mml:mrow>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> is the gradient. Then it submits (<inline-formula id="inf155">
<mml:math id="m155">
<mml:mrow>
<mml:msub>
<mml:mi>C</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>, <inline-formula id="inf156">
<mml:math id="m156">
<mml:mrow>
<mml:msub>
<mml:mi>r</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>) to the aggregator&#x20;<inline-formula id="inf157">
<mml:math id="m157">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>.</p>
<p>
<bold>Commitment verification:</bold> The aggregator <inline-formula id="inf158">
<mml:math id="m158">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> will compute the aggregated gradient <inline-formula id="inf159">
<mml:math id="m159">
<mml:mrow>
<mml:mi>c</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:munderover>
<mml:mstyle displaystyle="true">
<mml:mo>&#x220f;</mml:mo>
</mml:mstyle>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>k</mml:mi>
</mml:munderover>
<mml:msub>
<mml:mi>c</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> and the aggregated commitments <inline-formula id="inf160">
<mml:math id="m160">
<mml:mrow>
<mml:mi>C</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:munderover>
<mml:mstyle displaystyle="true">
<mml:mo>&#x220f;</mml:mo>
</mml:mstyle>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>k</mml:mi>
</mml:munderover>
<mml:msub>
<mml:mi>C</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>, <inline-formula id="inf161">
<mml:math id="m161">
<mml:mrow>
<mml:mi>r</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mstyle displaystyle="true">
<mml:munderover>
<mml:mo>&#x2211;</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>k</mml:mi>
</mml:munderover>
<mml:mrow>
<mml:msub>
<mml:mi>r</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mstyle>
</mml:mrow>
</mml:math>
</inline-formula>. Then it sends a random challenge value <inline-formula id="inf162">
<mml:math id="m162">
<mml:mi>e</mml:mi>
</mml:math>
</inline-formula> back to each data owner. Each <inline-formula id="inf163">
<mml:math id="m163">
<mml:mrow>
<mml:mi>d</mml:mi>
<mml:mi>a</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>a</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> owner <inline-formula id="inf164">
<mml:math id="m164">
<mml:mrow>
<mml:mi>o</mml:mi>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> needs to use the challenge value <inline-formula id="inf165">
<mml:math id="m165">
<mml:mi>e</mml:mi>
</mml:math>
</inline-formula> to compute a response <inline-formula id="inf166">
<mml:math id="m166">
<mml:mrow>
<mml:msub>
<mml:mi>R</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:msup>
<mml:mi>g</mml:mi>
<mml:mrow>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:msup>
<mml:msup>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:msub>
<mml:mi>l</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula>, <inline-formula id="inf167">
<mml:math id="m167">
<mml:mrow>
<mml:msub>
<mml:mi>u</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>&#x2b;</mml:mo>
<mml:mi>e</mml:mi>
<mml:msub>
<mml:mi>r</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mi>mod</mml:mi>
<mml:mi>p</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, <inline-formula id="inf168">
<mml:math id="m168">
<mml:mrow>
<mml:msub>
<mml:mi>v</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>&#x3d;</mml:mo>
<mml:msub>
<mml:mi>l</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>&#x2b;</mml:mo>
<mml:mi>e</mml:mi>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mi>mod</mml:mi>
<mml:mi>p</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>. Then each data owner submits <inline-formula id="inf169">
<mml:math id="m169">
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>R</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>u</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>v</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> to the aggregator <inline-formula id="inf170">
<mml:math id="m170">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>. After that, the aggregator <inline-formula id="inf171">
<mml:math id="m171">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> aggregates all <inline-formula id="inf172">
<mml:math id="m172">
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>R</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>u</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>v</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> to obtain <inline-formula id="inf173">
<mml:math id="m173">
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mi>R</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>u</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>v</mml:mi>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> by computing <inline-formula id="inf174">
<mml:math id="m174">
<mml:mrow>
<mml:mi>R</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:munderover>
<mml:mstyle displaystyle="true">
<mml:mo>&#x220f;</mml:mo>
</mml:mstyle>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>k</mml:mi>
</mml:munderover>
<mml:msub>
<mml:mi>R</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>, <inline-formula id="inf175">
<mml:math id="m175">
<mml:mrow>
<mml:mi>u</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mstyle displaystyle="true">
<mml:munderover>
<mml:mo>&#x2211;</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>k</mml:mi>
</mml:munderover>
<mml:mrow>
<mml:msub>
<mml:mi>u</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mstyle>
</mml:mrow>
</mml:math>
</inline-formula>, <inline-formula id="inf176">
<mml:math id="m176">
<mml:mrow>
<mml:mi>v</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mstyle displaystyle="true">
<mml:munderover>
<mml:mo>&#x2211;</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>k</mml:mi>
</mml:munderover>
<mml:mrow>
<mml:msub>
<mml:mi>v</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mstyle>
</mml:mrow>
</mml:math>
</inline-formula>. Then it verifies whether <inline-formula id="inf177">
<mml:math id="m177">
<mml:mrow>
<mml:msup>
<mml:mi>g</mml:mi>
<mml:mi>u</mml:mi>
</mml:msup>
<mml:msup>
<mml:mi>h</mml:mi>
<mml:mi>v</mml:mi>
</mml:msup>
<mml:mo>&#x3d;</mml:mo>
<mml:mi>R</mml:mi>
<mml:msup>
<mml:mi>C</mml:mi>
<mml:mi>e</mml:mi>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula> holds. If it passes, it means that each data owner <inline-formula id="inf178">
<mml:math id="m178">
<mml:mrow>
<mml:mi>o</mml:mi>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> proves it knows the secret value <inline-formula id="inf179">
<mml:math id="m179">
<mml:mrow>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> bound to the commitments&#x20;<inline-formula id="inf180">
<mml:math id="m180">
<mml:mrow>
<mml:msub>
<mml:mi>C</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>.</p>
<p>
<statement content-type="algorithm" id="Algorithm_2">
<label>
</label>
<p>
<inline-graphic xlink:href="fphy-09-739259-fx2.tif"/>
</p>
<p>
<bold>
<italic>Ownership verification:</italic>
</bold> To verify the committed value is the correct gradient, the aggregator <inline-formula id="inf211">
<mml:math id="m211">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> requests owners to decrypt the gradient <inline-formula id="inf212">
<mml:math id="m212">
<mml:mrow>
<mml:mi>c</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:munderover>
<mml:mstyle displaystyle="true">
<mml:mo>&#x220f;</mml:mo>
</mml:mstyle>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>k</mml:mi>
</mml:munderover>
<mml:msub>
<mml:mi>c</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>, and obtains the aggregated gradient <inline-formula id="inf213">
<mml:math id="m213">
<mml:mrow>
<mml:mi>m</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:munderover>
<mml:mstyle displaystyle="true">
<mml:mo>&#x2211;</mml:mo>
</mml:mstyle>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mi>k</mml:mi>
</mml:munderover>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>. Then he checks whether <inline-formula id="inf214">
<mml:math id="m214">
<mml:mrow>
<mml:mi>C</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:msup>
<mml:mi>g</mml:mi>
<mml:mi>r</mml:mi>
</mml:msup>
<mml:msup>
<mml:mi>h</mml:mi>
<mml:mi>m</mml:mi>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula>. If it passes, it means that the secret value <inline-formula id="inf215">
<mml:math id="m215">
<mml:mrow>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> is indeed the gradient corresponding to cipher <inline-formula id="inf216">
<mml:math id="m216">
<mml:mrow>
<mml:msub>
<mml:mi>c</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>. The aggregator <inline-formula id="inf217">
<mml:math id="m217">
<mml:mrow>
<mml:mi>a</mml:mi>
<mml:mi>g</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> confirms that each data owner owns the plaintext of his gradient.</p>
<p>In our scheme, the aggregator can reduce the consumption of verification through checking the aggregated commitments. If the verification failed, it means that some data owners cannot provide the correct plaintext of their gradients. The aggregation of gradients and commitments will be rescheduled. Concretely, the aggregator can divide the group into several subgroups, then repeat the gradient aggregation and commitment verification. The malicious data owner will be identified through a series of verifications.</p>
</statement>
</p>
</sec>
</sec>
<sec id="s5">
<title>Security Analysis</title>
<sec id="s5-1">
<title>The Protection of Gradient</title>
<p>In order to maintain the correctness of gradient and prevent it from being obtained directly by others, we use the addictive threshold Paillier homomorphic encryption algorithm. Firstly, we discuss the feasibility of the threshold Paillier encryption algorithm for gradient protection in our scheme.</p>
<p>
<statement>
<p>
<bold>
<italic>Lemma 1:</italic>
</bold> <inline-formula id="inf218">
<mml:math id="m218">
<mml:mrow>
<mml:msub>
<mml:mi>&#x3b5;</mml:mi>
<mml:mi>g</mml:mi>
</mml:msub>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:mi>x</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>y</mml:mi>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>&#x2192;</mml:mo>
<mml:msup>
<mml:mi>g</mml:mi>
<mml:mi>x</mml:mi>
</mml:msup>
<mml:mi>&#x2217;</mml:mi>
<mml:msup>
<mml:mi>y</mml:mi>
<mml:mi>n</mml:mi>
</mml:msup>
<mml:mi>mod</mml:mi>
<mml:msup>
<mml:mi>n</mml:mi>
<mml:mn>2</mml:mn>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula> is bijective when the order of <inline-formula id="inf219">
<mml:math id="m219">
<mml:mi>g</mml:mi>
</mml:math>
</inline-formula> is a non-zero multiple of <inline-formula id="inf220">
<mml:math id="m220">
<mml:mi>n</mml:mi>
</mml:math>
</inline-formula>, and it is also a homomorphic mapping that <inline-formula id="inf221">
<mml:math id="m221">
<mml:mrow>
<mml:msub>
<mml:mi>&#x3b5;</mml:mi>
<mml:mi>g</mml:mi>
</mml:msub>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>x</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>y</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mi>&#x2217;</mml:mi>
<mml:msub>
<mml:mi>&#x3b5;</mml:mi>
<mml:mi>g</mml:mi>
</mml:msub>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>x</mml:mi>
<mml:mn>2</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>y</mml:mi>
<mml:mn>2</mml:mn>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mo>&#x3d;</mml:mo>
<mml:msub>
<mml:mi>&#x3b5;</mml:mi>
<mml:mi>g</mml:mi>
</mml:msub>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>x</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo>&#x2b;</mml:mo>
<mml:msub>
<mml:mi>x</mml:mi>
<mml:mn>2</mml:mn>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>y</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo>&#x2b;</mml:mo>
<mml:msub>
<mml:mi>y</mml:mi>
<mml:mn>2</mml:mn>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>.</p>
</statement>
</p>
<p>
<statement>
<p>
<bold>
<italic>Lemma 2:</italic>
</bold> A number <inline-formula id="inf222">
<mml:math id="m222">
<mml:mi>x</mml:mi>
</mml:math>
</inline-formula> is said to be an <italic>n</italic>th residue modulo <inline-formula id="inf223">
<mml:math id="m223">
<mml:mrow>
<mml:msup>
<mml:mi>n</mml:mi>
<mml:mn>2</mml:mn>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula> if there exists a number <inline-formula id="inf224">
<mml:math id="m224">
<mml:mrow>
<mml:mi>y</mml:mi>
<mml:mo>&#x2208;</mml:mo>
<mml:msubsup>
<mml:mi>Z</mml:mi>
<mml:mrow>
<mml:msup>
<mml:mi>n</mml:mi>
<mml:mn>2</mml:mn>
</mml:msup>
</mml:mrow>
<mml:mtext>&#x2a;</mml:mtext>
</mml:msubsup>
</mml:mrow>
</mml:math>
</inline-formula> such that <inline-formula id="inf225">
<mml:math id="m225">
<mml:mrow>
<mml:mi>z</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:msup>
<mml:mi>y</mml:mi>
<mml:mi>n</mml:mi>
</mml:msup>
<mml:mi>mod</mml:mi>
<mml:msup>
<mml:mi>n</mml:mi>
<mml:mn>2</mml:mn>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula>, and it is hard to find the value of&#x20;<inline-formula id="inf226">
<mml:math id="m226">
<mml:mi>z</mml:mi>
</mml:math>
</inline-formula>.</p>
<p>The proof of Lemma 1 and Lemma 2 can be seen in [<xref ref-type="bibr" rid="B19">19</xref>]. Lemma 1 indicates that the aggregated ciphertext of gradient can be decrypted to the aggregated gradient. The aggregator is able to acquire aggregated gradient without knowing individual gradients. From Lemma 2, we can conclude that the ciphertext of gradient is hard to be cracked.</p>
<p>Each data owner in our threshold Paillier algorithm has the ability to decrypt a cipher only in groups, so whenever a data owner obtains an individual encrypted gradient, he can&#x2019;t decrypt it unless others collude with him. The individual gradient can be well protected in our encryption scheme.</p>
<p>The &#x3a3;-protocol can make one prove that he knows the secret without revealing it. Specifically, a prover can state a commitment and prove that he knows the secret in the commitment. In the process of our protocol, the data owner <inline-formula id="inf227">
<mml:math id="m227">
<mml:mrow>
<mml:mi>o</mml:mi>
<mml:msub>
<mml:mi>w</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> states <inline-formula id="inf228">
<mml:math id="m228">
<mml:mrow>
<mml:msub>
<mml:mi>C</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>:</mml:mo>
<mml:mo>&#x3d;</mml:mo>
<mml:msup>
<mml:mi>g</mml:mi>
<mml:mrow>
<mml:msub>
<mml:mi>r</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:msup>
<mml:msup>
<mml:mi>h</mml:mi>
<mml:mrow>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula>, and then generates two random values <inline-formula id="inf229">
<mml:math id="m229">
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mtext>i</mml:mtext>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>l</mml:mi>
<mml:mtext>i</mml:mtext>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> to hide the information in <inline-formula id="inf230">
<mml:math id="m230">
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>R</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mtext>&#xa0;</mml:mtext>
<mml:msub>
<mml:mi>u</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>v</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> to prevent gradient <inline-formula id="inf231">
<mml:math id="m231">
<mml:mrow>
<mml:msub>
<mml:mi>m</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> from being exposed to others.</p>
</statement>
</p>
<p>
<statement>
<p>
<bold>
<italic>Lemma 3:</italic>
</bold> Only when the generated random values <inline-formula id="inf232">
<mml:math id="m232">
<mml:mrow>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mtext>i</mml:mtext>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> and <inline-formula id="inf233">
<mml:math id="m233">
<mml:mrow>
<mml:msub>
<mml:mi>l</mml:mi>
<mml:mtext>i</mml:mtext>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> are different, no one can recover the secret value from the <inline-formula id="inf234">
<mml:math id="m234">
<mml:mrow>
<mml:mrow>
<mml:mo>(</mml:mo>
<mml:mrow>
<mml:msub>
<mml:mi>R</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mtext>&#xa0;</mml:mtext>
<mml:msub>
<mml:mi>u</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub>
<mml:mi>v</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>, that is, a commitment will not disclose any information about the committed&#x20;value.</p>
<p>The concrete proofs can be seen in [<xref ref-type="bibr" rid="B33">33</xref>]. As long as the data owner ensures that the random values <inline-formula id="inf235">
<mml:math id="m235">
<mml:mrow>
<mml:msub>
<mml:mi>k</mml:mi>
<mml:mtext>i</mml:mtext>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> and <inline-formula id="inf236">
<mml:math id="m236">
<mml:mrow>
<mml:msub>
<mml:mi>l</mml:mi>
<mml:mtext>i</mml:mtext>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> are different, we can think that the gradient is protected in the commitment according to Lemma&#x20;3.</p>
</statement>
</p>
</sec>
<sec id="s5-2">
<title>The Validity of Commitment</title>
<p>
<statement>
<p>
<bold>
<italic>Lemma 4:</italic>
</bold> Two commitments for two different messages are different, otherwise the relationship between <inline-formula id="inf237">
<mml:math id="m237">
<mml:mi>g</mml:mi>
</mml:math>
</inline-formula> and <inline-formula id="inf238">
<mml:math id="m238">
<mml:mi>h</mml:mi>
</mml:math>
</inline-formula> can be calculated, which is&#x20;not in line with the discrete logarithm hypothesis.</p>
<p>According to Lemma 4, we know each commitment is corresponding to a unique gradient. If a data owner submits a commitment, it means that it states the ownership of a gradient. We suppose that there exists a user who forwards another data owner&#x2019;s encrypted gradient. As we stated in <italic>Threat Models</italic>, we consider two kinds of treat&#x20;model.</p>
<p>If an attacker only obtains encrypted gradient, it needs to state a commitment. Consider that it does not know the plaintext of gradient <inline-formula id="inf239">
<mml:math id="m239">
<mml:mrow>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>, it may commit to a secret fake gradient <inline-formula id="inf240">
<mml:math id="m240">
<mml:mrow>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mrow>
<mml:mi>f</mml:mi>
<mml:mi>a</mml:mi>
<mml:mi>k</mml:mi>
<mml:mi>e</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> and upload the commitment <inline-formula id="inf241">
<mml:math id="m241">
<mml:mrow>
<mml:msub>
<mml:mi>C</mml:mi>
<mml:mrow>
<mml:mi>f</mml:mi>
<mml:mi>a</mml:mi>
<mml:mi>k</mml:mi>
<mml:mi>e</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>. In the following steps, it needs to respond to the challenge <inline-formula id="inf242">
<mml:math id="m242">
<mml:mi>e</mml:mi>
</mml:math>
</inline-formula>, which proves the binding relationship between fake gradient <inline-formula id="inf243">
<mml:math id="m243">
<mml:mrow>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mrow>
<mml:mi>f</mml:mi>
<mml:mi>a</mml:mi>
<mml:mi>k</mml:mi>
<mml:mi>e</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> and commitment <inline-formula id="inf244">
<mml:math id="m244">
<mml:mrow>
<mml:msub>
<mml:mi>C</mml:mi>
<mml:mrow>
<mml:mi>f</mml:mi>
<mml:mi>a</mml:mi>
<mml:mi>k</mml:mi>
<mml:mi>e</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>. In other words, if the verification passes, the aggregator can think that the user has committed to the plaintext of gradient, which can be denoted as <inline-formula id="inf245">
<mml:math id="m245">
<mml:mrow>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>. After that, the aggregator uses the decryption result to check whether the committed <inline-formula id="inf246">
<mml:math id="m246">
<mml:mrow>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mrow>
<mml:mi>f</mml:mi>
<mml:mi>a</mml:mi>
<mml:mi>k</mml:mi>
<mml:mi>e</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> is equal to the gradient <inline-formula id="inf247">
<mml:math id="m247">
<mml:mrow>
<mml:msub>
<mml:mi>g</mml:mi>
<mml:mi>i</mml:mi>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula>. If not, the user&#x2019;s malicious behavior of forwarding will be discovered.</p>
<p>If an attacker obtains encrypted data as well as its historical verification information, it needs to respond to the dynamic challenge <inline-formula id="inf248">
<mml:math id="m248">
<mml:mi>e</mml:mi>
</mml:math>
</inline-formula> in the verification process. Due to it even does not know the committed value in commitments, the verification will fail. In other words, the historical verification information is not reusable for an attacker.</p>
<p>Despite each data owner may obtain encrypted gradient from the aggregator in the decryption phase, the forwarding attack still does not work because of our commitment scheme.</p>
</statement>
</p>
</sec>
</sec>
<sec id="s6">
<title>Experimental Results</title>
<p>In this section, we introduce the experiments in our scheme, including the performance evaluation of Paillier algorithm and Pedersen commitment scheme. We deploy an aggregator and multiple data owners to simulate the process of collaborative training.</p>
<p>We build the deep learning model with Python(version3.83), Numpy(version 1.18.5), Pytorch(1.6.0) on GPUs. We use CelebFaces Attributes Dataset (CelebA) to conduct smile recognition. The dataset includes 202,599 face images with 40 binary attributes. We randomly select 60,000 images and averagely assign them to the data owners. We also use the famous MNIST dataset to conduct handwritten digit recognition. We set the epoch of training as 3. The structure of the network is shown in <xref ref-type="table" rid="T1">Table&#x20;1</xref>.</p>
<table-wrap id="T1" position="float">
<label>TABLE 1</label>
<caption>
<p>The structure of&#x20;model.</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="left">Smile recognition</th>
<th align="center">Digit recognition</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left">2 &#xd7; Conv3-64</td>
<td align="center">Conv1-16</td>
</tr>
<tr>
<td align="left">2&#x20;&#xd7;Conv3-128</td>
<td align="center">Conv1-32</td>
</tr>
<tr>
<td align="left">3 &#xd7; Conv3-256</td>
<td align="center">FC-10</td>
</tr>
<tr>
<td align="left">3 &#xd7; Conv3-256</td>
<td align="center">&#x2014;</td>
</tr>
<tr>
<td align="left">2 &#xd7; FC-4096</td>
<td align="center">&#x2014;</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>After each iteration of the training, we output the gradient and evaluate the performance of Paillier algorithm. We compress the gradient by setting the precision of each gradient at 3&#x2013;5, and use the gradient to update the model. Concretely, the data owners train their local model and output the gradient in given precision. Then we aggregate these gradients o update the model. With the change of given precision, the accuracy of the model is shown in <xref ref-type="fig" rid="F4">Figure&#x20;4</xref>.</p>
<fig id="F4" position="float">
<label>FIGURE 4</label>
<caption>
<p>The accuracy with different precision of gradient. <bold>(A)</bold>; On MNIST dataset <bold>(B)</bold> On CelebA dataset;</p>
</caption>
<graphic xlink:href="fphy-09-739259-g004.tif"/>
</fig>
<p>If we do not compress the gradient, the accuracy on CelebA dataset in each epoch is 90.66, 91.01, and 92.24%, respectively. The accuracy on MNIST dataset in each epoch is 96.71, 98.21, and 98.58%, respectively. When we control the precision of gradient at 5, 4, 3, the accuracy on CelebA dataset in the third epoch changes to 90.77, 91.08, and 90.41%, which is approximately 1.5% lower compared to the accuracy with no gradient compression. With gradient compression, the accuracy decline is not obvious on MNIST dataset, where the accuracy in the third epoch is 98.49, 98.51, and 98.33%. decreasing within 0.2%. The change of gradient precision has a more significant impact on large-scale training. When the precision decreases, the accuracy in different epochs is lower, which makes the training more difficult to converge. To ensure the quality and stability of training, we choose to set the precision at five in our subsequent experiment.</p>
<p>As for gradient encryption, we use the Paillier algorithm implemented in Python based on CPU. We use the Charm-crypto.<xref ref-type="fn" rid="fn1">
<sup>1</sup>
</xref> library to perform the encryption and decryption process of Paillier algorithm. Charm-crypto is a Python library for fast encryption on large numbers. We encode the gradient as a vector of integers that can be encrypted by Paillier algorithm. By controlling the precision of gradients, we get multiple vectors of the gradient in various lengths. Because the precision changes, the total number of parameters varies. We choose to evaluate the Paillier algorithm on a message with a length of <inline-formula id="inf249">
<mml:math id="m249">
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mn>10</mml:mn>
</mml:mrow>
<mml:mn>5</mml:mn>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula> digits. The evaluation of overhead is shown in <xref ref-type="fig" rid="F5">Figure&#x20;5</xref>.</p>
<fig id="F5" position="float">
<label>FIGURE 5</label>
<caption>
<p>The overhead of Paillier algorithm. <bold>(A)</bold> encrypted unit <inline-formula id="inf250">
<mml:math id="m250">
<mml:mo>&#x2208;</mml:mo>
</mml:math>
</inline-formula>[10,100]; <bold>(B)</bold> encrypted unit <inline-formula id="inf251">
<mml:math id="m251">
<mml:mo>&#x2208;</mml:mo>
</mml:math>
</inline-formula>[100,500].</p>
</caption>
<graphic xlink:href="fphy-09-739259-g005.tif"/>
</fig>
<p>To maintain the correctness of decryption results after cipher aggregation, the length of the encrypted unit is limited by the number of ciphers and security parameters of the Paillier algorithm. On the premise that we maintain the correctness of decryption, we divide the message into multiple units to encrypt. When the length of an encrypted unit ranges from 10 to 100, as the length is doubled, the time consumption is almost halved. The length of the unit does not have a significant impact on unit encryption time. When the length ranges from 100 to 500, the unit encryption time obviously increases as the length increases, however, the total time consumption still decreases. It is better to choose a larger encryption unit if possible. Since training overhead is much higher than the gradient encryption in cooperative training, the overhead of Paillier algorithm above is acceptable.</p>
<p>As for the Pedersen commitment scheme, we use cryptographic algorithms based on discrete logarithm to deploy it. We divide the message with a length of <inline-formula id="inf252">
<mml:math id="m252">
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mn>10</mml:mn>
</mml:mrow>
<mml:mn>5</mml:mn>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula> digits into multiple units again and evaluate the time consumption of the scheme. We first simulate the process of commitment and verification of a device. The overhead is shown in <xref ref-type="table" rid="T2">Table&#x20;2</xref>.</p>
<table-wrap id="T2" position="float">
<label>TABLE 2</label>
<caption>
<p>Overhead of Pedersen commitment scheme with one data&#x20;owner.</p>
</caption>
<table>
<thead valign="top">
<tr>
<th rowspan="2" align="left">phase</th>
<th colspan="5" align="center">Length of committed unit</th>
</tr>
<tr>
<th align="center">10 (s)</th>
<th align="center">50 (s)</th>
<th align="center">100 (s)</th>
<th align="center">200 (s)</th>
<th align="center">300 (s)</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left">Committing</td>
<td align="char" char=".">0.925</td>
<td align="char" char=".">0.311</td>
<td align="char" char=".">0.256</td>
<td align="char" char=".">0.204</td>
<td align="char" char=".">0.188</td>
</tr>
<tr>
<td align="left">Verifying</td>
<td align="char" char=".">2.329</td>
<td align="char" char=".">0.392</td>
<td align="char" char=".">0.296</td>
<td align="char" char=".">0.224</td>
<td align="char" char=".">0.202</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>The time consumption of committing is much less than the time consumption of encryption and decryption. When the unit is larger, the total overhead of the commitment scheme is at a lower level. To evaluate the impact of the number of data owners on the commitment scheme, we set the number of data owners from 1 to 10, respectively. Each data owner needs to commit to a message with a length of <inline-formula id="inf253">
<mml:math id="m253">
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mn>10</mml:mn>
</mml:mrow>
<mml:mn>5</mml:mn>
</mml:msup>
</mml:mrow>
</mml:math>
</inline-formula> digits. The experimental results can be seen in <xref ref-type="fig" rid="F6">Figure&#x20;6</xref>. The total time of commitment aggregation increases because the number of devices increases. The time consumption of verification increases slightly as the number of devices increases, which almost does not influence the total time consumption of our commitment scheme.</p>
<fig id="F6" position="float">
<label>FIGURE 6</label>
<caption>
<p>The overhead of Pedersen commitment scheme. <bold>(A)</bold> commitment aggregation; <bold>(B)</bold> commitment verification.</p>
</caption>
<graphic xlink:href="fphy-09-739259-g006.tif"/>
</fig>
<p>To better show the practicality of this commitment scheme in large-scale cooperative learning, we set the committed unit at 100, 200, respectively, and expand the number of devices to 50 and 100. The evaluation result can be seen in <xref ref-type="table" rid="T3">Tables 3</xref>, <xref ref-type="table" rid="T4">4</xref>. The total time consumption is still much lower than the encryption and decryption. It means that the increase in data owners will not impose a clear burden on the commitment scheme. Our experimental results indicate that our commitment scheme is feasible in the cooperative training.</p>
<table-wrap id="T3" position="float">
<label>TABLE 3</label>
<caption>
<p>Overhead of large-scale commitment aggregation.</p>
</caption>
<table>
<thead valign="top">
<tr>
<th rowspan="2" align="left">Length of committed unit</th>
<th colspan="3" align="center">Number of data owners</th>
</tr>
<tr>
<th align="center">10 (s)</th>
<th align="center">50 (s)</th>
<th align="center">100 (s)</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left">100</td>
<td align="char" char=".">0.294</td>
<td align="char" char=".">0.331</td>
<td align="char" char=".">0.377</td>
</tr>
<tr>
<td align="left">200</td>
<td align="char" char=".">0.222</td>
<td align="char" char=".">0.241</td>
<td align="char" char=".">0.264</td>
</tr>
</tbody>
</table>
</table-wrap>
<table-wrap id="T4" position="float">
<label>TABLE 4</label>
<caption>
<p>The Overhead of large-scale commitment verification.</p>
</caption>
<table>
<thead valign="top">
<tr>
<th rowspan="2" align="left">Length of committed unit</th>
<th colspan="3" align="center">Number of data owners</th>
</tr>
<tr>
<th align="center">10 (s)</th>
<th align="center">50 (s)</th>
<th align="center">100 (s)</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="left">100</td>
<td align="char" char=".">0.148</td>
<td align="char" char=".">1.091</td>
<td align="char" char=".">3.090</td>
</tr>
<tr>
<td align="left">200</td>
<td align="char" char=".">0.077</td>
<td align="char" char=".">0.568</td>
<td align="char" char=".">1.585</td>
</tr>
</tbody>
</table>
</table-wrap>
</sec>
<sec sec-type="conclusion" id="s7">
<title>Conclusion</title>
<p>In this paper, we propose an ownership verification mechanism against encrypted forwarding attacks in data-driven social computing. It can defend against the malicious gradient stealing and forwarding behavior in cryptography-based privacy-preserving methods. Based on the premise of maintaining gradient privacy, we present a protocol based on &#x3a3;-protocol and Pedersen commitment to achieve our security goal. Specifically, we design a united commitment algorithm to make participants cooperate to submit gradients and provide proof of data ownership. If any user submits other&#x2019;s gradient, it will fail to provide correct proof to pass the verification process. The experiment results validate the security of our proposed mechanism and demonstrate the practicality of our solution.</p>
</sec>
</body>
<back>
<sec id="s8">
<title>Data Availability Statement</title>
<p>Publicly available datasets were analyzed in this study. This data can be found here: the Large-scale CelebFaces Attributes (CelebA) Dataset, <ext-link ext-link-type="uri" xlink:href="http://mmlab.ie.cuhk.edu.hk/projects/CelebA.html">http://mmlab.ie.cuhk.edu.hk/projects/CelebA.html</ext-link>, and THE MNIST DATABASE of handwritten digits, <ext-link ext-link-type="uri" xlink:href="http://yann.lecun.com/exdb/mnist/">http://yann.lecun.com/exdb/mnist/</ext-link>.</p>
</sec>
<sec id="s9">
<title>Author Contributions</title>
<p>ZS: Conceptualization and methodology, writing&#x2014;original draft preparation; JW: formal analysis, validation, writing &#x2014;original draft preparation; ZC: visualization; BW: project administration, supervision, and writing&#x2014;review and editing; RL and YH: writing&#x2014;review and editing.</p>
</sec>
<sec id="s10">
<title>Funding</title>
<p>This work was supported in part by the National Key R&#x26;D Program of China (No. 2018YFB2100400), in part by the National Natural Science Foundation of China (No. 62002077, 61872100), in part by the China Postdoctoral Science Foundation (No. 2020M682657), in part by Guangdong Basic and Applied Basic Research Foundation (No. 2020A1515110385), in part by Zhejiang Lab (No. 2020NF0AB01), in part by Guangzhou Science and Technology Plan Project (202102010440).</p>
</sec>
<sec sec-type="COI-statement" id="s11">
<title>Conflict of Interest</title>
<p>The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.</p>
</sec>
<sec id="s12" sec-type="disclaimer">
<title>Publisher&#x2019;s Note</title>
<p>All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.</p>
</sec>
<ack>
<p>The authors would like to thank reviewers for their critical reading and improvement of the manuscript.</p>
</ack>
<fn-group>
<fn id="fn1">
<label>1</label>
<p>The encryption library called Charm-crypto can be download in <ext-link ext-link-type="uri" xlink:href="https://github.com/JHUISI/charm">https://github.com/JHUISI/charm</ext-link>.</p>
</fn>
</fn-group>
<ref-list>
<title>References</title>
<ref id="B1">
<label>1.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Zeroual</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Harrou</surname>
<given-names>F</given-names>
</name>
<name>
<surname>Dairi</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Sun</surname>
<given-names>Y</given-names>
</name>
</person-group>. <article-title>Deep Learning Methods for Forecasting COVID-19 Time-Series Data: A Comparative Study</article-title>. <source>Chaos, Solitons &#x26; Fractals</source> (<year>2020</year>) <volume>140</volume>:<fpage>110121</fpage>. <pub-id pub-id-type="doi">10.1016/j.chaos.2020.110121</pub-id> </citation>
</ref>
<ref id="B2">
<label>2.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Liang</surname>
<given-names>W</given-names>
</name>
<name>
<surname>Yao</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Chen</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Lv</surname>
<given-names>Q</given-names>
</name>
<name>
<surname>Zanin</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Liu</surname>
<given-names>J</given-names>
</name>
<etal/>
</person-group> <article-title>Early Triage of Critically Ill COVID-19 Patients Using Deep Learning</article-title>. <source>Nat Commun</source> (<year>2020</year>) <volume>11</volume>:<fpage>3543</fpage>&#x2013;<lpage>7</lpage>. <pub-id pub-id-type="doi">10.1016/j.physrep.2007.04.00410.1038/s41467-020-17280-8</pub-id> </citation>
</ref>
<ref id="B3">
<label>3.</label>
<citation citation-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Li</surname>
<given-names>F</given-names>
</name>
<name>
<surname>Sun</surname>
<given-names>Z</given-names>
</name>
<name>
<surname>Li</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Niu</surname>
<given-names>B</given-names>
</name>
<name>
<surname>Li</surname>
<given-names>H</given-names>
</name>
<name>
<surname>Cao</surname>
<given-names>G</given-names>
</name>
</person-group>. <article-title>Hideme: Privacy-Preserving Photo Sharing on Social Networks</article-title>. In: <conf-name>IEEE INFOCOM 2019-IEEE Conference on Computer Communications</conf-name>; <conf-date>2019, April 29-May 2</conf-date>; <conf-loc>Paris, France</conf-loc> (<year>2019</year>). <pub-id pub-id-type="doi">10.1109/INFOCOM.2019.8737466</pub-id> </citation>
</ref>
<ref id="B4">
<label>4.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Han</surname>
<given-names>W</given-names>
</name>
<name>
<surname>Tian</surname>
<given-names>Z</given-names>
</name>
<name>
<surname>Huang</surname>
<given-names>Z</given-names>
</name>
<name>
<surname>Li</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Jia</surname>
<given-names>Y</given-names>
</name>
</person-group>. <article-title>Topic Representation Model Based on Microblogging Behavior Analysis</article-title>. <source>World Wide Web</source> (<year>2020</year>) <volume>23</volume>:<fpage>3083</fpage>&#x2013;<lpage>97</lpage>. <pub-id pub-id-type="doi">10.1007/s11280-020-00822-x</pub-id> </citation>
</ref>
<ref id="B5">
<label>5.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Kone&#x10d;n&#xfd;</surname>
<given-names>J</given-names>
</name>
<name>
<surname>McMahan</surname>
<given-names>HB</given-names>
</name>
<name>
<surname>Ramage</surname>
<given-names>D</given-names>
</name>
<name>
<surname>Richt&#xe1;rik</surname>
<given-names>P</given-names>
</name>
</person-group>. <article-title>Federated Optimization: Distributed Machine Learning for On-Device Intelligence</article-title>. (<year>2016</year>) <comment>arXiv preprint arXiv:1610.02527</comment>. </citation>
</ref>
<ref id="B6">
<label>6.</label>
<citation citation-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Abadi</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Chu</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Goodfellow</surname>
<given-names>I</given-names>
</name>
<name>
<surname>McMahan</surname>
<given-names>HB</given-names>
</name>
<name>
<surname>Mironov</surname>
<given-names>I</given-names>
</name>
<name>
<surname>Talwar</surname>
<given-names>K</given-names>
</name>
<name>
<surname>Zhang</surname>
<given-names>L</given-names>
</name>
</person-group>. <article-title>Deep Learning with Differential Privacy</article-title>. In: <conf-name>Proceedings of the 2016 ACM SIGSAC conference on computer and communications security</conf-name> (<year>2016</year>). <pub-id pub-id-type="doi">10.1145/2976749.2978318</pub-id> </citation>
</ref>
<ref id="B7">
<label>7.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Li</surname>
<given-names>T</given-names>
</name>
<name>
<surname>Sahu</surname>
<given-names>AK</given-names>
</name>
<name>
<surname>Talwalkar</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Smith</surname>
<given-names>V</given-names>
</name>
</person-group>. <article-title>Federated Learning: Challenges, Methods, and Future Directions</article-title>. <source>IEEE Signal Process Mag</source> (<year>2020</year>) <volume>37</volume>:<fpage>50</fpage>&#x2013;<lpage>60</lpage>. <pub-id pub-id-type="doi">10.1109/MSP.2020.2975749</pub-id> </citation>
</ref>
<ref id="B8">
<label>8.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Li</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Wu</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Jiang</surname>
<given-names>G</given-names>
</name>
<name>
<surname>Srikanthan</surname>
<given-names>T</given-names>
</name>
</person-group>. <article-title>Blockchain-based Public Auditing for Big Data in Cloud Storage</article-title>. <source>Inf Process Manage</source> (<year>2020</year>) <volume>57</volume>:<fpage>102382</fpage>. <pub-id pub-id-type="doi">10.1016/j.ipm.2020.102382</pub-id> </citation>
</ref>
<ref id="B9">
<label>9.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Weng</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Weng</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Zhang</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Li</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Zhang</surname>
<given-names>Y</given-names>
</name>
<name>
<surname>Luo</surname>
<given-names>W</given-names>
</name>
</person-group>. <article-title>Deepchain: Auditable and Privacy-Preserving Deep Learning with Blockchain-Based Incentive</article-title>. <source>IEEE Trans Dependable Secure Comput</source> (<year>2019</year>) <fpage>1</fpage>. <pub-id pub-id-type="doi">10.1109/TDSC.2019.2952332</pub-id> </citation>
</ref>
<ref id="B10">
<label>10.</label>
<citation citation-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Li</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Duan</surname>
<given-names>Y</given-names>
</name>
<name>
<surname>Yang</surname>
<given-names>H</given-names>
</name>
<name>
<surname>Chen</surname>
<given-names>Y</given-names>
</name>
<name>
<surname>Yang</surname>
<given-names>J</given-names>
</name>
</person-group>. <article-title>TIPRDC: Task-independent Privacy-Respecting Data Crowdsourcing Framework for Deep Learning with Anonymized Intermediate Representations</article-title>. In: <conf-name>Proceedings of the 26th ACM SIGKDD International Conference on Knowledge Discovery &#x26; Data Mining</conf-name>; <conf-date>2020, July 6-10</conf-date>; <conf-loc>Virtual Event, CA, USA</conf-loc> (<year>2020</year>). <pub-id pub-id-type="doi">10.1145/3394486.3403125</pub-id> </citation>
</ref>
<ref id="B11">
<label>11.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Sun</surname>
<given-names>Z</given-names>
</name>
<name>
<surname>Yin</surname>
<given-names>L</given-names>
</name>
<name>
<surname>Li</surname>
<given-names>C</given-names>
</name>
<name>
<surname>Zhang</surname>
<given-names>W</given-names>
</name>
<name>
<surname>Li</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Tian</surname>
<given-names>Z</given-names>
</name>
</person-group>. <article-title>The QoS and Privacy Trade-Off of Adversarial Deep Learning: An Evolutionary Game Approach</article-title>. <source>Comput Security</source> (<year>2020</year>) <volume>96</volume>:<fpage>101876</fpage>. <pub-id pub-id-type="doi">10.1016/j.cose.2020.101876</pub-id> </citation>
</ref>
<ref id="B12">
<label>12.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Aghasian</surname>
<given-names>E</given-names>
</name>
<name>
<surname>Garg</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Gao</surname>
<given-names>L</given-names>
</name>
<name>
<surname>Yu</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Montgomery</surname>
<given-names>J</given-names>
</name>
</person-group>. <article-title>Scoring Users&#x27; Privacy Disclosure across Multiple Online Social Networks</article-title>. <source>IEEE access</source> (<year>2017</year>) <volume>5</volume>:<fpage>13118</fpage>&#x2013;<lpage>30</lpage>. <pub-id pub-id-type="doi">10.1109/ACCESS.2017.2720187</pub-id> </citation>
</ref>
<ref id="B13">
<label>13.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Li</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Zhao</surname>
<given-names>D</given-names>
</name>
<name>
<surname>Wu</surname>
<given-names>X</given-names>
</name>
<name>
<surname>Tian</surname>
<given-names>Z</given-names>
</name>
<name>
<surname>Li</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Wang</surname>
<given-names>Z</given-names>
</name>
</person-group>. <article-title>Functional Immunization of Networks Based on Message Passing</article-title>. <source>Appl Maths Comput</source> (<year>2020</year>) <volume>366</volume>:<fpage>124728</fpage>. <pub-id pub-id-type="doi">10.1016/j.amc.2019.124728</pub-id> </citation>
</ref>
<ref id="B14">
<label>14.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Du</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Jiang</surname>
<given-names>C</given-names>
</name>
<name>
<surname>Chen</surname>
<given-names>K-C</given-names>
</name>
<name>
<surname>Ren</surname>
<given-names>Y</given-names>
</name>
<name>
<surname>Poor</surname>
<given-names>HV</given-names>
</name>
</person-group>. <article-title>Community-structured Evolutionary Game for Privacy protection in Social Networks</article-title>. <source>IEEE Trans.Inform.Forensic Secur.</source> (<year>2018</year>) <volume>13</volume>:<fpage>574</fpage>&#x2013;<lpage>89</lpage>. <pub-id pub-id-type="doi">10.1109/TIFS.2017.2758756</pub-id> </citation>
</ref>
<ref id="B15">
<label>15.</label>
<citation citation-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Shokri</surname>
<given-names>R</given-names>
</name>
<name>
<surname>Stronati</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Song</surname>
<given-names>C</given-names>
</name>
<name>
<surname>Shmatikov</surname>
<given-names>V</given-names>
</name>
</person-group>. <article-title>Membership Inference Attacks against Machine Learning Models</article-title>. In: <conf-name>IEEE Symposium on Security and Privacy</conf-name>; <conf-date>2017, May 22-26</conf-date>; <conf-loc>San Jose, CA, USA</conf-loc> (<year>2017</year>). <pub-id pub-id-type="doi">10.1109/SP.2017.41</pub-id> </citation>
</ref>
<ref id="B16">
<label>16.</label>
<citation citation-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Melis</surname>
<given-names>L</given-names>
</name>
<name>
<surname>Song</surname>
<given-names>C</given-names>
</name>
<name>
<surname>De Cristofaro</surname>
<given-names>E</given-names>
</name>
<name>
<surname>Shmatikov</surname>
<given-names>V</given-names>
</name>
</person-group>. <article-title>Exploiting Unintended Feature Leakage in Collaborative Learning</article-title>. In: <conf-name>IEEE Symposium on Security and Privacy. (2017)</conf-name>; <conf-date>2019, May 19-23</conf-date>; <conf-loc>San Jose, CA, USA</conf-loc> (<year>2019</year>). <pub-id pub-id-type="doi">10.1109/SP.2019.00029</pub-id> </citation>
</ref>
<ref id="B17">
<label>17.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Yin</surname>
<given-names>L</given-names>
</name>
<name>
<surname>Feng</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Lin</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Cao</surname>
<given-names>Z</given-names>
</name>
<name>
<surname>Sun</surname>
<given-names>Z</given-names>
</name>
</person-group>. <article-title>A Blockchain-Based Collaborative Training Method for Multi-Party Data Sharing</article-title>. <source>Comput Commun</source> (<year>2021</year>) <volume>173</volume>:<fpage>70</fpage>&#x2013;<lpage>8</lpage>. <pub-id pub-id-type="doi">10.1016/j.comcom.2021.03.027</pub-id> </citation>
</ref>
<ref id="B18">
<label>18.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Brakerski</surname>
<given-names>Z</given-names>
</name>
<name>
<surname>Vaikuntanathan</surname>
<given-names>V</given-names>
</name>
</person-group>. <article-title>Efficient Fully Homomorphic Encryption from (Standard) $\Mathsf{LWE}$</article-title>. <source>SIAM J&#x20;Comput</source> (<year>2014</year>) <volume>43</volume>:<fpage>831</fpage>&#x2013;<lpage>71</lpage>. <pub-id pub-id-type="doi">10.1137/120868669</pub-id> </citation>
</ref>
<ref id="B19">
<label>19.</label>
<citation citation-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Paillier</surname>
<given-names>P</given-names>
</name>
</person-group>. <article-title>Public-key Cryptosystems Based on Composite Degree Residuosity Classes</article-title>. In: <conf-name>International Conference on the Theory and Applications of Cryptographic Techniques</conf-name>; <conf-date>1999, May 2-6</conf-date>; <conf-loc>Prague, Czech Republic</conf-loc> (<year>1999</year>). p. <fpage>223</fpage>&#x2013;<lpage>38</lpage>. <pub-id pub-id-type="doi">10.1007/3-540-48910-X_16</pub-id> </citation>
</ref>
<ref id="B20">
<label>20.</label>
<citation citation-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Gentry</surname>
<given-names>C</given-names>
</name>
</person-group>. <article-title>Fully Homomorphic Encryption Using Ideal Lattices</article-title>. In: <conf-name>Proceedings of the forty-first annual ACM symposium on Theory of computing</conf-name>; <conf-date>2009, May 31-June 2</conf-date>; <conf-loc>Bethesda, MD, USA</conf-loc> (<year>2009</year>). <pub-id pub-id-type="doi">10.1145/1536414.1536440</pub-id> </citation>
</ref>
<ref id="B21">
<label>21.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Phong</surname>
<given-names>LT</given-names>
</name>
<name>
<surname>Aono</surname>
<given-names>Y</given-names>
</name>
<name>
<surname>Hayashi</surname>
<given-names>T</given-names>
</name>
<name>
<surname>Wang</surname>
<given-names>L</given-names>
</name>
<name>
<surname>Moriai</surname>
<given-names>S</given-names>
</name>
</person-group>. <article-title>Privacy-Preserving Deep Learning via Additively Homomorphic Encryption</article-title>. <source>IEEE Trans.Inform.Forensic Secur.</source> (<year>2018</year>) <volume>13</volume>:<fpage>1333</fpage>&#x2013;<lpage>45</lpage>. <pub-id pub-id-type="doi">10.1109/TIFS.2017.2787987</pub-id> </citation>
</ref>
<ref id="B22">
<label>22.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Zhou</surname>
<given-names>C</given-names>
</name>
<name>
<surname>Fu</surname>
<given-names>A</given-names>
</name>
<name>
<surname>Yu</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Yang</surname>
<given-names>W</given-names>
</name>
<name>
<surname>Wang</surname>
<given-names>H</given-names>
</name>
<name>
<surname>Zhang</surname>
<given-names>Y</given-names>
</name>
</person-group>. <article-title>Privacy-preserving Federated Learning in Fog Computing</article-title>. <source>IEEE Internet Things J</source> (<year>2020</year>) <volume>7</volume>:<fpage>10782</fpage>&#x2013;<lpage>93</lpage>. <pub-id pub-id-type="doi">10.1109/JIOT.2020.2987958</pub-id> </citation>
</ref>
<ref id="B23">
<label>23.</label>
<citation citation-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Zhang</surname>
<given-names>CL</given-names>
</name>
<name>
<surname>Li</surname>
<given-names>SY</given-names>
</name>
<name>
<surname>Xia</surname>
<given-names>JZ</given-names>
</name>
<name>
<surname>Wang</surname>
<given-names>W</given-names>
</name>
</person-group>. <article-title>Batchcrypt: Efficient Homomorphic Encryption for Cross-Silo Federated Learning</article-title>. In: <conf-name>USENIX Annual Technical Conference. (2020)</conf-name>; <conf-date>2020, July 15-17</conf-date>; <conf-loc>Boston, MA, USA</conf-loc> (<year>2020</year>). </citation>
</ref>
<ref id="B24">
<label>24.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Hao</surname>
<given-names>M</given-names>
</name>
<name>
<surname>Li</surname>
<given-names>H</given-names>
</name>
<name>
<surname>Luo</surname>
<given-names>X</given-names>
</name>
<name>
<surname>Xu</surname>
<given-names>G</given-names>
</name>
<name>
<surname>Yang</surname>
<given-names>H</given-names>
</name>
<name>
<surname>Liu</surname>
<given-names>S</given-names>
</name>
</person-group>. <article-title>Efficient and Privacy-Enhanced Federated Learning for Industrial Artificial Intelligence</article-title>. <source>IEEE Trans Ind Inf</source> (<year>2020</year>) <volume>16</volume>:<fpage>6532</fpage>&#x2013;<lpage>42</lpage>. <pub-id pub-id-type="doi">10.1109/TII.2019.2945367</pub-id> </citation>
</ref>
<ref id="B25">
<label>25.</label>
<citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname>Damg&#xe5;rd</surname>
<given-names>I</given-names>
</name>
</person-group>. <source>On &#x3a3;-protocols. Lecture Notes</source>. <publisher-name>University of Aarhus, Department for Computer Science</publisher-name> (<year>2002</year>).</citation>
</ref>
<ref id="B26">
<label>26.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Guo</surname>
<given-names>JL</given-names>
</name>
<name>
<surname>Liu</surname>
<given-names>ZY</given-names>
</name>
<name>
<surname>Lam</surname>
<given-names>KY</given-names>
</name>
<name>
<surname>Zhao</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Chen</surname>
<given-names>YQ</given-names>
</name>
<name>
<surname>Xing</surname>
<given-names>CP</given-names>
</name>
</person-group>. <article-title>Secure Weighted Aggregation for Federated Learning</article-title>. (<year>2020</year>) <comment>arXiv preprint arXiv:2010.08730</comment>. </citation>
</ref>
<ref id="B27">
<label>27.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Xu</surname>
<given-names>G</given-names>
</name>
<name>
<surname>Li</surname>
<given-names>H</given-names>
</name>
<name>
<surname>Liu</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Yang</surname>
<given-names>K</given-names>
</name>
<name>
<surname>Lin</surname>
<given-names>X</given-names>
</name>
</person-group>. <article-title>Verifynet: Secure and Verifiable Federated Learning</article-title>. <source>IEEE Trans.Inform.Forensic Secur.</source> (<year>2020</year>) <volume>15</volume>:<fpage>911</fpage>&#x2013;<lpage>26</lpage>. <pub-id pub-id-type="doi">10.1109/TIFS.2019.2929409</pub-id> </citation>
</ref>
<ref id="B28">
<label>28.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Guo</surname>
<given-names>X</given-names>
</name>
<name>
<surname>Liu</surname>
<given-names>Z</given-names>
</name>
<name>
<surname>Li</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Gao</surname>
<given-names>J</given-names>
</name>
<name>
<surname>Hou</surname>
<given-names>B</given-names>
</name>
<name>
<surname>Dong</surname>
<given-names>C</given-names>
</name>
<etal/>
</person-group> <article-title>VeriFL: Communication-Efficient and Fast Verifiable Aggregation for Federated Learning</article-title>. <source>IEEE Trans.Inform.Forensic Secur.</source> (<year>2021</year>) <volume>16</volume>:<fpage>1736</fpage>&#x2013;<lpage>51</lpage>. <pub-id pub-id-type="doi">10.1109/TIFS.2020.3043139</pub-id> </citation>
</ref>
<ref id="B29">
<label>29.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Schnorr</surname>
<given-names>CP</given-names>
</name>
</person-group>. <article-title>Efficient Signature Generation by Smart Cards</article-title>. <source>J&#x20;Cryptology</source> (<year>1991</year>) <volume>4</volume>:<fpage>161</fpage>&#x2013;<lpage>74</lpage>. <pub-id pub-id-type="doi">10.1007/BF00196725</pub-id> </citation>
</ref>
<ref id="B30">
<label>30.</label>
<citation citation-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Pedersen</surname>
<given-names>TP</given-names>
</name>
</person-group>. <article-title>Non-interactive and Information-Theoretic Secure Verifiable Secret Sharing</article-title>. In: <conf-name>Annual international cryptology conference</conf-name>; <conf-date>1991, July 11-15</conf-date>; <conf-loc>Santa Barbara, CA, USA</conf-loc> (<year>1991</year>). p. <fpage>129</fpage>&#x2013;<lpage>40</lpage>. <pub-id pub-id-type="doi">10.1007/3-540-46766-1_9</pub-id> </citation>
</ref>
<ref id="B31">
<label>31.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Li</surname>
<given-names>S</given-names>
</name>
<name>
<surname>Jiang</surname>
<given-names>L</given-names>
</name>
<name>
<surname>Wu</surname>
<given-names>X</given-names>
</name>
<name>
<surname>Han</surname>
<given-names>W</given-names>
</name>
<name>
<surname>Zhao</surname>
<given-names>D</given-names>
</name>
<name>
<surname>Wang</surname>
<given-names>Z</given-names>
</name>
</person-group>. <article-title>A Weighted Network Community Detection Algorithm Based on Deep Learning</article-title>. <source>Appl Maths Comput</source> (<year>2021</year>) <volume>401</volume>:<fpage>126012</fpage>. <pub-id pub-id-type="doi">10.1016/j.amc.2021.126012</pub-id> </citation>
</ref>
<ref id="B32">
<label>32.</label>
<citation citation-type="confproc">
<person-group person-group-type="author">
<name>
<surname>Schoenmakers</surname>
<given-names>B</given-names>
</name>
<name>
<surname>Veeningen</surname>
<given-names>M</given-names>
</name>
</person-group>. <article-title>Universally Verifiable Multiparty Computation from Threshold Homomorphic Cryptosystems</article-title>. In: <conf-name>International Conference on Applied Cryptography and Network Security</conf-name>; <conf-date>2015, June 2-5</conf-date>; <conf-loc>New York, USA</conf-loc> (<year>2015</year>). p. <fpage>3</fpage>&#x2013;<lpage>22</lpage>. <pub-id pub-id-type="doi">10.1007/978-3-319-28166-7_1</pub-id> </citation>
</ref>
<ref id="B33">
<label>33.</label>
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Yu</surname>
<given-names>G</given-names>
</name>
</person-group>. <article-title>Simple Schnorr Signature with Pedersen Commitment as Key</article-title>. <source>IACR Cryptol Eprint Arch</source> (<year>2020</year>). </citation>
</ref>
</ref-list>
</back>
</article>