Patent Publication Number: US-11050762-B2

Title: High throughput secure multi-party computation with identifiable abort

Description:
REFERENCED DOCUMENTS 
     “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, Apr. 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. 
     FIELD AND BACKGROUND OF THE INVENTION 
     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. 
     SUMMARY OF THE INVENTION 
     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:
         Code instructions to participate in an MPC with the plurality of computing nodes using one or more secure protocols established over the one or more networks. The secure protocol(s) supporting transmittal of private messages to each of the plurality of computing nodes and transmittal of broadcast messages to all the plurality of computing nodes.   Code instructions to detect one or more invalid share values of a plurality of share values computed and committed by the plurality of computing nodes during the MPC.   Code instructions to verify each of the plurality of share values according to a plurality of agreed share values determined through a plurality of broadcast messages and private messages. The plurality of agreed share values is valid for the MPC.   Code instructions to identify an identity one or more malicious computing nodes of the computing nodes which committed the one or more invalid share values failing the verification.   Code instructions to output the identity.       

     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:
         Participating in an MPC with the plurality of computing nodes using one or more secure protocol established over the one or more networks. The secure protocol(s) supporting transmittal of private messages to each of the plurality of computing nodes and transmittal of broadcast messages to all the plurality of computing nodes.   Detecting one or more invalid share values of a plurality of share values computed and committed by the plurality of computing nodes during the MPC.   Verifying each of the plurality of share values according to a plurality of agreed share values determined through a plurality of the broadcast messages and the private messages. The plurality of agreed share values is valid for the MPC.   Identifying an identity one or more malicious computing nodes of the computing nodes which committed the one or more invalid share values failing the verification.   Outputting the identity.       

     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. 
    
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S) 
       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: 
         FIG. 1  is a flowchart of an exemplary process of identifying malicious party(s) participating in a secure MPC, according to some embodiments of the present invention; and 
         FIG. 2  is a schematic illustration of an exemplary system for identifying malicious party(s) participating in a secure MPC, according to some embodiments of the present invention. 
     
    
    
     DESCRIPTION OF SPECIFIC EMBODIMENTS OF THE INVENTION 
     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&#39;s computer, partly on the user&#39;s computer, as a stand-alone software package, partly on the user&#39;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&#39;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,  FIG. 1  illustrates a flowchart of an exemplary process of identifying malicious computing node(s) participating in a secure MPC, according to some embodiments of the present invention. An exemplary process  100  may be executed by each of a plurality of computing nodes (parties), for example, a computer, a server, a cluster of computing nodes and/or any computing device having one or more processors participating in a secure MPC for jointly computing a function over their respective private input data. The computing nodes may exchange data between one another using a secure MPC protocol with identifiable abort to identify the identity one or more malicious computing nodes (also referred as malicious, dishonest, cheating and/or corrupted parties) which may participate in the secure MPC. 
     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  FIG. 2 , which is a schematic illustration of an exemplary system for identifying malicious computing node(s) participating in a secure 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:
         Data privacy, meaning that none of the MPC agents  210  may infer any information about the input data held by the other MPC agents  210  from the messages exchanged during the execution of the secure MPC protocol(s).   Correctness, meaning that the secure MPC protocol prevents the malicious party(s) from forcing any of the honest parties to output incorrect data.   Independence of inputs, meaning that none of the MPC agents  210  may depend its input data on input data of other MPC agents  210 .   Fairness, meaning that the output of each of the MPC agents  210  is outputted only if the   Guaranteed output delivery meaning that the result of the jointly computed function is outputted only if all the MPC agents  210  are guaranteed to receive this result.       

     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 ϕ. 
     Definition 1 (Secure Computation): 
     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: 
     Functionality 1 (F GMPC —Reactive Functionality) 
     The ideal functionality F GMPC  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. F GMPC  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 F GMPC  does not store (varid, x) for some x. sid is a session identifier, which is unique to each unit operation. F GMPC , once invoked, accepts the following setup once and only once. After this setup, F GMPC  receives requests for various type of operations listed below. 
     On receiving (setup, sid, κ) from all the parties, F GMPC  sends (setup, sid, κ) to S. If F GMPC  receives (accept,sid) from s, it delivers (accept,sid) to all the parties. However, if F GMPC  receives (abort, sid, P l  ∈ I) from s, it delivers (abort, sid, P l ) to all the parties and aborts the functionality itself. 
     On receiving (random, sid, varid) from all the parties, where varid is a new index, F GMPC  sends (random, sid, varid) to S. If F GMPC  receives (accept, sid) from S, F GMPC  randomly generates x ∈  , stores (varid, x), and delivers (accept, sid) to all the parties. However, if F GMPC  receives (abort, sid, P l  Å I) from s, it delivers (abort, sid, P l ) to all the parties. 
     On receiving (input, sid, varid, P k , x) from P k  and (input, sid, varid, P k ) from all the other parties, where varid is new and x ∈  , F GMPC  sends (input, sid, varid, P k ) to S. If F GMPC  receives (accept, sid) from S, F GMPC  stores (varid, x) and delivers (accept, sid) to all the parties. However, if F GMPC  receives (abort, sid, P l  ∈ I) from s, it delivers (abort, sid, P l ) to all the parties. 
     On receiving (output, sid, varid, P j ) from all the uncorrupted parties where F GMPC  has a record (varid, x), F GMPC  sends (output, sid, varid, p j ) to S. F GMPC  delivers (value, sid, varid, x) to P j . a    a F   GMPC  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 F GMPC  has a record (varid′, x′), varid is a new index, and v ∈  , F GMPC  sends (addc/multc, sid, varid, varid′, v) to S. If F GMPC  receives (accept, sid) from S, F GMPC  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 F GMPC  receives (abort, sid, P l  ∈ I) from S, it delivers (abort, sid, P l ) to all the parties. 
     On receiving (add/malt, sid, varid, varid′, varid″) from all the parties, where F GMPC  has records (varid′, x′) and (varid″, x″), varid is a new index, F GMPC  sends (add/mult, sid, varid, varid′, varid″) to S. If F GMPC  receives (accept, sid) from S, F GMPC  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 F GMPC  receives (abort, sid, P l  ∈ I) from S, it delivers (abort, sid, P l ) 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, P i  ∈  ) 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 P 1 , P 2  and P 3  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, P i+1  is P 1  when i=3 and P i−1  is P 3  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. 
     Definition 2: 
     For any finite ring   and any element v ∈   shares of v of P j  for j ∈ {1, 2, 3} in the replicated secret sharing as known in the art is (v j , v j−1 ) for randomly chosen v 1 , v 2 , v 3  ∈   under the constraint v 1 +v 2 +v 3 =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 ):=( v   j   ,v   j−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′). 
     Definition 3: 
     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 ]:=(( v   1   ,v   3 ),( v   2   ,V   1 ),( v   3   ,v   2 )), [ 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:
         Semi-honest secure addition. As in the Boolean case, addition gates are computed by locally adding the share values in the ring  . More concretely, for each i ∈ {1, 2, 3}, P i  computes its share value as [v+v′]=([v] i,1 , [v] i,2 ). That is [v+v′]=((v 1 +v′ 1 , v 3 +v′ 3 ), (v 2 +V′ 2 , v′ 1 ), (v 3 +v′ 3 , v 2 +v′ 2 )).   Semi-honest secure multiplication. Let P 4  and P 0  denote, respectively, P 1  and P 3 . Assuming that for i=1, 2, 3, a party P i  holds ρ i  ∈   such that Σ i=1   3  ρ i =0 ∈  . It is noted that the parties P i  may generate such correlated randomness ρ 1 , ρ 2 , ρ 3  ∈   as much as needed from fixed length correlated randomness. Let v·v′ denote the multiplication of v and v′ in the ring  .       

     In order to compute a 
               (         2           3         )     ⁢     -     ⁢   sharing         
of the product or two values v and v′, that is [v·v′], the parties P i  may operate as follows:
         (1) For i ∈ {1, 2, 3}, P i  computes its share value of w i =v i ·v′ i +v i ·v′ i−1 +v i−1 ·v′ i +p i  and sends w i  to P i+1 . Here, v 4 :=v 1  and v′ 4 :=v′ 1 .   (2) For i ∈ {1, 2, 3}, P i  defines its share value of w=v·v′, that is [w] i  is defined as (w i , w i−1 ). Here w 0 =w 3 .       

     The MPC agents  210  using the secure MPC protocol with identifiable abort may further compute multiplication triples to verify the committed share values. 
     Definition 4: 
     A multiplication triple in the ring   is a tuple of share values ([a], [b], [c]) among the MPC agents  210  P 1 , P 2  and P 3  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: 
     Functionality 2 (F triple  Multiplication Triple Generation) 
     The ideal functionality F triple  is invoked with a set of corrupted parties I. We say varid is a new index to F triple  when F GMPC  does not store (varid, [a], [b], [c]). F triple , once invoked, accepts the following setup once and only once. After this setup, F triple  receives requests of (triple, sid, varid). 
     On receiving (setup, sid, κ) from all the parties, F triple  sends (setup, sid, κ) to S. If F triple  receives (accept, sid) from S, it delivers (accept, sid) to all the parties. However, if F triple  receives (abort, sid, P l  ∈ I), it delivers (abort, sid, P l ) 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 F triple , F triple  sends (triple,sid,varid) to S. If F triple  receives (accept, sid, (([a′] k , [b′] k , [c′] k ) k∈I ) from S, F triple  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 P j . 
     On receiving (verify,sid,varid) from P j , where F triple  stores (varid, [a],[b],[c]), F triple  generates open varid,j   triple  ∈ {0,1} k  and com varid, j   triple =Commit(([a] j,2 [b] j,2 , [c] j,2 , open varid,j   triple ), and sends (verify, sid,varid, P j ) to S. Then F triple  sends (accept, sid, varid, P j , com varid,j   triple ) to all parties, and sends (accept, sid, varid, P j , ([a] j,2 ), [b] j,2 , [c] j,2 ),open varid,j   triple ) to P j . 
     Protocol 8: 
     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 P j  for j ∈ {1,2,3} receives (setup, sid, κ, seed j , seed j−1 ), all the parties do as in the following;
         1. For each j ∈ {1,2,3} and for i=1, . . . , Nm+C, P j  generates [a′ i ] j =( (triple_iva, i, seed j ),  (triple_iva, i, seed j−1 )) [b′ i ] j    (triple_ivb, i, seed j ),  (triple_ivb, i, seed j−1 )) [c′ i ] j,1 =[a] j,1 ·[b] j,1 +[a] j,1 ·[b] j,2 +[a] j,1 ·[b] j,2 + (triple_ivc, i, seed j )− (triple_ivc, i, seed j−1 )       

     2. For each j ∈ {1,2,3}, p j  generates wopen j  ∈×{0,1} k , ([c′ i ] j=1, . . . , Nm+C , and wcom j =wcommit(([c′ i ] j,1, . . . , Nm+C , wopen j ) and broadcasts wcom j , and P j  also sends ([c′ i ] j,1 ) j=1, . . . m Nm+C , and wopen j  to p j+1 . For each j ∈ {1,2,3} and for i=1, . . . , Nm+C, P j  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 a i ·b i =c i . If the equation does not hold for any pair of parties, every party P i  proves in zeroknowledge that it has obeyed the protocol with seed j . All the parties output (abort, sid, P j ) for such P j  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 P j  proves in zeroknowledge that it has obeyed the protocol with seed j . All the parties output (abort, sid, P j ) for such P j  that did not obey the protocol. Let ([a k ], [b k ], [c k ]) k=1, . . . , N  be this N triples made of first triples in buckets. 
     5. For each j ∈ {1,2,3}, P j  generates wopen′ j  ∈ {0,1} k ×{0,1} k  and wcom′ j   triple =wcommit(([a k ] j,1 , [b k ] j,1 , [c k ] j,1 ) k=1, . . . , N , wopen′ j ), broadcasts wcom′ j   triple , and send wopen′ j  and ([a k ] j,1 , [b k ] j,1 , [c k ] j,1 ) k=1, . . . , N  to P j+1 . Then, for each j ∈ {1,2,3}, P j  verifies if wopen′ j−1  is a valid opening of wcom′ k−1   triple  with respect to ([a k ] j,2 ,[b k ] j,2 , [c k ] j,2 ) k=1, . . . , N . If it is not, P j  and P j−1  prove in zeroknowledge that they have obeyed the protocol with wopen j−1 ,wopen′ j−1 , and seed j−1 . Here, all the parties have wcom′ j−1   triple , wopen′ j−1 , com j−1 , and wopen j−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, P l ) for such P l  that did not obey the protocol. 
     When all the parties receives (triple, sid, valid), they randomly chooses k ∈ {1, . . . , N} and P j  outputs (accept, sid, valid, ([a k ] j ,[b k ] j , [c k ] j )). This triple is removed from the sequence and this k will never be chosen. 
     On receiving (verify, sid, varid), P 1  sends (verify, sid, varid, P j ) to all other parties. P 1  outputs (accept, sid, varid, P j , com varid,j   triple =com′ varid,j   triple ) and (accept, sid, varid, open′ varid,j   triple ). The other parties outputs (accept, sid, varid, P j , com′ varid,j   triple ). Note that com′ j   triple =Commit(([a k ] j,2 ,[b k ] j,2 , [c k ] j,2 ) k=1, . . . , N , open′ varid,j   triple ) within wcom′ varid,j   triple  that P j−1  has broadcasted once is also a commitment to ([a k ] j,2 , [b k ] j,2 , [c k ] j,2 ) for any k. And open′ varid,j   triple  an opening of com j   triple . 
     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  P 1 , P 2  and P 3 . 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  P 1 , P 2  and P 3  share an element x=x 1 +x 2 +x 3  in   as (x 1 , x 3 ) for the party P 1 , (x 2 , x 1 ) for the party P 2  and (x 3 , x 2 ) for the party P 3 . Assuming the party P 1  maliciously modified its share value to (x 1 , x′ 3 ) for x′ 3 ≠x 3 . Using the secure MPC protocols with abort as known in the art, even if all the parties P 1 , P 2  and P 3  share their share values with each other, the party P 2  may be unable to identify the malicious party since the party P 2  may be unable decide whether the party P 1  modified x 3  into x′ 3  or whether the party P 3  modified x′ 3  into x 3 . 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=x 1 +x 2 +x 3  in   for each party P i  may be expressed as (x j , x j−1 , com. open) where open and com=Commit(x j−1 , open) are generated by the party P j−1  and com is broadcasted by the party P j−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 P 1 , P 2  and P 3  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 P 1 , P 2  and P 3  to transmit one or more messages to all other parties while the private channels allow each of the parties P 1 , P 2  and P 3  to transmit one or more messages to a certain one of the other parties. Each of the broadcast messages exchanged between the parties P 1 , P 2  and P 3  is encoded for authentication of the originating party that sent the message. Each of the private messages exchanged between the parties P 1 , P 2  and P 3  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 P 1 , P 2  and P 3  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 P j  is storing varid, [x] j , com varid , open j−1   varid ) where {right arrow over (com)} varid  is a set of (com j   varid ) j∈{1,2,3}  such that com j   varid  is a commitment to a share value [x] j,1  that the honest party P j  broadcasted as (com j   varid , com′ j   varid ):=wcom j   varid , and open j−1   varid  is the opening of com j   varid . 
     For wcom lowerscript   upperscript , it is assumed that the components of wcom lowerscript   upperscript  are (com lowerscript   upperscript , com′ lowersecript   uppersecript =wcom lowerscript   upperscript  and (open lowerscript   lowerscript , open′ lowerscript   upperscript =wopen lowerscript   upperscript . 
     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: 
     Protocol 3 (Security with Identifiable Abort π GMPC ) 
     Setup: When all the parties received (setup, sid, κ), parties do as the following.
         1. For each j ∈ {1,2,3}, P j  randomly generates seed j  ∈ {0,1} k  and open j   seed  ∈ {0,1} k , generates com j   seed =Commit(seed j , open m   seed ), sends open j   seed  and seed j  to P j+1  and broadcasts com j   seed .   2. For each j ∈ {1,2,3}, P j  sends (setup, sid, κ) to F triple . If a party receives (abort, sid, P k ) from F triple , the party outputs (abort, sid, P k ) and abort the protocol. If a party receives (accept, sid) from F triple , the party proceeds to the next step.   3. If all the above processes are successful, all parties output (accept, sid). Otherwise, they output (abort, sid, P k ) for P k  who deviated the protocol.       

     Random: When all the parties received (random, sid, varid) for new varid, the parties do as the following for each j ∈ {1,2,3}:
         1. P j  generates
 
[ x ] j =( (rand_iv, sid,varid ,seed j ), (rand_iv, sid,varid ,seed j−1 ))wopen j   varid ∈ R {0,1} k ×{0,1} k   ,w com j   varid   =W commit([ x ] j,1   ,w open j   varid )
   2. P j  broadcasts (random_brd, sid, varid, wcom j   varid ) and sends (random_msg, sid, varid, wopen j   varid ) to P j+1 .   3. P j  verifies if wopen j−1   varid  is a valid opening of wcom j−1   varid  with respect to ([x] j,2 ) and, if it is not valid, broadcasts⊥ random . If any party broadcasted ⊥ random,  all the parties proceed to π identify.      4. P j  stores (varid, [x] j , , open j−1   varid ) and outputs (accept, sid).       

     Input: When P k  received (input, sid, varid, P k , x) and all other parties received (input, sid, varid, P k ) for new varid, all the parties do as in the following.
         1. P k  randomly generates {x 1 , x 2 , x 3 }∈ R     such that x 1 +x 2 +x 3 =x. Then, for j ∈ {1,2,3}, P k  generates
 
[ x ] j =( x   j   ,x   j−1 ),open k   varid,j ∈ R {0,1} k ,com k   varid,j =Commit( x   j ,open k   varid,j )
   2. P k  broadcasts (input_brd1, sid, P k , varid, com k   varid,1 , com k   varid,2 , com k   varid,3 ). Then, P k  sends (input_msg1, sid, P k , varid, [ x ] j , open k   varid,j , open k   varid,j− ) to P j  for j ∈ {1,2,3}.   3. For each j ∈ {1,2,3}, P j  generates
 
 w open j   varid ∈{0,1} k ×{0,1} k   ,w com j   varid   =W commit([ x ] j,1   ,w open j   varid )
   4. For each j ∈ {1,2,3}, P j  sends (input_msg2 j , sid, varid, wopen j   varid ) to P j+1 , and broadcasts (input_brd2, sid, varid, wcom j   varid ).   5. For each j ∈ {1,2,3}, P j  verifies if wopen j−1   varid  is a valid opening of wcom j−1   varid  with respect to ([x] j,2 ) and, if it is not valid, P j  broadcasts ⊥ input . If any party broadcasted ⊥ input , all the parties proceed to π identify .   6. For each j=1,2,3, P j  stores (varid,[x] j ,  , open j−1   varid ) and outputs (accept, sid).       

     Output: When all the parties received (output, sid, varid, P k ) for k ∈ {1,2,3} where each honest party P j  for j ∈ {1,2,3} stores (varid, [x] j ,  , open j−1   varid ), the parties do as the following.
         1. For each j ∈ {1,2,3}, P j  sends to P k  the message (output_msg, sid, varid, [x] j , open j−1   varid ). Then, from all P j  for j ∈ {1,2,3}, P k  receives (output_msg, sid, varid,[x] j , open j−1   varid ).   2. P k  verifies if it hold that [x] 1,1 =[x] 2,2 , [x] 2,1 =[x] 3,2 , [x] 3,1 =[x] 1,2 .
           If it does, P k  generates x=[x] 1,1 +[x] 1,2 +[x] 3,2      If it does not, P k  identifies j ∈ {1,2,3} such that com j−1   varid  is not a valid commitment to (varid, [x] j,2 ) by using open j−1   varid . Then, P k  generates x=[x] j−1,1 +[x] j−1,2 +[x] j+1,2      
           3. P k  outputs (value, sid, varid, x).       

     Multiply: When all the parties received (mult, sid, varid, varid′, varid″) where varid is new, each uncorrupted party P j  stores (varid′, [x′] j , , open j−1   varid ′) and (varid″, [x″] j ,  , the parties do as in the following;
         1. For each j ∈ {1,2,3}, P j  generates
 
ρ j = (mult_iv 1 , sid,vari ,seed j )− (mult,iv 1 , sid,varid ,seed j−1 )[ x ] j,1 =[ x ′] j,1 ·[ x ″] j,1 +[ x ′] j,1 ·[ x ″] j,2 +[ x ′], j,2 ·[ x ″] j,1 +ρ j  open j   varid ∈ R {0,1} k com varid =Committ([ x ] j,1 ,open j   varid )
   2. For each j ∈ {1,2,3}, P j  sends (mult_msg1 j , sid, varid, [x] j,1 , open j   varid ) and broadcasts (mult_brd1, sid, varid, com j   varid ).   3. For each j ∈ {1,2,3}, P j  sends (triple, sid, varid) to F triple  and obtains (accept, sid, [a] j , [b] j , [c] j ).   4. For each j ∈ {1,2,3}, P j  generates
 
[ x ] j =([ x ] j,1 ,[ x ] j−1,1 ),[ r ] j =[ x ′] j +[ a ] j ,[ s ] j =[ x ″] j +[ b ] j   w open j   varid,1 ∈ R {0,1} k ×{0,1} k ,open j   varid,2 ∈ R {0,1} k   w com j   varid,1   =W commit(([ a ] j,1 ,[ b ] j,1 ,[ c ] j,1 ), w open j   varid,1 )com j   varid,2 =Commit([ r ] j,2 ,[ s ] j,2 ,open j   varid,2 )
   5. For each j ∈ {1,2,3}, P j  sends (mult_msg2,sid, varid, [r] j,2 , [s] j,2 , wopen j   varid,1 , open j   varid,2 ) to P j+1  and broadcasts (mult_brd2, sid, varid, wcom varid,1 , com varid,2 ).   6. For each j ∈ {1,2,3}, p j  verifies if w open j−1   varid,1  is a valid opening of wcom j−1   varid,1  with respect to ([a] j,2 , [b] j,2 , [c] j,2 ) and, if it is not, p j  broadcasts ⊥ mult,1 . If any party broadcasted ⊥ mult_1 , all proceed to π identify .   7. For each j ∈ {1,2,3}, P j  generates
 
 r   j =[ r ] j,1 +[ r ] j,2 +[ r ] j−1,2   ,s   j =[ s ] j,1 +[ s ] j,2 +[ s ] j−1,2  
 
[ o ] j =−[ x ] j   +r   j   ·s   j ·[1] j   −s   j ·[ a ] j   −r   j ·[ b ] j +[ c ] j  
 
 Q   j = (mult_ iv 2, sid,varid ,seed j   ,r   j   ,s   j )
 
 Q′   j = (mult_ iv 3, sid,varid ,seed j ,[ o ] j,2 )(open j   varid,3 ,open j   varid,4 )∈ R {0,1} k ×{0,1} k  
 
(com j   varid,3 )=Commit( Q   j ,open j   varid,3 ),(com j   varid,4 )=Commit( Q′   j ,open j   varid,4 )
   8. For each j ∈ {1,2,3}, P j  sends (mult_msg3, sid, varid, Q j , open j   varid,3 ) to P j+1 , and broadcasts (mult_brd3, sid, varid, com j   varid,3 ).   9. For each j=1,2,3, P j  verifies if the following equation holds and, if it is not, P j  broadcasts ⊥ mult_2  
 
 Q   j−1 = (mult_ iv 2, sid,varid ,seed j−1   ,r   j   ,s   j )
 
If any party broadcasted ⊥ mult_2 , all the parties proceed to π identify .
   10. For each j ∈ {1,2,3}, P j  sends (mult_msg4, sid, varid, Q′ j , open j   varid,4 ) to P j+1 , and broadcasts (mult_brd4, sid, varid, Q′ j , com j   varid,4 ).   11. For each j=1,2,3, P j  verifies if the following equation holds and, if it is not, P j  broadcasts ⊥ mult_3 .
 
 Q′   j−1 = (mult_ iv 3, sid,varid ,seed j−1 ,−[ o ] j,1 −[0] j,2 )
 
If any party broadcasted ⊥ mult_3 , all the parties proceed to π identify  
   12. For each j=1,2,3, p j  stores (varid, [x] j ,  , open j−1   varid ) and outputs (accept, sid).       

     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 P j  stores (varid′, [x′] j ,  , open j−1   varid′ ) (and (varid″, [x″] j , , open j−1   varid ″) if add), the all parties do as in the following; 
     1. For each j ∈ {1,2,3}, generates 
                 [   x   ]     j     =     {           (           [   x   ]       j   ,   1       +     v   ·       [   1   ]       j   ,   1           ,         [   x   ]       j   ,   2       +     v   ·       [   1   ]       j   ,   2             )           if   ⁢           ⁢   addc               (           [     x   ′     ]       j   ,   1       ·   v     ,         [     x   ′     ]       j   ,   2       ·   v       )           if   ⁢           ⁢   multc               (           [     x   ′     ]       j   ,   1       +       [     x   ″     ]       j   ,   1         ,         [     x   ′     ]       j   ,   2       +       [     x   ″     ]       j   ,   2           )           if   ⁢           ⁢   add                     w open j   varid ∈{0,1} k ×{0,1} k   ,w com j   varid   =W commit([ x ] j,1   ,w open j   varid )
 
     2. For each j ∈ {1,2,3}, P j  sends (addc_msg/multc_msg/add_msg, sid, varid, open j   varid ) to P j+1 , and broadcasts (addc_brd/multc_brd/add_brd, sid, varid, com j   varid ). 
     3. For each j ∈ {1,2,3}, P j  verifies if wopen j−1   varid  is a valid opening of the wcom j−1   varid  with respect to ([x] j,2 ) and, if it is not valid, P j  broadcasts ⊥ addc/multc/add . If any party broadcasted ⊥ addc/multc/add,  all the parties proceed to π identify    
     4. For each j=1,2,3, P j  stores (varid, [x] j ,  , open j−1   varid ) 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: 
     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}, P j  does as in the following:
         If P j  output ⊥, P j  outputs (abort, sid, P j−1 ).   If P j  did not output ⊥, but P j+1  sid, P j , outputs (abort, sid, p j+1 ).   If neither P j  nor p j+1  output ⊥.   1. If ⊥ random , P j−1  proves to P j  in zeroknowledge the knowledge of (wopen j+1   varid , [ x ] j−1,2 , seed j+1 , open j+1   seed ) such that:
 
[ x ] j−1,2 = (rand_ iv,sid,varid ,seed j+1 )
 
accept≠Verify(com k+1   varid ,[ x ] j−1,2 ,open j+1   varid )
 
accept=Verify(com′ j+1   varid ,open j+1   varid ,open′ j+1   varid )
 
accept=Verify(com j+1   seed ,seed j+1 ,open j+1   seed)  
 
where com j+1   seed , wcom j+1   varid , varid, and sid are owned by both parties.
   2. If ⊥ input , P j−1  proves to P j  in zeroknowledge the knowledge of ([ x ] j−1,2 , open k   varid,j+ 1, open j+1   varid , open′ j+1   varid ) such that:
 
accept=Verify(com k   varid,j+1 ,[ x ] j−1,2 ,open k   varid,j+1 )
 
accept≠Verify(com k+1   varid ,[ x ] j,2 ,open j+1   varid )
 
accept=Verify(com′ j+1   varid ,open k+1   varid ,open′ j+1   varid )
 
where (com k   varid,j+1 , wcom k+1   varid , sid, and varid are owned by both parties.
   3, If ⊥ add/addc/multc , P k−1  proves to P j  in zeroknowledge the knowledge of [ x ] j−1,2 , open j+1   varid , [ x ′] j−1,2 , open j+1   varid′  (and [ x ″] j−1,2, , open j+1   varid″  if ⊥ add ) such that:
 
accept=Verify(com j+1   varid′ ,[ x ′] j−1,2 ,open j+1   varid′ )
 
accept=Verify(com j+1   varid″ ,[ x ″] j−1,2 ,open j+1   varid″ ) if add
       

                 [   x   ]         j   -   1     ,   2       =     {               [   v   ]         j   -   1     ,   2       +       [     x   ′     ]         j   -   1     ,   2               if   ⁢           ⁢     ⊥   addc                 v   ·       [     x   ′     ]         j   -   1     ,   2               if   ⁢           ⁢     ⊥   mulc                     [     x   ′     ]         j   -   1     ,   2       +       [     x   ″     ]         j   -   1     ,   2               if   ⁢           ⁢     ⊥   add                     accept≠Verify(com j+1   varid ,[ x ] j−1,2 ,open j+1   varid )
 
accept=Verify(com′ j+1   varid ,open j+1   varid ,open′ j+1   varid )
 
where v, com j+1   varid′ , com j+1   varid″ , wcom +1   varid , sid, varid, and varid′ are owned by both parties.
         4. If the above proof is successful, P j  outputs (abort, sid, P j+1 ). Otherwise, P j  outputs (abort, sid, P j−1 ).       

     Case and ⊥ mult_1 , ⊥ mult_2 , and ⊥ mult_3 : For each j ∈ {1,2,3}, P j  runs the following protocol with P j−1 .
         1. For each j ∈ {1,2,3}, if P i  is among those who broadcasted ⊥ mult_1 , P j  sends (verify, sid, varid, P j ) to F triple . Then, F triple  sends (accept, sid, varid, P j , com varid,j   triple ) to all parties, and sends (accept, sid, varid, P j ([a] j,2 , [ b ] j,2 , [ c ] j,2 ), open varid,j   triple ) to P j . Then, P j  proves to all other parties in zeroknowledge the knowledge of wopen j−1   varid,1 , open varid,j   triple , [ a ] j,2 ,[b] j,2 , and [c] j,2  such that
 
accept=Verify(com varid,j−1   triple ,([ a ] j,2 [ b ] j,2 [ c ] j,2 ),open varid,j−1   triple )
 
accept=Verify(com j−1   varid,1 ,([ a ] j,2 [ b ] j,2 [ c ] j,2 ),open j−1   varid,1 )
 
accept=Verify(com j−1   varid,1 ,open j−1   varid,1 ,open j−1   varid,1 )
 
where com varid,j   triple , wcom j−1   varid,1 , sid, and varid are known to all th parties. If this proof is varid 1 successful, all the party output (abort, sid, P j−1 ). If this proof is not successful, all the party output (abort,sid, P k ).
   2. For each j ∈ {1,2,3}, P j−1  proves to P j  the knowledge of open j+1   varid′ , open j+1   varid″ , seed j+1 , open j+1   seed , [ x ] j−1,2 [ x ′] j−1,2 , [ x ″] j−1,2 , [a] j−1, 2 , [ b ] j−1,2 [ c ] j−1,2 , open j+1   varid , [ r ] j+1,2 , [ s ] j+1,2 open j+1   varid,2 , Q j+1 , open j+1   varid,3 , and (Q′ j+1 , open j+1   varid,4  only when ⊥ mult_3 ) in zeroknowledge that satisfy the following relations.
 
accept=Verify(com j+1   varid′ ,[ x ′] j−1,2 ,open j+1   varid′ )
 
accept=Verify(com j+1   varid″ ,[ x ″] j−1,2 ,open j+1   varid″ )
 
accept=Verify(com j+1   varid ,[ x ] j−1,2 ,open j+1   varid )
 
accept=Verify(com j+1   seed ,seed j+1 ,open j+1   seed )
 
accept=Verify(com j+1   varid,1 ,([ a ] j−1,2 [ b ] j−1,2 [ c ] j−1,2 ),open j+1   varid,1 )
 
accept=Verify(com j+1   varid,2 ,[ r ] j+1,2 ,[ s ] j+1,2 ,open j+1   varid,2 )
 
accept=Verify(com j+1   varid,3   ,Q   j+1 ,open j−1   varid,3 )
 
accept=Verify(com j+1   varid,4   ,Q′   j+1 ,open j+1   varid,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_ iv 1 ,sid,varid ,seed j−1 )− (mult_ iv 1 ,sid,varid ,seed j+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   −s   j−1 ·[ a ] j,2   −r   j−1 ·[ b ] j,2 +[ c ] j,2  
 
[ o ] j−1,2 =−[ x ] j−1,2   +r   j−1   ·s   j−1 ·[1] j−1,2   −s   j−1 ·[ a ] j−1,2   −r   j−1 ·[ b ] j−1,2 +[ c ] j−1,2  
 
 Q   j−1 = (mult_ iv 2, sid,varid ,seed j−1   ,r   j−1   ,s   j−1 )
 
 Q   j−1 = (mult_ iv 3, sid,varid ,seed j−1 ,[ o ] j−1,2 )
 
 Q   j+1 ≠ (mult_ iv 2, d sid,varid ,seed j   ,r   j−1   ,s   j−1 ) when ⊥ mult_2  
 
 Q′   j+1 ≠ (mult_ iv 3, sid,varid ,seed j ,−[ o ] j−1,1 [ o ] j−1,2 ) when ⊥ mult_3  
 
where all the parties have com j+1   varid′ , com j+1   varid″ , com j+1   varid , com j+1   seed , com j+1   varid,1 , com j+1   varid,2 , com j+1   varid,3 , com j+1   varid,4 , varid, varid′, varid″, sid, [x′] j,2 , [x″] j,2 ,[x] j−1,1 , [a] j,2 , [b] j,2 , [c] j,2 , [r] j−1,2 , [s] j−1,2 , seed j−1 .
       

     If P j−1  fails in the proof, P J  outputs (abort,sid,p J−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: 
     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&#39;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 Q j  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 naïve 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. 
     
       
         
           
               
               
               
               
               
               
               
               
             
               
                 TABLE 1 
               
               
                   
               
               
                 MPC Protocol 
                 Fairness 
                 Detect 
                 Comm. 
                 Input/Update 
                 Reuse 
                 History 
                 Identify 
               
               
                   
               
             
            
               
                   
               
            
           
           
               
               
               
               
               
               
               
               
            
               
                 [1] 
                 — 
                 ¼ 
                 2 
                 GMPC 
                 GMPC 
                 All messages 
                 0 
               
               
                 [2] 
                 ✓ 
                 1-neg(k) 
                 28 
                 GMPC 
                 0 
                 All messages 
                 0 
               
               
                 [3] 
                 ✓ 
                 1-neg(k) 
                 7 
                 GMPC 
                 0 
                 All messages 
                 GMPC 
               
               
                 [4] 
                 ✓ 
                 1-neg(k) 
                 7 
                 0 
                 0 
                 — 
                 N/A 
               
               
                 [5] 
                 ✓ 
                 1-neg(k) 
                 7 
                 0 
                 0 
                 0 
                 ~60 msec 
               
               
                   
               
            
           
         
       
     
     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 [4] 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 S A ) Let P l  be the corrupted party. S A  is an ideal adversary that interacts with the parties engaging in π GMPC  and π identify  in (F GMPC )-hybrid model. It also has a black-box access to the real adversary A who corrupted P l . 
     On receiving (setup, sid, κ) from F GMPC , S A  does the followings; 
     1. S A  generates seed l−1  ∈{0,1} k , a random commitment com l+1   seed , Open l−1   seed  ∈ R  {0,1} k , and com l−1   seed =Commit(seed l−1 , open l−1   seed ), S A  sends open l−1   seed  to P l  and broadcast com l−1   seed  as P l−1  and com l+1   seed  as P l+1 . S A  receives open l   seed  and com l   seed  from A. 
     2. S A  as P l+1  and P l−1  sends (setup, sid, κ) to F triple . If a party receives (abort, sid, P k ) from F triple , the party outputs (abort, sid, P k ) and abort the protocol. If a party receives (accept, sid) from F triple , the party proceeds to the next step. 
     3. If all the above processes are successful, S A  sends (accept, sid) to F GMPC . Otherwise, it sends (abort, sid, P l ) to F GMPC . 
     On receiving (random, sid, varid) from F GMPC , S A  does as follow: 
     1. S A  generates
 
[ x ] l = (rand_ iv,sid,varid ,seed l ), (rand_ iv,sid,varid ,seed l−1 ))
 
     2. S A  generates a random commitment wcom l+1   varid , wopen l−1   varid  ∈ R  {0,1} k ×{0,1} l , and wcom l−   varid =W commit([x] l,2 , wopen l−1   varid ). S A  broadcasts (random_brd, sid, varid, wcom l−1   varid ) as P l−1  and (random_brd, sid, varid, 
     wcom l+1   varid ) as P l+1 , and sends (random_msg, sid, varid, wopen l−1   varid ) to A. S A  receives (random_msg, sid, varid, wcom l   varid ) and (random_msg, sid, varid, wopen l   varid ) from A. 
     3. S A  verifies if wopen l   varid  is a valid opening of wcom l   varid  with respect to ([x] l,1 ), and if it is not, S A  broadcasts ⊥ random  as P l+1 . If any party among P l  (corrupted by A) and P l+1  (simulated by S A ) broadcasts ⊥ random,  simulates the prover and plays the verifier of zeroknowledge protocol in π identify,  and completes simulation by sending (abort, sid, P l ) to F GMPC . 
     4. If no one broadcasts ⊥ random , S A  stores (varid, ([x] l,1 , [x] l,2 ), Com l   varid , open l   varid ) and sends (accept, sid) to F GMPC.  In this case, S A  completes the simulation for this request of random here. 
     On receiving (input, sid, varid, P l ) from F GMPC  (where P l  is corrupted), S A  does as in the following: 
     1. S A  receives (input_msg1, sid, P l , varid, [x] j , open j   varid,1 , open j   varid,2 ) for j=l+1 and j=l−1 from A. S A  receives (input_brd1, sid, P l , varid, com j   varid,1 , com j   varid,2 , com j   varid,3 ). 
     2. S A  generates a random wcom l+1   varid ), wopen l−1   varid  ∈ R  {0,1} k ×{0,1} k , and wcom=wcommit([x] l−1,1 , wopen l−1   varid ). S A  sends (input_msg2, sid, varid, 
     wopen l−1   varid ) to A, broadcast (input_brd2, sid, varid, wcom l−1   varid ) as P l−1  and (input_brd2, sid, 
     varid,wcom l+1   varid ) as P l+1 . S A  receives (input_brd2, sid, varid, wcom l   varid ) and (input_msg2, sid, varid, wopen l   varid ). 
     3. S A  verifies if wopen varid,l  is a valid opening of wcom l   varid  with respect to ([x] l+1,2 ).
         If the opening is not valid, S A  broadcasts ⊥ input  as P l+1 .   If the latter equation does not hold, S A  broadcasts ⊥ input  as P l−1 .   If any party among P l  (corrupted by A) and P l−1  and P l+1  (both simulated by S A ) broadcasts ⊥ input , S A  simulates the prover and plays the verifier of zeroknowledge protocol in π identify , and completes simulation by sending (abort, sid, P l ) to F GMPC .       

     4. If no one broadcasts ⊥ input , S A  stores (varid, ([x] l+1,2 , [x] l−1,1 ), com l   varid , open l   varid ), generates x=[x] l+1,2 +[x] l−1,1 +[x] l−1,2 , sends (accept, sid, x) to F GMPC . In this case, S A  completes the simulation for this request of input here. 
     On receiving (input, sid, varid, P k ) from F GMPC  where P k  is an uncorrupted party, S A  does as the following: 
     1. S A  generates [x] l =([x] l,1 , [x] l,2 ) ∈ R    × , open k   varid,l ∈   R  {0,1} k , open k   varid,l−1  ∈ R  {0,1} k , com k   varid,l =com([x] l,1 open k   varid,l ), com k   varid,l−1 =com([x] l,2 , open k   varid,l−1 ) and a random com k   varid,l+1 . S A  sends 
     (input_msg1, sid, P k , varid, [x] l , open k   varid,l , open k   varid,l−1 ) to A, an broadcasts (input_brd1, sid, P k , varid, com k   varid,1 , com k   varid,2 , com k   varid,3 ). 
     2. S A  also generates a random commitment wcom l+1   varid , wopen l−1   varid  ∈ R  {0,1} k ×{0,1} k , and wcom l−1   varid =Wcommit([x] l,2 , wopen l−1   varid ). S A  sends (input_msg2, sid, varid, wopen l−1   varid ) to A, and broadcasts (input_brd2, 
     sid, varid, wcom l−1   varid ) as P l−1  and (input_brd2, sid, varid, wcom l+1   varid ) as P l+1 . S A  receives the message (input_msg2, sid, varid, wopen l   varid ) and (input_brd2, sid, varid, wcom l   varid ). 
     3. S A  verifies if wopen l   varid  is a valid opening of wcom l   varid  with respect to([x] l,1 ), and if it is not, S A  broadcasts ⊥ input  as P l+1 . If any party among P l  (corrupted by A) and P l+1  (simulated by S A ) broadcasts ⊥ input , S A , S A  simulates the prover and plays the verifier of zeroknowledge protocol in π identify,  and completes simulation by sending (abort, sid, P l ) to F GMPC . 
     4. If no one broadcasts ⊥ input , S A  stores (varid, ([x] l,1 , [x] l,2 ), com l   varid , open l   varid ) and sends (accept, sid) to F GMPC . In this case, S A  completes the simulation for this request of input here. 
     On receiving (output, sid, varid, P k ) from F GMPC , where (varid,[x] l ,com l   varid , open l   varid ) is stored and P k  is not the corrupted party, S A  does as in the following; 
     1. S A  receives a message that A, as P l , sends to P k . 
     2. S A  sends (accept, sid) to F GMPC . 
     On receiving (output, sid, varid, P l ) from F GMPC , where (varid,[x] l , com l   varid , open l   varid ) is stored where P l  is the corrupted party, S does as in the following; 
     1. S, as P l , receives (value, sid, varid, x) from F GMPC . 
     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  open l+1   varid  ∈ R  {0,1} k , com l+1   varid Commit([x] l+1,1 , open l+1   varid ) 
     3. S A , as P l+1 , sends (output_msg, sid, varid, [x] l+1 , open l   varid ) to A. S A , as P l−1 , sends (output_msg, sid, varid, [x] l−1 , open l+1   varid ) to A. 
     On receiving (addc, sid, varid, varid′, v)/(multic, sid, varid, varid′, v)/(add, sid, varid, varid′, v) from F GMPC  where (varid′, [x′] l , com l   varid′ , open l   varid′ ) is stored, (varid″, [x″] l , com l   varid″ , open l   varid″ ) is stored if add, v ∈   if addc or multc, and varid is a new index. S does as in the following; 
     1. S A  generates a random commitment wcom l+1   varid  and; 
     
       
         
           
             
               
                 [ 
                 
                   x 
                   varid 
                 
                 ] 
               
               ℓ 
             
             = 
             
               { 
               
                 
                   
                     
                       
                         
                           
                             ( 
                             
                               
                                 
                                   
                                     [ 
                                     
                                       x 
                                       ′ 
                                     
                                     ] 
                                   
                                   
                                     ℓ 
                                     , 
                                     1 
                                   
                                 
                                 + 
                                 
                                   v 
                                   · 
                                   
                                     
                                       [ 
                                       1 
                                       ] 
                                     
                                     
                                       ℓ 
                                       , 
                                       1 
                                     
                                   
                                 
                               
                               , 
                               
                                 
                                   
                                     [ 
                                     
                                       x 
                                       ′ 
                                     
                                     ] 
                                   
                                   
                                     ℓ` 
                                     , 
                                     2 
                                   
                                 
                                 + 
                                 
                                   v 
                                   · 
                                   
                                     
                                       [ 
                                       1 
                                       ] 
                                     
                                     
                                       ℓ 
                                       , 
                                       2 
                                     
                                   
                                 
                               
                             
                             ) 
                           
                         
                         
                           
                             if 
                             ⁢ 
                             
                                 
                             
                             ⁢ 
                             addc 
                           
                         
                       
                       
                         
                           
                             ( 
                             
                               
                                 
                                   
                                     [ 
                                     
                                       x 
                                       ′ 
                                     
                                     ] 
                                   
                                   
                                     ℓ 
                                     , 
                                     1 
                                   
                                 
                                 · 
                                 v 
                               
                               , 
                               
                                 
                                   
                                     [ 
                                     
                                       x 
                                       ′ 
                                     
                                     ] 
                                   
                                   
                                     ℓ 
                                     , 
                                     2 
                                   
                                 
                                 · 
                                 v 
                               
                             
                             ) 
                           
                         
                         
                           
                             if 
                             ⁢ 
                             
                                 
                             
                             ⁢ 
                             multc 
                           
                         
                       
                       
                         
                           
                             ( 
                             
                               
                                 
                                   
                                     [ 
                                     
                                       x 
                                       ′ 
                                     
                                     ] 
                                   
                                   
                                     ℓ 
                                     , 
                                     1 
                                   
                                 
                                 + 
                                 
                                   
                                     [ 
                                     
                                       x 
                                       ″ 
                                     
                                     ] 
                                   
                                   
                                     ℓ 
                                     , 
                                     1 
                                   
                                 
                               
                               , 
                               
                                 
                                   
                                     [ 
                                     
                                       x 
                                       ′ 
                                     
                                     ] 
                                   
                                   
                                     ℓ 
                                     , 
                                     2 
                                   
                                 
                                 + 
                                 
                                   
                                     [ 
                                     
                                       x 
                                       ″ 
                                     
                                     ] 
                                   
                                   
                                     ℓ 
                                     , 
                                     2 
                                   
                                 
                               
                             
                             ) 
                           
                         
                         
                           
                             if 
                             ⁢ 
                             
                                 
                             
                             ⁢ 
                             add 
                           
                         
                       
                     
                     ⁢ 
                     
                       
 
                     
                     ⁢ 
                     
                       wopen 
                       
                         ℓ 
                         - 
                         1 
                       
                       varid 
                     
                   
                   ⁢ 
                   
                     ∈ 
                     R 
                   
                   ⁢ 
                   
                     
                       { 
                       
                         0 
                         , 
                         1 
                       
                       } 
                     
                     κ 
                   
                 
                 , 
                 
                   
                     wcom 
                     
                       ℓ 
                       - 
                       1 
                     
                     varid 
                   
                   = 
                   
                     W 
                     ⁢ 
                     
                         
                     
                     ⁢ 
                     
                       commit 
                       ⁡ 
                       
                         ( 
                         
                           
                             
                               [ 
                               x 
                               ] 
                             
                             
                               ℓ 
                               , 
                               2 
                             
                           
                           , 
                           
                             wopen 
                             
                               ℓ 
                               - 
                               1 
                             
                             varid 
                           
                         
                         ) 
                       
                     
                   
                 
               
             
           
         
       
     
     2. S A  sends (addc_msg/multc_msg/add_msg, sid, varid, wopen l−1   varid ) to A. S A  broadcasts (addc_brd/multc_brd/add_brd, sid, varid, wcom l−1   varid ) and (addc_brd/multc_brd/add_brd, sid, varid,wcom l+1   varid ). S A , as P l+1 , receives (addc_msg/multc_msg/add_msg, sid, varid, wopen l   varid ) and 
     (addc_brd/mult_brd/add_brd, sid, varid, wcom l   varid ) from A. 
     3. S A  verifies if wopen l   varid  is a valid opening of wcom l   varid  with respect t ([x] l,1 ), and if it is not valid, S A  broadcasts ⊥ addc/multc/add  as P l+1 . If any party among P l  (corrupted by A) and P l+1  (simulated by S A ) broadcasts ⊥ add/multc/add , S A  simulates the prover and plays the verifier of zeroknowledge protocol in π identify,  and completes simulation by sending (abort, sid, P l ) to F GMPC . 
     4. If no one broadcasts ⊥ addc/multc/add , S A  stores (varid, [x] l , com l   varid , open l   varid ) and sends (accept, sid) to F GMPC . In this case, S A  completes the simulation for this request of addc/multc/add here. 
     On receiving (malt, sid, varid, varid′, varid″) where (varid′, [x′] l , com l   varid′ , 
     open l   varid′ ) and (varid″, [x″] l , com l   varid″ , open l   varid″ ) are stored, and varid is a new index, S A  does as in the following. 
     1. S A  generates a random commitmentcom l+1   varid ,[x] l−1,1  ∈ R    , open l−1   varid  ∈ R  {0,1} k , and com l−1   varid =Commit([x] l−1,1 , open l−1   varid ), 
     2. S A  sends (mult_msg1, sid, varid, [x] l−1,1 , open l−1   varid ) to A, and broadcasts (mult_brd1, sid, varid, com l−1   varid ) as P l−1  and (mult_brd1, sid, varid, com l+1   varid ) as P l+1 . S A  receives (mult_msg1, sid, varid,[x] l,1 , open l   varid ) and 
     (mult_brd1, sid, varid, com l   varid ) from A. 
     3. S A  lets P l+1  and P l−1  send (triple, sid, varid) to F triple , and S A  receives (triple, sid, varid) from F triple , which is forwarded to A. Then, S A  receives (accept, sid, ([a] l , [b] l , [c] l )) from F triple    
     4. S A  generates a random commitment com l+1   varid,2  and verifiable commitment wcom l+1   varid,1 , and; 
     [r] l−1,2  ∈ R      varid , [s] l−1,2  ∈ R      varid , wopen 1-1   varid,1  ∈ R  {0,1} k ×{0,1} k , 
     wcom l−1   varid,1 =Wcommit(([a] l,2 , [b] l,2 , [c] l,2 ), wopen l−1   varid,1 ) open l−1   varid,2  ∈ R  {0,1} k , com l−1   varid,2 =Commit(([r] l−1,2 , [s] l−1,2 ), open l−1   varid,2 ) (mult_msg2, sid, varid, [r] l−1,2 , [s] l−1,2 , wopen l−1   varid,1 , open l−1   varid,2 ) to A. S A  broadcasts (mult_brd2, sid, varid, wcom l−1   varid,1 , com l−1   varid,2 ) as P l−1  and (mult_brd2, sid, varid, wcom l+1   varid,1 , com l+1   varid,2 ) as P k+1 . S A  receives (mult_msg_2, sid, varid, [r] l,2 , [s] l,2 , wopen l   varid,1 , open l+1   varid,2 ) and 
     (mult_brd2, sid,varid,wcom l   varid,1 , com l   varid,2 ) from A. 
     6. S A  verifies if wopen l   varid,1  is a valid opening of wcom l   varid,1  with respect to ([a] l,1 , [b] l,1 , [c] l,1 ), and if it is not, S A  broadcasts ⊥ mult_1  as P l+1 . If any of the parties has broadcasted ⊥ mult_1 , S A  proceeds to Step (12). 
     7. S A  generates the following values in order to simulate Q l−1  and Q′ l−1  that P l−1  sends to P l , when P l+1  rejects Q l  and Q′ l , and when P l−1  rejects Q l+1  and Q′ l+1 . Note that P l+1  may accept even if P l  deviates the protocol and P l−1  may reject P l+1  although P l+1  is honest. This is because P l  is controlling some of values they use.
 
 p   l = (mult_ iv 1 ,sid,varid ,seed l )− (mult_ iv 1 ,sid,varid ,seed l−1 )
 
[   x   ] l,1 =[ x ′] l,1 ·[ x ″] l,1 +[ x ′] l,1 ·[ x ″] l,2 +[ x ′] l,2 ·[ x ″] l,1 +ρ l  
 
[   x   ] l :=([   x   ] l,1 ,[ x ] l−1,1 ),[   r   ] l =[ x ′] l +[ a ] l ,[   s   ] l =[ x ″] l +[ b ] l  
 
 r   l−1 =[ r ] l−1,2 +[   r   ] l,1 +[   r   ] l,2   ,s   l−1 =[ s ] l−1,2 +[   s   ] l,1 +[   s   ] l,2  
 
 Q   l−1 = (mult_ iv 2, sid,varid ,seed l−1   ,r   l−1   ,s   l−1 )
 
open l−1   varid,3 ∈ R {0,1} k ,com l−1   varid,3 =Commit( Q   l−1 ,open l−1   varid,3 )
 
open l+1   varid,3 ,open l+1   varid,4 =random commitments
 
 r   l+1 =[ r ] l−1,2 +[   r   ] l,1 +[ r ] l,2   ,s   l+1 =[ s ] l−1,2 +[   s   ] l,1 +[ s ] l,2  
 
[ o ] l−1,2 =([ x ] l,2 +[   x   ] l,1 )− r   l−1   ·s   l−1 ·([1] l,2 +[1] l+1,2 )+ s   l−1 ·([ a ] l,2 +[ a ] l,1 )+ l−1 ·([ b ] l,2 +[ b ] l,1 )−([ c ] l,2 +[ c ] l+1,2 )
 
 Q′   l−1 = (mult_ iv 3, sid,varid ,seed l−1 ,[ o ] l−1,2 )
 
open l−1   varid,4 ∈ R {0,1} k ,com l−1   varid,4 =Commit( Q′   l−1 ,open l−1   varid,4 )−[ o ] l−1,1 [ o ] l−1,2 =−[   x   ] l,1   +r   l−1   ·s   l−1 ·[1] l+1,2   −s   l−1 ·[ a ] l,1   −r   l−1 ·[ b ] l,1 +[ c ] l+1,2  
 
[ o ] l+1,2 =−[ x ] l,1   +r   l−1   ·s   l−1 ·[1] l+1,2   −s   l−1 ·[ a ] l,1   −r   l−1 ·[ b ] l,1 +[ c ] l,1  
 
[ o ] l+1,1 =([ x ] l−1 +[   x   ] l,1 )− r   l−1   ·s   l−1 ·([1] l,1 +[1] l,1 )(+ s   l−1 ·([ a ] l,1 +[ a ] l−1,1 )+ r   l−1 ·([ b ] l,1 +[ b ] l−1,1 )−([ c ] l,1 +[ c ] l−1,1 )
 
−[ o ] l+[1,1   o ] l+1,2 =−([ x ] l−1 +[   x   ] l,1 [ x ] l,1 )+ r   l−1   ·s   l−1 ·[1] l−1,1  
 
− s   l−1 ·[ a ] l,2   −r   l−1 ·[ b ] l,2 +[ c ] l,2  
 
     8. S A  broadcasts (mult_brd3, sid, varid, com l−1   varid,3 ) as P l−1  and (mult_brd3, 
     sid, varid, com l+1   varid,3 ) as P l+1 . S A  sends (mult_msg3, sid, varid, Q l−1 , 
     open l−1   varid,3 ) to A. S A  receives (mult_msg3, sid, varid, Q l , open l   varid,3 ) and (mult_brd3, sid, varid, com l   varid,3 ) from A. 
     9. S A  verifies if ⊥ mult_2  should be broadcast:
         If Q l = (mult_iv2, sid, varid, seed l , r l+1 , s l+1 ) does not hold, S A  broadcasts ⊥ mult_2  as P l+1 .   If (r l+1 , s l+1 )=(r l−1 , s l−1 ) does not hold, S A  broadcasts ⊥ mult_2  as P l−1      A broadcast ⊥ mult_2  as P l .       

     If any of the parties has broadcasted ⊥ mult_2 , S A  proceeds to Step (12). 
     10. S A  broadcasts (mult_brd4, sid, varid, com l−1   varid,4 ) as P l−1  and (mult_brd4, 
     sid, varid, com l+1   varid,4 ) as P l+1 . S A  sends (mult_msg4, sid, varid, Q′ l−1 , 
     open l−1   varid, ) to A. S A  receives (mult_msg4, sid, varid, Q′ l , open l   varid,4 ) and (mult_brd4, sid, varid, com l   varid,3 ) from A. 
     11. S A  verifies if ⊥ mult_3  should be broadcast:
         If Q′ l = (mult_iv2, sid, varid, seed l , −[o] l+1,1 −[o] l+1,2 ) does not hold, S A  broadcasts ⊥ mult_3  as P l+1 .   If [o] l+1,2 =−[o] l−1,1 −[o] l−1,2  does not hold, S A  broadcasts ⊥ mult_3  as P l .   A broadcast ⊥ mult_3  as P l .       

     If any of the parties has broadcasted ⊥ mult_3 , S A  proceeds to Step (12). 
     12. If ⊥ mult_1  is broadcast, S A  sends (verify, sid, varid) as such P j  ∈ {P l+1 , P l−1 } that broadcasted ⊥ mult_1 . Then it receives (accept, sid, varid, com varid,j   triple ) and (accept, sid, varid, ([a] j , [b] j , [c] j ), open varid,j   triple ) for any party P j  that requires to do so. 
     13. S A  simulates the prover and plays the verifier of zeroknowledge protocol in π identify , and completes simulation by sending (abort, sid, P l ) to F GMPC . 
     Theorem 6. π GMPC , which is followed by π identify  when a party aborts, in F triple -hybrid model securely realizes F GMPC . 
     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 seed l+1 . In simulated view, these are random values. These are in the following. 
     Setup: The real protocol and simulated protocol differ in that com l+1   seed  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, seed l+1 )+ (rand_iv, sid, varid, seed l )+ (rand_iv, sid, varid, seed l−1 )} varid . 
     In a simulated protocol, {x ∈   varid } varid . 
     This difference comes from the fact that, while the real protocol π GMPC  determines it by pseudorandom function with the input of seed l+1 , F GMC  generates if from randomly chosen x. 
     The only way for the adversary to abort the protocol is 
     wopen l   varid  is not a valid opening of wcom l   varid  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 wopen v  ar l  is a valid opening of wcom l   varid . This simulation is straightforward. In the second case, A again simply fails in zeroknowledge proof in the real protocol as P l−1 &#39;s is honest and its output is totally independent to A. This simulation is direct. These cases are consistent to S A &#39;s sending (abort, sid, P l ) to F GMPC . 
     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 
     wopen l   varid  is not a valid opening of wcom l   varid  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 com l   varid  and wcom l   varid  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 P l−1 &#39;s is honest and its output is totally independent to A. This simulation is direct. These cases are consistent to S A &#39;s sending (abort, sid, P l ) to F GMPC . Therefore, the real protocol and simulated protocol are indistinguishable. 
     Input by the corrupted party: As the P l &#39;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 
     wopen l   varid  is not a valid opening of wcom l   varid  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 wopen l−1   varid  is a valid opening of wcom l−1   varid  with respect to [x] l,2 . This simulation is straightforward. These cases are consistent to S A &#39;s sending (abort, sid, P l ) to F GMPC . Therefore, the real protocol and simulated protocol are indistinguishable. 
     Output when the receiver is not the corrupted party: As A&#39;s behavior does not affect S A &#39;s simulation. S A  stores (varid,[x] l , com l   varid , open l   varid ) only when the previous protocol is completed successfully and open l   varid  is a valid opening of com l   varid  with respect to [x] l,1 . Hence, that the S A  has such data that guarantees what S A  sends (accept, sid) to F GMPC  is 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 S A , 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 
     wopen l   varid  is not a valid opening of wcom l   varid  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 wopen l−1   varid  is a valid opening of wcom l−1   varid  with respect to [x] l,2 . This simulation is direct. These cases are consistent to S A &#39;s sending (abort, sid, P l ) to F GMPC . 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_ iv 1 ,sid,varid ,seed l−1 )− (mult_iv1 ,sid,varid ,seed l+1 ),
 
[ a ] l,2 ·[ b ] l,2 +[ a ] l,2 ·[ b ] l−1,2 +[ a ] l−1,2 ·[ b ] l,2 + (triple_ ivc,i ,seed l−1 )− (triple_ ivc,i ,seed l+1 )
 
[ x ′]l l−1,2 + (triple_ iva,i ,seed l+1 ),[ x ″] l−1,2 + (triple_ ivb,i ,seed l+1 )} varid  
 
where as they are random numbers in the simulated protocol. All the values in the real protocol includes pseudorandom number generated from seed l+1 .
 
     The only ways for the adversary to abort the protocol is, 
     Maneuver P l+1  to send Q l+1  that is not  (mult_iv2, sid, varid, seed l+1 , r l−1 , s l−1 ) to P l−1 . This can be done by adjusting the value of ([r] l,2 , [s] l,2 ) that A sends to P l+1 . 
     Send Q l  that is not  (mult_iv2, sid, varid, seed l , r l+1 , s l+1 ) to P l+1 . 
     Maneuver P l−1  to send Q l−1  that is not  (mult_iv2, sid, varid, seed l−1 , r l−1 , s l−1 ) to P l . 
     Maneuver P l+1  to send Q′ l+1  that is not  (mult_iv3, sid, varid, seed l+1 , [o] l−1,1 −[o] l−1,2 ) to P L−1 . This can be done by adjusting the value of [x varid ] l,1  that A sends to P l+1 . 
     Send Q′ l  that is not  (mult_iv3, sid, varid, seed l , [o] l+1,1 −[o] l+1,2 ) to P l+1 . 
     Maneuver P l−1  to send Q′ l−1  that is not  (mult_iv3, sid, varid, seed l−1 , −[o] l,1 −[o] l,2 ) to P l−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 S A  is able to simulate r l−1  and s l−1  accurately, S A  as P l−1  broadcasts ⊥ mult_2  exactly when it should as in the real protocol. In other words, Q l+1  is maneuvered by A through ([r] l,2 , [s] l,2 ), but this is accurately simulated by S A . This case occurs only when P l  deviates from the protocol and P l+1  is able to prove its cheating in the real protocol. This is consistent to S A &#39;s sending (abort, sid, P l ) to F GMPC . All the simulation of proofs between players are straightforward. 
     In the second case, since S A  is able to simulate r l+1  and s l+1  accurately, S A  as P l+1  broadcasts ⊥ mult_2  exactly when it should as in the real protocol. As r l+1  and s l+1  are maneuvered by ([r] l,2 , [s] l,2 ), P l+1  is not always expected to detect the cheating by the verification of the equation. However, this cheating is always detected by P l−1 , and then P l+1  is able to identify P l  as the cheater as P l  should fail to prove that it did send the correct ([r] l,2 , [s] l,2 ). This is consistent to S A &#39;s sending (abort, sid, P l ) to F GMPC . All the simulation of proofs between players are straightforward. 
     In the third case, (r l−1 , s l−1 )=(r l , s l ) if P l  generates the latter pair honestly, S A  is able to simulate exactly the Q l−1  that P l−1  should generate in the real protocol. Hence, in case P l  outputs ⊥ mult_2 , P l+1  is able to identify P l  as the cheater as P l  should fail to prove that its decision against P l−1  was correct. This is consistent to S A &#39;s sending (abort, sid, P l ) to F GMPC.    
     If no one has broadcasted ⊥ mult_2 , that all the parties agreed that r 1 =r 2 =r 3  and s 1 =s 2 =s 3 . This is assumed in the below. 
     In the fourth case, A is able to maneuver P l+1  &#39;s computation of Q′ l+1  but is not able to maneuver P l−1 &#39;s verification. This is precisely simulated by S A  as S A  is able to simulate maneuvered Q′ l+1 . P l+1  broadcasts ⊥ mult_3  as P l−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, P l+1  is able to prove that P l &#39;s cheating in the real protocol. Hence, this is consistent to S A &#39;s sending (abort, sid, P l ) to F GMPC . All the simulation of proofs between players are straightforward. 
     In the fifth case, since S A  is able to simulate maneuvered−[o] l+1,1 −[o] l+1,2  accurately, S A  as P l+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 , P l+1  is not always expected to detect the cheating by the verification of the equation. However, this cheating is detected when P l  is required to prove to all the parties that P l  generated [x] l+1,2  correctly. Hence, as long as cheating is detected, the cheater is correctly identified. This is consistent to S A &#39;s sending (abort, sid, P l ) to F GMPC . All the simulation of proofs between players are straightforward. 
     Theorem 7. {tilde over (π)} gmpc  in F triple -hybrid model realizes F GMPC . 
     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 , com l   varid′ , open l   varid′ ) and 
     (varid, [x″] l , com l   varid″ , open l   varid″ . The latter is only for addition and multiplication. Since the simulator does not use com l   varid′ , open l   varid′ , com l   varid″ , and open l   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 P l . 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 P l+1  sends this very value to P l−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.