Extending the Security of SPDZ with Fairness

SPDZ refers to a family of protocols for Secure Multi-Party Computation (MPC) that lie at the foundation of very popular software frameworks for MPC, such as SCALE-MAMBA and MP-SPDZ. SPDZ provides good efficiency while guaranteeing security even when all but one of the participants are corrupted. This seemingly optimal property comes at a price: the protocol only offers security with abort, meaning that even a single cheating participant can force the protocol to abort, leaving honest participants with no clue on what the correct output is, or who cheated. This is especially problematic since cheating participants are able to obtain the correct output of the computation, effectively ‘stealing’ it. We propose a hybrid secure adaptation to SPDZ, which retains the existing security guarantees, but in case the number of cheating players is less than half of the total, we achieve fairness, meaning that either all players obtain the correct output of the computation, or no player does. The ‘less than half’ threshold of corrupted players has been proven to be a tight bound to achieve fairness. Aside from the description of the protocol and its security proof, we also present a proof-of-concept implementation, and evaluate its practical performance, thereby demonstrating that our solution has negligible overhead compared to standard SPDZ in most application scenarios.

resulting value back to the parties, thus guaranteeing privacy of the inputs  1 , . . .,   and correctness of the output  ( 1 , . . .,   ).
Introduced by Yao [42] in the 1980s, MPC only began to be used in practical scenarios in the last decade, starting from the seminal work on agricultural-market auctions in Denmark [7], and subsequently other topics such as financial benchmarking [18], genome computation [28], and various other applications [43].This increasing number of practical deployments of MPC is due, on one hand, to new MPC frameworks with very high efficiency, and on the other hand, the increased need for secure data sharing solutions.
Several settings for MPC have been investigated, with different assumptions regarding the number and behavior of participants, and with different security guarantees.The highly popular family of protocols based on SPDZ [19,21,32], which led to several widely used software frameworks [1,30], supports any number  ≥ 2 of participants, and guarantees security even in the presence of  − 1 corrupted participants.This, however, has effects on the exact type of security that is achieved: while privacy of the inputs is guaranteed (under computational-hardness assumptions), only a weak form of correctness is ensured, known as security with selective abort.This means that no honest participant will be led to accept an incorrect result, even when all other participants cooperate by actively cheating and deviating from the instructions of the protocol.However, no 'positive' guarantee is given: cheating behavior will cause the protocol to abort, leaving the honest participants with no clue as to what the correct result is, or who cheated.This effectively allows a dishonest participant to perform a denial-of-service attack on the protocol.On top of this, an attack is described at the end of Subsection 2.3 that enables a single dishonest participant to obtain the correct result, while forcing the protocol to abort without any fear of getting caught, thus effectively 'stealing' the result.This can be highly problematic in various scenarios, such as auctions, where the inputs  1 , . . .,   are bids and the result is the highest bid or bidder: in this case, a dishonest party can learn the highest bid, while leaving the other participants with no clue on its value or who cheated, thus gaining an unfair advantage and effectively barring the use of protocols that merely guarantee security-with-abort in this setting.Similar problems occur in financial benchmarking, where one cheating party could walk away with exclusive access to important benchmarking results, and contract signing, where a single party may obtain a (possibly legally enforceable) signed contract.At its core one or more of the participants may be enticed to 'steal' the output  ( 1 , . . .,   ) in scenarios where the value of asymmetrical knowledge between the  1 , . . .,   may be larger than the value of the output only [13].
A possible mitigation to this problem in the context of SPDZbased protocols was introduced in the form of cheater detection [41], where dishonest parties can still 'steal' the result, but will be identified as cheaters by the other parties (although honest parties will not necessarily identify the same cheater).More generally, the shortcomings of security with abort has inspired the study of secure computation protocols with identifiable abort [38].However, this only solves part of the problem, since cheating parties are still able to obtain the result of the computation, and/or prevent other parties from doing so.
The ideal solution is captured by the notion of fairness: either all participants obtain the correct output of the computation, or no participant does.However, fairness cannot, in general, be guaranteed when half or more of the participants are corrupted [14], seemingly conflicting with the existing security guarantee of SPDZ, which holds in the presence of up to  − 1 corrupted participants.
We address this apparent incompatibility with a hybridsecure [11,23] approach.Namely, we propose an adaptation to the SPDZ-based protocol(s) that guarantees different notions of security, depending on the number of corrupted participants .If /2 ≤  <  (dishonest majority), we retain the security guarantees of SPDZ: no honest party will be led to accept an incorrect result.However, when  < /2, we guarantee fairness, thus eliminating the possibility that cheating parties 'steal' the computation result.Privacy of the inputs is always guaranteed.
The variant of SPDZ we introduce thus has the potential of considerably increasing the scope of possible application scenarios of SPDZ-based software suites.

Contributions
Our work is an enhancement of the SPDZ-2 protocol [19], and is compatible with improvements that share the same online phase, such as MASCOT [31], LowGear and HighGear [32], and TopGear [3].
The modified version we introduce maintains the security guarantees of SPDZ, i.e. it ensures privacy of the parties' inputs and security with abort, even when all but one parties are corrupted.When only a minority of the parties is corrupted, our modified protocol achieves fairness.Guaranteeing fairness extends the use cases of the aforementioned protocols with those where asymmetric knowledge of the output is valuable and accepting an incorrect result is undesirable.The requirement that only a minority of parties may be corrupted has been shown to be, in general, a necessary condition to achieve fairness [14].Furthermore, it was shown that the even stronger property of robustness cannot be guaranteed while also achieving security with abort for up to  − 1 corruptions, for general MPC protocols based on secret sharing, such as the SPDZ-based protocols [27].Extending the SPDZ-based protocols with fairness in the presence of an honest majority is therefore optimal.We stress the fact that the number of corrupted parties does not need to be given as input parameter to the protocol.
We describe our solution and formally prove that it satisfies the two aforementioned notions of security.Moreover, we present a proof-of-concept implementation and provide benchmarking results that show that the overhead of our solution, compared to 'standard' SPDZ, is negligible in both communication and computation.
A point of attention is that we only provide a security proof in the stand-alone model, as opposed to the universal-composability model [10] where the security of standard SPDZ is proved.This is due to the fact that, during the last phase of our protocol, parties need to unanimously agree on whether proceeding to attempt to reconstruct the output, or aborting; intuitively, this requires synchronous channels, and hence make a security proof in the UC model (which is inherently asynchronous) extremely complex at best [29].We stress the fact that a lack of formal UC proof does not mean that our solution is inherently insecure when composed in parallel; for practical applications as those described in the previous subsection, in particular, we do not foresee this to pose limitations: for such applications, MPC solutions would arguably be run in a protected environment, with end-to-end encryption and authenticated network connections.On the one hand, parties could therefore agree to run a single execution if they deem attacks on composed protocols to be realistic; on the other hand, these environment would typically enforce measures, by e.g.direct cable connections or traffic control, that would prevent the adversary from arbitrarily delaying messages and disrupt unanimous agreement.

Related Work
The SPDZ-2 protocol [19], which forms the basis for our scheme, was introduced in 2012.The protocol improves upon the original SPDZ [21] protocol by introducing a (covert-) secure key-generation protocol, improving the overall efficiency of the preprocessing phase and introducing a new, efficient online phase.The new online phase uses a simpler MAC scheme, enabling the generation of shared randomness for multiple function evaluations using the same MAC-key.
Since the introduction of SPDZ-2, several improvements have been made with regard to the efficiency of the preprocessing phase.Keller et al. [31] introduced MASCOT, which improves the throughput of generating multiplication triples up to two orders of magnitude using symmetric key primitives in combination with oblivious transfer, instead of the previously used public-key schemes.Keller et al. [32] introduce the LowGear and HighGear protocols in the Overdrive paper, which improve the efficiency of the Zero-Knowledge Proof of Knowledge (ZKPoK) for a low and high number of participants respectively.Baum et al. [3] introduced TopGear, which leverages a new proving strategy to improve the efficiency of the ZKPoKs once more.Since all these protocols, including the SPDZ-2 protocol, use the same online phase, we refer to them as the SPDZ-based protocols.
Other work aims to extend the security that SPDZ-based protocols offer.Spini and Fehr [41] deter participants from cheating by adding cheater detection.Their scheme retains the original efficiency of the online phase when no cheating occurs.Baum et al. [5] extend SPDZ with identifiable abort and public verifiability, coming at the cost of increased complexity.Cunningham et al. [15] extend the protocol with three separate properties: complete identifiable abort, complete identifiable auditability and openability.
A very relevant work in the field of hybrid security is an impossibility result by Ishai et al. [27], proving that there exists no protocol based on secret sharing (as the SPDZ-based protocols do) that can guarantee security with abort for  − 1 participants, while also guaranteeing robustness.A multitude of hybrid secure protocols have been proposed, including schemes that are hybrid in the number of corrupted participants [9], type of corruption (active/passive) [27], computational capabilities of the adversary [12] and a mix of these characteristics [26,27].
Another relevant feasibility result was presented by Cleve [14], which shows that, in general, it is impossible to achieve fairness when a majority of the participants is corrupt.To guarantee fairness, a wide variety of techniques has been proposed.These include the use of trusted dealers [25,34], stimulating honest behavior by linking the computation to cryptocurrencies [4,33] or reputation systems [2], and using public bulletin boards [13].An interesting approach to achieving fairness is that of gradual release, where sensitive information is released gradually.This gradual release of information ensures that the advantage of a malicious participant is bounded by a certain factor [6,17,26].Notice that these works typically rely on GMW-like constructions [24], and are hence less efficient than SPDZ-based protocols, due to the use of zeroknowledge proofs.
A framework that can transform a variety of secret-sharing based semi-honest minority protocols into malicious minority protocols, guaranteeing security with abort, was introduced by Lindell and Nof [35].They guarantee security with abort by verifying all multiplications that were performed in the computation stage, before they continue with the output-reconstruction stage.We note that they do not achieve fairness, although this is possible in the honestmajority setting.
Damgård et al. [20] present a general construction, based on verifiable secret sharing, that constructs a fair protocol from any protocol satisfying security with abort against a dishonest minority and having a special structure, called compute-then-open by the authors.While SPDZ seems to satisfy this condition, the authors do not make claims on a possible extension to the dishonest-majority setting.
Finally, Nordholt and Veeningen [37] continue on this work, including the addition of fairness.First, they propose a protocol that guarantees fairness in the malicious minority setting, but is only secure for a small number of participants.Second, they provide a SPDZ-based three-party computation protocol that achieves fairness in the malicious minority setting by blinding the output values with three input masks, one for every participant, before verifying them.
Table 1 provides an overall comparison of the results discussed in this section.

High-level Overview of our Construction
In this section, we provide some intuition on how our scheme works and provide some insights in its applicability to arbitrary actively-secure MPC protocols.
We begin with some intuition on the overall idea behind our construction.For simplicity, assume that the functionality  that the parties wish to compute produces a single output.Loosely speaking, our construction makes use of two components: an actively secure MPC protocol offering security with abort against  − 1 corrupted parties, and a fair reconstruction protocol that, on input of a secret sharing of a given value, allows the parties to reconstruct that value, while guaranteeing correctness against  − 1 corrupted parties, and fairness against < /2 corrupted parties.In our case, the first protocol is given by SPDZ, while the second one is based on the conversion of an additive -out-of- secret sharing to a Shamir secret sharing with threshold ⌈/2⌉, and subsequent reconstruction.The parties then use the MPC protocol to compute  ( 1 , . . .,   ) +, where  is a random 'masking' value, and to compute a secret sharing of  of the format required by the fair-reconstruction protocol.At this point, the parties simply use the latter protocol to fairly reconstruct , then subtract this value from the output of the MPC protocol, and finally obtain  ( 1 , . . .,   ) in a fair way.
Intuitively, the security with abort against  − 1 corrupted parties is guaranteed since both the MPC protocol and the fairreconstruction protocol enjoy this property, while fairness is guaranteed by the reconstruction protocol: dishonest parties can only obtain  ( 1 , . . .,   ) +  for an unknown random value  through the (unfair) MPC protocol, and are thus unable to obtain any information related to the actual output  ( 1 , . . .,   ).At this point, reconstructing the actual output is equivalent to reconstructing the masking value , and the fairness property of the reconstruction protocol assures fairness of the complete secure computation.This high-level intuition is therefore quite general in nature; in particular, it is not per se specific to the SPDZ protocol.
However, the actual construction described in this article uses particular aspects of the SPDZ protocol for improved efficiency.More precisely, recall that the fair-reconstruction protocol is given by a share conversion from an additive -out-of- sharing to a Shamir sharing.This conversion needs some additional security mechanisms to guarantee correctness; in our case, this is achieved by reusing security mechanisms from SPDZ.Therefore, instantiating the MPC protocol and the fair-reconstruction protocol separately would actually incur in some redundancy, since some operations that are necessary to achieve correctness would need to be executed twice.In order to gain efficiency, we instead execute them only once during the execution of SPDZ, and feed the values produced by them to the fair-reconstruction protocol.Moreover, we use another important efficiency aspect of SPDZ, namely its division into a preprocessing phase (independent of the computation inputs) and a very efficient 'online' phase, by executing some of the operations of the fair-reconstruction protocol during the preprocessing phase.
These adaptations result in a very efficient construction, which nicely adheres to the design principles of SPDZ.However, they also imply that the two components of our construction (an MPC protocol offering security with abort, and a fair-reconstruction protocol) can no longer be seen as two generic black-box components.

Organization
The paper is organized as follows.In Section 2 the required background knowledge and notation are described.Section 3 presents the fair SPDZ protocol by introducing a new reveal phase, accompanied with a complexity analysis.Section 4 analyses the practical performance of both the non-fair and fair protocol, by evaluating their running time and bandwidth usage.Section 5 provides the formal security statement of our construction, with complete proof found in Appendix A. Finally, conclusions are drawn in Section 6.

PRELIMINARIES
This section provides the background information which is necessary for our construction.Table 2 explains the meaning of the main variables that we use.

Security Setting
Several assumptions are made about the security setting in which our scheme, including the online phase of the SPDZ protocol, operates.The set of  participants P is partitioned in two nonoverlapping sets: the set of ℎ honest participants H and the set of  actively corrupt participants A. The adversary is the central entity that controls the participants in A. Since the proposed design is hybrid-secure in the number of corrupted participants, different corruption thresholds are assumed in different settings.To be precise, we achieve security with abort for  < , while we can guarantee fairness with  < /2.We therefore assume that  > 2, since otherwise fairness cannot be achieved.Since our design extends the SPDZ-2 protocol [19], several assumptions are inherited.First, the adversary is computationally bounded.Second, the adversary is static, i.e. the adversary determines which parties to corrupt before the protocol starts.Finally, it is assumed that the participants have access to a complete synchronous point-to-point communication network, i.e. the communication between participants is private and authenticated, and messages sent by an honest participant cannot be arbitrarily delayed by the adversary.
It must be noted that the different preprocessing phases for SPDZ operate in various security settings (covert/active, ... ).We assume that the preprocessing phase securely generates all necessary data for the online phase under the aforementioned assumptions.

Protocol building blocks
The pseudorandom generator U  (, ) is a deterministic function that extends a seed  to a list of  pseudo-random elements in the field F  , as defined in [19].Furthermore, we assume parties have access to a cryptographic hash function H 1 , which is modeled as a random oracle [19].
2.2.1 Shamir's secret-sharing scheme.Shamir's secret-sharing scheme [40] is a powerful secret-sharing scheme that operates over a finite field.We will only discuss this scheme over the finite field F  , where  is prime. 1 A (, )-sharing of secret  indicates that the secret  is split into  shares, of which  are needed to reconstruct the secret  again.The complete Shamir sharing of  is denoted by  (), while the Shamir share of participant   ∈ P is denoted by  ()  .In order to share a secret value , a random ( − 1)-degree polynomial  is sampled, such that  is the constant term, and  unique non-zero points on this polynomial are computed, which act as the shares.In our scheme, the point (,  ()) is always given to participant   .
The secret value  can be reconstructed by interpolating the polynomial  .Following Lagrange's interpolation theory, we know that it is always possible to interpolate a ( − 1)-degree polynomial using  points.To reconstruct from any set of  points ( 1 ,  ( 1 )), ... , (  ,  (  )) we use Lagrange's interpolation formula, albeit in a different form, which allows us to precisely formulate the required number of operations to reconstruct the polynomial  (Section 3.3).The polynomial is calculated as , which is a linear combination of the Shamir shares and reconstruction coefficients (1) 0 ... ,  () −1 .These coefficients are calculated as follows: where  =  −  − 1.The weighting terms  (1) , ... ,  () are calculated as Once the polynomial  is interpolated, it is verified that the remaining points ( +1 ,  ( +1 )), ... , (  ,  (  )) also lie on  .Since  and  (1) , ... ,  () are constant for the same  1 , ... ,   , the secret  can be efficiently constructed, when these constants have been precomputed.
We refer to the complete interpolation as Reconstruct, while only reconstructing the secret value using precomputed weighting terms and coefficients is referred to as EffReconstruct.

Broadcast.
The Broadcast protocol is used to let participants communicate a message to all other participants, while ensuring consistency of the received messages.Notice that we only describe a situation where all participants are required to broadcast a message simultaneously, and that a weak form of broadcast, offering security with selective abort, will be enough for our purposes.We formally model the required broadcasting functionality in F Broadcast (Funct.3; a formal definition is provided in Appendix C).We write Broadcast( (1) , . . .,  () ) to denote the parties jointly running an instance of the broadcast functionality F Broadcast , where party   broadcasts  () .
In the random-oracle model, this functionality can be implemented as follows: Each participant   ∈ P begins by communicating their message  () plus a broadcast message to all other participants.Subsequently, each participant calculates the hash H 1 (), where  =  (1) ∥ ... ∥  () , and communicates this hash to all other participants.Finally, each participant compares the received hashes to their own, ensuring that each participant received the same messages (or outputs ⊥). 1 The reason for this will become clear in Protocol 4.
In the random oracle model, the functionality can be instantiated as follows.First, each participant   ∈ P runs Commit  () , which generates an  from the output range of hash function H 1 , and returns the tuple  () ,  () = H 1  () ∥  ,  () ∥  .The commitments  (1) , ... ,  () are broadcast, preventing anyone from claiming an input ξ ≠ .Once all commitments are received, the participants broadcast the opening information  (1) , ... ,  () .To verify the correctness of the commitments, the function Open  () ,  ()   is executed for   ∈ P, i.e. it is verified whether 2.2.4 F Continue .We further need a protocol that allows the honest parties to agree whether to continue with the protocol execution before opening the blinding values; this functionality has to satisfy security with unanimous abort in the honest-majority case.We formalize this notion in F Continue (Funct.5; a formal definition is provided in Appendix C).This functionality can be instantiated with protocols for detectable byzantine agreement (which in fact satisfies a stronger notion of fairness, both in the honest and dishonest majority case).By [22] detectable byzantine agreement can be achieved unconditionally for any number of corruptions  < .

An Overview of SPDZ-2
The protocol introduced in [19], referred to as SPDZ-2, is a general multi-party computation protocol that guarantees security with abort against up to  − 1 active corrupt participants, while still providing efficient function evaluation.A key factor for achieving this efficiency is the separation of the protocol into a preprocessing and online phase.In the time-consuming preprocessing phase, the participants generate shared randomness.Subsequently, in the online phase, the output of a given function  is computed by evaluating a circuit over the inputs of the participants.In this phase, the shared randomness is consumed to efficiently perform certain operations, such as sharing input data, and multiplying and squaring intermediate (secret) values.The preprocessing phase can be run before the function  and the inputs are known (only an upper bound on the number of inputs and on the different types of gates of  , expressed as a circuit, is needed).Other protocols have been proposed to generate shared randomness more efficiently, such as the MASCOT, LowGear, HighGear and TopGear protocols [3,31,32].Privacy is achieved by additively secret-sharing each value throughout the circuit.An additively secret-shared value  is denoted as ⟦⟧, where each participant   ∈ P holds share   and the sum of the shares of the participants  =1   is equal to  in F  .Correctness is guaranteed by adding an additively secret-shared MAC-tag to each value throughout the circuit.The MAC-tag of a value , denoted as  (), is equal to  • , where  is the secret MAC-key.This MAC-key  is additively secret-shared itself.Each secret-shared value throughout the circuit therefore consists of the additive sharings of the value and the corresponding MAC-tag, referred to as a ⟨•⟩-sharing, where ⟨•⟩ = (⟦•⟧ , ⟦ (•)⟧).The participants can partially open a ⟨•⟩-sharing by opening the shares of its underlying ⟦•⟧-sharing.This process, known as PartialOpen, consists of two steps.First, the participants  1 , . . .,   send their additive shares to a designated participant -say,  1 .Second,  1 calculates the sum of the respective shares and distributes these to the participants  2 , . . .,   .
On several occasions the participants receive unverified values; to make this situation clear, we add a tilde symbol to such a value, obtaining e.g.ã.The MAC-Check protocol, formalized in Protocol 1, is used to determine whether any number of  unverified partially-opened values are correctly ⟨•⟩-shared.Assuming  > 1, the participants start by calculating a random linear combination over the unverified partially opened values ã(1) , . . ., ã() to obtain a single value ã =  =1  () • ã() , given the jointly generated random values  (1) , ... ,  () .A similar random linear combination is calculated over the MAC-tags, resulting in ⟦ ()⟧ =  =1  () •   () .Subsequently, the participants recalculate the MAC-tag over the value ã and subtract it from the original MAC-tag  (), resulting in ⟨⟩.Afterwards, the participants securely open the ⟦⟧-sharing, and verify whether it equals zero.If so, the original MAC-tag and the recalculated MAC-tag were equal, guaranteeing that the values ã(1) , ... , ã() were correctly ⟨•⟩-shared.If not, the protocol returns the abort message ⊥, resulting in the fact that ⊥ is broadcast to all participants, who then immediately abort the protocol.
At the end of the online phase, once the circuit is evaluated and the output sharings  (1) , ... ,  () have been calculated, the reveal phase is initialized.The standard, 'non-fair' reveal phase is formalized in Protocol 2. This reveal phase starts by verifying whether the computation has been performed correctly.This is guaranteed by verifying whether all earlier  partially opened values were correctly ⟨•⟩-shared, using the MAC-Check protocol.Afterwards, the participants partially open the ℓ output sharings  (1) , ... ,  (ℓ) , which are also verified using the MAC-Check protocol.
It can now be seen that it is quite simple for the adversary to obtain the correct output(s), while preventing the honest participants from doing so.Namely, the adversary can instruct the dishonest participants to correctly execute the protocol up until the last step, meaning that all parties do obtain correct sharings  (1) , ... ,  (ℓ) of the output values.At this point, these values will be partially opened, and hence the values  (1) , . . .,  (ℓ) become public, and subsequently, the MAC-Check protocol is executed in order to confirm their correctness.Now the dishonest participants can simply cheat during the execution of MAC-Check (e.g., by sending incorrect values   ), hence leading the protocol to fail: this means that honest participants will not accept  (1) , . . .,  (ℓ) as the correct output values, and will therefore be left with no output.On the other hand, the adversary knows that these values were actually correctly computed, and that it was only their correctness check that was improperly executed; the adversary thus obtains these (correct) values as output.

PROPOSED SCHEME 3.1 Overview
Our scheme extends all SPDZ-based protocols with the fairness security guarantee in the presence of an honest majority.This is achieved by the introduction of a novel reveal phase, which is consistent between SPDZ-based protocols, and fairly opens the output values.
To guarantee fairness, our scheme transforms the (, )-sharings of the output values into (⌈/2⌉, )-sharings.Such ( ⌈/2⌉, )sharings guarantee fairness in an honest majority setting (where the number of honest participants is equal to, or larger than, the reconstruction threshold).
The (⌈/2⌉, )-sharings use Shamir's secret-sharing scheme, since this scheme has a variable reconstruction threshold, operates on prime fields, and allows for linear operations.The latter two characteristics are needed to efficiently transform the SPDZsharings to Shamir sharings (Section 3.2.1)and to prove consistency between these sharings (Section 3.2.2),respectively.
of the output, and only depend on the number of output values.
As a result, these data do not reveal any information on the reconstructed output values, except its count.Once the Shamir shares are opened, the validation data enable a participant to determine whether a Shamir sharing is correct and consistent, without requiring additional communication.
To optimize the practical performance of the scheme, the transformation from additive sharings to Shamir sharings, and the generation of validation data, are moved to the preprocessing phase.This approach minimizes the increase in running time of the low-latency online phase, whose efficiency is one of the main advantages of SPDZ-based protocols.
The resulting reveal phase, formalized in Protocol 3, operates as follows.First, all partially opened values are verified (Step 1a), just as in the non-fair reveal phase (Protocol 2).Second, blinding sharings, i.e. random SPDZ sharings, are added to the output SPDZ sharings (Step 2a).These blinded output SPDZ-sharings are then opened and verified to be correct (Steps 2b-2c); notice that this check remains secure even in the presence of a dishonest majority, i.e., it will fail if the value is incorrect.After this step, the MAC-check plays no further role: once the hidden output SPDZ-sharings are verified, the actual output values can be calculated by subtracting the aforementioned random SPDZ-sharings from the hidden output SPDZ-sharings.Since these random SPDZ-sharings have been transformed in the preprocessing phase to Shamir sharings, these values can be reconstructed by publishing the Shamir sharings; since the ( ⌈/2⌉, ) Shamir sharings can be fairly opened in the presence of an honest majority, the output values are fairly opened in this setting.Therefore, the protocol ends by reconstructing the random secrets from the Shamir sharings (Step 3a) and subtracting these from the verified hidden output values (Step 3b).The results are the output values, given that the reconstructed random secrets from the Shamir sharings are consistent with the secrets in the random SPDZ-sharings.
Protocol 3 FairOutputs: Fair opening of output values.

Design of the Proposed Scheme
This section formalizes the protocols that transform SPDZ-sharings into Shamir sharings, generate the corresponding validation data, and verify opened Shamir shares based on the validation data.

Transformation of Sharings
. SPDZ-sharings can efficiently be transformed to Shamir sharings by leveraging the linearity of Shamir's secret-sharing scheme.Protocol 4 formalizes the transformation of ℓ + 1 sharings. 2Transforming a single SPDZ-sharing consists of two major operations.First, each participant creates a (⌈/2⌉, ) Shamir sharing of their additive SPDZ-share and distributes this among the participants (Step 1).Second, each participant sums their  received Shamir shares (Step 2).The resulting Shamir shares can be used to reconstruct the same secret as their corresponding SPDZ-shares when all participants follow the protocol.
(2) Combining Shamir shares The participants calculate the Shamir sharing  b =  =1  b .

Generating Validation Data.
The validation data are generated using a Commit-Challenge-Response approach.The complete process is formalized in Protocol 5. First, each participant commits to their unverified Shamir shares by broadcasting a commitment (Step 1a-1b).Second, the participants securely generate a random seed, using the SecureOpen protocol (Step 2a-2c).This seed is used to generate the challenge (Step 2d), i.e. a list of random elements, from the pseudo-random generator U  (, ℓ + 1) (Section 2.2).Third, each participant calculates their response, which equals the random linear combination of their Shamir shares, where the coefficients are the aforementioned list of random elements (Step 3a).Subsequently, the resulting Shamir sharing of the secret value  is securely opened and  is reconstructed (Step 3b-3c).
The MAC-Check protocol is used to verify that  is consistent between the Shamir sharing and the SPDZ-sharing (Step 3d-3f). 3 The validation data consist of the commitments to the Shamir shares, the list of random elements, and the published Shamir sharing of .Intuitively, the commitments and random elements reveal no information about the random secret values, which is important as they are used to hide the output values in the reveal phase.Moreover, one of the ℓ + 1 secret values, used to calculated , is 'sacrificed', i.e. unused.This is necessary to prevent information on the blinding values to be prematurely leaked, while checking the consistency of the SPDZ-and Shamir-shares.

Verifying Shamir sharings.
The opening of the Shamir sharings is formalized in Protocol 6.Once the sharings are opened, the generated validation data are used to determine whether they are consistent with the SPDZ-sharings they originate from.Whenever published Shamir shares of a participant are inconsistent with the validation data, the participant is identified as a cheater and their 3 This trick enables us to verify a Shamir sharing with the MAC-data of a SPDZ-sharing.

The protocol:
(1) Commit phase shares are discarded.This process repeats until the protocol is either finished, or until there are insufficient 'non-cheating' shares remaining.
The verification process consists of two steps.First, the participants open and verify the commitments to the Shamir shares (Step 1-2b).Second, the participants recalculate the linear combination of the opened Shamir shares, and compare these to the earlier published Shamir shares (Step 2c).If these checks succeed, and there are sufficient 'non-cheating' Shamir shares, the remaining Shamir shares are used to reconstruct the secret values (Step 3).
Protocol 6 FairBlinds: Fair Opening of Blinding Values.

Complexity of the Proposed Scheme
In this section the communication and computational complexities of the proposed scheme are analyzed.The difference in complexity compared to 'standard', non-fair SPDZ is discussed, in order to provide a thorough understanding of the overhead associated with guaranteeing fairness.Furthermore, a distinction is made between the complexities of the online phase and the preprocessing phase.The complexities are formalized for the number of participants , the reconstruction threshold  = ⌈/2⌉, the number of output values ℓ, the prime  (recall that operations are performed on F  ), the hash size  and the number of partially opened values .The additional complexity introduced by our scheme does not depend on the depth of the circuit, number of inputs, nor the amount of consumed randomness.All complexities are formalized for a single participant.
Throughout this section, it is assumed that the participants have access to sufficiently many random SPDZ-sharings. 4.3.1 Communication Complexity.The communication complexity is analyzed in terms of the number of communication rounds and the average number of bits that are sent by a participant.To simplify this analysis, only the case where the number of output values is larger than one will be discussed; furthermore, we also exclude the cost of the functionality F Continue for simplicity.
The communication complexity of the 'standard', non-fair reveal phase is formalized in Table 3.The majority of the communication rounds are the result of performing the MAC-Check protocol (Step 1a and Step 2b).The majority of the number of sent bits is a result of partially opening the output values (Step 2a), when the number of output values ℓ is large.
Table 3: Communication complexity of the non-fair reveal phase (excluding F Continue ).

Step
Rounds Sent bits Online: Protocol 2 Step 1a 4 2 The communication complexity of the fair design is formalized in Table 4.The total increase in the number of communication rounds, compared to the 'standard', non-fair reveal phase, is primarily due to generating the validation data (Protocol 5).This protocol performs Broadcast once (Step 1b) and SecureOpen three times (Steps 2b, 3b and 3f), either directly or indirectly, all requiring two communication rounds.Besides this, our design only adds one communication round in Protocol 4, and two communication rounds in Protocol 6.The majority of the increase in sent bits originates from broadcasting ℓ + 1 elements (Protocol 4, Step 1 and Protocol 6, Step 1), for a large number of output values.
When focusing on the online phase, the increase in communication complexity is relatively modest.The number of communication rounds increases from 10 to 12, while the number of sent bits increases from roughly 2/ •  to (1 + 2/) •  , where  = ( − 1) • ℓ • ⌈log 2 ()⌉, for a large number of output values.

Computational
Complexity.The computational complexity is analyzed in terms of the number of values to be hashed, random elements to be generated, and field operations to be performed.The different input and/or output sizes of such hashes and random elements are ignored, effectively assuming a constant cost.Moreover, for simplicity sake, only the case where the number of partially opened values and output values are larger than one is discussed, and we exclude the cost of the functionality F Continue .Step Rounds Sent bits Preprocessing: Protocol 4 Step 1 1 Step 1b 2 2 Step 1 2 The computational complexity of the non-fair reveal phase is shown in Table 5.Since both Step 1a and Step 2b are calls to the MAC-Check protocol, they result in a similar complexity.Within each call to the MAC-Check protocol, the SecureOpen protocol is run twice, requiring 2 hashes.The generated random values in these steps are used to calculate linear combinations over the partially opened values.The number of additions in Step 2a is multiplied by 1/, since only one of the  participants sums the opened output values, which are then redistributed.
In Table 6 the computational complexity of our scheme is formalized.The hashes in Protocol 5, Steps 2b, 3b, 3f, and Protocol 3, Steps 1a and 2c, are computed during calls to the SecureOpen protocol, either directly or indirectly.The hashes computed in Steps 1 and 2b are used in the Broadcast and Open functions respectively.The additional random elements are primarily generated for the random coefficients when transforming the SPDZ-sharings to Shamir sharings (Protocol 4, Step 1) and the random elements for calculating the random linear combinations of the secret values.When focusing on the online phase, the number of hashes increases from 4 to 5, while the number of random values remains the same.
Another noteworthy operation is the Reconstruct function (Protocol 5, Step 3c).First, the  weighting terms  (1) , ... ,  () are calculated, each requiring  − 1 subtractions,  − 2 multiplications and one division.Second, the  2 base coefficients  ( )  , 0 ≤  < , 1 ≤  ≤ , are calculated.To calculate all  possible values of ,  + 1 subtractions are required.The first term requires  − 1 multiplications, since  has  possible values.The last term can be efficiently computed by pre-computing the 2  −  − 1 (singletons and empty set excluded) multiplicative subsets of  1 , ... ,   , which can be realized in 2  −  − 1 multiplications.Adding the respective multiplicative subsets requires an additional 2  −  − 1 additions.To combine the three terms, each base coefficient requires two multiplications for a total of 2 2 multiplications.
Once the base coefficients have been calculated, any polynomial can be efficiently reconstructed from a Shamir sharing with ( + 1) • ( − 1) additions and  2 multiplications.After the polynomial is interpolated, it is determined whether the other ⌊/2⌋ points also lie on this polynomial, requiring  − 1 additions and  multiplications each, assuming that  2 , ... ,  −1 , for 2 ≤  ≤ , have been stored.
In the online phase, each reconstruction only costs  multiplications and  − 1 additions (Protocol 6, Step 3), since only the constant term needs to be reconstructed, and the base coefficients have already been pre-computed.
When  ≫ ℓ and  ≫ , i.e., the number of operations that consume shared randomness is much greater than the number of outputs values and the number of participants, 5 both the fair and the non-fair reveal phase require roughly  random values, 2 additions and 2 multiplications.

PERFORMANCE AND IMPLEMENTATION
In this section we aim to analyze the overhead of guaranteeing fairness for SPDZ-based protocols by benchmarking, and comparing the fair and non-fair reveal phase.To provide an honest comparison between the two, both are implemented in Python. 6Moreover, a practical function is evaluated using the SPDZ protocol, providing insight in the total overhead introduced by our scheme.The benchmarks are based on the existing MobileNet V1 0.25_128 neural network implementation [16], where one participant inputs an image and another participant inputs the trained network.Our implementation uses the MP-SPDZ framework [30] with the LowGear preprocessing phase and TopGear zero-knowledge proof of knowledge. 7Due to space constraints, only the results on the total performance overhead are presented here; for an in-depth analysis of the overhead of the reveal phase, the reader can refer to Appendix D.
All benchmarks are performed on a 6-core AMD Ryzen 5 3600 with 12 threads.Each participant is run in a separate docker container with access to two threads, providing consistent computing power for varying numbers of participants. 8We define a LAN setting, where the traffic between the participants is unhindered, and the WAN setting, where all traffic is delayed by 50 ms and the bandwidth of the participants is restricted to 50 Mbit/s, as used before in [31,32].Finally, we differentiate between the running data of the offline phase, i.e. preprocessing phase, and the online phase.All data are the result of averaging a hundred protocol runs, unless stated otherwise.
To analyze the total overhead introduced by guaranteeing fairness, the MobileNet V1 0.25_128 neural network is evaluated using Table 5: Required additional field operations for the original reveal phase (excluding F Continue ).

Position Hashes Random Value Addition Subtraction Multiplication Division
Online: Protocol 2 Step 1a 2 Table 6: Required additional field operations for the proposed design (excluding F Continue ).

Position Hashes Random Value Addition Subtraction Multiplication Division
Preprocessing: Step 1a 1 Step 1 both the standard and fair reveal phase, presented in Table 7.The standard run-time data are obtained by evaluating the neural network using the MP-SPDZ framework.The fair run-time data are equal to the standard run-time data, increased with the cost of generating the required number of random SPDZ-sharings for our scheme and the overhead introduced by fairly opening the output values.The run-time data of the offline phase are obtained from one function evaluation, due to its long running time.Table 7 clearly indicates that the amount of sent data increases at a negligible rate (< 0.005%), for both the offline and online phase and for varying numbers of participants.Moreover, the running time of the offline phase only increases marginally (< 1%), primarily due to the cost of generating additional random SPDZ-sharings.

FULL PROTOCOL AND SIMULATION-BASED SECURITY
In this section we provide the full protocol description (Protocol 7) and give the outline of the formal security guarantees that our protocol satisfies: security with selective abort against up to  − 1 malicious participants, and fairness against < /2 malicious participants.We provide a stand-alone simulation-based proof in the synchronous model, namely we show that our scheme is indistinguishable from the ideal functionality provided by F Online (Functionality 1) assuming synchronous point-to-point communication channels.
With this, the major part of the online protocol (Protocol 7) is a procedure to fairly open the blinding values  (1) , . . .,  (ℓ) , given authenticated blinding values  (1) , . . .,  (ℓ+1) (where the additional value  (ℓ+1) is sacrificed in Protocol 5 to ensure that the conversion to Shamir shares was performed correctly).
In Appendix A.4 we prove the main security theorem.
F Online (Funct.1) in the (F Broadcast , F SecureOpen , F BlindOnline )hybrid model with computational security against any static malicious adversary corrupting up to  − 1 parties.Functionality 1 F Online .
Parameters.Let  be a super-polynomial prime and F = F  be the finite field of size .Let C be an arithmetic circuit over F with  input gates id 1 , . . ., id  and ℓ output gates.Let further each input gate id  be uniquely associated with a party   .Corrupted parties.Let A denote the set of parties corrupted by the adversary.Input phase: On input Input,   , id  ,  from party   (potentially controlled by the adversary) proceed as follows: ( (1) If no input has been registered for an input gate of C, return ⊥ to all parties and to the adversary and exit.

CONCLUSION AND FUTURE WORK
We introduced an adaptation of SPDZ and similar MPC platforms to overcome the lack of fairness, where we additionally blinded the MPC outputs, and fairly revealed the blinding values.
We implemented the adaptation and benchmarked practical performance, to find that the run-time for guaranteeing fairness takes less than one percent in the preprocessing phase, and roughly 0.02% in the online phase.W.r.t.communication, the increase in the amount of sent data is less than 0.005% for both the preprocessing and online phase.Furthermore, the additional work is less than linear in the number of parties and in the number of output values.
To conclude, we found a way to make SPDZ, and implementations thereof, such as MP-SPDZ and SCALE-MAMBA, fair at a negligible cost.For future work, other MPC platforms building on authenticated secret sharing could similarly be made fair, and the scheme might be extended with cheater detection by leveraging the formalized method to detect invalid Shamir shares.Moreover, although we only provide a security proof in the stand-alone model, this does not directly imply that our solution becomes insecure Functionality 2 F BlindOnline .
Communicate  (1) , . . .,  (ℓ) to all parties in  and ⊥ to all other parties.By default, the functionality ignores any unexpected input, and aborts sending ⊥ to all parties if the adversary fails to respond on any of the queries.
when concurrently executed: we actually expect the resulting protocol to be secure, although a dedicated security proof would be needed.An interesting direction for future work would be providing such a proof.
• Perfect hiding: For all  ∈ N and for all adversaries A, it holds: , where we require that A returns valid messages  0 ,  1 ∈ .• Computational binding: For all PPT adversaries A, there exists a negligible function negl : N → R ≥0 , such that for all  ∈ N: where we require that A returns valid messages  0 ,  1 ∈ .
• Perfect trapdoor: For all  ∈ N and for all adversaries A it holds: , where we require that A returns valid messages  0 ,  1 ∈ .
Note that one can instantiate the above trapdoor commitment schemes via Pedersen commitments [39].Alternatively, one can obtain the required trapdoor commitment schemes in the (programmable) random oracle model: Let  : {0, 1} * → {0, 1}  be modeled as a random oracle.Then, a commitment scheme can be defined as follows: • Com on input of a message  ∈ {0, 1} * draws

C IDEAL FUNCTIONALITIES USED IN OUR CONSTRUCTION
This section provides a formal description of some of the building blocks of our construction: namely, the (weak) broadcast functionality, the simultaneous revealing of elements held by participants, and the agreement functionality used by participants in order to decide whether to open the blinding values or not.We begin with the broadcast functionality (Funct.3), which provides consistency, but with selective abort.Functionality 3 F Broadcast .
Corrupted parties.Let A denote the set of parties corrupted by the adversary.Broadcast phase: (1) For all   ∉ A receive (Broadcast,  () ) from party   .
We then present the secure-opening functionality (Funct.4), that allows participants to simultaneously reveal given values, hence preventing the adversary from adjusting their values based on the ones communicated by honest participants.Functionality 4 F SecureOpen .
Finally, we present the functionality (Funct.5) that allows (honest) participants to agree on whether to proceed with a given step of the protocol (in our case, revealing the blinding values) or not.This functionality has to satisfy security with unanimous abort in the honest majority case, as otherwise the adversary can force some honest parties to abort, while it can use the information from the remaining parties to reconstruct the result, thereby violating fairness.

D IN-DEPTH ANALYSIS OF THE IMPLEMENTATION PERFORMANCE OF THE REVEAL PHASE
In Table 8 the running times for both the standard and fair reveal phases are presented in the LAN and WAN setting, where applicable.
To more accurately analyze the overhead introduced by our scheme the computation verification is excluded from the online phase, as it is the same for both protocols.The increase in running time is less than one-to-one with respect to the number of output values, since e.g. the run times for 1000 Communicate ok to all parties in  and ⊥ to all other parties.
output values are less than double of the respective times for 500 output values.The offline times are roughly equal to the corresponding online times for our fair design.This shows that the separation between the preprocessing and online phase significantly reduces the running time of the online phase.As a result, the online phase only requires a couple of milliseconds of overhead when fairly opening a low number of output values.
Our design is significantly faster in the LAN setting than the WAN setting, as expected.Since the offline and online phase require 9 and 8 rounds, excluding the computation verification, respectively, their running times increase with around 450ms and 400ms, respectively.The additional increase in run-time is due to the bandwidth restriction in the WAN setting.This additional delay increases for both a larger number of output values and participants, as both increase the required amount of sent data.

Table 1 :
Comparison of most closely related work, excluding results based on trusted set-up assumptions.

Table 2
(, ) generator on seed  of  pseudorandom F  -elements F  finite field of prime order   () Shamir secret-sharing of   ()  Shamir share of participant   Shamir reconstruction threshold  () weight of -th share during reconstruction  () commitment of participant   () opening information of participant   size of hash output (for broadcasts, commitments) ⟦⟧ additive secret-sharing of    additive share of participant   () MAC-tag of value   secret MAC-key ( () =  • ) ⟨•⟩ sharing consisting of ⟦•⟧ and ⟦ (•)⟧  number of unverified partially-opened values ã() -th unverified partially-opened value ã random linear combination of the ã() -s  difference between MAC-tag of ã and original  ()  () -th output value ℓ the number of output values  random value masking the output  blinded output value ( =  + )

Table 4 :
Communication complexity of the proposed design (excluding F Continue ).

Table 8 :
Running times of the different reveal phases excluding the computation verification in milliseconds.