Eﬃcient Secure Multiparty Computation with Identiﬁable Abort

. We study secure multiparty computation (MPC) in the dishonest majority setting providing security with identiﬁable abort, where if the protocol aborts, the honest parties can agree upon the identity of a corrupt party. All known constructions that achieve this notion require expensive zero-knowledge techniques to obtain active security, so are not practical. In this work, we present the ﬁrst eﬃcient MPC protocol with identiﬁable abort. Our protocol has an information-theoretic online phase with message complexity O ( n 2 ) for each secure multiplication (where n is the number of parties), similar to the BDOZ protocol (Bendlin et al., Eurocrypt 2011), and a factor in the security parameter lower than the identiﬁable abort protocol of Ishai et al. (Crypto 2014). A key component of our protocol is a linearly homomorphic information-theoretic signature scheme, for which we provide the ﬁrst deﬁnitions and construction based on a previous non-homomorphic scheme. We then show how to implement the preprocessing for our protocol using somewhat homomorphic encryption, similarly to the SPDZ protocol (Damg˚ard et al., Crypto 2012) and other recent works with applicable eﬃciency improvements.


Introduction
Multiparty Computation (MPC) deals with the problem of jointly computing a function among a set of mutually distrusting parties with some security guarantees such as correctness of the output and privacy of the input.MPC has been an interesting topic in cryptography for the last 30 years, but while in the past efficiency was the main bottleneck and MPC was exclusively the subject of academic studies, the situation has steadily improved and now even large circuits can be evaluated with acceptable costs in terms of time and space.A key example of this progress is the recent line of work that began with the BDOZ [BDOZ11] and SPDZ [DPSZ12,DKL + 13] protocols.These protocols are based on a secret-sharing approach and can provide active security against a dishonest majority, where any number of the parties may be corrupt.
The SPDZ-style protocols work in the preprocessing model (or offline/online setting), with an offline phase that generates random correlated data independent of the parties' inputs and the function, and an online phase, in which this correlated randomness is used to perform the actual computation.The key advantage of the preprocessing model in SPDZ lies in the efficiency of the online phase, which only uses information-theoretic techniques.
It is a well-known fact that, in the dishonest majority setting, successful termination of protocols cannot be guaranteed, so these protocols simply abort if cheating is detected.It was also shown by Cleve in [Cle86] that, unless an honest majority is assumed, it is impossible to obtain protocols for MPC that provide fairness and guaranteed output delivery.Fairness is a very desirable property and intuitively means that either every party receives the output, or else no-one does.
In this scenario SPDZ-style protocols, and in general all known efficient MPC protocols that allow dishonest majority, are vulnerable to Denial-of-Service attacks, where one or more dishonest parties can force the protocol to abort, so that honest parties never learn the output.They can even do this after learning the output, whilst remaining anonymous to the honest parties, which could be a serious security issue in some applications.This motivates the notion of MPC with identifiable abort (ID-MPC) [CL14,IOZ14].Protocols with identifiable abort either terminate, in which case all parties receive the output of the computation, or abort, such that all honest parties agree on the identity of at least one corrupt party.It is clear that, while this property neither guarantees fairness nor output delivery (as it does not prevent a corrupt party from aborting the protocol by refusing to send messages) at the same time it discourages this kind of behaviour because, upon abort, at least one corrupt party will be detected and can be excluded from future computations.
Why Efficient ID-MPC is not Trivial.It is easy to see that the SPDZ protocol is not ID-MPC: Each party holds an additive share x i of each value x and similarly an additive share m(x) i of an information-theoretic MAC on x.To open a share, all parties first provide their shares of both the value and the MAC, and then check validity of the MAC.A dishonest party P i can make the protocol abort by sending a share x * i = x i or m(x) * i = m(x) i .However, since the underlying value x is authenticated, and not the individual shares, P i is neither committed to x i nor m(x) i , so other parties cannot identify who caused the abort.At first glance, it seems that the [BDOZ11] protocol might satisfy identifiable abort.In this protocol, instead of authenticating x, pairwise MACs are set up so that each party holds a MAC on every other party's share.However, the following counterexample (similar to [Sey12,Sec. 3.6]), depicted in Fig. 1, shows that this is not sufficient.
Let the adversary control parties P 1 and P 2 .P 1 sends the correct value x 1 to both remaining parties P 3 , P 4 , but only the correct MAC m(x 1 ) 3 to P 3 .To P 4 , he sends an incorrect MAC m(x 1 ) * 4 .
P 1 (Abort, P 1 ) x 2 m(x 2 ) * 3 Fig. 1.Counterexample for identifiable abort with pairwise MACs Conversely, P 2 will send the incorrect MAC m(x 2 ) * 3 of his share x 2 to P 3 and the correct m(x 2 ) 4 to P 4 .Now both honest parties P 3 , P 4 can agree that some cheating happened, but as they do not agree on the identity of the corrupt party they are unable to reliably convince each other who cheated.(Note that a corrupt party could also decide to output (Abort, P 3 ), confusing matters even further for the honest P 2 , P 3 .)We conclude that, with an approach based on secret-sharing, special care must be taken so that all honest parties can agree upon the correctness of an opened value.
Our Contributions.In this work we present an efficient MPC protocol in the preprocessing model that reactively computes arithmetic circuits over a finite field, providing security with identifiable abort against up to n − 1 out of n malicious parties.The online phase relies only on efficient, information-theoretic primitives and a broadcast channel, with roughly the same complexity as the BDOZ protocol [BDOZ11].The offline phase, which generates correlated randomness, can be instantiated using somewhat homomorphic encryption based on ring-LWE, and allows use of all the relevant optimisations presented in [DPSZ12,DKL + 13,BDTZ16].
A first building block towards achieving this goal is our definition of homomorphic informationtheoretic signatures (HITS).Information-theoretic signature schemes [CR91] cannot have a public verification key (since otherwise an unbounded adversary can easily forge messages), but instead each party holds a private verification key.The main security properties of IT signatures are unforgeability and consistency, meaning that no-one can produce a signature that verifies by one honest party but is rejected by another.Swanson and Stinson [SS11] were the first to formally study and provide security proofs for IT signatures, and demonstrated that many subtle issues can arise in definitions.On the other hand, homomorphic signature schemes [BFKW09,CJL09] feature an additional homomorphic evaluation algorithm, which allows certain functions to be applied to signatures.The verification algorithm is then given a signature, a message m and a description of a function f , and verifies that m is the output of f , applied to some previously signed inputs.We give the first definition of HITS, and the first construction of HITS for affine functions, which is based on the (non-homomorphic) construction from [HSZI00] (proven secure in [SS11]), and has essentially the same complexity.
Our definition of HITS is slightly different to [SS11], as we only consider a single, honest signer, instead of allowing any user to sign messages.This simplifies the definitions, but requires taking some additional care in proving the consistency property, which in our case is no longer implied by unforgeability.
We then show how to build ID-MPC in the preprocessing model, based on any HITS with some extra basic properties.Our basic protocol is similar to the online phase of SPDZ and BDOZ, based on a correlated randomness setup that produces random shared multiplication triples, authenticated using HITS with an unknown signing key.The downside of this approach is the need for a secure broadcast channel in every round of the protocol.Since broadcast with up to n−1 corrupted parties requires Ω(n) rounds of communication1 [GKKO07] (assuming a PKI setup), this leads to a round complexity of Ω(n • D), for depth D arithmetic circuits, and a message complexity of Ω(n 3 ) field elements per multiplication gate.We show that the number of broadcast rounds can be reduced to just two -and the total number of rounds to O(n + D) -by using an insecure broadcast for each multiplication gate, and then verifying the insecure broadcasts at the end of the protocol in a single round of authenticated broadcast.Additionally, by batching the signature verification at the end of the protocol, we can reduce the message complexity per multiplication to O(n 2 ).Overall, this gives on online phase that is only around n times slower than the SPDZ protocol, or similar to BDOZ.
In addition, we present a preprocessing protocol that uses somewhat homomorphic encryption to compute the correlated randomness needed for the online phase of our protocol, obtaining security with identifiable abort.The method for creating multiplication triples is essentially the same as [DPSZ12], but creating the additional HITS data is more complex.
In Section 8, we present a simple modification of our ID-MPC scheme that implies public verifiability: In the ID-MPC setting, the honest parties agree upon which party is corrupt, but they are not able to convince anyone outside of the computation of this fact.We sketch how our scheme can be modified so that this in fact is possible, using a public bulletin board.In 9, we present an information-theoretic MPC protocol in the preprocessing model that is optimised for a different range of field sizes and which is related to the MiniMACS protocol [DZ13].This MPC protocol also uses HITS but can tolerate lower security guarantees than our main protocol.
Comparison to Existing Work.The model of identifiable abort was first explicitly defined in the context of covert security, by Aumann and Lindell [AL10].Cohen and Lindell [CL14] considered the relationships between broadcast, fairness and identifiable abort, and showed that an MPC protocol with identifiable abort can be used to construct secure broadcast.The classic GMW protocol [GMW87] (and many protocols based on this) satisfies the ID-MPC property, but is highly impractical due to the non-black box use of cryptographic primitives.
The most relevant previous work is by Ishai et al. [IOZ14], who formally studied constructing identifiable abort, and presented a general compiler that transforms any semi-honest MPC protocol in the preprocessing model into a protocol with identifiable abort against malicious adversaries.Their protocol is information-theoretic, and makes use of the 'MPC-in-the-head' technique of Ishai et al. [IKOS07] for proving the correctness of each message in zero-knowledge.Although recent work by Giacomelli et al. [GMO16] shows that this technique can be efficient for certain applications, we show that when applied to ID-MPC as in [IOZ14], the resulting protocol is around O(σ) times less efficient than ours, to achieve soundness error 2 −σ .Note that Ishai et al. also use IT signatures for authenticating values, similarly to our usage, but without the homomorphic property that allows our protocol to be efficient.For the preprocessing stage, they describe an elegant transformation that converts any protocol for implementing any correlated randomness setup in the OT-hybrid model into one with identifiable abort, which makes black-box use of an OT protocol.Again, unfortunately this method is not particularly practical, mainly because it requires the OT protocol to be secure against an adaptive adversary, which is much harder to achieve than statically secure OT [LZ13].
Several other works have used similar primitives to information-theoretic signatures for various applications.In [CDD + 99], a primitive called IC signatures is used for adaptively secure multiparty computation.These are very similar to what we use and their construction is linearly homomorphic, but the opening stage requires every party to broadcast values, whereas in our HITS only the sender broadcasts a message.Moreover, IC signatures are required to handle the case of a corrupted dealer (which we do not need, due to trusted preprocessing), and this leads to further inefficiencies.In [IOS12], a unanimously identifiable commitment scheme is presented, which is used to construct identifiable secret sharing; this has similarities to a simplified form of IC signatures, but is not linear.
Finally, we note that when the number of parties is constant, it is possible to achieve a relaxed notion of fairness, called partial fairness, in the dishonest majority setting by allowing a nonnegligible distinguishing probability by the environment [BLOO11].
Organisation.In Section 2, we describe the model and some basic preliminaries, and also discuss the need for and use of a broadcast channel in our protocols.Section 3 introduces the definition of homomorphic information-theoretic signatures, and Section 4 describes our construction.Our information-theoretic ID-MPC protocol in the preprocessing model is presented in Section 5, followed by the preprocessing using SHE in Section 6.In Section 7 we evaluate the efficiency of our protocols, compared with the previous state of the art.In Section 8 we show how to upgrade the security of our ID-MPC protocol to be publicly verifiable by an external party, and we give an ID-MPC construction over small fields in Section 9.

Notation
Throughout this work, we denote by κ and λ the statistical, resp.computational, security parameters, and we use the standard definition of negligible (denoted by negl(κ)) and overwhelming function from [Gol01].We use bold lower case letters for vectors, i.e. v and refer to the ith element of a vector v as v| i .The notation x ← S will be used for the uniform sampling of x from a set S, and by [n] we mean the set {1, . . ., n}.The n parties in the protocol are denoted as P = {P 1 , . . ., P n }, while the adversary is denoted by A, and has control over a subset I ⊂ [n] of the parties.We also sometimes let P denote the index set [n], depending on the context.

Model
We prove our protocols secure in the universal composability (UC) model of Canetti [Can01], with which we assume the reader has some familiarity.Our protocols assume a single static, active adversary, who can corrupt up to n − 1 parties at the beginning of the execution of a protocol, forcing them to behave in an arbitrary manner.We assume a synchronous communication model, where messages are sent in rounds, and a rushing adversary, who in each round, may receive the honest parties' messages before submitting theirs.
We use the UC definition of MPC with identifiable abort, or ID-MPC, from Ishai et al. [IOZ14].Given any UC functionality F, define F ID ⊥ to be the functionality with the same behaviour as F, except that at any time the adversary may send a special command (Abort, P i ), where i ∈ I, which causes F ID ⊥ to output (Abort, P i ) to all parties.Definition 1 ( [IOZ14]).Let F be a functionality and F ID ⊥ the corresponding functionality with identifiable abort.A protocol Π securely realises F with identifiable abort if Π securely realises the functionality As noted in [IOZ14], the UC composition theorem [Can01] naturally extends to security with identifiable abort, provided that the higher-level protocol always respects the abort behaviour of any hybrid functionalities.

Broadcast Channel
Our protocols require use of a secure broadcast channel.Since Cohen and Lindell showed that MPC with identifiable abort can be used to construct a broadcast channel [CL14], and it is well known that secure broadcast is possible if and only if there are fewer than n/3 corrupted parties, it is not surprising that we require this (the protocols in [IOZ14] require the same).
In practice, we suggest the broadcast primitive is implemented using authenticated broadcast, which exists for any number of corrupted parties, assuming a PKI setup.For example, the classic protocol of Dolev and Strong [DS83] uses digital signatures to achieve this, and Pfitzmann and Waidner [PW92] extended this method to the information-theoretic setting.Both of these protocols have complexity O( n2 ) when broadcasting -bit messages.Hirt and Raykov [HR14] presented a protocol that reduces the communication cost to O( n) when is large enough.We are not aware of any works analysing the practicality of these protocols, so we suggest this as an important direction for future research.

Homomorphic Information-Theoretic Signatures
In this section, we define the notion of homomorphic information-theoretic signatures (HITS).It differs slightly from standard cryptographic signatures: First and foremost, in the informationtheoretic setting, a signature 2 scheme must have a distinct, private verification key for each verifying party.This is because we define security against computationally unbounded adversaries, hence a verifier could otherwise easily forge signatures.Secondly, allowing homomorphic evaluation of signatures requires taking some additional care in the definitions.To prevent an adversary from exploiting the homomorphism to produce arbitrary related signatures, the verification algorithm must be given a function, and then verifies that the signed message is a valid output of the function on some previously signed messages.
With this in mind, our definition therefore combines elements from the IT signature definition of Swanson and Stinson [SS11], and (computational) homomorphic signature definitions such as [BFKW09,CJL09,GVW15].
Definition 2 (Homomorphic Information-Theoretic Signature).A homomorphic informationtheoretic signature (HITS) scheme for the set of verifiers P = {P 1 , . . ., P n }, function class F and message space M, consists of a tuple of algorithms (Gen, Sign, Ver, Eval) that satisfy the following properties: (sk, vk) ← Gen(1 κ , w) takes as input the (statistical) security parameter κ and an upper bound w ∈ N on the number of signatures that may be created, and outputs the signing key sk and vector of the parties' (private) verification keys, vk = (vk 1 , . . ., vk n ).
σ ← Sign(m, sk) is a deterministic algorithm that takes as input a message m ∈ M and signing key sk, and outputs a signature σ.
0/1 ← Ver(m, σ, f, vk j ) takes as input a message m, a signature σ, a function f and P j 's verification key vk j , and checks that m is the valid, signed output of f .
Remark 1. HITS schemes can generally be defined to operate over data sets.Multiple data sets can be handled by tagging each dataset with a unique identifier and restricting operations to apply only to signatures with the same tag.However, for our application we only require a single dataset, which simplifies the definition.
Remark 2. To streamline the definition even more, we consider a setting where there is only one signer, who is honest.This leads to a definition that is conceptually simpler than the IT signature definition of Swanson and Stinson [SS11], which considers a group of users who can all sign and verify each others' messages.
Unforgeability: Let I [n] be an index set of corrupted verifiers, and define the following game between a challenger C and an adversary A: 1. C computes (sk, vk) ← Gen(1 κ , w) and sends {vk i } i∈I to the adversary.2. A may query C adaptively up to a maximum of w times for signatures.Let m 1 , . . ., m w be the list of messages queried to C.
A scheme is unforgeable if for any subset of corrupted verifiers I [n] and for any adversary A, Consistency: The security game for consistency is identical to the unforgeability game, except for the final step (the winning condition), which becomes: Ver(m * , σ * , f, vk i ) = 1 and Ver(m * , σ * , f, vk j ) = 0.
A scheme satisfies consistency if for any set I [n] and for any A playing the above modified game, Note that evaluation correctness implies signing correctness, but we state two separate properties for clarity.The consistency (or transferability) property guarantees that a corrupted party cannot create a signature σ that will be accepted by one (honest) verifier but rejected by another.In [SS11], a reduction from consistency to unforgeability is given.However, their definition of IT signatures considers a group of users who are all signers and verifiers, any of whom may be corrupted.In our setting, there is a single, honest signer, so consistency is no longer implied and must be defined separately.
Additionally, we require that signatures output by the Eval algorithm do not reveal any information on the input messages m 1 , . . ., m other than that given by f (m 1 , . . ., m ).This is similar to the concept of context hiding [GVW15] in the computational setting, and is captured by the following definition.
Definition 4 (Evaluation privacy).A HITS scheme (Gen, Sign, Eval, Ver) is evaluation private if there exists a PPT algorithm Sim that, for every (sk, vk) ← Gen, for every function f ∈ F, for all messages m 1 , . . ., m with m = f (m 1 , . . ., m ), Intuitively, this means that any valid signature that comes from Eval can also be computed without knowing the original inputs to f , so is independent of these.This definition is simpler than that of [GVW15], as our signing algorithm is restricted to be deterministic, so we require equality rather than an indistinguishability-based notion.

Construction of HITS
We now describe our construction of homomorphic information-theoretic signatures.The message space M is a finite field F. We restrict the function class F to be the set of all affine transformations f : F w → F (where w is the maximum number of signatures that can be produced).The general case of affine functions with fewer than w inputs can be handled by using a default value, ⊥, for the unused input variables.Note also that the signing algorithm is stateful, and must keep track of how many messages have been signed previously.

Sign(m, sk):
To sign the i-th message, m, (for i ≤ w) the signer computes the vector The new signature σ is obtained by evaluating f , excluding the constant term, over every component of the input signatures: Ver(m, σ, f, vk j ): First use f to compute the additional verification data Then check that where σ| r indicates the rth component of σ.If the check passes output 1, otherwise 0.
Theorem 1.Let κ ∈ N be the security parameter, F be a finite field.Moreover, define M := F and F be the the set of affine maps from F w to F, then the tuple of algorithms (Gen, Sign, Eval, Ver) is a (w, 2/|F|)-secure HITS with evaluation privacy.

Security of Theorem 1
Proof (of Theorem 1).We prove that our construction satisfies all the properties required for a HITS (Definitions 3 and 4).
Signing and evaluation correctness.Signing correctness is implied by evaluation correctness for f = π i , so we show the latter.Let w, n ∈ N + and j ∈ [n] be arbitrarily chosen.Moreover, let (sk, vk) ← Gen(1 κ , w), take arbitrary (m 1 , ..., m w ) ∈ M w and let f ∈ F be defined by f (m 1 , ..., m w ) = w i=1 µ i • m i + c, for some µ 1 , ..., µ w , c ∈ F. Applying the Sign algorithm for i = 1, . . ., w, we obtain Using these signatures and f , Eval then computes σ f = w i=1 µ i • σ i .The verification algorithm will compute and the algorithm will output 1.
Unforgeability.Before we start proving the unforgeability and consistency of the scheme, we prove a bound on the adversary's uncertainty about sk.In particular, we show that there are always at least |F| vectors (α 1 , ..., α n ) that are consistent with the adversary's view, and all are equally likely.
Lemma 1.Let I [n] be an index set of corrupted verifiers, and define the following game between a challenger C and an adversary A: 1. C samples (sk, vk) ← Gen(1 κ , w) and sends {vk j } j∈I to the adversary.2. A may query C adaptively up to a maximum of w times for signatures.3. A outputs (α 1 , . . ., α n ).
Proof.In Step 1 of the game, A obtains

It then in
Step 2 provides messages m 1 , ..., m w ∈ F and obtains .
Collect all of A's information about the αr , βi,r into a system of linear equations.For simplicity, consider the setting where w = 1 and I = {1, ..., n − 1}.We obtain The system has 3n − 2 equations but only 2n variables.Fortunately the matrix on the left is not full-rank: Assuming m = 0, the first n − 1 rows can be used to obtain the next n − 1 rows using the last n rows, so we can safely remove them. 4If m = 0, then the n leftmost columns are 0 for the last 2n − 1 rows, out of which at most n can be linearly independent.Therefore, the matrix has rank at most 2n−1 for 2n unknowns and A cannot recover the correct sk.Instead, by fixing a certain α i there exists at least one (α 1 , . . ., α n ) compatible with this choice.The same applies in the case of w signatures where A will obtain a matrix with (w + 1) • n − 1 independent rows, but has to solve for (w + 1) • n unknown values.Since all the αi were chosen uniformly at random each such choice of α i yields a candidate vector that is equally likely.
In the definition of the unforgeability game, A chooses a function f by fixing µ 1 , ..., µ l , c.It is easy to see that the choice of c does not make any difference, so assume that c = 0 for simplicity.Let m i 1 , . . ., m i l be the messages queried to C and σ i 1 , . . ., σ i l the responses.We conclude that, for all j ∈ [n] \ I, the equation with must hold due to evaluation correctness.Now A picks m * ∈ F such that m * = f (m i 1 , ..., m i l ) and a signature σ * , and assume for the sake of contradiction that A wins the game with probability p > 1/|F|.Then holds for some j ∈ [n] \ I.We can subtract (2) from (1) and obtain A can make Equation 3 hold by either providing the trivial solution or another vector in the kernel of the map.In Lemma 1 we established that the view of A contains at least |F| candidates for (α 1 , ..., αn ), all of which being equally likely.Therefore, finding the trivial solution with probability > 1/|F| contradicts Lemma 1.On the other hand, by the rank nullity theorem, the linear map induced by the right-hand side of (3) has a kernel of dimension n − 1.All v j,1 , ..., v j,n were chosen uniformly at random and are unknown by A, so Equation (3) will hold with probability Consistency.Assume that A can break consistency with probability p > 1/|F|.By definition of the game, it must then hold that at least one of , which contradicts the winning condition.
First suppose that m * = f (m 1 , ..., m l ), so σ * = l k=1 µ k • σ i k .Then by the winning condition, it must hold that for at least one j ∈ [n] \ I. Suppose at least one of the values x 1 , ..., x n is non-zero.Then due to the random choice of the v j,r the above sum will only be 0 with probability at most 1/|F| (as in the Unforgeability proof).Thus, it must hold that x 1 = x 2 = ... = x n = 0 and therefore Hence for every r it must hold that which contradicts the assumption.We therefore observe that the cheating probability in this case can be bounded by 1/|F|.Consider the case where m * = f (m i 1 , ..., m i l ), then the setting equals the Unforgeability game for which we upper-bounded the success of A as 1/|F| as well.Hence the overall probability if Evaluation privacy.Let (sk, vk) ← Gen(1 κ , w) and f : F l → F be any linear map defined by: Suppose m = f (m 1 , . . ., m l ) for some messages m 1 , . . ., m l ∈ M. Then the algorithm Sim, when given sk, m, f , creates a signature on m, f as follows: 2. Output σ * .Now let σ i ← Sign(sk, m i ), for i ∈ [l], and σ = Eval(f, σ 1 , ..., σ l ).Note that m − c = i µ i • m i , and then we have, for all r ∈ [n],

Lower Bounds on IT Signatures
After the first impractical unconditionally secure signature scheme proposed by Chaum et al. [CR91], there have been many attempts to modify unconditionally secure authentication codes (A-codes) adding to them the extra security properties required by signature schemes.The relation between A-codes and unconditionally secure signatures have been extensively studied by Safavi-Naini et al. [SMY04].A particular interesting extension of A-codes is given by multi-receiver authentication codes (MRA), introduced by Desmedt et al. [DFY92].
Roughly, a MRA-code consists of three sets of participants, a trusted authority (TA), a single honest sender (S) and a set of receivers (R 1 , . . ., R n ).The TA generates secret information s and r 1 , . . .r n for S and R 1 , . . ., R n , respectively.In order to send a message m to R 1 , . . ., R n , S generates an authenticated message (m, τ ) by using the secret s, and then transmits it to the receivers.Each receiver R i can individually verify the authenticity of the received message using their private key r i .
An ( , t, n)-MRA-code is a multi-receiver authentication code where n is the number of receivers, and for which the probability of success for up to t colluding corrupt receivers is .The formal security definition for MRA-codes considers two types of attacks: -A substitution attack, in which an adversary substitutes an authenticated message (m, τ ) with a different message (m * , τ * ) while m = m * .
-An impersonation attack, in which an adversary creates a new message (m * , τ * ) without seeing any messages from the sender.
Information theoretic bounds on the success probability of attacks and combinatorial bounds on the sizes of the key and code spaces are given in [SW99,Sim85].We can use these bounds to have a measure of the efficiency of our HITS construction.It is indeed possible to prove that HITS satisfies all the conditions for an MRA-code, but with stronger cryptographic properties like consistency, non-repudiation and evaluation privacy.
Proposition 1.Let SG, SK and VK be the domains of the signatures, signing and verification keys, respectively.Our HITS has the following memory sizes: In terms of the memory size of signatures, our scheme is n-bits close to the bound of optimal MRA-codes.This follows from the fact that our definition of unforgeability implies security against substitution and impersonation attacks, and from Theorem 3.5 in [SW99] Note that the scheme of [SS11], which is not homomorphic, requires the same memory size as HITS for signatures and signing keys, but slightly smaller verification keys (|F| n(w+2)−1 ).We do not know if the signature schemes described in [SS11] and our HITS are optimal in terms of the memory size of the keys, or if the need for larger verification keys in HITS is due to the homomorphic property of the scheme.

Online Phase for Efficient MPC with Identifiable Abort
In this section we describe our information-theoretic protocol for secure multiparty computation with identifiable abort in the preprocessing model.We assume a set of n parties {P 1 , . . ., P n }, and any HITS scheme HITS = (Gen, Sign, Eval, Ver) that satisfies (w, negl(κ))-security and evaluation privacy from Section 3, and supports homomorphic evaluation of linear functions over a message space of a finite field F.
Our protocol performs reactive computation of arithmetic circuits over F, using correlated randomness from a preprocessing setup, similarly to the BDOZ and SPDZ protocols [BDOZ11,DPSZ12].Correctness, privacy and identifiable abort are guaranteed by the security properties of HITS.The functionality that we implement is F MPC , shown in Fig. 2. Note that F MPC already contains an explicit command for identifiable abort in the output stage, since it models an unfair execution where the adversary can abort after learning the output.The modified functionality F MPC ID ⊥ then extends this abort to be possible at any time.Input: On input (Input, Pi, id , x) from Pi and (Input, Pi, id ) from all other parties, with id a fresh identifier and x ∈ F, store (id , x).
Output: On input (Output, id ) from all parties (where id is present in memory), retrieve (id , y) and send y to the adversary.Wait for the adversary to input either Deliver or (Abort, Pi) for some i ∈ I.If the adversary sends Deliver then output y to all honest parties, otherwise output (Abort, Pi).Authenticated secret sharing.Our protocol is based on authenticated additive secret sharing over the finite field F, and we use the following notation to represent a shared value a: where party P i holds a i ∈ F and σ a i = Sign(a i , sk), such that i∈P a i = a.
By the linearity of the secret sharing scheme and HITS we can easily define addition of two shares, z = x + y , as follows: Note that if σ x i , σ y i are already outputs of the Eval algorithm, then f should instead be defined to include the linear function that was applied to these inputs previously, and Eval applied to those inputs.However, this is just a technicality and in practice, each homomorphic addition can be computed on-the-fly.We can also define addition or multiplication of shared values by constants, using Eval in a similar way.5 Open( a ): 1. Every party Pi ∈ P broadcasts (ai, σa i ).
2. Each party Pi runs Ver(aj, σa j , f, vki), for each j = i.If for some j the check fails, Pi outputs (Abort, Pj), otherwise it outputs a = P i∈P ai.In Fig. 3 we define the basic subprotocol used to open authenticated, shared values.Each time the command Open is called, parties check the correctness of the opened value using the Ver algorithm.For each share, the intuition is that if the corresponding signature is verified, then the share is correct with overwhelming probability due to the unforgeability of the scheme; on the contrary, if there exists an index j ∈ P \ I, where I denotes the set of corrupt parties, for which the check does not go through, then the same happens for all honest parties, due to the consistency of HITS.
Preprocessing requirements.The preprocessing functionality, F Prep , is shown in Fig. 4. It generates a set of HITS keys (sk, vk) and gives each party a verification key, whilst no-one learns the signing key.The functionality then computes two kinds of authenticated data, using sk: -Input tuples: Random shared values r , such that one party, P i , knows r.This is used so that P i can provide input in the online phase.
- Note that corrupted parties can always choose their own shares of authenticated values, instead of obtaining random shares from the functionality.
Protocol.Our protocol, shown in Fig. 5, is based on the idea of securely evaluating the circuit gate by gate in a shared fashion, using the linearity of the • -representation for computing all linear gates, preprocessed multiplication triples for multiplication using Beaver's technique [Bea91], and preprocessed input tuples for the inputs.

Security
Theorem 2. In the F Prep -hybrid model, the protocol Π Online implements F MPC ID ⊥ with statistical security against any static active adversary corrupting up to n − 1 parties.

Protocol Π Online
Let nM be the number of secure multiplications to be performed and nI the total number of inputs.
Input: For party Pi to input x ∈ F, the parties call F Prep with (Input, Pi) to obtain a mask value r , and Pi also obtains r: 1. Pi sets m = r − x and broadcasts m.
2. All parties locally compute x = r − m.
Add: On input ( x , y ), parties locally compute x + y = x + y .
Multiply: On input ( x , y ), the parties do the following: 1.Take one multiplication triple ( a , b , c ) from Output: To output a share y , the parties call Open( y ).If for some i ∈ P the check fails, output (Abort, i) and halt, otherwise accept y as a valid output.

Fig. 5. Operations for Secure Function Evaluation with Identifiable Abort
Proof.Let A be a malicious PPT real adversary attacking the protocol Π Online , we construct an ideal adversary S with access to F MPC which simulates a real execution of Π Online with A such that no environment Z can distinguish the ideal process with S and F MPC from a real execution of Π Online with A. S starts by invoking a copy of A and running a simulated interaction of A with Z.
After describing the simulator we will argue indistinguishability of the real and ideal worlds.Let I be the index set of corrupt parties, simulation proceeds as follows: Simulating the Initialise step.The simulator S honestly emulates F Prep towards the adversary A. Note that S knows all the data given to the adversary and the simulated signing key sk * of HITS, so can generate a valid signature for any message.
Simulating the Input step.We distinguish two cases: -For i ∈ P \ I, S emulates towards A a broadcast of a random value m ∈ F, and proceeds according to the protocol with the next simulated random input tuple, r.Thereafter, S computes x = r − m and stores x, the dummy, random input for honest P i .-For i ∈ I, S receives from the adversary the message m, and retrieves the next random input tuple r.It then computes x = r − m and inputs it to the F MPC ID ⊥ .
Simulating the Circuit Evaluation.For linear gates, the simulator does not have to simulate any message on the behalf of the honest parties.S updates the internal shares and calls the respective procedure in F MPC ID ⊥ .In a multiplication gate, for each call to Open, S receives all the corrupt shares (t * j , σ t * j ) from A, and computes and sends the shares and signatures for the dummy honest parties as in the protocol.Let (t j , σ t j ) be the values that S expects from the dishonest P j , based on previous computations and the simulated preprocessing data.S checks for all the (t * j , σ t * j ) received from A and for all i ∈ P \ I that t j = t * j and σ t j = σ t * j .If the check does not pass for some j ∈ I then S sends (Abort, P j ) to F MPC ID ⊥ .Otherwise it proceeds. 66 If there is more than invalid share then we always abort with the smallest index where the check fails.
Simulating the Output step.The simulator sends (Output) to the functionality and gets the result y back.Let y be the output value that the simulator has computed using dummy, random inputs on behalf of the honest parties.Then it picks an honest party P i 0 , and modifies its share as y * i 0 = y i 0 + (y − y ), then uses the evaluation privacy algorithm to compute σ y * i 0 = Sim(sk * , y * i 0 , f ), where f is the same linear function that has been applied to obtain σ y i 0 , and sends the honest shares and signatures to the adversary.It then receives (y * j , σ y * j ) j∈I from the adversary, while expecting y j , σ y j .If y j = y * j and σ y j = σ y * j for all j ∈ I then S sends Deliver to the functionality; otherwise it sends (Abort, P j ) for the lowest j that failed and halts.
Indistinguishability. Now we prove that the all the simulated transcripts and the honest parties' outputs are identically distributed to the real transcripts and output in the view of the environment Z, except with probability negl(κ).
During initialisation, the simulator honestly runs an internal copy of F Prep , so the simulation of this step is perfect.In the input step, the values m broadcast by honest parties are uniformly random in both cases, as they are masked by a one-time uniformly random value from F Prep that is unknown to Z.
In the multiplication step, the parties call the command Open.Honest shares and signatures are simulated as in the protocol, using the simulated data from the emulation of F Prep , and applying the Eval algorithm.The broadcast shares are all uniformly distributed in both worlds, as the shares are always masked by fresh random values from F Prep , so are perfectly indistinguishable.To argue indistinguishability of the signatures, we need to use the evaluation privacy property.We must prove that i , where {σ t * i } i ∈I are the simulated ideal-world signatures, and {σ t i } i ∈I are the real-world signatures, for some honest parties' shares {t i } i / ∈I .Since σ t i and σ t * i are both valid signatures output from Eval, evaluation privacy guarantees that there exists an algorithm Sim such that: where g is the linear function evaluated to get the values t i and t * i , and sk and sk * are respectively the real-world and ideal-world secret keys.Since (t i , sk) and (t * i , sk * ) are identically distributed in both the executions, then the same holds for σ t i and σ t * i .Note that it is crucial here that S computes σ t * i using Eval and the function g, rather than creating a fresh signature using sk * , otherwise indistinguishability would not hold.
We also must consider the abort behaviour of the Open procedure in the two worlds.If during any opening, A attempts to open a fake value then it will always be caught in the simulation, whereas it succeeds if it is able to forge a corresponding signature in the real protocol.Hence, if the ideal protocol aborts with the identity of some corrupt party P i , then the same happens in the real world, except with negligible probability due to unforgeability.The consistency property of HITS ensures that if one honest party outputs (Abort, P i ) in the protocol, then all the honest parties will output the same, except with negligible probability.Now, if the real or simulated protocol proceeds to the last step, Z observes the output value y, and the corresponding honest parties' shares, together with their signatures.The honest shares are consistent with y and the signatures are correctly generated in both worlds.Again, to argue indistinguishability of the signatures we can use the evaluation privacy property of HITS.Hence Z's view of the honest parties' messages in the last step has the same distribution in the real and hybrid execution.
Finally, we must argue indistinguishability of the outputs in both worlds.In the ideal world, the output y is a correct evaluation on the inputs, so the only way the environment can distinguish is to produce an incorrect output in the real world.This can only happen if a corrupt party sending an incorrect share that is successfully verified.However, as we have seen before, if the adversary attempts to open a fake value, during the input, multiplication or output step, then it will be caught with overwhelming probability, by the unforgeability and consistency properties of HITS.

An Optimised Protocol
When instantiated with our HITS scheme from Section 4, the online phase protocol above requires O(n 2 ) field elements to be broadcasted per secure multiplication.Since each authenticated broadcast requires O(n) rounds, this gives a communication complexity of at least O(n 3 ) field elements per multiplication and O(D • n) rounds overall, where D is the multiplicative depth of the arithmetic circuit.We now describe an optimised variant of our protocol, which reduces the number of rounds to O(D + n) and the communication cost per multiplication to O(n 2 ).
Reducing the Number of Broadcasts.Let Π bc be the UC protocol for authenticated broadcast used in the protocol.We make the following assumption about its structure: in the first round of Π bc , the sender (with input x) sends x, and nothing more, to all parties.7 Let the remainder of the protocol be denoted Π bc .
We now modify the protocol Π Online so that whenever a party P i is supposed to broadcast a value x i in the Open subprotocol, P i instead sends x i to all parties, and appends x i to a list B i .Note that the Input stage still requires broadcast, as otherwise it seems difficult for the simulator to extract a corrupted party's input.The Output stage is then modified so that first, each party runs Π bc (B i ) to complete the broadcasts that were initialised in the previous rounds.With this change, there are only two broadcast rounds and each multiplication gate requires just one round of communication, reducing the overall number of rounds to O(D + n).
Batching the Signature Verification.We can reduce the number of field elements sent during a multiplication to n − 1 per party by checking all signatures together in the Output stage of the protocol, rather than during the circuit evaluation.This means that during the computation, the parties only send shares without the corresponding signatures.We then check a random linear combination of each parties' signatures just before every output stage.
The complete protocol for the optimised output stage is given in Fig. 6.Since there are only two authenticated broadcast rounds, the number of rounds for computing a depth D circuit with one output gate in the optimised protocol is O(D + n).The total number of field elements sent over the network is no more than8 where n I is the total number of private inputs, n M the number of secure multiplications and bc(m) the cost of broadcasting m elements using Π bc .Meanwhile, the storage cost (for the preprocessing data) is O(n(n M + n I )) per party.
Protocol Output( y ) Let Bi be the list of shares sent by a party Pi in all input and multiplication steps since the last Output invocation.
OutputCheck: Run the following, for each party Pi: 1. Pi sends the share yi to all other parties, and appends yi to Bi.
Output: Each party computes y = P n i=1 yi and outputs y.

Security
We now argue security of the new online protocol, describing the key differences compared with the previous protocol.In the simulation, the simulator S now cannot determine whether a corrupt party has sent the correct message during the Multiply command, since the signatures are not sent here.Instead, this must be detected in the output stage when the broadcasts and signatures are checked.
In the OutputCheck stage, S first calls the functionality F MPC ID ⊥ to obtain the result y, then adjusts one honest party's share and signature (using the evaluation privacy algorithm) to fix the correct output as before, and sends the honest shares to the adversary.For the remainder of this stage, the simulator acts as in the protocol for the honest parties, computing the random linear combination of signatures using Eval, and then runs the simulator of Π bc for each broadcast.If any broadcast fails for a corrupt sender P j then S sends (Abort, P j ) to F MPC ID ⊥ .If all broadcasts succeed, S checks the signatures and sends (Abort, P j ) if the signature of P j does not verify.Note that an incorrect broadcast can lead to an honest party's signature being incorrect, so it is important that the broadcasts are checked first here.
Indistinguishability of all shares sent up until the Output stage follows from uniformity of the preprocessing data, as in the previous protocol.The security of the Π bc simulator guarantees indistinguishability of step 5, in particular that all parties agree upon the sets of shares B i that were sent by each party P i during the protocol.
If the broadcasts succeed then the honest parties' signatures will always be correctly generated, and the evaluation privacy property of HITS guarantees they are identically distributed.The environment therefore can only distinguish between the worlds by causing the output, y, to be incorrect.Suppose a corrupt party P i broadcasts the values B i = (a 1 , . . ., a t ) in the protocol, and a j = a j for at least one j, where a j is the original signed value that P i was supposed to send.Then if the verification in step 5 of the output stage succeeds, the correctness and security properties of HITS guarantee that: It is easy to see that the probability of this check passing is 1/|F|, as the values r i are unknown to the adversary at the time of choosing a i , so the check prevents an incorrect output with overwhelming probability.

Preprocessing with Identifiable Abort
This section describes a practical protocol for securely implementing F Prep with identifiable abort, based on somewhat homomorphic encryption.The protocol is based on the SPDZ preprocessing [DPSZ12,DKL + 13], but the cost is around n 2 times higher due to the larger amount of preprocessing data needed for the HITS data in our online phase.
We first explain in more detail why the generic preprocessing method of Ishai et al. [IOZ14] does not lead to an efficient protocol.They presented a method to transform any protocol for a correlated randomness setup in the OT-hybrid model into a protocol that is secure with identifiable abort.Although their compiled protocol only requires black-box use of an OT protocol, it is impractical for a number of reasons: -The protocol to be compiled is assumed to consist only of calls to an ideal OT functionality and a broadcast channel.This means that any pairwise communication must be performed via the OT functionality and so is very expensive.-The transformation requires first computing an authenticated secret sharing of the required output, and then opening this to get the output.In our case, the output of F Prep is already secret shared and authenticated, so intuitively, this step seems unnecessary.-Their security proof requires the underlying OT protocol to be adaptively secure.This is much harder to achieve in practice, and rules out the use of efficient OT extensions [LZ13].

Prep
The F Prep functionality from Section 5 is completely black-box with respect to the HITS scheme used.In this section, we implement preprocessing specifically for the scheme HITS from Section 4. We also make one small modification to the initialisation of F Prep , shown in Fig. 8, which simplifies our preprocessing protocol by not requiring the adversary's verification data, v j , to be uniformly random.The following proposition shows that the scheme, and therefore online phase, remain secure with this modification.
On input (Init, nM , nI ) from all parties, set w = n • (nM + nI ) and do the following: 1. Wait for the adversary to input vj ∈ F n , for each j ∈ I.
2. Compute (sk, vk) ← HITS.Gen(1 κ , w), except using the provided values {vj}j∈I to compute {vkj}j∈I, instead of sampling fresh values.3. Send vki to party Pi and store sk.Proof.This easily follows by inspection of the scheme.Notice that the signing and verification algorithms for honest parties are independent of the values {v j } j∈I , so changing the distribution of these cannot cause an honest party to accept an invalid signature or reject a valid signature.
We now show how to use somewhat homomorphic encryption scheme to perform the preprocessing with identifiable abort.

SHE Scheme Requirements
As in SPDZ, we use a threshold somewhat homomorphic encryption scheme SHE = (Gen, Enc, Dec, , ) to generate the preprocessing data.The scheme must have a message space of F, and we represent ciphertexts known to all parties with the notation x = Enc(x).The binary operators , then guarantee that x + y = x y and x • y = x y , for some suitable choice of randomness in the output ciphertexts.For our purposes, these homomorphic operations only need to support evaluation of circuits with polynomially many additions and multiplicative depth 1.As was shown in [DPSZ12,DKL + 13], a ring-LWE variant of the BGV scheme [BGV12] is practical for this purpose, and this also allows homomorphic operations to be batched for greater efficiency.
In addition, we require the following interactive protocols that will be used for the preprocessing.
Zero Knowledge Proof of Plaintext Knowledge.A protocol Π ZKPoK , which is a public-coin zeroknowledge proof of knowledge of the message and randomness that makes up a ciphertext.When used in our preprocessing protocol, all parties will sample the public verifier's messages with a coin-tossing functionality F Rand (see Fig. 7), so that the proofs are verified by all parties.
Distributed Key Generation and Decryption.The distributed key generation protocol outputs a public key to all parties, and an additively shared secret key.The distributed decryption protocol then allows the parties to decrypt a public ciphertext so that all parties obtain the output.These requirements are modelled in the functionality F KeyGenDec (Fig. 9).To achieve security with identifiable abort in our preprocessing protocol, note that the distributed decryption method modelled in F KeyGenDec always outputs a correct decryption, unlike the method in SPDZ [DPSZ12], which allows a corrupted party to introduce additive errors into the output.The SPDZ method can easily be modified to achieve this, by including a zero-knowledge proof, similar to the Π ZKPoK proof used for ciphertext generation.Efficient ZK proofs for actively secure LWE-based key generation and distributed decryption were also given in [AJL + 12], which can be adapted to the ring-LWE setting.to all parties, where m may be a valid message or an invalid ciphertext symbol, ⊥.
Fig. 9. SHE distributed key generation and decryption functionality

Basic Subprotocols
In Fig. 10 we describe some basic subprotocols for generating and decrypting ciphertexts.The RandShCtxt subprotocol creates n public ciphertexts encrypting uniformly random shares, where each party holds one share.The ShareDec subprotocol takes a public ciphertext m , encrypting m, and performs distributed decryption in such a way that each party learns only a random, additive share of m.If the flag new ctxt is set to 1 then ShareDec additionally outputs a fresh encryption of the message m to all parties.This is used to ensure that SHE only needs to evaluate circuits of multiplicative depth 1.The PrivateDec subprotocol is another variant of distributed decryption that decrypts the ciphertext x to only P i .Note that the private decryption protocol used in [DPSZ12] is not suitable here, as it involves parties all sending a single message to P j ; in the identifiable abort setting, this would allow P j to claim that an honest party P i sent an invalid message, as the messages are not verifiable by all parties.To get around this, our PrivateDec protocol only uses broadcasted messages that are verifiable by all parties using the public-coin zero-knowledge proofs.

Creating the Preprocessing Data
The complete preprocessing protocol is shown in Fig. 11 and Fig. 12.To create a multiplication triple, each party must obtain random, additive shares (a i , b i , c i ) such that c = a•b, along with signatures on these shares.Creating shares of triples is essentially identical to the method in [DPSZ12], except we use the correct distributed decryption command of F KeyGenDec , instead of a possibly faulty method.This means that there is no way the adversary can introduce errors into triples, so we avoid the need for the pairwise sacrificing procedure from [DPSZ12], where half of the triples are wasted to check correctness.The main other difference in our protocol, compared to [DPSZ12], Input(Pi): Creates a random, authenticated value r , where r is known to Pi. 1. Run RandShCtxt to obtain additive shares rj, and public ciphertexts rj that encrypt these shares, for j ∈ [n]. 2. Run Auth(rj, rj , Pj) for every j ∈ [n] to obtain r .

Comput r = r1
• • • rn and run PrivateDec( r , Pi) so that Pi learns r.The simulator S first generates an SHE key pair (pk, SHE.sk) ← SHE.Gen(1 λ ) and sends pk to all parties.Simulate the rest of the setup phase by honestly following the protocol, until it comes to the final stage of simulating calls to F KeyGenDec .PrivateDec, to decrypt the verification keys.At this point, use the SHE key sk to decrypt the adversary's ciphertexts containing the verification data v j for j ∈ I, and send these to ⊥ the remaining verification data α j , {β j,i } i∈[w] and send this to the adversary, simulating the output of F KeyGenDec .PrivateDec in step 6.
Simulating the triple and input generation protocols (and their subroutines) proceeds similarly: the simulator sends ciphertexts on behalf of honest parties as in the protocol, and decrypts the adversary's ciphertexts containing shares of triples a i , b i and sends these to F * Prep , along with the shares of c i that are extracted from ciphertexts received in the ShareDec procedure.In response, the simulator receives from F * Prep signatures on all corrupted parties' shares, and uses these to simulate the final calls to F KeyGenDec .Π PubDec during the Auth subroutine.
To ensure security with identifiable abort, we require that if at any stage during the simulation, a proof of correct ciphertext generation (Π ZKPoK ) fails for P j where j ∈ I, then S sends (Abort, P j ) to F * Prep ID ⊥ and halts.Since Π ZKPoK is the only place in which the protocol can abort, we do not need to consider identifiable abort elsewhere.
Indistinguishability. The argument for indistinguishability of the triple shares, SHE keys and ciphertexts in the two worlds is similar to that in [DPSZ12], which shows how to use an algorithm that distinguishes between the two worlds with non-negligible probability to break the meaningless keys property of the SHE scheme.Since our usage of SHE with zero-knowledge proofs is almost identical to that work, we do not describe the reduction here.Note that our scenario is slightly simpler than [DPSZ12], as our distributed decryption method is guaranteed to be correct, so we do not have to handle any errors there.
We must also show that the verification keys and signatures generated are indistinguishable in both worlds.In the setup phase, the signing key values αj , βj,i are never seen by the environment; also, since each of these values is calculated as the sum of random shares contributed by all parties, they will be uniformly distributed, even if the adversarial shares are not.This means the underlying signing key is identically distributed in both worlds, and hence so are the honest parties' verification keys.The corrupted parties' verification keys are also identically distributed, because the adversary's contributions, v j , are sent to the functionality in the ideal world so that the keys are computed in exactly the same way.
Finally, we must consider the distributions of the signatures.It is easy to see by inspection of the protocol that in the real world, all signatures are correctly generated according to the Sign algorithm, using the underlying signing key that is unknown to all parties.On the other hand, in the ideal world, the signatures are generated by F Prep ID ⊥ using Sign and the signing key of F Prep ID ⊥ .Since we have already shown that the signature keys are identically distributed in both worlds, it follows that the distributions of signatures are the same also, and so all signatures will correctly verify in both worlds.

Efficiency Evaluation
We now evaluate the concrete efficiency of our protocol, and compare it with the BDOZ [BDOZ11] and SPDZ [DPSZ12] protocols -which only offer security with abort -and the IOZ protocol [IOZ14], which achieves identifiable abort.First we discuss the complexity of broadcast in the two settings, then we compare the online phases of each protocol, and finally discuss the preprocessing.
Cost of Broadcast.For MPC with identifiable abort, we denote the cost of broadcasting m field elements by bc(m).To be able to identify a cheater, this must be done using authenticated broadcast, which requires a PKI setup.The classic Dolev-Strong broadcast [DS83] has message complexity O(mn 2 ), or a more recent protocol by Hirt and Raykov costs O(mn) for large enough messages [HR14].Note that any authenticated broadcast protocol requires Ω(n) rounds of communication if up to n − 1 parties may be corrupt [GKKO07], which is considerably more expensive than the standard abort setting.
When security with (non-unanimous) abort is allowed (here, for SPDZ and BDOZ), a simple "broadcast with abort" protocol suffices [GL05].Here, the broadcaster sends x to everyone, then all other parties resend x and check they received the same value.This can be further optimised by performing trivial, insecure broadcasts, and then at the end of the protocol, doing a single broadcast of the hash of all sent values to verify correctness [DKL + 12].This means each broadcast costs O(n) messages, with a one-time O(n 2 ) cost to verify these at the end.
When opening shared values (such as during multiplication) a more efficient method was described in [DPSZ12], where each party first sends their share to P 1 , who then computes the sum and sends the result to all parties.This gives a cost of 2(n − 1) messages per opening, instead of n(n − 1) for the previous method (again, the actual broadcast is verified at the end of the protocol).
SPDZ.In the SPDZ protocol (as in [DKL + 13]), an authenticated secret share consists of n additive shares on the secret and n MAC shares, so each party stores two field elements.The preprocessing consists of one authenticated share per input, and three per multiplication triple.In the online phase, each input requires one party to broadcast a single value, for a communication cost of n − 1 field elements.A multiplication consists of two openings, each of which requires all parties to broadcast a share at a cost of 2n(n − 1) messages using the protocol described above.
In the output phase of SPDZ, first the shares are opened, then a random linear combination of the MACs is checked, and finally all broadcasts must be checked.The MAC and broadcast checking methods both have a communication cost in O(n 2 ).
BDOZ.In the BDOZ protocol, each party first obtains a fixed, global MAC key α i .This is fixed for all shared values, so we ignore this cost.For each shared representation [a], party P i also stores the share a i , n local MAC keys β i a 1 , . . ., β i an and n MAC values m 1 (a i ), . . ., m n (a i ).Each of these are a single field element, so we get a total storage cost of 2n + 1 field elements per party for each authenticated shared value.
If we assume an optimised version of the original protocol, so that all parties open their shares a i using the SPDZ broadcast and then delay MAC checking until the Output stage, then the online communication costs are essentially the same as SPDZ.
IOZ.The IOZ online phase takes any semi-honest MPC protocol (with preprocessing), and compiles it to a malicious protocol with identifiable abort, simililarly to the GMW paradigm [GMW87].The compiled protocol has a preprocessing phase that outputs the original semi-honest preprocessing data, authenticated using IT signatures, as well as additional data for ZK proofs using MPCin-the-head, which are required for each round of the semi-honest protocol.Using a semi-honest GMW protocol with multiplication triples as a base, the preprocessing data already contains the same number of IT signatures as our protocol, before taking into account the ZK proofs.
Each ZK proof requires storing m IT signatures as preprocessing, where m is the number of parties in the MPC-in-the-head method.In [IOZ14], they choose m = O(σ) for statistical security σ, whereas [GMO16] use m = 3, but require repeating the proof σ times to get negligible soundness error.Since repeating the proof requires extra preprocessing for each repetition, we obtain a very rough lower bound of storing σ signatures (or σ • n field elements) per proof with either approach.
For the communication costs, we only take into account the cost for every party to broadcast one proof, plus the (at least) two signatures that are broadcast in the Π SCP protocol of [IOZ14].According to [GMO16, Sec.4.2], the proof size is at least 2 • σ • log 2 (|F|), for a proof with soundness 2 −σ , generously ignoring the size of the circuit representing the NP-relation being proven and other constant factors.If the IOZ version of MPC-in-the-head is used instead, each proof still requires broadcasting t = O(σ) field elements in the Π 1SCP protocol, so would not have significantly better complexity.
Comparison of the Online Phases.The complexities in Table 1 for our protocol can be derived from the analysis in Section 5.2.We have ignored storage costs for the v j , α j parts of the verification keys, as these are independent of the number of signatures.Our protocol is roughly a factor of n times worse than SPDZ in terms of storage and communication cost, and has similar costs to BDOZ, bar the requirement for two rounds of authenticated broadcast.Compared with the IOZ protocol, we improve by at least a multiplicative factor in the security parameter, as well as a greatly reduced number of broadcast rounds.

Protocol
Prep. storage Online Comms.Rounds

Preprocessing Cost
For preprocessing, the main factor affecting computation and communication costs in [DPSZ12,DKL + 13] is the number of zero-knowledge proofs of correct ciphertext generation that are required, so this is what we measure in our protocol.
The main cost of our preprocessing protocol, compared with [DPSZ12], is to produce the signatures and verification keys for each shared value, instead of MACs as in SPDZ.The Setup phase of our protocol (Fig. 11) generates verification keys, whose size depends on the number of signatures.Ignoring any costs independent of the number of signatures, this requires n calls to RandShCtxt for each signature.Each RandShCtxt call requires n ZK proofs, and since there are n signatures per shared value (one per share) this gives a total of O(n 3 ) ZK proofs per multiplication triple or input tuple.This dominates the cost of creating the n signatures for each shared value, which is in O(n 2 ).
In contrast, SPDZ shared MAC values only require O(n) proofs each, so our protocol requires O(n 2 ) more proofs than SPDZ in the preprocessing phase.It as an interesting problem to see if this can be reduced, although it seems that with IT signatures a factor of at least O(n) is inherent, due to the signature size.
For comparison, note that the IOZ preprocessing transformation, which is based on any protocol in the OT-hybrid model, uses a verifiable OT protocol which broadcasts a message for every message of the OT protocol, adding an O(n) overhead on top of the OT-hybrid protocol.When accounting for producing the larger amount of preprocessing data needed for the online phase, this gives an overall overhead of O(n 2 ), the same as ours.However, it seems unlikely that an OT-based protocol for F Prep could be much more efficient than using SHE, mainly because the need for adaptive security in IOZ prevents the use of efficient OT extensions [LZ13].
8 From MPC with Identifiable Abort to MPC with Public Verifiability.
In a practical setting, it can be necessary to raise the deterrent to malicious behavior by e.g.allowing so-called public verifiability (see e.g.[AO12] ).That means that an honest party can convince an external third party (e.g. a judge) that another party cheated in the computation (that is called accountability), whereas a dishonest party cannot blame an honest party (a property named defamation-freeness).In addition, we require that the third party does not learn anything about the inputs of the honest parties (in case that it is controlled by A), which we call privacy-preserving.
In more formal terms, let Π(P, A, I, 1 κ , (x k ) k ∈I ) denote the random variable describing a transcript for a protocol with n parties P = {P 1 , ..., P n }, out of which the ones in I are controlled by A and where the honest parties have inputs x k as mentioned above.We assume that there exists a PPT algorithm Jud that, on input (n, 1 κ , π, j), outputs a bit b and has the following properties: Moreover, no corrupt Jud should be able to learn anything about the parties' inputs: Privacy-Preserving: For all k ∈ I let xk ← M be drawn uniformly at random from the message space.Then, for any PPT algorithm Jud and i ∈ I it holds that This third property is necessary to exclude the trivial solution where a party P i allows Jud to check the transcript by opening a commitment to its key vk i , as this would reveal the input P i to Jud.This notion of public verifiability extends the idea of [BDO14] where the external party (which the authors call the Auditor ) can inspect the transcript for correctness after the computation is done.In their model and protocol, one is not able to identify a dishonest party, whereas we will now sketch how to modify our protocol such that this indeed can be done.
In a first step, replace the broadcast channel with a bulletin board 9 B. That means that there is a resource available to which each party can send messages, such that these sent messages cannot be altered after they have been published.Moreover, B must be publicly readable in particular by Jud, and each message must be accompanied by a signature of the sending party.This transcript of all messages does not yield privacy problems, since Jud only obtains information that A learns as well.Now, the Ver algorithm will be run such that it generates verification keys for 2n parties.As before, we privately give vk i to P i but additionally post commitments to vk n+1 , ..., vk 2n on B. The opening information to the commitment of vk n+i is given to P i .Moreover, we demand that each commitment is signed by all parties (this can be done during the offline phase).We want to point out that only having one such additional key is not sufficient, because this key would then be known to A and the consistency of the HITS only applies when such an additional key is unknown.
If a party P i detects cheating of some P j , P i can simply send the opening information for vk n+i to Jud, which by the consistency of the HITS will end up with the same conclusion as P i .Moreover, the same property ensures that a dishonest P j cannot defamate an honest P i .As for privacy, this is ensured because the only information that A controlling Jud can obtain is the same as for a HITS instance with 2n parties, where 2n − 1 can be corrupted.
We leave a more detailed description of such a protocol as future work.
9 Efficient MPC with Identifiable Abort over Small Fields In Section 5 we introduced an MPC protocol whose security relies on the size of the field F. In particular, Corollary 1 requires that log |F| − 2 ≥ κ if all properties of the HITS scheme should hold with overwhelming probability.A standard approach over smaller fields is to extend the •representation to contain multiple signatures with different keys.This construction unfortunately does not work well in conjunction with small fields: If |F| = O(1) then one necessarily needs Ω(κ) signatures on each share to achieve error probability < 2 −κ .
We will now show how to adapt a technique due to Damgård and Zakarias [DZ13] that uses a dedicated preprocessing to work with HITS.Their approach only works for circuits that are not too thin (i.e. they need a certain number of gates that can be evaluated in parallel) but then permits (in the best case) constant overhead for MPC without identifiable abort.They assume that the circuit comes in layers, where each layer only consists of addition or multiplication gates only.We now revisit and extend their construction and obtain ID-MPC over small fields with O(1) signatures per share.

Packing Shares into Codewords
We assume that the field F permits the construction of an [m, k, d] linear systematic block code (where m, k, d = O(κ)).That means that we can represent each vector x ∈ F k using the efficiently computable monomorphism C : F k → F m such that ∀x, y ∈ F k : x = y ⇒ #(C(x) − C(y)) ≥ d where #(•) is the Hamming weight of a vector.This map is systematic if x appears in C(x) in the first k coordinates.We moreover assume that there exists a poly(κ)-time procedure to decide for a given c ∈ F m if c lies in the image of C. If so, then we will denote this as c ∈ C or say that c is a codeword.Note that we will denote with C both the map and the image of it.
An interesting notion to study is the so-called Schur transform of a code, for which we consider C * = span{C(x) C(y) | x, y ∈ F k } where is the coordinate-wise product of two vectors.C * is itself a linear [m, k , d ] code where k ≥ k, d ≤ d.We make the assumption that d, d ∈ O(κ).Codes that allow for such parameters are e.g. the Reed-Solomon code or Algebraic Geometry codes.
Similar to our previous definition of the • -representation we will now introduce the • mrepresentation as follows: Assume that there are m sets of keys {(sk t , (vk 1,t , ..., vk n,t ))} t∈[m] for m independent instances of HITS.We will represent a vector x ∈ F k by letting x 1 , ..., x n be chosen uniformly at random subject to the constraint that x = i x i .Each party P i will secretly hold x i .Then x m := C(x 1 ), ..., C(x n ), (σ skt (C(x 1 )| t ), ..., σ skt (C(x n )| t )) t∈ [m] .
In this representation one puts a signature σ skt (C(x i ))| t on each coordinate of C(x i ) that P i holds, where (as in Section 5) P i also holds this signature.It is immediate that addition of two such representations x m , y m can be done by a coordinatewise addition.We obtain the following algorithm, where each party P i does the following: To add a constant vector c ∈ F k to x m we let a fixed party (let's assume P 1 ) set C(x 1 ) ← C(c) + C(x 1 ).Afterwards, all parties use Eval to add the constant C(c)| t by adjusting σ sk 1 (C(x 1 )| t ) and the function they evaluate during Ver.
Given a random representation r m , where r is known to P i , this already allows a party P i , to privately input a vector x into the computation as in our original ID-MPC scheme (this r m will come from the preprocessing, as before).
We can moreover repurpose the Open algorithm to work on x m : 1. Every party P i broadcasts (C(x i ), (σ skt (C(x i )| t )) t∈[m] ). 2. Each party P i runs Ver(C(x j )| t , σ skt (C(x j )| t ), f, vk i,t ), for each j = i, t ∈ [m] and checks that C(x i ) is a codeword of C. If for some j, t the check fails or the vector is not a codeword, P i outputs (Abort, P j ). 3. Output x = i∈P x i where x i is obtained from decoding C(x i ).
The opening is now successful iff P j has verified all signatures and if C(x i ) is indeed a codeword of C. As in [DZ13] we obtain correctness since A must have successfully forged signatures for at least d positions (the minimal distance of C).Due to our choice, the probability of successfully forging d signatures is |F| −d = |F| −O(κ) .As before, the properties of the HITS allow us to identify a cheater in case of abort.

Evaluating the Circuit
Following the approach of Section 5 we want to be able to multiply constant vectors c into a • m -representation, which then permits multiplication of these representations using the Beaver circuit randomization technique.This can be done by coordinate-wise multiplication of the vectors of x m with C(c) plus carefully adjusting the signatures.But the resulting representation does not have codewords from C, but from C * instead.Let us write x * m in the case where we have a • m -representation where the codewords are in the Schur transform.In order to continue the computation we have to turn each such • * m back into a • m -representation containing the exact same value.To achieve this we assume that the preprocessing outputs pairs ( r * m , r m ), where r was chosen uniformly at random.This gives rise to an interactive multiplication protocol for constants that is similar to the multiplication protocol of Π Online : As outlined in Π Online this protocol can now be used to multiply • m -representations using multiplication triples.An additional complication (in comparison to Π Online ) is that we may have to reorder values inside x m or between multiple representations (or duplicate them), due to the wiring between layers of the circuit.For simplicity, we assume that all values of a layer fit into one representation (but the generalization is straightforward): Observe that each such rewiring corresponds to applying a linear transformation f to the vector of the representation.We demand from the preprocessing to obtain a pair ( r m , f (r) m ) for each such layer.To compute f (x) m we then use the following algorithm: In order to generate these pairs ( r m , f (r) m ) the preprocessing must be aware of the actual circuit that is evaluated in the online phase.This dependence can be resolved by using programmable sorting networks (see [DZ13] for details) instead of the fixed maps from the actual circuit.

Identifiable Abort and Efficiency
A careful inspection shows that our above protocol follows the same outline as Π Online and that the subprotocols use similar techniques, with the difference being the representation switching and the inter-layer permutation.Both of these are variants of the Mult protocol of Π Online .Hence, security again reduces to being able to securely perform Open.As we argued above, with a sufficient parameter choice we can ensure that opening • m , • * m -representations can be done such that cheating is detected, based on d, d being large enough.
Concerning the efficiency of the sketched scheme, we observe that it only performs O(n) worse than the original construction by Damgård and Zakarias.Namely, the storage per • mrepresentation is < 3nm field elements (including the m verification keys), whereas [DZ13] stores 3m elements from F. For each unreliable open of [DZ13] one uses broadcast n times on m field elements each, whereas we use n times broadcast on m + m • n values due to the signatures that we have to open.
The analysis of the network communication of [DZ13] can equally be applied to our setting by plugging in the different overhead from our construction.Using Reed-Solomon codes we achieve a network overhead of O(n • polylog(κ)), whereas [DZ13] has O(polylog(κ)).
Functionality F MPC Let I be the set of indices of corrupt parties.

Fig. 2 .
Fig. 2. Ideal functionality for reactive MPC in the finite field F.

Fig. 3 .
Fig. 3. Procedure for opening an authenticated, shared value Multiplication triples: Random shared triples a , b , c , where a, b ← F and c = a • b.
Functionality F PrepLet I be the set of indices of corrupt parties.The functionality is parametrised by the statistical security parameter, κ.Initialise: On input (Init, w) from all parties, do the following:1.Compute (sk, vk) ← Gen(1 κ , w) 2. Send vki to party Pi and store sk.Macro Bracket: On input (Bracket, x), create the representation x as follows:1.Receive shares xi for i ∈ I from the adversary.2. Sample random shares xi ← F, for i / ∈ I, subject to the constraint that x = x1 + • • • + xn. 3.For i = 1, . . ., n, compute σx i = Sign(xi, sk) and return {xi, σx i } i∈[n]  .Input: On input (Input, Pi) from all parties, sample a random r ← F and run (Bracket, r) to obtain r .Output (rj, σr j ) to each party Pj, and also r to Pi. Triple: On input (Triple) from all parties, do the following: 1. Sample a, b ← F and let c = a • b. 2. Run the macro (Bracket) on input a, b and c to obtain a , b , c .Output (ai, bi, ci, σa i , σ b i , σc i ) to each party Pi.

Fig. 6 .
Output stage of the optimised online protocolFunctionality F Rand (F) Random sample: Upon receiving (rand; u) from all parties, it samples a uniform r ∈ F and outputs (rand, r) to all parties.

1.
Compute and open x − r m using the above open algorithm and reconstruct x − r.If Open fails then abort.2. Each party locally computes y ← f (x − r). 3. Set f (x) m ← y + f (r) m .

Table 1 .
Comparison of the storage and communication costs of the protocols, measured in number of field elements.N = NI + 2NM (where NI is number of inputs, NM is number of multiplications), D is the multiplicative depth of the circuit, and σ is a statistical security parameter.