Patent Application
20200014703
“Optimized Honest-Majority MPC for Malicious Adversaries Breaking the 1 Billion-Gate per Second Barrier” by T. Araki, A. Barak, J. Furukawa, T. Lichter, Y. Lindell, A. Nof, K. Ohara, and A. Watzman, in IEEE Symposium on Security and Privacy, SP 2017, San Jose, Calif., USA, May 22-24, 2017, IEEE Computer Society, 2017, the contents of which are incorporated herein by reference in their entirety.
“From Passive to Covert Security at Low Cost” by I. Damgard, M. Geisler, and J. B. Nielsen, in D. Micciancio, editor, Theory of Cryptography, 7th Theory of Cryptography Conference, TCC 2010, Zurich, Switzerland, Feb. 9-11, 2010, proceedings, volume 5978 of Lecture Notes in Computer Science, pages 128-145, Springer, 2010, the contents of which are incorporated herein by reference in their entirety.
“Verifiable Computation in Multiparty Protocols with Honest Majority” by P. Laud and A. Pankova, in S. S. M. Chow, J. K. Liu, L. C. K. Hui, and S. Yiu, editors, Provable Security-8th International Conference, ProvSec 2014, Hong Kong, China, Oct. 9-10, 2014, proceedings, volume 8782 of Lecture Notes in Computer Science, pages 146-161, Springer, 2014, the contents of which are incorporated herein by reference in their entirety.
“High-Throughput Secure Three-Party Computation for Malicious Adversaries and an Honest Majority” by J. Furukawa, Y. Lindell, A. Nof, and O. Weinstein, in J. Coron and J. B. Nielsen, editors, Advances in Cryptology-EUROCRYPT 2017-36th
Annual International Conference on the Theory and Applications of Cryptographic Techniques, Paris, France, April 30-May 4, 2017, Proceedings, Part II, volume 10211 of Lecture Notes in Computer Science, pages 225-255, 2017, the contents of which are incorporated herein by reference in their entirety.
The present invention, in some embodiments thereof, relates to identifying malicious (adversary) computing nodes (parties) participating in a secure Multi-Party Computation (MPC) and, more particularly, but not exclusively, to identifying malicious computing nodes participating in the secure MPC by validating each shared value computed and committed by each of the computing nodes.
Computations involving multiple parties (MPC) which jointly compute a function may be of major significance for a plurality of practical applications ranging from simple tasks such as, for example, coin tossing to more complex tasks such as, for example, electronic auctions, E-commerce (on-line commerce), electronic voting, privacy-preserving data mining and/or the like.
Due to one or more reasons, for example, privacy, security and/or the like, in many of the MPC applications, the parties participating in the joint computation are reluctant to share their own data with the other parties. A secure MPC utilizing a cryptography based secure protocol as known in the art may therefore provide a framework for such MPC applications. Moreover, in addition to assuring privacy, the secure MPC as known in the art may ensure immunity to malicious parties, independence of input data among the parties, fairness in distributing the output of the jointly computed function to all parties, guaranteed output and/or the like.
According to a first aspect of the present invention there is provided a system for identifying one or more malicious parties participating in a secure multi-party computation (MPC), comprising one or more of a plurality of computing nodes communicating with the plurality of computing nodes through one or more networks, wherein the one or more computing nodes comprising one or more processors adapted to execute a code. The code comprising:
According to a second aspect of the present invention there is provided a computer implemented method of identifying one or more malicious parties participating in a secure multi-party computation (MPC), comprising using one or more processors of one or more of a plurality of computing nodes communicating with the plurality of computing nodes through one or more networks. The one or more processors are adapted to execute a code for:
Identifying and exposing the identity of the malicious computing node(s) and hence hurting the adversary and his reputation may naturally deter potential adversaries from corrupting the secure MPC. Moreover, since the secure MPC protocol with identifiable abort ensures data privacy and correctness (i.e. aborts when the adversary is detected), the adversary may gain nothing by cheating while risking exposure and/or reputation damage. Moreover while supporting identifying the malicious computing node(S), the high throughput of the secure MPC protocol is maintained since the identification process may be conducted after detection of the invalid share value(s). As such during runtime (until detection of the malicious computing node(s)) the MPC protocol executes as standard MPC protocols.
In a further implementation form of the first and/or second aspects, the one or more malicious computing nodes constitute a minority among the plurality of computing nodes. In order to identify the malicious computing node(s) the honest computing nodes must constitute a majority of the computing nodes. In case this condition is not met, the honest malicious nodes may not be able to accumulate sufficient reliable data, specifically agreed share values to reconstruct the MPC protocol and identify the malicious computing node(s).
In a further implementation form of the first and/or second aspects, one or more of the plurality of agreed share values is determined based on a data exchanged between the plurality of computing nodes transmitting the plurality of broadcast messages and private messages after the detection. The plurality of computing nodes may exchange data with each other, in particular after detecting the malicious computing node(s) to allow the other computing nodes to access the committed share values. Accessing the committed share values, the honest computing nodes may agree on the agreed share values which are committed by the honest computing nodes.
In a further implementation form of the first and/or second aspects, one or more of the plurality of agreed share values is determined based on a data exchanged between the plurality of computing nodes transmitting the plurality of broadcast messages and private messages prior to the detection. The plurality of computing nodes may store message history of messages exchanged between the computing nodes during the MPC prior to the detection of the malicious computing node(s). Using the history of messages the honest computing nodes may agree on the agreed share values which were committed by the honest computing nodes during the MPC session, in particular before detecting the malicious computing node(s).
In a further implementation form of the first and/or second aspects, the identification is based on a reconstruction of the one or more secure protocols from the plurality of agreed share values to identify, for each of the plurality of share values, an originating computing node which committed the each of share values. Since the invalid share value(s) is not agreed on as an agreed share value, using the agreed share values, the honest computing nodes may reconstruct the secure protocol to identify the originating malicious computing node(s) which committed the invalid share value(s).
In a further implementation form of the first and/or second aspects, the reconstruction is done based on data exchanged between the plurality of computing nodes transmitting the plurality of broadcast messages and private messages. The plurality of computing nodes may transmit private messages which are typically encrypted to another computing node to provide the other computing node the access key (opening) to the broadcasted commitment messages comprising the committed share values.
In an optional implementation form of the first and/or second aspects, a plurality of instances of the secure protocol(s) is executed concurrently. Executing the plurality of instances of the protocol may significantly increase the throughput of data exchanged between the computing nodes.
In a further implementation form of the first and/or second aspects, each of the plurality of broadcast messages is encoded for authentication of an originating computing node of the each broadcast message. This may allow each of the plurality of computing nodes to verify the identity of the originating computing node which transmitted a certain broadcast message.
In a further implementation form of the first and/or second aspects, each of the plurality of private messages is encrypted for authentication of the each private message, wherein the authentication comprising authentication of a content of the each private message and authentication of an originating computing node of the each private message. This may allow each computing node to verify the identity of the originating computing node from which a certain private message is received. The encryption may further allow only the intended recipient (having an appropriate encryption key) to access the content of the message.
In a further implementation form of the first and/or second aspects, one or more of the plurality of private messages is encrypted using a random process applying one or more seeds committed by one or more pseudorandom function. Using the random processes based on the seeds which are also selected randomly may significantly increase robustness of the encryption of the messages, specifically the private messages.
Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention pertains. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the invention, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.
Implementation of the method and/or system of embodiments of the invention can involve performing or completing selected tasks manually, automatically, or a combination thereof. Moreover, according to actual instrumentation and equipment of embodiments of the method and/or system of the invention, several selected tasks could be implemented by hardware, by software or by firmware or by a combination thereof using an operating system.
For example, hardware for performing selected tasks according to embodiments of the invention could be implemented as a chip or a circuit. As software, selected tasks according to embodiments of the invention could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In an exemplary embodiment of the invention, one or more tasks according to exemplary embodiments of method and/or system as described herein are performed by a data processor, such as a computing platform for executing a plurality of instructions. Optionally, the data processor includes a volatile memory for storing instructions and/or data and/or a non-volatile storage, for example, a magnetic hard-disk and/or removable media, for storing instructions and/or data. Optionally, a network connection is provided as well. A display and/or a user input device such as a keyboard or mouse are optionally provided as well.
Some embodiments of the invention are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments of the invention. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the invention may be practiced.
In the drawings:
The present invention, in some embodiments thereof, relates to identifying malicious (adversary) computing nodes (parties) participating in a secure MPC and, more particularly, but not exclusively, to identifying malicious computing nodes participating in a secure MPC by validating each shared value computed and committed by each of the computing nodes.
The secure MPC is conducted by a plurality of computing nodes (parties), for example, a server, a computer, a processing device, a cluster of computing nodes and/or any computing device comprising one or more processors to jointly compute a function over their respective input data without exposing their private input data to the other computing nodes. The secure MPC may be applicable for a plurality of practical applications ranging from simple tasks such as, for example, coin tossing and/or the like to highly complex tasks such as, for example, electronic auctions, E-commerce, electronic voting, privacy-preserving data mining and/or the like.
The computing nodes participating in the secure MPC may exchange data among them using one or more secure MPC protocols which are cryptography based secure protocols allowing data sharing between the computing nodes while ensuring data privacy. While executing the secure MPC protocol(s), the computing nodes may transmit encrypted private messages with each other and broadcast authenticated messages to all of the other computing nodes. Data privacy in the secure MPC context means that none of the computing nodes may infer any information about the input data held by the other computing nodes from the messages exchanged during the execution of the secure MPC protocol.
The only information that may be inferred by each of the computing nodes about the (private) input data of the other computing nodes is therefore whatever may be inferred only from the output of the jointly computed function. The secure MPC protocols.
While ideally the computing nodes participating in the MPC are honest (honest parties), in reality an adversary may corrupt one or more of the computing nodes such that one or more malicious computing node(s) may also participate in the secure MPC. The malicious computing node(s), i.e. malicious party(s), may also be referred to as dishonest party(s), cheating party(s), corrupted party(s) and/or cheater(s) herein after. Such malicious computing nodes may deviate from the secure MPC protocol in an attempt to corrupt the protocol, for example, obtain the private input data of one or more of the honest computing nodes, affect the output of the one or more of the honest computing nodes, affect the output of the jointly computed function and/or the like.
Assuming the honest computing nodes constitute a majority among the computing nodes participating in the MPC, one or more secure MPC protocols with abort as known in the art, for example, as described in referenced documents [1], [2], [3] and [4]), may ensure correctness of the protocol and guarantee an output delivery while maintaining the data privacy. Where ensuring the correctness means that the secure MPC protocol prevents the malicious computing node(s) from forcing any of the honest computing nodes to output incorrect data. Guarantying the output delivery means that the secure MPC protocol may guarantee that the correct output data of honest computing nodes is provided to the other computing nodes.
The secure MPC protocol(s) with abort may guarantee the correctness and the output delivery by detecting errors, i.e. invalid share values committed by one or more of the computing nodes during the MPC cycles and forcing the participating computing nodes to abort the MPC and hence maintain their data privacy. However, while able to detect the error(s), the secure MPC protocols with abort may be unable to identify the computing node(s) which committed the invalid share values which may typically be malicious computing node(s).
According to some embodiments of the present invention, there is provided methods, systems and computer program products for identifying an identity of one or more malicious computing nodes participating in the secure MPC by applying a secure MPC protocol with identifiable abort. The secure MPC protocol with identifiable abort which is based on secret sharing algorithms maintains the high throughput, the data privacy and output delivery guarantee as the secure MPC protocols with abort while further allowing identification of the identity of the malicious party(s) which committed the invalid share value(s).
The secure MPC protocols with identifiable abort further ensures independence of inputs as well as fairness where the independence of inputs means that none of the computing nodes may depend its input data on input data of other computing nodes and fairness means that the result of the jointly computed function is outputted only if all the computing nodes. Since fairness coupled with identifiable abort may guarantee the output delivery, the secure MPC protocol with identifiable abort thus provides full security.
Identifying the identity of the malicious computing node(s) is done following the abort event, i.e. following detection of one or more messages comprising the invalid share value(s). Identifying the identity of the malicious computing node(s) may be done by verifying each of the share values committed by all of the computing nodes. The computing nodes, specifically the honest computing nodes may verify all the share values committed by all of the computing nodes according to (against) “agreed share values” which are determined as valid share values for the secure MPC.
The honest computing nodes communicating amongst themselves using the private and broadcast messages may apply one or more algorithms to determine and/or identify the agreed share values. In order to agree on the agreed share values, an honest computing node may send to another honest computing node a commitment message comprising a part of its share value that is to be agreed and an opening value which may be used by the other honest computing node to open (decrypt) the commitment message. This sending honest computing node may also broadcast the same commitment message. The receiving honest computing node may verify if the received opening value is the valid opening value of the broadcasted commitment message. If the opening value is valid, the part of share value(s) transmitted by the sending honest computing is agreed.
If the opening value is not valid, the receiving honest computing node may broadcasts a complaint for the received opening value. In response to the broadcasted complaint, the sending honest computing node may broadcast an opening value for the broadcasted commitment message. If the broadcasted opening value is a valid opening of the broadcasted commitment message, the part of share value(s) transmitted by the sending honest computing is agreed. If the broadcasted opening value is not a valid opening value of the broadcasted commitment message, the sending honest computing is identified as the malicious computing node (cheater).
Once the agreed share values are set, each of the honest computing nodes may reconstruct the secure protocol from the agreed share values to the abort point in order to identify the originating computing node of each share value.
Therefore, by analyzing the commitment messages, one or more of the honest computing nodes may identify one or more invalid commitment messages which failed the verification, i.e. the invalid commitment message(s) is incompliant with the agreed share values. According to the reconstruction of the protocol, one or more of the honest computing nodes may trace each of the commitment messages, specifically each of the invalid commitment message(s) to its originating computing node(s) and thus identify the identity of the malicious computing node(s) which sent each invalid commitment message(s). Optionally, one or more of the honest computing nodes reconstructs the protocol based on the message history.
After identifying the malicious party(s), the honest computing node(s) may output, for example, distributed, published and/or the like the identity of the identified malicious party(s) to publicize this identity(s) in order to expose the malicious computing node(s) and/or the adversary(s).
The secure MPC protocol with identifiable abort may present significant advantages compared to existing secure MPC protocols, in particular, secure MPC protocols which abort at detection of the malicious party(s) as the secure MPC protocol with identifiable abort allows identifying the identity of the malicious computing node(s) while maintaining extremely high throughput which may be essential for an efficient secure MPC. Identifying and exposing the identity of the malicious computing node(s) and hence hurting the adversary and his reputation may naturally deter potential adversaries from corrupting the secure MPC. Moreover, since the secure MPC protocol with identifiable abort ensures data privacy and correctness (i.e. aborts when the adversary is detected), the adversary may gain nothing by cheating while risking exposure and/or reputation damage.
Some of the existing secure MPC protocols which achieve high throughput may only be secure in the presence of semi-honest malicious parties. Other protocols may achieve high throughput while failing to guarantee fairness as well as unable to identify the malicious party(s) such that the adversary may cause the parties to abort and not receive an output (even in cases where the adversary received the output) and the parties may not identify the malicious party(s).
Some of the secure MPC protocols supporting identification of the malicious party(s) for semi-honest malicious parties may be modified to achieve identifiable abort in which the malicious parties may be identified.
Such modifications may include, for example, a nave approach, in which each of the computing nodes may sign its respective committed share values. By analyzing the share values and their assigned signatures, the signature of the detected invalid share value(s) may be indicative of the malicious computing node(s) which committed the invalid share value(s). However, such approach may be highly demanding as it may require the parties to invest significantly high resources to encode, decode and communicate the signatures for each committed share value in run time during the commitment operation, thus add significant overhead to the computation which may negatively impact the throughput.
The secure MPC protocol with identifiable abort on the other hand maintains the high throughput of the secure MPC protocol with abort as known in the art since the verification of the shared values is done only after aborting the secure MPC, i.e. after detecting the invalid shared values(s). The verification process may therefore be regarded as an offline process which is conducted after the joint computation of the function is aborted. As such the online performance, specifically the throughput of the secure MPC protocol with identifiable abort is maintained during the computation phase of the secure MPC.
Moreover, the secure MPC protocol with identifiable abort may preserve the secure MPC properties as the secure MPC protocol with abort, specifically, data privacy, independence of input, correctness and guaranteed output delivery. In some scenarios the fairness may be somewhat compromised as the verification process also needs to be robust.
Furthermore, the secure MPC protocol with identifiable abort may execute and ensure security under the concurrent general composition such that multiple secure MPC protocols with identifiable abort may be concurrently established between the computing nodes thus significantly increasing data exchange throughput and/or decreasing transmission latency between the computing nodes. While some of the existing secure MPC protocols may support some operations in the concurrent general composition these secure MPC protocols may not allow some other operations to execute under the concurrent execution of multiple such secure MPC protocols.
The secure MPC with identifiable abort on the other hand may support most if not all operations to execute under the concurrent execution.
In addition, some of the existing secure MPC protocols may fail the asynchronous nature of the concurrent general composition as the adversary may block messages exchanged between the honest parties. In contrast, the secure MPC with identifiable abort may be executed in a concurrent general composition even when the network is asynchronous by preventing the adversary from blocking messages exchanged between the honest parties. While the malicious parties may still delay their own messages, this may have little and typically no impact on the overall performance and/or throughput of the secure MPC protocol with identifiable abort.
Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the Examples. The invention is capable of other embodiments or of being practiced or carried out in various ways.
The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.
The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing.
A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing.
A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages.
The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.
Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s).
In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.
Referring now to the drawings,
The secure MPC protocol with identifiable abort may be applicable for secure
MPC sessions in which honest computing nodes constitute a majority among the computing nodes participating in the secure MPC, i.e. the malicious computing node(s) constitutes a minority among the computing nodes participating in the secure MPC. Moreover, the secure MPC may be executed under concurrent general composition in which multiple instances of the secure MPC protocols may be executed concurrently thus significantly increasing the data throughput between the computing nodes and/or reducing latency in data transfer between the computing nodes.
Identifying the malicious party(s) may be done by verifying each of a plurality of share values committed by the computing nodes after detecting one or more errors, i.e. invalid commitment messages for committing invalid share value(s). Verifying the plurality of committed share values is done only after abort, i.e. after detecting the presence of the malicious party(s) in the secure MPC.
The computing nodes, specifically the honest computing nodes may exchange private and broadcast messages to determine and/or identify valid agreed share values committed by the honest parties and reconstruct the secure MPC protocol from the agreed share values to the point of abort, i.e. to the point of detection of the malicious computing node(s). The agreed share values may be further determined based on message history comprising a plurality of messages exchanged between the computing nodes during one or more cycles of the secure MPC session.
The agreed share values may also be identified by comparing the committed share values to pre-computed values allowed for the secure MPC. Committed share values which failed the verification, i.e. incompliant with the agreed share values may be considered invalid and the identity of the malicious party(s) which committed these invalid share value(s) may be identified.
Once identified, the identity of the identity of the identified malicious party(s) may be outputted, for example, distributed, published and/or the like to publicize the identity of the malicious party(s).
Reference is also made to
MPC, according to some embodiments of the present invention. An exemplary system 200 comprises a plurality of computing nodes 201, for example, computing nodes 201_1, 201_2 through 201_N participating in the secure MPC each executing a process such as the process 100 to execute (follow) the secure MPC protocol with identifiable abort in order to identify the identity of one or more malicious parties participating in the secure MPC.
Each of the computing nodes 201, for example, a computer, a server, a cluster of computing nodes and/or any computing device having one or more processors may typically include a network interface 202, a processor(s) 204 and a storage 206. The processor(s) 204 is coupled to the network interface 202 and to the storage 206 through one or more interconnecting interfaces, for example, a bus, a communication interface, a switch fabric and/or the like.
The network interface 202 may provide one or more network interfaces, for connecting to the other computing nodes 201 over a network 230 comprising one or more networks, for example, a Local Area Network (LAN), a wide Area Network (WAN), a Wireless LAN (WLAN) (e.g. Wi-Fi), a cellular network and/or the like. The network 230 may support private channels over which each of the computing nodes 201 may exchange secure authenticated private messages with each of the other computing nodes 201. The network 230 further supports broadcast channels over which each of the computing nodes 201 may broadcast authenticated messages to all of the other computing nodes 201. Naturally, each private message may be encrypted to be decoded only by its respective destination computing nodes 201 while each broadcast message may be decoded by all of the computing nodes 201. Both the private messages and the broadcast messages may typically be authenticated such that the originating computing node 201 of each of the messages may be identified.
The processor(s) 204, homogenous or heterogeneous, may be arranged for parallel processing, as clusters and/or as one or more multi core processor(s).
The storage 206 may include one or more computer readable medium devices, either persistent storage and/or volatile memory for one or more purposes, for example, storing program code, storing data, storing intermediate computation products and/or the like. The persistent storage may include one or more persistent memory devices, for example, a Flash array, a Solid State Disk (SSD) and/or the like for storing program code. The volatile memory may also include one or more volatile memory devices, for example, a Random Access Memory (RAM) device. The storage 206 may further include one or more networked storage resources, for example, a storage server, a Network Attached Storage (NAS) and/or the like accessible through the network interface 202.
The processor(s) 204 may execute one or more one or more software modules, for example, a process, an application, an agent, a utility, a script, a plug-in and/or the like. Wherein a software module may comprises a plurality of program instructions stored in a non-transitory medium such as the storage 206 and executed by a processor such as the processor(s) 204.
The processor(s) 204 may execute, for example, an MPC agent 210 for participating in the secure MPC using one or more secure MPC protocols with identifiable abort. Optionally, one or more of the MPC agents 210 are executed by one or more virtual machines (VM) hosted by one or more of the computing nodes 201. Optionally, one or more of the MPC agents 210 are executed by one or more remote platforms, for example, a remote server, a cloud computing platform, such as, for example, Amazon Web Service (AWS), Google Cloud, Microsoft Azure and/or the like. In such cases, the processor(s) 204 of computing node(s) 201 may locally execute one or more local software modules, for example, a local agent, a web browser and/or the like to communicate with the remote platform(s) executing the MPC agent(s) 210.
The computing nodes 201 participating in the secure MPC may be considered and/or referred to herein after as parties in the secure MPC. More specifically, each party consists of a computing node 201 executing its respective MPC agent 210. However, for brevity, a party, i.e. a computing node 201 executing its respective MPC agent 210 may be referred to herein after only as the MPC agent 210.
The computing nodes 201 may include a majority of honest computing nodes which follow the rules of the secure MPC protocol and one or more malicious computing nodes (also referred as dishonest, cheating and/or corrupted parties) which may deviate (cheat) from the secure MPC protocol in an attempt to corrupt the protocol, for example, to obtain the input data of one or more of the honest parties, affect the output of the one or more of the honest parties, affect the output of the jointly computed function and/or the like.
Assuming a majority of honest computing nodes among the computing nodes 201, the secure MPC protocol(s) with identifiable abort enables the computing nodes 201 each having private input data to compute a joint function over their respective input data in the presence of adversarial behavior, i.e. in the presence of one or more of the malicious computing nodes. The secure MPC protocol guarantees several aspects of the secure MPC:
In the case of no honest majority, there exist some joint functions, for example, the XOR function, unbiased coin tossing and/or the like which may not be securely computed with fairness or guaranteed output delivery using the secure MPC protocol. Thus, in such cases, security with abort is defined, where privacy, correctness and independence of inputs are required, but not fairness or guaranteed output delivery. Such exemplary secure MPC protocols with abort include, among others, the secure MPC protocols described in the referenced documents [1], [2], [3] and/or [4].
Feasibility and efficiency of the secure MPC protocols is known in the art. It was demonstrated that under appropriate hardness assumptions, any probabilistic polynomial-time functionality may be securely computed with computational security with or without a majority of honest computing nodes where security with abort is achieved for the case of no honest majority. In addition, when less than a third of the MPC agents 210 are corrupted, any functionality may be securely computed with information-theoretic security assuming ideal communication channels supported by the network 230.
When assuming a broadcast channel, information-theoretic security may be achieved for any honest majority. These fundamental feasibility results exhibited the extraordinary power of secure MPC and laid the foundation for the secure MPC potential to enable shared utilization of data while preserving data privacy for each of the MPC agents 210. Efficiency of the secure MPC is also demonstrated in the art, for example, in the referenced documents [1] and [4] among other publications and may therefore be used in practice to solve many non-trivial problems.
The concretely efficient secure MPC protocols as known in the art may be divided into protocols that aim to achieve low latency and protocols that aim to achieve high throughput. Where low latency related to minimizing the time from the beginning to the end of a single computation and high throughput relates to maximizing the number of function computations per second. These different goals may be suitable for different applications, and may thus be of major interest. Protocols targeting low latency may typically have a constant number of cycles and may be based on garbled circuits. In contrast, protocols targeting high throughput may have low communication per gate and may be based on secret sharing.
The specific case of three parties (i.e. MPC agents 210) with a majority of honest parties may be of considerable interest in the context of high throughput secure computation. This case may be well suited to the client-server “MPC service” model, where clients (parties) share their inputs to the three servers who carry out the secure computation for them.
The secure MPC protocol with identifiable abort may use some functionality which is implemented by one or more existing secure MPC protocol with abort as known in the art, specifically for identifying the malicious party(s). However the MPC protocol with identifiable abort is modified to include provisions to allow the identification of the malicious party(s) once detected. However, the secure MPC protocol with identifiable abort includes additional functionality compared to the existing secure MPC protocol with abort to support the identification of the malicious party(s) based on verification of the share values computed and committed by the MPC agents 210.
Identification of the malicious MPC agent(s) may depend on the fact that the secure MPC protocol is computationally secure since achieving absolute information theoretical security may not be feasible and/or practical due to the extremely high resources, for example, processing power, computations time, network bandwidth, latency and/or the like. As known in the art, such straight-line computational security which may be simulated in the stand-alone setting may not imply security under concurrent general composition, the security model of the secure MPC protocol with identifiable abort under concurrent general composition is first proved. The security of the secure MPC protocol with identifiable abort is maintained with complete fairness and identifiable abort.
Moreover, the security model of the secure MPC protocol with identifiable abort under the concurrent general composition ensures the security even when the network 230 is asynchronous and the malicious computing node(s) (adversary) is only allowed to delay the delivery of messages, i.e. the security model may prevent the adversary(s) from blocking messages exchanged between the honest parties while allowing the adversary(s) to delay its own messages. The secure MPC protocol with identifiable abort may require such an asynchronous network 230 to achieve complete fairness and identifiable abort.
Under the concurrent general composition, the MPC agents 210 may participate in an MPC using a general arbitrary secure MPC protocol ϕ that concurrently executes multiple instances of such a secure MPC protocol π which computes an ideal reactive functionality . In order to define the security, a real execution of the secure MPC protocol ϕ with the secure MPC protocol π is compared to an idealized setting where the secure MPC protocol ϕ is executed, but the MPC agents 210 access the ideal reactive functionality
instead of executing the secure MPC protocol π. Such an execution may be referred to as a hybrid model, because the ideal functionality
is within the model, but the secure MPC protocol ϕ also communicates real messages.
The security requirement is that, for every real adversary and every arbitrary secure MPC protocol ϕ, there exists an ideal adversary
such that for every set of inputs χ to the secure MPC protocol ϕ and an auxiliary input z to the real adversary
, the output of the ideal adversary
and the honest parties in the hybrid execution of the secure MPC protocol ϕ with the ideal functionality
is computationally indistinguishable to the output of the real adversary
and the honest parties in a real execution of the secure MPC protocol ϕ with the multiple instance of the secure MPC protocol π. Here, inputs to the secure MPC protocol π are determined by the secure MPC protocol ϕ.
Let k be the security parameter. An MPC protocol π securely computes the ideal functionality under concurrent general composition with computational security if for every non-uniform probabilistic polynomial-time real adversary
and every arbitrary secure MPC protocol ϕ, there exists a non-uniform probabilistic polynomial-time ideal adversary
such that for every set of input χ to the secure MPC protocol π and an auxiliary input z to the real adversary
, the output of the ideal adversary and honest parties, denoted by
(k, X), is computationally indistinguishable to the output of the real adversary
and the honest parties, denoted by
(k, X) as described in equation 1 below.
{(k, X)
{
(k, X)
Equation 1:
The secure MPC protocol with identifiable abort may achieve security with complete fairness and identifiable abort, meaning that the protocol terminates when either all of the MPC agents 210 receive the prescribed output or all the MPC agents 210 abort without receiving the output. In case of abort, all of the honest parties may learn the identity of one or more of the malicious (corrupted) parties. An ideal reactive function GMPC of a general computation MPC (GMPC) achieving such security is presented in Functionality 1 below where sid is a session identifier unique to each operation and varid is a unique index that identifies the secret shared value.
In Functionality 1, a ring refers to an algebraic structures used in abstract algebra which may consist of a set equipped with two binary operations that generalize the arithmetic operations of addition and multiplication. Every value stored by the Functionality 1 is indexed by a unique index varid.
Functionality 1 (FGMPC—Reactive Functionality)
The ideal functionality FGMPC is invoked with a set of corrupted parties I and a ring . I is minority and
is any finite ring in which every operation of the functionality is carried out. κ is the security parameter. FGMPC stores multiple pairs of a unique index and a value in the form (varid, x) for some x ∈
. We say varid is a new index when FGMPC does not store (varid, x) for some x. sid is a session identifier, which is unique to each unit operation. FGMPC, once invoked, accepts the following setup once and only once. After this setup, FGMPC receives requests for various type of operations listed below.
On receiving (setup, sid, κ) from all the parties, FGMPC sends (setup, sid, κ) to S. If FGMPC receives (accept,sid) from s, it delivers (accept,sid) to all the parties. However, if FGMPC receives (abort, sid, Pl ∈ I) from s, it delivers (abort, sid, Pl) to all the parties and aborts the functionality itself.
On receiving (random, sid, varid) from all the parties, where varid is a new index, FGMPC sends (random, sid, varid) to S. If FGMPC receives (accept, sid) from S, FGMPC randomly generates x ∈ , stores (varid, x), and delivers (accept, sid) to all the parties. However, if FGMPC receives (abort, sid, Pl Å I) from s, it delivers (abort, sid, Pl) to all the parties.
On receiving (input, sid, varid, Pk, x) from Pk and (input, sid, varid, Pk) from all the other parties, where varid is new and x ∈ , FGMPC sends (input, sid, varid, Pk) to S. If FGMPC receives (accept, sid) from S, FGMPC stores (varid, x) and delivers (accept, sid) to all the parties. However, if FGMPC receives (abort, sid, Pl ∈ I) from s, it delivers (abort, sid, Pl ) to all the parties.
On receiving (output, sid, varid, Pj ) from all the uncorrupted parties where FGMPC has a record (varid, x), FGMPC sends (output, sid, varid, pj) to S. FGMPC delivers (value, sid, varid, x) to Pj.a a FGMPC accepts only one output for each varid to make the simulation simple.
On receiving (addc/multc, sid, varid, varid′, v) from all the parties, where FGMPC has a record (varid′, x′), varid is a new index, and v ∈ , FGMPC sends (addc/multc, sid, varid, varid′, v) to S. If FGMPC receives (accept, sid) from S, FGMPC generates x=x′+v when addc or x=x′·v when multc, stores (varid, x), and delivers (accept, sid) to all the parties. However, if FGMPC receives (abort, sid, Pl ∈ I) from S, it delivers (abort, sid, Pl) to all the parties.
On receiving (add !malt, sid, varid, varid′, varid″) from all the parties, where FGMPC has records (varid′, x′) and (varid″, x″), varid is a new index, FGMPC sends (add/mult, sid, varid, varid′, varid″) to S. If FGMPC receives (accept, sid) from S, FGMPC generates x=x′+x′ when add or x=x′·x″ when mult, stores (varid, x), and delivers (accept, sid) to all the parties. However, if FGMPC receives (abort, sid, Pl ∈ I) from S, it delivers (abort, sid, Pl ) to all the parties.
As seen in functionality 1, since the output operation always outputs the result to all of the honest (uncorrupted) parties if and only if all the honest parties agree to output data, and there are no other operations that output data, the functionality is fair. Moreover, since the GMPC always outputs (abort, sid, Pi ∈
) in case of abort, where
is the set of malicious (corrupted) parties, the abort is of the type identifiable, i.e. the identity of one or more of the malicious parties is identified. As the fairness and identifiable properties of the secure MPC protocol with identifiable abort are fulfilled the security of the secure MPC protocol with identifiable abort is thus proved.
For brevity, the secure MPC protocol with identifiable abort is demonstrated for a three-party computation where three MPC agents 210 designated P1, P2 and P3 participate in the MPC using the secure MPC protocol with identifiable abort. However, the secure MPC protocol with identifiable abort may be applied to a plurality of MPC agents 210 and the demonstrated three-party computation should not be construed as limiting. The secure MPC protocol with identifiable abort targets high throughput MPC applications and is therefore based on secret sharing. An index i indicates a certain one of the MPC agents 210 (party), i=0 implies i=3 and i=4 implies i=1. Hence, Pi+1 is P1 when i=3 and Pi−1 is P3 when i=1. It is noted that indices of the MPC agents 210 (parties) are also used as indices of values, i.e. share values which may be referred to as values in an ideal functionality.
For any finite ring and any element v ∈
shares of v of Pj for j ∈ {1, 2, 3} in the replicated secret sharing as known in the art is (vj, vj−1) for randomly chosen v1, v2, v3 ∈
under the constraint v1+v2+v3=v ∈
. The element v may be expressed by expression 1 below.
[v]:=([v]1, [v]2, [v]3), [v]j:=([v]j,1, [v]j,2):=(vj, vj−1) Expression 1:
It is easy to verify that the element v may be recovered from any two share values of [v], and the distribution of each share value of the MPC agents 210 is identical for any element v.
Let (Commit, Verify) be a commitment scheme. Given a message msg ∈ {0,1}* and a randomly chosen open ∈ {0, 1}k value which may be used with a com=Commit(msg, open) to open the commitment message msg, where Commit generates a commitment com ∈ {0, 1}k as com=Commit(msg, open) and Verify outputs either accept or reject. For all msg ∈ {0, 1}* and for all open ∈ {0, I}k, accept=Verify(Commit(msg, open), msg, open). Commitment schemes have hiding and binding properties. The commitment scheme described herein above is only computationally binding since a pair of arbitrary message and fixed length opening bears only a fixed length commitment.
Let Wcommit : {0,1}k×0,1}k×0,1}k {0,1}k×{0,1}k be such that for any msg ∈ {0,1}* and for randomly chosen wopen:=(open, open′) ∈ {0, 1}k×{0,1}k, Wcommit outputs wopen:=(com, com′) ∈ {0,1}k×{0,1}k and such that com=Commit(msg, open) and com′=Commit(open, open′). As such wcom=Wcommit(msg, open, open′).
Let (wcom, wopen) be such that wcom:32 (com, com′) and wopen=(open, open′). It is said that (wcom, wopen) is correct if Verify(com′, open, open′)=accept. It is said that wopen is a valid opening of the wcom for the message msg ∈ {0, 1} if accept=Verify(com, msg, open).
Let arbitrary msg ∈ {0, 1}*, randomly chosen open ∈ {0, 1}k and open′ ∈ {0,1}k, wopen=(open, open′) and wcom:=(com, com′) ∈ {0,1}k ×{0,1}k. For a given commitment (wcom, wopen) it is possible to verify whether or not the commitment is correct as a verifiable commitment. Given a correct commitment (wcom, wopen), for any msg ∈ {0,1}*, it is possible to prove either (and only either) that wopen is a valid opening of the wcom to the message msg ∈ {0, 1}* or that wopen is an invalid opening of the wcom to the message msg ∈ {0,1}*. In order to prove validity, the knowledge of wopen may be proved such that accept=Verify(com, msg, open). In order to prove invalidity, the knowledge of wopen may be proved such that accept ≠ Verify(com, msg, open) and accept=Verify(com′, open, open′). For a valid wopen of wcom with respect to msg, due to the binding property of the second commitment, it is computationally hard to prove the knowledge of (open†, open‡) such that accept ≠ Verify(com, msg, open†) and accept=Verify(com′, open†, open‡) for some open† and open‡. For an invalid wopen of wcom with respect to the message msg, due to the binding property of the second commitment, it is computationally hard to prove the knowledge of open† such that accept=Verify(com, msg, open†)) for some open†. [97] The secure MPC protocol with identifiable abort may further use some concepts applied in semi-honest Secure Protocol. Let a secret sharing of v, v′ ∈ be expressed by expression 2 below.
[v]:=((v1, v3), (v2, V1), (v3, v2)), [v′]:=((v′1, v′3), (v′2, v′1), (v′3, v′2)) Expression 2:
Semi-honest secure addition operation and multiplication operations as known in the art are as follows:
In order to compute a
of the product or two values v and v′, that is [v·v′], the parties Pi may operate as follows:
The MPC agents 210 using the secure MPC protocol with identifiable abort may further compute multiplication triples to verify the committed share values.
A multiplication triple in the ring is a tuple of share values ([a], [b], [c]) among the MPC agents 210 P1, P2 and P3 for a,b,c ∈
. It is said that a multiplication triple ([a], [b], [c]) is correct if a triple (a, b, c) reconstructed from the share values of honest parties, which are assumed to constitute a majority among the MPC agents 210, satisfies c=a·b.
Multiplication triples have the following properties: it is possible to efficiently validate whether a multiplication triple is correct (i.e., whether c=a·b) by opening the multiplication triple and it is possible to efficiently verify if a multiplication triple ([a], [b], [c]) is correct without opening the multiplication triple by using another correct multiplication triple ([a′], [b′], [c′]). The latter check is such that if one multiplication triple is correct and the other multiplication triple is not, then the adversary may always be caught. Furthermore, nothing may be learned about the values a, b, c while the multiplication triple ([a′], [b′], [c′]) is discarded (“wasted”) and may not be used again.
Techniques of MPC multiplication using multiplication triples are known in the art and have been used extensively to achieve efficient secure MPC computation in many protocols known in the art. Moreover, as known in the art a large number of multiplication triples may be generated where, as long as a malicious (cheating) is not detected, each triple is correct with high probability. Using the secure MPC protocol with identifiable abort, the MPC agents 210 may generate a large number of multiplication triples with semi-honest secure MPC multiplication, randomly open a small portion of the multiplication triples to verify the multiplication triples are correct with a certain probability, randomly group the rest of the multiplication triples in “buckets”, which is a set of triples, and mutually verify the multiplication triples within each bucket.
The secure MPC protocol with identifiable abort that securely realizes the reactive function GMPC (presented in Functionality 1) may generate multiplication (Beaver) triples using a multiplication triples generator
triple as presented in Functionality 2 below. An exemplary protocol realizing the multiplication triples generator
triple is presented in Protocol 8 below.
Functionality 2 (Ftriple Multiplication Triple Generation)
The ideal functionality Ftriple is invoked with a set of corrupted parties I. We say varid is a new index to Ftriple when FGMPC does not store (varid, [a], [b], [c]). Ftriple, once invoked, accepts the following setup once and only once. After this setup, Ftriple receives requests of (triple, sid, varid).
On receiving (setup, sid, κ) from all the parties, Ftriple sends (setup, sid, κ) to S. If Ftriple receives (accept, sid) from S, it delivers (accept, sid) to all the parties.
However, if Ftriple receives (abort, sid, Pl ∈ I), it delivers (abort, sid, Pl) to all the parties and aborts the functionality itself.
On receiving (triple, sid, varid) from all the uncorrupted parties, where varid is a new index to Ftriple, Ftriple sends (triple ,sid,varid) to S. If Ftriple receives (accept , sid, (([a′]k, [b′]k, [c′]k)k∈I) from S, Ftriple generates ([a], [b], [c]) such that “[a]k=[a′]k, [b]k=[b′]k, [c]k=[c′]k” for all k ∈ I and a b=c for randomly generated a, b ∈ , stores (varid, [a], [b], [c]), and sends (accept, sid, ([a]j, [b]j, [c]j)) to each Pj.
On receiving (verify,sid,varid) from Pj, where Ftriple stores (varid, [a],[b],[c]), Ftriple generates openvarid,jtriple ∈ {0,1}k and comvarid, jtriple =Commit(([a]j,2[b]j,2, [c]j,2, openvarid,jtriple), and sends (verify, sid,varid, Pj) to S. Then Ftriple sends (accept, sid, varid, Pj, comvarid,jtriple) to all parties, and sends (accept, sid, varid, Pj, ([a]j,2), [b]j,2, [c]j,2),openvarid,jtriple) to Pj.
Protocol 8 (Multiplication Triple Generation in Background πtriple)
Let N, m, C be appropriately chosen for given κ by the method given in [1].
When each party Pj for j ∈ {1,2,3} receives (setup, sid, κ, seedj, seedj−1), all the parties do as in the following;
2. For each j ∈ {1,2,3}, pj generates wopenj ∈×{0,1]k, ([c′i]j=1, . . . , Nm+C, and wcomj=wcommit(([c′i]j,1, . . . , Nm+C, wopenj) and broadcasts wcomj, and Pj also sends ([c′i]j,1)j=1, . . . m Nm+C, and wopenj to pj+1. For each j ∈ {1,2,3} and for i=1, . . . , Nm+C, Pj sets ([c′i]j=([c′i]j,1, [c′i]j−1,1).
3. All the parties collaborate in shuffling ([a′i], [b′i], [c′i])i=1, . . . , Nm+C. Every pair of parties open the last C triples to check if ai·bi=ci. If the equation does not hold for any pair of parties, every party Pi proves in zeroknowledge that it has obeyed the protocol with seedj. All the parties output (abort, sid, Pj) for such Pj that did not obey the protocol. All the parties remove the sampled C triples from the sequence.
4. All the parties randomly generates N buckets of m triples from the sequence of Nm triples. For each bucket, using the last m−1 triples, verify if the firs triple is correct. If it does not hold for any bucket with respect to any pair of parties, every party Pj proves in zeroknowledge that it has obeyed the protocol with seedj. All the parties output (abort, sid, Pj) for such Pj that did not obey the protocol. Let (]ak], [bk], [ck])k=1, . . . , N be this N triples made of first triples in buckets.
5. For each j ∈ {1,2,3}, Pj generates wopen′j ∈ {0,1}k×{0,1}k and wcom′jtriple=wcommit(([ak]j,1, [bk]j,1, [ck]j,1)k=1, . . . , N, wopen′j), broadcasts wcom′jtriple , and send wopen′j and ([ak]j,1, [bk]j,1, [ck]j,1)k=1, . . . , N to Pj+1. Then, for each j ∈ {1,2,3}, Pj verifies if wopen′j−1 is a valid opening of wcom′k−1triple with respect to ([ak]j,2,[bl]j,2, [ck]j,2)k=1, . . . , N. If it is not, Pj and Pj−1 prove in zeroknowledge that they have obeyed the protocol with wopenj−1,wopen′j−1, and seedj−1. Here, all the parties have wcom′j−1triple , wopen′j−1, comj−1, and wopenj−1, and how they shuffled the sequence of triples via authenticated broadcast channel. Hence, the proof is with respect to these commitments. All the parties output (abort, sid, Pl) for such Pl that did not obey the protocol.
When all the parties receives (triple, sid, valid), they randomly chooses k ∈ {1, . . . , N} and Pj outputs (accept, sid, valid, ([ak]j,[bk]j, [ck]j)). This triple is removed from the sequence and this k will never be chosen.
On receiving (verify, sid, varid), P1 sends (verify, sid, varid, Pj) to all otherparties. P1 outputs (accept, sid, varid, Pj, comvarid,jtriple=com′varid,jtriple) and (accept, sid, varid, open′varid,jtriple). The other parties outputs (accept, sid, varid, Pj, com′varid,jtriple). Note that com′jtriple=Commit(([ak]j,2,[bk]j,2, [ck]j,2)k=1, . . . , N, open′varid,jtriple) within wcom′varid,jtriple that Pj−1 has broadcasted once is also a commitment to ([ak]j,2, [bk]j,2, [ck]j,2) for any k. And open′varid,jtriple an opening of comjtriple.
The secure MPC protocol with verifiable abort may follow other secure MPC protocols with abort as known in the art with several modifications. Specifically, while executing the secure MPC protocol with verifiable abort, the MPC agents 210 may generate verifiable commitment to share values they commit (send). Based on these commitments, when the verification of one or more share value tuples fails, the MPC agents 210 may be able to identify one or more malicious parties which deviated from the secure MPC protocol. The MPC agents 210 may output these commitments and their respective openings when they receive an instruction (Verify, sid, varid) for some varid.
As discussed before, the secure MPC protocol with identifiable abort is demonstrated for a three-party computation for the three MPC agents 210 P1, P2 and P3. It is stresses that the secure MPC protocol with identifiable abort may be extended an MPC conducted by a plurality of MPC agents 210 and the demonstrated three-party computation should therefore not be construed as limiting.
Let the MPC agents 210 P1, P2 and P3 share an element x=x1+x2+x3 in as (x1, x3) for the party P1, (x2, x1) for the party P2 and (x3, x2) for the party P3. Assuming the party P1 maliciously modified its share value to (x1, x′3) for x′3≠x3. Using the secure MPC protocols with abort as known in the art, even if all the parties P1, P2 and P3 share their share values with each other, the party P2 may be unable to identify the malicious party since the party P2 may be unable decide whether the party P1 modified x3 into x′3 or whether the party P3 modified x′3 into x3. This problem may be common to all information theoretically secure MPC protocols.
The secure MPC protocol with identifiable abort therefore introduces a new notion agreed share values which may enable the honest parties to agree on the valid (right) share values. For each k ∈ {1, 2, 3}, the agreed share of x=x1+x2+x3 in for each party Pi may be expressed as (xj, xj−1, com. open) where open and com=Commit(xj−1, open) are generated by the party Pj−1 and com is broadcasted by the party Pj−1 in an authenticated manner. Based on the agreed share value and randomness committed during an initialization phase, once the malicious (cheating) party is detected, the honest parties may be able to reconstruct the secure MPC session (protocol) from an agreed share value and identify which of the MPC agents 210 is has cheated (modified the share value) at which point of the MPC. For example, the honest parties may construct the secure MPC session (protocol) as follows. The behavior of each of the parties is determined by its input, the randomness, and commitment messages the party receives during the MPC session (protocol).
The input is the share value(s) which is agreed and the randomness is committed at the initialization phase. The commitment messages are committed and broadcasted.
Hence, every data a certain party generates may be verified whether it is honestly generated if all of share values, randomness, and messages are revealed. As zero-knowledge protocols enable a party to prove to a verifier that it generated committed messages from committed inputs and randomness without opening the commitment to the verifier, using the same technique the party may prove to other parties that it reconstructed the MPC session (protocols) honestly (if it indeed did so).
The parties P1, P2 and P3 employing the secure MPC protocol with identifiable abort communicate with each other using private and broadcast channels supported by the network 230. The broadcast channels allow each of the parties P1, P2 and P3 to transmit one or more messages to all other parties while the private channels allow each of the parties P1, P2 and P3 to transmit one or more messages to a certain one of the other parties. Each of the broadcast messages exchanged between the parties P1, P2 and P3 is encoded for authentication of the originating party that sent the message. Each of the private messages exchanged between the parties P1, P2 and P3 is encrypted for both authentication of the originating party as well as encryption of the message content such that only the destination party may decode the private message.
The secure MPC protocol with identifiable abort is composed of two main procedures. The first procedure which is denoted πGMPC described in Protocol 3 below, basically follows secure MPC protocols with abort as known in the art with some modifications made to apply provisions for identifying the malicious party in case a cheating malicious party is detected. The second procedure which is denoted πidentify described in Protocol 4 below, is executed by the parties P1, P2 and P3 to identify the identity of the malicious party after the malicious party is detected. It is noted that a concrete protocol for guaranteed output delivery is not presented as it may be guaranteed by general secure two-party computation among honest parties once the malicious (cheater) party is identified.
For the πGMPC procedure and the πidentify procedure sid denotes a session identifier unique to each operation, for example setup, random, input, output, addc, add, mult, mulct and/or the like and varid is a unique index that identifies the secret share value. It is said that varid exists when each honest party Pj is storing varid, [x]j, com varid, openj−1varid) where {right arrow over (com)}varid is a set of (comjvarid)j∈{1,2,3} such that comjvarid is a commitment to a share value [x]j,1 that the honest party Pj broadcasted as (comjvarid, com′jvarid):=wcomjvarid, and openj−1varid is the opening of comjvarid.
For wcomlowerscriptupperscript, it is assumed that the components of wcomlowerscriptupperscript are (comlowerscriptupperscript, comlowersecriptuppersecript=wcomlowerscriptupperscript and (open lowerscriptlowerscript, openlowerscriptupperscript=wopenlowerscriptupperscript.
It is said that varid is a new index when varid does not exist.
When a party sends a wopen in a private message to another (destination) party and broadcasts wcom in a broadcast message in the same communication round, the destination party may consider that the private message of wopen is not in valid form if (wcom, wopen) is not correct. Or, when a party sends a private message of wopen and msg to another (destination) party and broadcast com in a broadcast message in the same communication round, the destination party may consider that the private message of open and msg is not in valid form if reject=Verify(com, msg, open).
It is assumed that, if a certain party did not send a private message in a valid form (format) as required by the secure MPC protocol, all the parties may be able to recognize the certain party and consider this party as a malicious party (a cheater). Therefore the MPC secure protocol with identifiable abort may no handle such cases in which a certain party(s) transmits messages which are not in valid form, i.e. do not comply with the secure MPC protocol.
Let :
be a cryptographic hash function that outputs an element of
. Define δj,i=1 only when i=j, otherwise δj,i=0. Let [1] be such public share values of 1 that is [1]j:=([1]j,1, [1]j,2)=(δj,1, δj,2) for j ∈ {1, 2, 3}.
Protocol 3 (Security with Identifiable Abort πGMPC)
Setup: When all the parties received (setup, sid, κ), parties do as the following.
Random: When all the parties received (random, sid, varid) for new varid, the parties do as the following for each j ∈ {1,2,3}:
[x]j=((rand_iv, sid, varid, seedj),
(rand_iv, sid, varid, seedj−1) wopenjvarid ∈R {0,1}k×{0,1}k, wcomjvarid=Wcommit([x]j,1, wopenjvarid)
Input: When Pk received (input, sid, varid, Pk, x) and all other parties received (input, sid, varid, Pk) for new varid, all the parties do as in the following.
[x]j=(xj, xj−1), openkvarid,j ∈R {0,1}k, comkvarid,j=Commit(xj, openkvarid,j)
wopenjvarid ∈{0,1}k×{0,1}k, wcomjvarid=Wcommit([x]j,1, wopenjvarid)
Output: When all the parties received (output, sid, varid, Pk) for k ∈ {1,2,3} where each honest party Pj for j ∈ {1,2,3} stores (varid, [x]j, , openj−1varid), the parties do as the following.
Multiply: When all the parties received (mult, sid, varid, varid′, varid″) where varid is new, each uncorrupted party Pj stores (varid′, [x′]j,, openj−1varid′) and (varid″, [x″]j,
, the parties do as in the following;
ρj=(mult_sid, varid, seedj)−
(mult sid, varid, seedj−1) [x]j,1=[x′]j,1·[x″]j,1+[x′]j,1·[x″]j,2+[x′],j,2·[x″]j,1+ρj openjvarid ∈R {0,1}kcomvarid=Committ([x]j,1, openjvarid)
[x]j=([x]j,1, [x]j−1,1), [r]j=[x′]j+[a]j, [s]j=[x″]j+[b]j wopenjvarid,1 ∈R {0,1}k×{0,1}k, openjvarid,2 ∈R {0,1}k wcomjvarid,1=Wcommit(([a]j,1, [b]j,1, [c]j,1), wopenjvarid,1) comjvarid,2=Commit([r]j,2, [s]j,2, openjvarid,2)
r
j
=[r]
j,1
+[r]
j,2-30 [r]j−1,2, sj=[s]j,1+[s]j,2+[s]j−1,2
[o]j=−[x]j+rj·sj·[1]j−sj·[a]j−rj·[b]j+[c]j
Q
j=(mult_iv2, sid, varid, seedj, rj, sj)
Q′
j=(mult_iv3, sid, varid, seedj, [o]j,2) (openjvarid,3, openjvarid,4) ∈R {0,1}k ×{0,1}k
(comjvarid,3)=Commit(Qj, openjvarid,3), (comjvarid,4)=Commit(Q′j, openjvarid,4)
Q
j−1=(mult_iv2, sid, varid, seedj−1, rj, sj)
If any party broadcasted ⊥mult_2, all the parties proceed to πidentify.
Q′
j−1=(mult_iv3, sid, varid, seedj−1, −[o]j,1−[0]j,2)
If any party broadcasted ⊥mult_3, all the parties proceed to πidentify
Add with Constant/Multiply with Constant/Add: When all the parties received (addc, sid, varid, varid′, varid″, v )/(multc, sid, varid, varid′, v)/(add, sid, varid, varid′, varid″) where v ∈ , varid is a new index, and each uncorrupted party Pj stores (varid′, [x′]j,
, openj−1varid′) (and (varid″, [x″]j,
, openj−1varid″) if add), the all parties do as in the following;
1. For each j ∈ {1,2,3}, generates
wopenjvarid ∈ {0,1}k×{0,1}k, wcomjvarid=Wcommit ([x]j,1, wopenjvarid)
2. For each j ∈ [1,2,3}, Pj sends (addc_msg/multc_msg/add_msg, sid, varid, openjvarid) to Pj+1, and broadcasts (addc_brd/multc_brd/add_brd, sid, varid, comjvarid).
3. For each j ∈ [1,2,3}, Pj verifies if wopenj−1varid is a valid opening of the wcomj−1varid with respect to ([x]j,2) and, if it is not valid, Pj broadcasts ⊥addc/multc/add. If any party broadcasted ⊥addc/multc/add, all the parties proceed to πidentify
4. For each j=1,2,3, Pj stores (varid, [x]j, , openj−1varid) and then outputs (accept, sid).
The πidentify procedure which is the malicious (cheater) party(s) identification part of the secure MPC protocol with identifiable abort is basically used by the parties to prove and verify the behavior of each of the MPC agents 210, specifically, verifying the share values committed by each of the MPC agents 210. The verification is based on zero-knowledge proof (argument) of knowledge and therefore each operation of the MPC starts from either agreed share values, verifiable share values and/or reconstructable share values and ends in agreed share values. Moreover every randomness process in the secure MPC protocol is provided by one or more pseudorandom functions with one or more committed seeds. The seeds may be short random numbers which may be extended using the pseudorandom function(s) in order to establish the randomness used for encrypting the messages. An MPC agents 210 (party) may use the randomness which may include for example, a cryptographic key or random sampling and/or the like to prevent a malicious party (adversary) from guessing the cryptographic key. Based on these two properties, each of the MPC agents 210 may be able to verify the validity of its behavior, i.e. generated and transmitted messages, specifically, to verify its committed share values.
Protocol 4 (Cheater Identification Protocol πidentify)
Parties proceeds to πidentify when a party broadcasts ⊥, for some *. The parties runs this protocol depending on this ⊥, as in the following.
Case ⊥. such that*≠ mult: For each j ∈ {1,2,3}, Pj does as in the following:
[x]
j−1,2=(rand_iv, sid, varid, seedj +1)
accept ≠Verify(comk+1varid, [x]j−1,2, openj+1varid)
accept=Verify(com′j+1varid, openj+1varid, open′j+1varid)
accept=Verify(comj+1seed, seedj+1, openj+1seed)
where comj+1seed, wcomj+1varid, varid, and sid are owned by both parties.
accept=Verify(comkvarid,j+1, [x]j−1,2, openkvarid,j+1)
accept 16 Verify(comk+1varid, [x]j,2, openj+1varid)
accept=Verify(com′j+1varid, openk+1varid, open′j+1varid)
where (comkvarid,j+1, wcomk+1varid, sid, and varid are owned by both parties.
accept=Verify(comj+1varid′, [x′]j−1,2, openj+1varid′)
accept=Verify(comj+1varid″, [x″]j−1,2, openj+1varid″) if add
accept ≠ Verify(comj+1varid, [x]j−1,2, openj+1varid)
accept=Verify(com′j+1varid, openj+1varid, open′j+1varid)
where v, comj+1varid′, comj+1varid″, wcom+1varid, sid, varid, and varid′ are owned by both parties.
Case and ⊥mult_1, ⊥mult_2, and ⊥mult_3: For each j ∈ {1,2,3}, Pj runs the following protocol with Pj−1.
accept=Verify(comvarid,j−1triple, ([a]j,2[b]j,2[c]j,2),openvarid,j−1triple)
accept ≠ Verify(comj−1varid,1, ([a]j,2[b]j,2[c]j,2), openj−1varid,1)
accept=Verify(comj−1varid,1, openj−1varid,1, openj−1varid,1)
where comvarid,jtriple, wcomj−1varid,1, sid, and varid are known to all th parties. If this proof is varid 1 successful, all the party output (abort, sid, Pj−1). If this proof is not successful, all the party output (abort,sid, Pk).
accept=Verify(comj+1varid′, [x′]j−1,2, openj+1varid′)
accept=Verify(comj+1varid″, [x″]j−1,2, openj+1varid″)
accept=Verify(comj+1varid, [x]j−1,2, openj+1varid)
accept =Verify(comj+1seed, seedj+1, openj+1seed)
accept=Verify(comj+1varid,1 , ([a]j−1,2[b]j−1,2[c]j−1,2), openj+1varid,1)
accept=Verify(comj+1varid,2, [r]j+1,2, [s]j+1,2, openj+1varid,2)
accept=Verify(comj+1varid,3, Qj+1, openj−1varid,3)
accept =Verify(comj+1varid,4, Q′j+1, openj+1varid,4) only when ⊥mult,3)
[x]
j−1,1
=[x′]
j,2
·[x″]
j,2
+[x′]
j,2
·[x″]
j−1,2
+[x′]
j−1,2
·[x″]
j,2, +(mult_iv1, sid, varid, seedj−1)−
(mult_iv1, sid, varid, seedj+1)
[r]
j−1,2
=[x′]
j−1,2
+[a]
j−1,2
, [s]
j−1,2
=[x″]
j−1,2
+[b]
j−1.2
[r]
j−1,1
=[x′]
j,2
+[a]
j,2
, [s]
j−1,1
=[x″]
j,2
+[b]
j,2
r
j−1
=[r]
j−1,1
+[r]
j−1,2
+[r]
j+1,2
, s
j−1
=[s]
j−1,1
+[s]
j−1,2
+[s]
j+1,2
[o]
j−1,1
=−[x]
j−1,1
+r
j−1,1
·s
j−1·[1]j−1,1−sj−1·[a]j,2−rj−119 [b]j,2+[c]j,2
[o]
j−1,2
=−[x]
j−1,2
+r
j−1
·s
j−1·[1]j−1,2−sj−1·[a]j−1,2−rj−1·[b]j−1,2+[c]j−1,2
Q
j−1=(mult_iv2,sid, varid, seedj−1, rj−1, sj−1)
Q
j−1=(mult_iv3, sid, varid, seedj−1, [o]j−1,2)
Q
j+1 ≠ (mult_iv2,d sid, varid, seedj , rj−1, sj−1) when ⊥mult 2
Q′
j+1 ≠(mult_iv3, sid, varid, seedj1, −[o]j−1,1−[o]j−1-1,2) when ⊥mult_3
where all the parties have comj+1varid′, comj+1varid″, comj+1varid, comj+1seed, comj+1varid,1, comj+1varid,2, comj+1varid,3, comj+1varid,4, varid, varid′, varid″, sid, [x′]j,2, [x″]j,2,[x]j-31 1,1, [a]j,2, [b]j,2, [c]j,2, [r]j−1,2, [s]j−1,2, seedj−1.
If Pj−1 fails in the proof, P1 outputs (abort, sid,13—1).
The secure MPC protocol with identifiable abort may further utilize multiple such protocols in order to increase the throughput of the communication between the MPC agents 210. This may be highly applicable since the operations conducted by the MPC agents 210, for example, the commitments, the openings, the hash values computations and/or the like may require significantly high communication bandwidth. Moreover, applying the plurality of protocols executed concurrently may significantly reduce the communication messages. Such concurrent execution was demonstrated in the art, for example, using Kerberos authentication and/or the like. The secure MPC protocol with identifiable abort therefore may not decrease the communication throughput compared to prior art secure MPC protocols with abort.
Moreover, the communication throughput may be increased when using the secure MPC protocol with identifiable abort since some operations which are non-interactive in the prior art secure MPC protocols with abort, for example, random, addc, multc, add and/or the like are in fact interactive in the secure MPC protocol with identifiable abort. This may be achieved since the MPC agents 210 may be able to conduct underlying semi-honest secure computations without these communicating with other MPC agents 210 except for the output operation which may be executed after all verification operations are completed. In the secure MPC protocol with identifiable abort, each of the MPC agents 210 may execute each verification operation which is most of the protocol (except for the semi-honest secure part) directly after executing its relevant semi-honest secure protocol. In this way, the increase in the number of communication rounds remains in a small constant for the whole MPC computation. The secure MPC protocol with identifiable abort therefore may not increase the latency compared to prior art secure MPC protocols with abort.
However, if the MPC agents 210 execute a multiplication operation on a result of such a multiplication operations that is not completely verified yet, the security of each component multiplication may not imply the security of the whole operation. Clearly, the secure MPC protocol with identifiable abort may identify the malicious party (cheater) when aborted and may keep confidentiality when the not aborted. However, it is not obvious whether the secure MPC protocol with identifiable abort maintains fairness. This may result from the fact that the adversary may infer a hint of the shared secrets from the behavior of the cheating detection and/or the identity of the malicious party (cheater). Therefore, the secure MPC protocol with identifiable abort may therefore need to be conducted with special care and possibly with some provisions to maintain such care. A protocol {tilde over (π)}GMPC, which is a hyper-concurrent variant of the protocol πGMPC may be secure when executed in such a rush manner. An exemplary hyper-concurrent {tilde over (π)}GMPC protocol is presented in Protocol 5 below. Theorem 7 presented herein after may prove that the exemplary hyper-concurrent {tilde over (π)}GMPC securely realizes the ideal functionality.
Protocol 5 (Hyper Concurrent Run of πGMPC ({tilde over (π)}GMPC))
{tilde over (π)}GMPC is a hyper-concurrent run of the πGMPC and πidentify for a single circuit in the following manner. Each operation is divided into semihonest secure computation and verification process. Each verification is divided in to cheater detection described within πGMPC and cheater identification described in πidentify. A circuit is composed of layers of gates. Each layer is a small circuit whose input is from the lower layer. Thus, the evaluation of circuit proceeds strictly from lower layer to higher layer. In each layer, that is a small circuit, an output of gate in this layer is allowed to be input to another gate in the same layer only when the former gate is not multiplication of two inputs (a gate of multiplication with a constant is allowed). Operations with respect to a computation of this circuit is schedules as in the following;
Each operation in the circuit is allowed to start based on the outputs of other operation's semihonest secure computation.
If no party broadcasts abort, for some * for the entire circuit, only then the output operations are executed.
Operations in layers are synchronized in a way that the verification of an operation in a layer always proceeds ahead of the verification of the same type of operation in the higher layer. This means that Qj and Q′j, respectively, for some j in one layer should not be evaluated unless all the dependent Q, and Q′i, respectively, in the lower layer are evaluated.
Whenever, a party in πGMPC broadcasts abort, for some *, stop this operation without proceeding to πidentify. By completing other operations within πGMPC, identify one gate that outputs abort, for some*such that all of its preceding gates do not abort. Run πidentify only for this gate to identify the cheater.
The malicious party (cheater) identification protocol πidentify may require a lot of zero-knowledge protocols for commitment operations and/or for hash functions computations. While such operations may be extremely heavy, i.e. extensive resource demanding, for example, computation resources, communication resources and/or the like compared to the semi-honest secure computation of a single ring operation, execution of the πidentify procedure may be required for only one gate in the entire computation where the cheating, i.e. the invalid share value(s) is first detected. In addition, as long as cheating is not detected, execution of the πidentify procedure may never take place. Hence, the cost of cheater identification is acceptable as long as that single execution is practical. A practical execution of the πidentify procedure may be achieved by efficiently using one or more techniques, for example, ZKBoo and/or the like as known in the art.
Typically, the most resource demanding case of malicious party (cheater) identification in the MPC protocol with identifiable abort may be a case of multiplication. In the case that the cheating is detected at a multiplication, the malicious party (cheater) identification may require the MPC agents 210 to prove the knowledge of the opening of commitment and compute hash functions. For example, assuming the Commit operation is instantiated by SHA-256 with k=256 and is a 64-bit integer. The cost of malicious party (cheater) identification at the multiplication operation may be roughly equivalent to proving the knowledge of input of SHA-256 function for a 100 times. According to the ZKBoo technique, such a computation may be executed within 60 msec. It should be noted that using a public key primitive, for example, a signature for zero-knowledge proofs as may be done by the naive implementation instead of applying the commitment(s) as done in the MPC protocol with identifiable abort may be too heavy with respect to resources consumption even when using the efficient ZKBoo and may thus be impractical.
As shown at 102, the process 100 starts with the plurality MPC agents 210 (parties) participating in the secure MPC to jointly compute one or more functions. The MPC agents 210 may communicate with one another to exchange data and commit their respective computed share values using the πGMPC procedure with identifiable abort. While executing the πGMPC procedure, each of the MPC agents 210 may transmit one or more secure private messages to one or more of the other MPC agents 210 and broadcast one or more broadcast messages to all the other MPC agents 210. Each of the private messages is encrypted for content protection and authentication, such that only the destination MPC agent 210 may decode each private message and identify the originating MPC agent 210 which transmitted the private message. Each of the broadcast messages is authenticated such that each of the MPC agents 210 may identify the originating MPC agent 210 which transmitted the broadcast message.
Optionally, the MPC agents 210 employ the hyper-concurrent {tilde over (π)}GMPC procedure which may be executed under the concurrent general composition where multiple secure MPC protocol such as the πGMPC procedure are executed concurrently in order to increase the throughput of the communication between the MPC agents 210.
As shown at 104, during one or more cycles of the MPC, one or more of the MPC agents 210 executing the MPC with identifiable abort may detect an error, i.e. an invalid share value committed by one or more potentially malicious parties among the MPC agents 210, i.e. a dishonest party, a cheater, a corrupted party and/or the like in an attempt to corrupt the secure MPC, for example, obtain the input data of one or more honest parties, affect the output of the one or more of the honest parties, affect the output of the jointly computed function and/or the like.
As shown at 106, the MPC agents 210, specifically the honest parties among the MPC agents 210 may execute the πidentify procedure to verify their committed share values. Verifying the share values may be done by determining and/or identifying the agreed share values as described herein above for the πidentify procedure. The honest parties among the MPC agents 210 may verify each of the committed share values against the agreed share values and thus verify the share values and identify the share values which dialed the verification, i.e. do not comply with the agreed share values. The honest parties among the MPC agents 210 may determine the agreed share values may by exchanging data with one or more of the other honest parties among the MPC agents 210 using broadcast and/or private messages. Moreover, the MPC agents 210 may use message history in order to determine one or more of the agreed share values. The message history may include a plurality of messages, either private and/or broadcast messages previously transmitted by one or more of the MPC agents 210 during one or more cycles of the secure MPC.
As shown at 108, the MPC agents 210, specifically the honest parties among the MPC agents 210 may execute the πidentify procedure to identify the identity of the malicious party(s) among the MPC agents 210 (malicious computing node(s)) which committed the invalid share value(s). The honest parties among the MPC agents 210 may reconstruct the protocol from the agreed share values to the point of detection of the cheating (abort) as described herein above for the πidentify procedure. By reconstructing the protocol, the honest parties among the MPC agents 210 may identify the identity of the originating MPC agent 210 which committed each of the shared values and specifically identify the identify the malicious party(s) among the MPC agents 210 which committed the invalid share value(s). Optionally, one or more of the honest parties among the MPC agents 210 may exchange data with one or more of the other MPC agents 210 using the private and/or broadcast messages in order to reconstruct the protocol. Moreover, one or more of the honest parties among the MPC agents 210 may use message history in order to reconstruct the protocol.
As shown at 110, one or more of the MPC agents 210, specifically one or more of the honest parties may output the identity of the malicious party(s) among the MPC agents 210 (malicious computing node(s)), i.e. the cheating computing node(s) (cheater(s)). The identity(s) may then be publicized in order to hurt the reputation of such malicious parties and thus deter the adversary from corrupting the secure MPC session and/or one or more future secure MPC sessions.
Performance Comparison
The complexity and performance, in particular throughput of the secure MPC protocol with identifiable abort is compared for a three party computation to secret sharing based secure MPC protocols known in the art.
The comparison of secure MPC protocols is directed to complete fairness (Fairness), the probability of cheater detection (Detect), the ratio of overhead for semihonest secure MPC (i.e. communication overhead/communication for semihonest secure MPC, the amount of communication required for data input or data update (Input/Update), reuse (Reuse), and history required for identification during the computation of a circuit (History) and the amount of additional communication required for identification (Identify). The results of the performance comparison are presented in table 1 below.
MPC Protocol [1] designates the secret sharing based secure MPC protocol as presented in referenced document [2], the contents of which are incorporated herein by reference in their entirety. As seen in table 1, the MPC Protocol [1] enables semihonest secure MPC to detect and identify the malicious (cheating) party(s) with the probability of ¼. While the detection probability is not significantly high, the additional communication cost required to support the identification is extremely low. However, at the beginning of each cycle of the MPC Protocol [1], each party should convert each of its inputs into two inputs where one input is the genuine input and the other input is a dummy input where none of the other parties knows which is the dummy input. Since this conversion needs to be verifiable, it requires a GMPC which is secure in the presence of malicious parties. The GMPC may typically involve significant and potentially extreme communication traffic and data exchange. The same conversion is necessary when the committed share values are reused and/or updated. Moreover, as seen in table 1, The MPC Protocol [1] may fail to maintain fairness between the parties and requires storing all messages history until the relevant MPC cycle is completed.
MPC Protocol [2] designates the secret sharing based secure MPC protocol as presented in referenced document [3], the contents of which are incorporated herein by reference in their entirety. The parties applying the MPC protocol [2] may execute, simultaneously to the semihonest secure protocol, a verification protocol that may identify the malicious party(s). Although the protocol requires communicating (exchanging) multiple signatures between the parties, the parties may share these signatures among other protocols executed in parallel. Hence, signatures communication may be neglected. Each party is required to commit to all its inputs, distribute its share values to the verifier, and verify that these committed inputs and shared inputs are the same. This requires a GMPC which is secure in the presence of malicious parties for inputs and update. The MPC Protocol [2] also requires storing all messages history until the relevant MPC cycle is completed.
MPC Protocol [3] designates the secret sharing based secure MPC protocol as presented in referenced document [1], the contents of which are incorporated herein by reference in their entirety. Each party is required to commit to all its inputs, distribute its share values to the verifier, and verify that these committed inputs and shared inputs are the same. This requires a GMPC which is secure in the presence of malicious parties for inputs and update. In addition, similarly to the previously presented MPC protocols [1] and [2], all messages history may need to be stored until the relevant MPC cycle is completed.
MPC Protocol [4] designates a modified secure MPC protocol which is based on a secure MPC protocol presented in referenced document [4], the contents of which are incorporated herein by reference in their entirety. The modification may include verification of the input share values. To that end the (base) secure MPC protocol presented in the prior art item is modified to support cheater identifiability. As seen in table 1, the MPC protocol [4] does not require storing the messages history.
The MPC Protocol [5] presents the secure MPC protocol with identifiable abort as described in the present invention. As evident in table 1, The MPC Protocol [49 presents similar characteristics and performance, i.e. input, update, history management, throughput and/or the like until an abort event is detected, i.e. malicious party(s) is detected. As the MPC Protocol [4] is optimized for high throughput, the MPC Protocol [5] also presents such high throughput during normal MPC cycles until the abort event. The MPC Protocol [5] may require additional computation at each of the parties for identifying the malicious party(s). The additional computation may require extensive resources, for example, computation resources, communication resources and/or the like. However, since the additional computation is required only once following the abort event, the penalty for the additional computation may be of little significance.
Security Proof
Following is a security proof of the secure MPC protocol with identifiable abort (MPC Protocol [5]). The security proof first presents a simulated protocol of the secure MPC protocol with identifiable abort and further proves the indistinguishability of the simulated protocol and the real secure MPC protocol with identifiable abort. In the security proof presented herein, the malicious party is referred to as the adversary which may have access to a corrupted party.
Definition 5. (Simulator SA) Let Pl be the corrupted party. SA is an ideal adversary that interacts with the parties engaging in πGMPC and πidentify in (FGMPC)-hybrid model. It also has a black-box access to the real adversary A who corrupted Pl.
On receiving (setup, sid, κ) from FGMPC, SA does the followings;
1. SA generates seedl−1 ∈{0,1}k, a random commitment coml+1seed, Openl−1seed ∈R {0,1}k, and coml−1seed=Commit(seedl−1, openl−1seed), SA sends openl−1seed to Pl and broadcast coml−1seed as Pl−1and coml+1seed as Pl+1. SA receives openlseed and comlseed from A.
2. SA as Pl+1 and Pl−1 sends (setup, sid, κ) to Ftriple. If a party receives (abort, sid, Pk) from Ftriple, the party outputs (abort, sid, Pk) and abort the protocol. If a party receives (accept, sid) from Ftriple, the party proceeds to the next step.
3. If all the above processes are successful, SA sends (accept, sid) to FGMPC. Otherwise, it sends (abort, sid, Pl) to FGMPC.
On receiving (random, sid, varid) from FGMPC, SA does as follow:
1. SA generates
[x]l=(rand_iv, sid, varid, seedl),
(rand_iv,sid, varid, seedl−1))
2. SA generates a random commitment wcoml+1varid, wopenl−1varid ∈R {0,1}k×{0,1}l, and wcoml−varid=W commit([x]l,2, wopenl−1varid). SA broadcasts (random_brd, sid, varid, wcoml−1varid) as Pl−1 and (random_brd, sid, varid,
wcom;+1v arid) as Pl+1, and sends (random_msg, sid, varid, wopenl−1varid) to A. SA receives (random_msg, sid, varid, wcomlvarid) and (random_msg , sid, varid, wopenlvarid) from A.
3. SA verifies if wopenlvarid is a valid opening of wcomlvarid with respect to ([x]l,1), and if it is not, SA broadcasts ⊥random as Pl+1. If any party among Pl (corrupted by A) and Pl+1 (simulated by SA) broadcasts ⊥random, simulates the prover and plays the verifier of zeroknowledge protocol in πidentify, and completes simulation by sending (abort, sid, Pl) to FGMPC.
4. If no one broadcasts ⊥random, SA stores (varid, ([x]l,1, [x]l,2), Comlvarid, openlvarid) and sends (accept , sid) to FGMPC. In this case, SA completes the simulation for this request of random here.
On receiving (input, sid, varid, Pl) from FGMPC (where Pl is corrupted), SA does as in the following:
1. SA receives (input_msg1, sid, Pl, varid, [x]j, openjvarid,1, openjvarid,2) for j=l+1 and j=l−1 from A. SA receives (input_brd1, sid, Pl, varid, comjvarid,1, comjvarid,2, comjvarid,3).
2. SA generates a random wcoml+1varid), wopenl−1varid ∈R {0,1}k×{0,1}k, and wcom=wcommit([x]l−1,1, wopenl−1varid). SA sends (input_msg2, sid, varid,
wopenl−1varid) to A, broadcast (input_brd2, sid, varid, wcoml−1varid) as Pl−1 and (input_brd2, sid,
varid,wcoml+1varid) as Pl+1. SA receives (input_brd2, sid, varid, wcomlvarid) and (input_msg2, sid, varid, wopenlvarid).
3. SA verifies if wopenvarid ,l is a valid opening of wcomlvarid with respect to ([x]l+1,2).
4. If no one broadcasts ⊥input, SA stores (varid, ([x]l+1,2, [x]l−1,1), comlvarid, openlvarid), generates x=[x]l+1,2+[x]l−1,1+[x]l−1,2, sends (accept, sid, x) to FGMPC. In this case, SA completes the simulation for this request of input here.
On receiving (input, sid, varid, Pk) from FGMPC where Pk is an uncorrupted party, SA does as the following:
1. SA generates [x]l=([x]l,1, [x]l,2) ∈R ×
, openkvarid,l ∈R {0,1}k, openkvarid,l−1 ∈R {0,1}k, comkvarid,l=com([x]l,1openkvarid,l), comkvarid,l−1=com([x]l,2, openkvarid,l−1) and a random comkvarid,l+1. SA sends
(input_msg1, sid, Pk, varid, [x]l, openkvarid,l, openkvarid,l−1) to A, an broadcasts (input_brd1, sid, Pk, varid, comkvarid,1, comkvarid,2, comkvarid,3).
2. SA also generates a random commitment wcoml+1varid, wopenl−1varid ∈R {0,1}k×{0,1}k, and wcoml−1varid=Wcommit([x]l,2, wopenl−1varid). SA sends (input_msg2, sid, varid, wopenl−1varid) to A, and broadcasts (input_brd2, sid, varid, wcoml−1varid) as Pl−1 and (input_brd2, sid, varid, wcoml+1varid) as Pl+1. SA receives the message (input_msg2, sid, varid, wopenlvarid) and (input_brd2, sid, varid, wcomlvarid).
3. SA verifies if wopenlvarid is a valid opening of wcomlvarid with respect to([x]l,1), and if it is not, SA broadcasts ⊥input as Pl+1. If any party among Pl (corrupted by A) and Pl+1 (simulated by SA) broadcasts ⊥input, SA, SA simulates the prover and plays the verifier of zeroknowledge protocol in πidentify, and completes simulation by sending (abort, sid, Pl) to FGMPC.
4. If no one broadcasts ⊥input, SA stores (varid, ([x]l,1, [x]l,2), comlvarid, openlvarid) and sends (accept, sid) to FGMPC. In this case, SA completes the simulation for this request of input here.
On receiving (output, sid, varid, Pk) from FGMPC, where (varid,[x]l,comlvarid, openlvarid) is stored and Pk is not the corrupted party, SA does as in the following;
1. SA receives a message that A, as Pl, sends to Pk.
2. SA sends (accept, sid) to FGMPC.
On receiving (output, sid, varid, Pl) from FGMPC, where (varid,[x]l, comlvarid, openlvarid) is stored where Pl is the corrupted party, S does as in the following;
1. S, as Pl, receives (value, sid, varid, x) from FGMPC.
2. S generates the following messages
[x]l+1,1=x−[x]l,1−[x]l,2, [x]l+1,2=[x]l,1, [x]l,1,1=[x]l,2, [x]l−1,2=[x]l+1,1 openl+1varid ∈R {0,1}k, coml+1varidCommit([x]l+1,1, openl+1varid)
3. SA, as Pl+1, sends (output_msg, sid, varid, [x]l+1, openlvarid) to A. SA, as Pl−1, sends (output_msg , sid, varid, [x]l−1, openl+1varid) to A.
On receiving (addc, sid, varid, varid′, v)/(multic, sid, varid, varid′, v)/(add, sid, varid, varid′, v) from FGMPC where (varid′, [x′]l, comlvarid′, openlvarid′) is stored, (varid″, [x″]l, comlvarid″, openlvarid″) is stored if add, v ∈ if addc or multc, and varid is a new index. S does as in the following;
1. SA generates a random commitment wcoml+1varid and;
2. SA sends (acidc_msg/multc_msg/add_msg, sid, varid, wopenl−1varid) to A. SA broadcasts (addc_brd/multc_brd/acid_brd, sid, varid, wcoml−1varid) and (addc_brd/multc_brd/add_brd, sid, varid,wcoml+1varid). SA, as Pl+1, receives (addc_msg/multc_msg/add_msg, sid, varid, wopenlvarid) and
(addc_brd/mult_brd/add_brd, sid, varid, wcomlvarid) from A.
3. SA verifies if wopenlvarid is a valid opening of wcomlvarid with respect t ([x]l,1), and if it is not valid, SA broadcasts ⊥addc/multc/add as Pl+1. If any party among Pl (corrupted by A) and Pl+1 (simulated by SA) broadcasts ⊥add/multc/add, SA simulates the prover and plays the verifier of zeroknowledge protocol in πidentify, and completes simulation by sending (abort, sid, Pl) to FGMPC.
4. If no one broadcasts ⊥addc/multc/add, SA stores (varid, [x]l, comlvarid, openlvarid) and sends (accept, sid) to FGMPC. In this case, SA completes the simulation for this request of acidc/multc/add here.
On receiving (malt, sid, varid, varid′, varid″) where (varid′, [x′]l, comlvarid′,
openlvarid′) and (varid″, [x″]l, comlvarid″, openlvarid″) are stored, and varid is a new index, SA does as in the following.
1. SA generates a random commitmentcom;+1varid,[x]l−1,1 ∈R , openl−1varid ∈R {0,1}k, and coml−1varid=Commit([x]l−1,1, openl−1varid),
2. SA sends (mult_msg1, sid, varid, [x]l−1,1, openl−1varid) to A, and broadcasts (mult_brd1, sid, varid, coml−1varid) as Pl−1 and (mult_brd1, sid, varid, coml+1varid) as Pl+1. SA receives (mult_msg1, sid, varid,[x]l,1, openlvarid) and
(mult_brd1, sid, varid, comlvarid) from A.
3. SA lets Pl+1 and Pl−1 send (triple, sid, varid) to Ftriple, and SA receives (triple, sid, varid) from Ftriple, which is forwarded to A. Then, SA receives (accept, sid, ([a]l, [b]l, [c]l)) from Ftriple
4. SA generates a random commitment coml+1varid,2 and verifiable commitment wcoml+1varid,1, and;
[r]l−1,2 ∈R varid, [s]l−1,2 ∈R
varid, wopen1-1varid,1 ∈R {0,1}k×{0,1}k,
wcoml−1varid,1=Wcommit(([a]l,2, [b]l,2, [c]l,2), wopenl−1varid,1) openl−1varid,2 ∈R {0,1}k, coml−1varid,2=Commit(([r]l−1,2, [s]l−1,2), openl−1varid,2) (mult_msg2, sid, varid, [r]l−1,2, [s]l−1,2, wopenl−1varid,1, openl−1varid,2) to A. SA broadcasts (mult_brd2, sid, varid, wcoml−1varid,1, coml−1varid,2) as Pl−1 and (mult_brd2, sid, varid, wcoml+1varid,1, coml+1varid,2) as Pk+1. SA receives (mult_msg_2, sid, varid, [r]l,2, [s]l,2, wopenlvarid,1, openl+1varid,2) and
(mult_brd2, sid,varid,wcomlvarid,1, comlvarid,2) from A.
6. SA verifies if wopenlvarid,1 is a valid opening of wcomlvarid,1 with respect to ([a]l,1, [b]l,1, [c]l,1), and if it is not, SA broadcasts ⊥mult)1 as Pl+1. If any of the parties has broadcasted ⊥mult_1, SA proceeds to Step (12).
7. SA generates the following values in order to simulate Ql−1 and Q′l−1 that Pl−1 sends to Pl, when Pl+1 rejects Ql and Q′l, and when Pl−1 rejects Ql+1 and Q′l+1. Note that Pl+1 may accept even if Pl deviates the protocol and Pl−1 may reject Pl+1 although Pl+1 is honest. This is because Pl is controlling some of values they use.
p
l=(mult_iv1, sid, varid, seedl)−
(mult_iv1, sid, varid, seedl−1)
[
[
r
l−1
=[r]
l−1,2
+[
l,1
+[
l,2
, s
l−1
=[s]
l−1,2
+[
l,1
+[
l,2
Q
l−1=(mult_iv2, sid, varid, seedl−1, rl−1, sl−1)
openl−1varid,3 ∈R {0,1}k, coml−1varid,3=Commit(Ql−1, openl−1varid,3)
openl+1varid,3, openl+1varid,4=random commitments
r
l+1
=[r]
l−1,2
+[
l,1
+[r]
l,2
, s
l+1
=[s]
l−1,2
+[
l,1
+[s]
l,2
[o]l−1,2=([x]l,2+[
Q′
l−1=(mult_iv3, sid, varid, seedl−1, [o]l−1,2)
openl−1varid,4 ∈R {0,1{k, coml−1varid,4=Commit(Q′l−1, openl−1varid,4)−[o]l−1,1−[o]l−1,2=−[
[o]l+1,2=−[x]l,1+rl−1·sl−1·[1]l+1,2−sl−1·[a]l,1−rl−1·[b]l,1+[c]l,1
[o]l+1,1=([x]l−1+[
−[o]l+1,1−[o]l+1,2=−([x]l−1+[
−sl−1·[a]l,2−rl−1·[b]l,2+[c]l,2
8. SA broadcasts (mult_brd3, sid, varid, coml−1varid,3) as Pl−1 and (mult_brd3,
sid, varid, coml+1varid,3) as Pl+1. SA sends (mult_msg3, sid, varid , Ql−1,
openl−1varid,3) to A. SA receives (mult_msg3, sid, varid, Ql, openlvarid,3) and (mult_brd3, sid, varid, comlvarid,3) from A.
9. SA verifies if ⊥mult_2 should be broadcast:
If any of the parties has broadcasted ⊥mult_2, SA proceeds to Step (12).
10. SA broadcasts (mult_brd4, sid, varid, coml−1varid,4) as Pl−1 and (mult_brd4,
sid, varid, coml+1varid,4) as Pl+1. SA sends (mult_msg4, sid, varid, Q′l−1,
openl‘1varid,) to A. SA receives (mult_msg4, sid, varid, Q′l, openlvarid,4) and (mult_brd4, sid, varid, comlvarid,3) from A.
11. SA verifies if ⊥mult_3 should be broadcast:
If any of the parties has broadcasted ⊥mult_ 3, SA proceeds to Step (12).
12. If ⊥mult_1 is broadcast, SA sends (verify, sid, varid) as such Pj ∈ {Pl+1, Pl−1} that broadcasted ⊥mult 1. Then it receives (accept, sid, varid, comvarid,jtriple) and (accept, sid, varid, ([a]j, [b]j, [c]j), openvalidtriple,) for any party Pj that requires to do so.
13. SA simulates the prover and plays the verifier of zeroknowledge protocol in πidentify, and completes simulation by sending (abort, sid, Pl) to FGMPC.
Theorem 6. πGMPC, which is followed by πidentify when a party aborts, in Ftriple-hybrid model securely realizes FGMPC.
Proof The difference between simulated view and the real view is only in two sequences. In the view of real execution, some values are computed by pseudorandom function with the input of this seedl+1. In simulated view, these are random values. These are in the following.
Setup: The real protocol and simulated protocol differ in that coml+1seed in the real protocol is replaced by a commitment to a random string in the simulated protocol. Others are the same or simulated. Therefore, as long as commitment is hiding, they cannot be distinguished.
Random: The distributions of real protocol and simulated protocol differ in the sequence of {x}varid unless the protocol is aborted. Note that these values are implicitly parametrized by varid. They are;
In a real protocol, {(rand_iv, sid, varid, seedl+1)+
(rand_iv, sid, varid, seedl)+
(rand_iv, sid, varid, seedl−1)}varid.
In a simulated protocol, {x ∈varid}varid.
This difference comes from the fact that, while the real protocol πhd GMPC determines it by pseudorandom function with the input of seedl+1, FGMC generates if from randomly chosen x.
The only way for the adversary to abort the protocol is
wopenlvarid is not a valid opening of wcomlvarid with respect to [x]l,1 of varid.
The adversary broadcasts ⊥random.
In the first case, A simply fails in proof in the real protocol as there is no other [x]l,1 that A can prove for which wopenv arl is a valid opening of wcomlvarid. This simulation is straightforward. In the second case, A again simply fails in zeroknowledge proof in the real protocol as Pl−1's is honest and its output is totally independent to A. This simulation is direct. These cases are consistent to SA's sending (abort, sid, Pl) to FGMPC.
Therefore, the real protocol and simulated protocol differ only in that above sequences. As long as pseudorandom number functions are indistinguishable, they cannot be distinguished.
Input by uncorrupted party: As the simulator succeeds in extraction of the input value x, the distributions of real protocol and simulated protocol are the same as long as all the parties are honest.
The only way for the adversary to abort the protocol is
wopenlvarid is not a valid opening of wcomlvarid with respect to [x]l,1 of varid.
The adversary broadcasts ⊥input.
In the first case, A simply fails in proof as a commitment A himself generated as the dealer is share by ([x]l+1,2) and ([x]l,1). The binding property of comlvarid and wcomlvarid does not allow ([x]l+1,2) ≠ ([x]l,1). This simulation is straightforward. In the third case, A again simply fails in zeroknowledge proof in the real protocol as Pl−1's is honest and its output is totally independent to A. This simulation is direct. These cases are consistent to SA's sending (abort, sid, Pl) to FGMPC. Therefore, the real protocol and simulated protocol are indistinguishable.
Input by the corrupted party: As the Pl's shares of the any input is indistinguishable from those of a random secret, the distributions of real protocol and simulated protocol are the same as long as all the parties are honest. The only ways for the adversary to abort the protocol is
wopenlvarid is not a valid opening of wcomlvarid with respect to [x]l,1 of varid.
The adversary broadcasts ⊥input
In the first case, A simply fails in proof as the dealer committed to [x]l,1. This simulation is straightforward. In the second case, A again simply fails in zeroknowledge proof in the real protocol since wopenl−1varid is a valid opening of wcoml−1varid with respect to [x]l,2. This simulation is straightforward. These cases are consistent to SA's sending (abort, sid, Pl) to FGMPC. Therefore, the real protocol and simulated protocol are indistinguishable.
Output when the receiver is not the corrupted party: As A's behavior does not affect SA's simulation. SA stores (varid,[x]l, comlvarid, openlvarid) only when the previous protocol is completed successfully and openlvarid is a valid opening of comlvarid with respect to [x]l,1. Hence, that the SA has such data that guarantees what SA sends (accept, sid) to FGMPCis a perfect simulation. Therefore, the real protocol and simulated protocol are indistinguishable.
Output when the receiver is the corrupted party: Once the share of A and the secret is fixed, the rest of shares are determined. As these shares are generated perfectly by SA, the real protocol and the simulated protocol are indistinguishable.
Addition with Constant, Multiplication with Constant, and Addition: As long as A behaves honestly, the distribution of the real protocol and the simulated protocol are the same. The only ways for the adversary to abort the protocol is
wopenlvarid is not a valid opening of wcomlvarid with respect to [x]l,1 of varid.
The adversary broadcasts ⊥addc/multc/add.
In the first case, A simply fails in proof as this value is simulated perfectly. This simulation is straightforward. In the second case, A again simply fails in zeroknowledge proof in the real protocol as wopenl−1varid is a valid opening of wcoml−1varid with respect to [x]l,2. This simulation is direct. These cases are consistent to SA's sending (abort, sid, Pl) to FGMPC. Therefore, the distribution of the real protocol and simulated protocol are the same.
Multiplication: The distributions of the real protocol and the simulated protocol differ in the sequence of {[x]l−1,1 , [c]l−1,1, [r]l−1,2, [s]l−1,2)varid. They are, in the real protocol,
{[x]l,2·[x″]l,2+[x′[l,2·[x″]l−1,2+[x′]l−1,2 ·[x″l,2 +(mult_iv1, sid, varid, seedl−1)−
(mult_iv1, sid, varid, seedl+1),
[a]l,2·[b]l,2+[a]l,2·[b]l−1,2+[a]l−1,2·[b]l,2 +(triple_ivc, i, seedl−1)−
(triple_ivc, i, seedl+1)
[x′]ll−1,2+(triple_iva, i , seedl+1), [x″]l−1,2+
(triple_ivb, i, seedl+1)}varid
where as they are random numbers in the simulated protocol. All the values in the real protocol includes pseudorandom number generated from seedl+1.
The only ways for the adversary to abort the protocol is,
Maneuver Pl+1 to send Ql+1 that is not (mult_iv2, sid, varid, seedl+1, rl−1, sl−1) to Pl−1. This can be done by adjusting the value of ([r]l,2, [s]l,2 ) that A sends to Pl+1.
Send Ql that is not (mult_iv2, sid, varid, seedl, rl +1, sl+1) to Pl+1.
Maneuver Pl−1 to send Ql−1 that is not (mult_iv2, sid, varid, seedl−1, rl−1, sl−1) to Pl.
Maneuver Pl+1 to send Q′l+1 that is not (mult_iv3, sid, varid, seedl+1, [o]l−1,1−[o]l−1,2) to PL−1. This can be done by adjusting the value of [xvarid]l,1 that A sends to Pl+1.
Send Q′l that is not (mult_iv3, sid, varid, seedl, [o]l+1,1−[o]l +1,2) to Pl+1.
Maneuver Pl−1 to send Q′l−1 that is not (mult_iv3, sid, varid, seedl−1, −[o]l,1−[o]l,2) to Pl−1. As A is not able to control any of the value used in this verification, A cannot abort the protocol by this maneuver.
The adversary broadcasts ⊥mult_1/mult_2.
In the first case, since SA is able to simulate rl−1 and sl−1 accurately, SA as Pl−1 broadcasts ⊥mult_2 exactly when it should as in the real protocol. In other words, Ql+1 is maneuvered by A through ([r]l,2, [s]l,2), but this is accurately simulated by SA. This case occurs only when Pl deviates from the protocol and Pl+1 is able to prove its cheating in the real protocol. This is consistent to SA's sending (abort, sid, Pl) to FGMPC. All the simulation of proofs between players are straightforward.
In the second case, since SA is able to simulate rl+1 and sl+1 accurately, SA as Pl+1 broadcasts ™mult 2 exactly when it should as in the real protocol. As rl+1 and sl+1 are maneuvered by ([r]l,2, [s]l,2), Pl+1 is not always expected to detect the cheating by the verification of the equation. However, this cheating is always detected by Pl−1, and then Pl+1 is able to identify Pl as the cheater as Pl should fail to prove that it did send the correct ([r]l,2, [s]l,2). This is consistent to SA's sending (abort, sid, Pl) to FGMPC. All the simulation of proofs between players are straightforward.
In the third case, (rl−1, sl−1)=(rl, sl) if Pl generates the latter pair honestly, SA is able to simulate exactly the Ql−1 that Pl−1 should generate in the real protocol. Hence, in case Pl outputs ⊥mult_2, Pl+1 is able to identify Pl as the cheater as Pl should fail to prove that its decision against Pl−1 was correct. This is consistent to SA's sending (abort, sid, Pl) to FGMPC.
If no one has broadcasted ⊥mult_2, that all the parties agreed that r1=r2=r3 and s1=s2=s3. This is assumed in the below.
In the fourth case, A is able to maneuver Pl+1 's computation of Q′l+1 but is not able to maneuver Pl−10's verification. This is precisely simulated by SA as SA is able to simulate maneuvered Q′l+1. Pl+1 broadcasts ⊥mult_3 as Pl−1 exactly when it should as in the real protocol. The simulator precisely does the simulation of this phenomenon. In case ⊥mult_3 is broadcasted, Pl+1 is able to prove that Pl's cheating in the real protocol. Hence, this is consistent to SA's sending (abort, sid, Pl) to FGMPC. All the simulation of proofs between players are straightforward.
In the fifth case, since SA is able to simulate maneuvered −8 o]l+1,1−[o]l+1,2 accurately, SA as Pl+1 broadcasts ⊥mult_3 exactly when it should as in the real protocol. As −[o]l+1,1−[o]l+1,2 is maneuvered by [x]l,1, Pl+1 is not always expected to detect the cheating by the verification of the equation. However, this cheating is detected when Pl is required to prove to all the parties that Pl generated [x]l+1,2 correctly. Hence, as long as cheating is detected, the cheater is correctly identified. This is consistent to SA's sending (abort, sid, Pl) to FGMPC. All the simulation of proofs between players are straightforward.
Theorem 7. {tilde over (π)}gmpc in Ftriple -hybrid model realizes FGMPC.
Proof The simulation of the protocol for the entire circuit is simply running the simulator for all gates with few exceptions.
Setup: As the setup is independent to other operations, the simulation is the same.
Random: The simulation of random ring element generation does not directly depend on the result of other operations (outputs of other gates). It only depends on how A behaves and dependency to other result is only via A. Hence, the simulation is the same.
Input: The simulation of input operation does not directly depend on the result of other operations (outputs of other gates). It only depends on how A behaves and dependency to other result is only via A. Hence, the simulation is the same.
Output: The output operation is only after every verification is completed. Hence, the simulation is the same.
Addition and Multiplication with Constant, Addition, Multiplication: The input to the simulator is (varid,[x′]l, comlvarid′, openlvarid′) and
(varid, [x″]l, comlvarid″, openlvarid″. The latter is only for addition and multiplication. Since the simulator does not use comlvarid′, open lvarid′, comlvarid″, and openl varid″, unless it simulates πidentify, and since the protocol does not run πidentify until every other related verification is completed without abort, simulation with respect to these commitments and openings are by the same algorithm. More concretely, the simulator does not need to simulate related values when until it comes to the point that simulates πidentify and when it comes to that point, it has them as every related simulation is completed.
Now the issue is how to prepare right [x′[l and [x″]l for the simulator. We explain only for the [x″]l because the logic is the same for [x″]l.
In case x′ is the output of addition of y and z. The simulator generates [x′]l=[y]l+[z]l where [y]l and [z]l are what the simulator prepared before.
In case x′ is the output of addition of y and v. The simulator generates [x′]l=[y]l+[v]l where [y]l is what the simulator prepared before and the constant v is known.
In case x′ is the output of multiplication of y and v. The simulator generates [x′]l=[y]l·v where [y]l is what the simulator prepared before and the constant v is known.
In case x′ is the multiplication of addition of y and v. The simulator generates [x]l,1 from the data A sends to Pl. The simulator generates [x′]l,2 by the same method that original simulator generates [x]l−1,1 (randomly) and sends to A.
The original simulator depends on the assumptions that [x′]l+1,1=[x″]l−1,2 holds, [x′]l+1,2 is [x″]l,1 and [x′]l−1,1 is [x″]l,2 for its validity of simulation. These assumptions always hold in semihonest secure protocol because either they are the pair of sum of pairs of equal values (when acid/addc), they are the pair of equal values multiplied by the same number (when multc), or Pl+1 sends this very value to Pl−1 (when mult). Therefore, even the multiplication is maneuvered maliciously; the simulator simulates the execution that is computationally indistinguishable to the real one.
It is expected that during the life of a patent maturing from this application many relevant systems, methods and computer programs will be developed and the scope of the terms MPC detection procedure, algorithms and/or technique are intended to include all such new technologies a priori.
As used herein the term “about” refers to ±10%.
The terms “comprises”, “comprising”, “includes”, “including”, “having” and their conjugates mean “including but not limited to”.
The term “consisting of means “including and limited to”.
As used herein, the singular form “a”, “an” and “the” include plural references unless the context clearly dictates otherwise. For example, the term “a compound” or “at least one compound” may include a plurality of compounds, including mixtures thereof.
Throughout this application, various embodiments of this invention may be presented in a range format. It should be understood that the description in range format is merely for convenience and brevity and should not be construed as an inflexible limitation on the scope of the invention. Accordingly, the description of a range should be considered to have specifically disclosed all the possible subranges as well as individual numerical values within that range. For example, description of a range such as from 1 to 6 should be considered to have specifically disclosed subranges such as from 1 to 3, from 1 to 4, from 1 to 5, from 2 to 4, from 2 to 6, from 3 to 6 etc., as well as individual numbers within that range, for example, 1, 2, 3, 4, 5, and 6. This applies regardless of the breadth of the range.
Whenever a numerical range is indicated herein, it is meant to include any cited numeral (fractional or integral) within the indicated range. The phrases “ranging/ranges between” a first indicate number and a second indicate number and “ranging/ranges from” a first indicate number “to” a second indicate number are used herein interchangeably and are meant to include the first and second indicated numbers and all the fractional and integral numerals therebetween.
It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the invention. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.
