Concretely Efficient Large-Scale MPC with Active
Security
(or, TinyKeys for TinyOT)
Carmit Hazay1?, Emmanuela Orsini2??, Peter Scholl3? ? ?, and Eduardo
Soria-Vazquez4†
1
Bar-Ilan University, Israel [email protected] 2 KU Leuven, imec-COSIC, Belgium
[email protected] 3 Aarhus University, Denmark
University of Bristol, UK
Abstract. In this work we develop a new theory for concretely efficient, large-scale MPC with active security. Current practical techniques are mostly in the strong setting of all-but-one corruptions, which leads to protocols that scale badly with the number of parties. To work around this issue, we consider a large-scale scenario where a small minority out of many parties is honest and design scal-able, more efficient MPC protocols for this setting. Our results are achieved by introducing new techniques for information-theoretic MACs with short keys and extending the work of Hazay et al. (CRYPTO 2018), which developed new pas-sively secure MPC protocols in the same context. We further demonstrate the usefulness of this theory in practice by analyzing the concrete communication overhead of our protocols, which improve upon the most efficient previous works.
1
Introduction
Secure multi-party computation (MPC) protocols allow a group ofnparties to compute some functionf on the parties’ private inputs, while preserving a number of security properties such asprivacyandcorrectness. The former property implies data confiden-tiality, namely, nothing leaks from the protocol execution but the computed output. The
?
Supported by the European Research Council under the ERC consolidators grant agreement n. 615172 (HIPS), and by the BIU Center for Research in Applied Cryptography and Cyber Security in conjunction with the Israel National Cyber Bureau in the Prime Minister’s Office.
??
Supported in part by ERC Advanced Grant ERC-2015-AdG-IMPaCT.
? ? ?
Supported by the European Union’s Horizon 2020 research and innovation programme under grant agreement No 731583 (SODA), and the Danish Independent Research Council under Grant-ID DFF-6108-00169 (FoCC).
†
latter requirement implies that the protocol enforces the integrity of the computations made by the parties, namely, honest parties are not led to accept a wrong output. Se-curity is proven either in the presence of a passive adversary that follows the protocol specification but tries to learn more than allowed from its view of the protocol, or an active adversary that can arbitrarily deviate from the protocol specification in order to compromise the security of the other parties in the protocol.
The past decade has seen huge progress in making MPC protocols communica-tion efficient and practical; see [KS08,DPSZ12,DKL+13,ZRE15,LPSY15,WMK17,
HSS17] for just a few examples. In the two-party setting, actively secure protocols [WRK17a] by now reach within a constant overhead factor over the notable semi-honest construction by Yao [Yao86]. On the practical side, a Boolean circuit with around 30,000 gates (6,400 AND gates and the rest XOR) can be securely evaluated with ac-tive security in under20ms [WRK17a]. Moreover, current technology already supports protocols that securely evaluate circuits with more than a billion gates [KSS12]. On the other hand, secure multi-party computation with a larger number of parties and a dishonest majority is far more difficult due to scalability challenges regarding the number of parties. Here, the most efficient practical protocol with active security has a multiplicative factor ofO(λ/log|C|)due to cut-and-choose [WRK17b] (whereλis a statistical security parameter and|C|is the size of the computed circuit). On the prac-tical side, the same Boolean circuit of 30,000 gates can be securely evaluated at best in500ms for 14 parties [WRK17b] in a local network where the latency is neglected, or in more than 20s in a wide network. The problem is that current MPC protocols do not scale well with the number of parties, where the main bottleneck is a relatively high communication complexity, while the number of applications requiring large scale communication networks are constantly increasing, involving sometimes hundreds of parties.
An interesting example is safely measuring the Tor network [DMS04] which is among the most popular tools for digital privacy, consisting of more than6000relays that can opt-in for providing statistics about the use of the network. Nowadays and due to privacy risks, the statistics collected over Tor are generally poor: There is a reduced list of computed functions and only a minority of the relays provide data, which has to be obfuscated before publishing [DMS04]. Hence, the statistics provide an incomplete picture which is affected by a noise that scales with the number of relays.
In the context of securely computing the interdomain routing within the Border Gateway Protocol (BGP) which is performed at a large scale of thousands of nodes, a recent solution in the dishonest majority setting [ADS+17] centralizes BGP so that two parties run this computation for all Autonomous Systems. Large scale protocols would allow scaling to a large number of systems computing the interdomain routing themselves using MPC, hence further reducing the trust requirements.
also enforce independent of inputs between the corrupted and honest parties as well as correctness, in the sense that parties are not allowed to change their vote once they learn they lost. This type of security requires more complicated tools and is knows as active security. Designing secure solutions for auctions played an important role in the literature of MPC. In fact, the first MPC real-world implementation was for the sugar beet auction [BCD+09] with three parties and honest majority, where the actual num-ber of parties was 1129. In a very recent work by Keller et al. [KPR18], the authors designed a new generic protocol based on semi-homomorphic encryption and lattice-based zero-knowledge proofs of knowledge, and implemented the second-price auction with 100 parties over a field of size240. The running time of their offline phase for the SPDZ protocol is 98s. The authors did not provide an analysis of their communication complexity.
Motivated by the fact that current techniques are insufficient to produce highly prac-tical protocols for such scenarios, we investigate the design of protocols that can more efficiently handle large numbers of parties withstrong securitylevels. In particular, we study the setting of active security with only a minority (around 10–30%) of honest par-ticipants. By relaxing the well-studied, very strong setting of all-but-one corruptions (or full-threshold), we hope to greatly improve performance. Our starting point is the re-cent work by Hazay et al. [HOSS18] which studied this corruption setting with passive security and presented a new technique based on “short keys” to improve the communi-cation complexity and the running times of full-threshold MPC protocols. In this paper we extend their results to the active setting.
Technical background for [HOSS18].Towards achieving their goal, Hazay et al. ob-served that instead of basing security on secret keys held by each party individually, they can base security on theconcatenation of all honest parties’ keys. Namely, a se-cure multi-party protocol withhhonest parties can be built by distributing secret key material so that each party only holds asmall part of the key. Formalizing this intuition is made possible by reducing the security of their protocols to the Decisional Regu-lar Syndrome Decoding (DRSD)problem, which, given a random binary matrixH, is to distinguish between the syndrome obtained by multiplyingH with an error vector
e= (e1k · · · keh)where eachei ∈ {0,1}2
`
has Hamming weight one, and the uniform distribution. This can equivalently be described as distinguishingLh
i=1H(i, ki)from
the uniform distribution, whereHis a random function and eachki is a random`-bit
key. A specified in [HOSS18], whenhis large enough, the problem isunconditionally hardeven for`= 1, which means for certain parameter choices 1-bit keys can be used without introducing any additional assumptions.
creating MACs in a distributed manner compared with previous works, due to the use of short MAC keys. For our second contribution, we show how to use these efficient MAC schemes to construct actively secure MPC for binary circuits, based on the ‘TinyOT’ family of protocols [NNOB12,BLN+15, FKOS15,HSS17,WRK17b]. All previous protocols in that line of work supportedn−1out ofn corruptions, so our protocol extends this to be more efficient for the setting of large-scale MPC with a few honest parties.
Concrete efficiency improvements.The efficiency of our protocols depends on the to-tal number of parties,n, and the number of honest parties,h, so there is a large range of parameters to explore when comparing with other works. We discuss this in more detail in Section8. Our protocol starts to concretely improve upon previous protocols when we reachn = 30parties andt = 18corruptions: here, our triple generation method requires less thanhalf the communication cost of the fastest MPC protocol which is also based on TinyOT [WRK17b] (dubbed WRK) tolerating up ton−1corruptions. For a fairer comparison, we also consider modifying WRK to run in a committee of sizet+ 1, to give a protocol with the same corruption threshold as ours. In this setting, we see a small improvement of around 10% over WRK, but at larger scales the impact of our protocol becomes much greater. For example, withn= 200parties andt= 160
corruptions we have up to an 8 times improvement over WRK with full-threshold, and a 5 times improvement when WRK is modified to the threshold-tsetting.
Technical Overview
In our protocols we assume that two committees,P(h)andP(1), have been selected out of all thenparties providing inputs in the MPC protocol, such thatP(h)contains at least hhonest parties andP(1)contains at least 1 honest party. These can be chosen determin-istically, for instance, if there arehhonest parties in total we letP(h)={P1, . . . , Pn}
andP(1)={P1, . . . , Pn−h+1}. We can also choose committees at random using
coin-tossing, if we start with a very large group of parties from whichh0 > hare honest.
Since we have|P(h)|>|P(1)|, to avoid unnecessary interaction we take care to ensure
that committeeP(h)is only used when needed, and when possible we will do operations in committeeP(1)only.
storage overhead by “compressing” the MACs into a single, SPDZ-like sharing inonly committeeP(1).
Section4–5.We next show how to efficiently create authenticated shares for our MAC scheme with short keys. As a building block, we need a protocol for random correlated oblivious transfer (or random ∆-OT) on short strings. We consider a variant of the OT extension protocol of Keller et al. [KOS15], modified to produce correlated OTs (as done in [NST17]) and with short strings. Our authentication protocol for creating distributed MACs improves upon the previous best-known approach for creating MACs (optimized to usehhonest parties) by a factor ofh(n−h)/ntimes in terms of overall communication complexity. This gives performance improvementsfor allh >1, with a maximumn/4-fold gain ashapproachesn/2.
Section7.Finally, we introduce our triple generation protocol, in two phases. Similarly to [WRK17b], we first show how to compute the cross terms in multiplication triples by computing so-called ‘half-authenticated’ triples. This protocol does not authenticate all terms and the result may yield an incorrect triple. Next, we run a standard cut-and-choose technique for verifying correctness and removing potential leakage. Our method for checking correctness does not follow the improved protocol from [WRK17b] due to a limitation introduced by our use of the DRSD assumption. The security of our protocol relies on a variant of the DRSD assumption that allows one bit of leakage, and for this reason the number of triplesrgenerated by these protocols depends on the security of RSD. So, while we can produce an essentially unlimited number of random correlated OTs and random authenticated bits, if we were to produce ‘half-authenticated’ triples in a naive way, we would be bounded on the total number of triples and hence the size of the circuits we can evaluate. To fix this issue we show how to switch the MAC representation from using one key∆to a representation under another independent key
˜
∆. This switch is performed everyrtriples.
Extension to Constant Rounds.Since Hazay et al. [HOSS18] also described a constant round protocol based on garbled circuits with passive security, it is natural to wonder if our approach with active security also extends to this setting. Unfortunately, it is not straightforward to extend our approach to multi-party garbled circuits with short keys and active security, since the adversary can flip a garbled circuit key with non-negligible probability, breaking correctness. Nevertheless, we can build an alternative, efficient solution based on the transformation from [HSS17], which shows how to turn any non-constant round, actively secure protocol for Boolean circuits into a constant round [BMR90]-based protocol. When applying [HSS17] to our protocol, we obtain a multi-party garbling protocol with full-length keys, but we still improve upon the naive (full-threshold) setting, since the preprocessing phase is more efficient due to our use of TinyOT with short keys. More details will be given in the full version.
2
Preliminaries
non-negligible) if there exists a positive polynomialp(·)such that for all sufficiently largeκit holds thatµ(κ)≥ 1
p(κ). We use the abbreviation PPT to denote probabilistic polynomial-time. We further denote bya←Athe uniform sampling ofafrom a setA, and by[d]the set of elements{1, . . . , d}. We often view bit-strings in{0,1}kas vectors
inFk2, depending on the context, and denote exclusive-or by “⊕” or “+”. Ifa, b ∈F2 thena·bdenotes multiplication (or AND), and ifc∈F2κthena·c∈Fκ2 denotes the product ofawith every component ofc.
Security and Communication Models. We use the universal composability (UC) framework [Can01] to analyse the security of our protocols. We assume all parties are connected via secure, authenticated point-to-point channels, as well as a broadcast channel which is implemented using a standard 2-round echo-broadcast. The adversary model we consider is a static, active adversary who corrupts up totout ofnparties at the beginning of the protocol. We denote byAthe set of corrupt parties, andA¯the set of honest parties.
Regular Syndrome Decoding Problem. We recall that theregular syndrome decoding (RSD) problem is to recover a secret error vectore = (e1k · · · keh), where eachei ∈
{0,1}m/hhas Hamming weight one, given only(H,He), for a randomly chosen binary
r×mmatrixH. In [HOSS18] it was shown that the search and decisional versions of this problem are equivalent and even statistically secure whenhis big enough compared tor. In this work we use an interactive variant of the problem, where the adversary is allowed to try to guess a few bits of information on the secret e before seeing the challenge; if the guess is incorrect, the game aborts. We conjecture that this ‘leaky’ version of the problem, defined below, is no easier than the standard problem. Note that on average the leakage only allows the adversary to learn 1 bit of information one, since if the game does not abort he only learns thatV
Pi(e) = 1.
The ‘leaky’ part of the assumption is introduced as a result of an efficient instantia-tion of random correlated OTs on short strings (Secinstantia-tion4). Once the adversary has tried to guess these short strings, which act as short MAC keys in the authentication protocol (Section5), a DRSD challenge is presented to him during the protocol computing the cross terms of multiplication triples (Section7.1). As in [HOSS18], the appearance of the DRSD instance is due to the fact of ‘hashing’ the short MAC keys of at leasth honest parties during said multiplications.
Definition 2.1 (Decisional Regular Syndrome Decoding with Leakage) Letr, h, `∈ Nandm=h·2`. Consider the gameL-DRSDbr,h,`forb∈ {0,1}, defined between a
challenger and an adversary:
1. SampleH←Fr×m
2 and a random, weight-hvectore∈Fm2 .
2. Send H to the adversary and wait for the adversary to adaptively query up to hefficiently computable5 predicatesP
i : Fm2 → {0,1}. For eachPi queried, if
Pi(e) = 0then abort, otherwise wait for the next query.
5
3. Ifb = 0, sampleu ← Fr
2and send(H,u)to the adversary. Otherwise ifb = 1, send(H,He).
The DRSD problem with leakagewith parameters(r, h, `)is to distinguish between L-DRSD0r,h,`andL-DRSD1r,h,`with noticeable advantage.
2.1 Resharing
At several points in our protocols, we have a valuex=P i∈Xx
ithat is secret-shared
between a subset of parties{Pi}i∈X, and wish to re-distribute this to a fresh sharing
amongst a different set of parties, say{Pj}j∈Y. The naive method to do this is for every
partyPito generate a random sharing ofxi, and send one share to eachPj. This costs
|X| · |Y| ·mbits of communication, wheremis the bit length ofx. Whenmis large, we can optimize this using a pseudorandom generatorG:{0,1}κ→ {0,1}m, as follows:
1. Fori∈X, partyPidoes as follows:
(a) Pick an indexj0∈Y6
(b) Sample random keyski,j← {0,1}κ, forj∈Y \j0
(c) Sendki,jto partyP
j, and sendxi,j
0
=P
jG(k
i,j) +xito partyP j0 2. Forj∈Y, partyPjdoes as follows:
(a) Receiveki,jfrom eachP
iwho sendsPj a key, and a sharexi,jfrom eachPi
who sendsPja share. For the keys, compute the expanded sharexi,j=G(ki,j)
(b) Outputxj=P i∈Xx
i,j.
Now eachPionly needs to send a single share of sizembits, since the rest are
com-pressed down toκbits using the PRG. This gives an overall communication complexity ofO(|X| · |Y| ·κ+|X| ·m)bits.
3
Information-Theoretic MACs with Short Keys
We now describe our method for authenticated secret-sharing based on information-theoretic MACs with short keys. Our starting point is the standard information-information-theoretic MAC scheme on a secretx∈ {0,1}given bym=k+x·∆, for a uniformly random key(k, ∆), wherek∈ {0,1}`is only used once per messagex, whilst∆∈ {0,1}`is
fixed. Given the messagex, the MACmand the keyk, verification consists of simply checking the linear equation holds. It is easy to see that, givenxandm, forging a valid MAC for a messagex0 6= xis equivalent to guessing∆. In a nutshell, we adapt this basic scheme for the multi-party, secret-shared setting, with the guarantee that forging a MAC to all parties can only be done with probability2−λ,even when the key length`
is much smaller thanλ, by relying on the fact that at leasthparties are honest.
Our scheme requires choosing two (possibly overlapping) subsets of partiesP(h), P(1)⊆ P, such thatP(h)has at leasthhonest parties andP(1)at least 1 honest party. To authenticate a secret valuex, we first additively secret-sharexbetweenP(1), and
6
then give every party inP(1) a MAC on its share under a random MAC key given to each party inP(h), as follows:
Pi∈ P(h): ∆i,{ki,j[xj]}j∈P(1),j6=i
Pj∈ P(1): xj,{mj,i[xj]}i∈P(h),i6=j
such thatx=X j
xj and mj,i[xj] =ki,j[xj] +xj·∆i.
whereki,j[xj]is a key chosen byP
ifrom{0,1}`to authenticate the messagexjthat
is chosen byPjwhereasmj,i[xj]is a MAC on a messagexjcomputed using the keys
∆iandki,j[xj]. We denote this representation by[x]P(h),P(1)
∆ . Note that sometimes we
use representations with a different set of global keys∆={∆i}
i∈P(h), but when it is
clear from context we omit∆and write[x]P(h),P(1).
We remark that a special case is whenP(h) = P(1) = P, which gives the usual n-party representation of an additively shared value x = x1 +· · · +xn, as used
in [BDOZ11,BLN+15]:
[x] ={xi, ∆i,{mi,j,ki,j
}j6=i}i∈[n], mi,j=k
j,i
+xi·∆j,
where each partyPi holds then−1MACs{mi,j}onxi, as well as the keyski,jon
eachxj, forj6=i, and a global key∆i.
The idea behind our setup is that to cheat when openingxto all parties would require guessing at leasthMAC keys of the honest parties in committeeP(h). In Figure1and Figure 2we describe our protocols for opening values to a subsetP ⊆ P¯ and to a single party, respectively, and checking MACs. First each party inP(1) broadcasts its sharexj toP(h), and then later, when checking MACs,Pj sends the MACmj,itoPi
for verification. To improve efficiency, we make two optimizations to this basic method: firstly, instead of sending the individual MACs, when opening a large batch of values Pj only sends a single, random linear combination of all the MACs. Secondly, the
verifierPidoes not check every MAC equation from eachPj, but instead sums up all
the MACs and performs a single check. This has the effect that we only verify the sum xwas opened correctly, and not the individual sharesxj.
Overall, to open xto an incorrect valuex0 requires guessing the ∆i keys of all
honest parties inP(h), so can only be done with probability≤ 2−h`. This means we can choose`=λ/hto ensure security. Note that it is crucial when opening[x]P(h),P(1)
that the sharesxj arebroadcast to all parties inP(
h), to ensure consistency. Without this, a corruptPj could open, for example, an incorrect value to a single party inP(h) with probability2−`, and the correct share to all other parties.
More details on the correctness and security of our open and MACCheck protocols are given in the full version of this paper.
ProtocolΠP(h),P(1)
[Open]
PARAMETERS:P(h),P(1),P ⊆ P¯ three (possibly overlapping) subsets of parties, such that
P(h)has at leasthhonest parties andP(1)has at least one honest party;`=key length ;m= number of authenticated bits
Open: To open[x]P(h),P(1)to a set of partiesP ⊆ P¯ :
1. Each partyPj∈ P(1)broadcasts its sharexjtoP¯. 2. All parties inP¯locally computex=P
j∈P(1)x
j
.
Single Check: To check the MAC on the opened valuex:
1. EachPj∈ P(1)sendsmj,i[x]to everyPi∈ P(h)\ {Pj}.
2. Each party inP¯broadcasts the previously receivedxtoP(h). 3. EachPi∈ P(h)checks that
X
j∈P(1)\Pi
mj,i[x] +ki,j[x]+ (x+xi)·∆i= 0
wherexi= 0ifPi∈ P/ (1). If any check fails, abort.
Batch Check: To check the MACs on a batch of opened valuesx1, . . . , xm:
1. Parties inP¯,P(h),P(1)samplemrandom valuesχ1, . . . , χm← FRand(F2λ).
2. Each party inP¯locally computesy=Pm
k=1χk·xk∈F2λand broadcasts this toP(h). 3. If parties inP(h)receive inconsistent values, then abort.
4. EachPi∈ P(h)∩ P(1)computesyi=Pmk=1χk·xik.
5. Parties inP(h)∪ P(1)locally compute[y] P(h),P(1)
=Pm
k=1χk·[xk] P(h),P(1)
(with multiplication overF2λ).
6. EachPj∈ P(1)sendsmj,i[y]to everyPi∈ P(h)\ {Pj}.
7. EachPi∈ P(h)has received values{y}and MACs{mj,i[y]}, j ∈ P(1)\ {Pi}, and
checks that
X
j∈P(1)\{Pi}
mj,i[y] +ki,j[y]+ (y+yi)·∆i= 0,
whereyi= 0
ifPi∈ P/ (1). If any check fails, abort.
Fig. 1.Protocols for opening and MAC-checking on(P(h),P(1))-authenticated secret shares
ProtocolΠP(h),P(1),Pi0
PrivateOpen
Private Open: To open a value[x]P(h),P(1)towardsP
i0:
1. EachPj∈ P(1)sends their sharexjtoPi0, who locally reconstructsx=
P
j∈P(1)x
j
.
Batch Check:To check the MACs on a batch of opened valuesx1, . . . , xm:
1. Parties in P(h),P(1) call F P(h),P(1)
aBit to obtain λ random authenticated values [r1]
P(h),P(1)
∆ , . . . ,[rλ]
P(h),P(1)
∆
2. EachPj∈ P(1)sendsr
j
1, . . . , r
j λtoPi0.
3. Sampleλrandom valuesχk←F2λusingFRand,k∈[m] 4. Pi0locally computes
y=
m
X
k=1
χk·xk+ λ
X
k=1
Xk−1·rk,
and broadcasts the result toP(h). 5. EachPi∈ P(h)∩ P(1)computes
yi=
m
X
k=1
χk·xik+ λ
X
k=1
Xk−1·rki
6. Parties inP(h)∪ P(1)locally compute
[y]P(h),P(1)
∆ =
m
X
k=1
χk·[xk]
P(h),P(1)
∆ +
l
X
k=1
Xk−1·[rk]
P(h),P(1)
∆ ,
where multiplication is performed over the finite fieldF2λ.
7. EachPj∈ P(1)privately sendsm
j,i
∆[y]to everyPi∈ P(h)\Pj.
8. EachPi∈ P(h)has received MACs{m
j,i
∆[y]}j∈P(1)\Pi, and checks that
X
j∈P(1)\Pi
mj,i∆[y] +k i,j ∆[y]
+ (y+yi)·∆i= 0
whereyi= 0ifPi∈ P/ (1). If any check fails, abort and notify all parties inP.
Fig. 2.Protocol for privately opening(P(h),P(1))-party authenticated secret shares to a single partyPi0and MAC-checking
Extension to Arithmetic Shares. The scheme presented above can easily be extended to the arithmetic setting, with shares in a larger field instead of justF2. To do this with short keys, we simply choose the MAC keys∆ito be from a small subset of the field.
For example, overFpfor a large primep, each party chooses∆i∈ {0, . . . ,2`−1}, and
will obtain MACs of the formmj,i =ki,j+xj ·∆iover
Fp, whereki,j is a random
element ofFp. This allows for a reduced preprocessing cost when generating MACs
`OTs onk-bit strings between(n−1)(t+ 1)pairs of parties to set up each shared MAC.
3.1 Operations on[·]P(h),P(1)-Shared Values
Recall thatP(h)∩ P(1)is not necessarily the empty set.
Addition and multiplication with constant:We can define addition of[x]P(h),P(1)
∆ with
a public constantc∈ {0,1}by:
1. A designatedPi∗∈ P(1)replaces its sharexi ∗
withxi∗+c.
2. EachPi(fori ∈ P(h), i6= i∗) replaces its keyki,1[x]withki,1[x] +c·∆i. (All other values are unchanged.)
We also define multiplication of[x]P(h),P(1)
∆ by a public constantc ∈ {0,1}(or in
{0,1}`) by multiplying every sharexi, MACmi,j[x]and keyki,j[x]
byc. Addition of shared values: Addition (XOR) of two shared values[x]P(h),P(1)
∆ ,[y]
P(h),P(1) ∆
is straightforward addition of the components. Note that it is possible to compute the sum[x]P(h),P(1)
∆ + [y]
P(h),P(h)
∆ of values shared within different committees in the same
way, obtaining a[x+y]P(h),P(h)∪P(1)
∆ representation.
3.2 Converting to a More Compact Representation
We can greatly reduce the storage overhead in our scheme by “compressing” the MACs into a single, SPDZ-like sharing inonlycommitteeP(1) with longer keys. Recall that the SPDZ protocol MAC representation [DPSZ12,DKL+13] of a secret bitxheld by the parties inP(1)is given by
JxK={x
j,mj[x]} j∈P(1)
where each partyPj inP(1)holds a sharexj, a MAC sharemj[x]∈ Fλ2 and a global MAC key share∆j∈
Fλ2, such that x= X
j∈P(1)
xj, X
j∈P(1)
mj= ( X j∈P(1)
xj)·( X j∈P(1)
∆j)
Using this instead of the previous representation gives a much simpler and more ef-ficient MAC scheme in the online phase of our MPC protocol, since each party only storesλ+ 1bits per value, instead of up to|P(h)| ·`+ 1bits with the scheme using short keys. Therefore, to obtainboththe efficiency ofgeneratingMACs in the previous scheme, andusingthe MACs with SPDZ, below we show how to convert an inefficient, pairwise sharing[x]P(h),P(1)into a more compact SPDZ sharing
JxK. This procedure is
shown in Figure3.
ProtocolΠP(h),P(1),m,`
MACCompact
PARAMETERS:P(h),P(1)⊆ Ptwo (possibly overlapping) subsets of parties, such thatP(h)
has at leasthhonest parties andP(1) has at least one honest party;` =key length;m = number of authenticated bits.
On input[x1] P(h),P(1)
∆ , . . . ,[xm]
P(h),P(1)
∆ , do as follows:
1. EachPi∈ P(h)samples and broadcastsri←F2λ.
2. Forι∈[m]:
(a) EachPi∈ P(h)computesri·Pj∈P(1)k
i,j[x
ι], then reshares the resulting value
to the parties inPj∈ P(1), each of which obtains random shares{k˜
i,j
[xι]}i∈P(h). (b) EachPi∈ P(h)reshares∆i·ri∈F2λto the parties inP(1), each of which obtains
{∆˜i,j} i∈P(h).
(c) EachPj∈ P(1)outputs its part ofJxιKby computing the MAC share
˜
mj[xι] =
X
i∈P(h)
(˜ki,j[xι] +mj,i[xι]·ri)∈F2λ
and key share∆˜j=P
i∈P(h)∆˜
i,j∈
F2λ.
Fig. 3.Protocol for transforming[x]P(h),P(1)representations to
JxKrepresentations
To see correctness, first notice that from step2a, we have thatP j˜k
i,j=ri·P jk
i,j.
So each party inP(1)holds a sharexjand a MAC sharem˜
j
∈F2λ, which satisfy:
X
j ˜
mj=X j
X
i
(˜ki,j+mj,i·ri)
=X
i,j
(ki,j+mj,i)·ri=X i,j
xj·∆i·ri=x·∆.˜
The security of this scheme now depends on the single, global MAC key ∆˜ = P
i∆
i·ri, instead of the concatenation of∆i fori ∈ P
(h). Since at leasthof the short keys ∆i ∈
F2` are unknown and uniformly random, from the leftover hash
lemma [ILL89] it holds that ∆˜ is within statistical distance2−λ of the uniform
dis-tribution over{0,1}λas long ash`≥3λ. This gives a slightly worse bound than the
previous scheme, but allows for a much more efficientonline phaseof the MPC pro-tocol since, once the SPDZ representations are produced, only parties inP(1) need to interact, and they have much lower storage and local computation costs. Note that in our instantiation of this scheme for the overall MPC protocol, we also need to choose the parametersh, `such that theL-DRSDassumption is hard; it turns out that all of our parameter choices (see Section8) for this already satisfyh`≥3λ, so in this case using more compact MACs does not incur any extra overheads.
that we can write the new key∆˜as∆˜=R·∆, whereR∈ {0,1}λ×nis a matrix with rias columns. Since at leasthpositions of∆are uniformly random, from randomness
extraction results for bit-fixing sources (as used in, e.g. [NST17, Theorem 1]) it holds that since every honestly sampled row ofRis uniformly random,∆˜is within statistical distance 2λ−h of the uniform distribution. We therefore require h ≥ 2λ, instead of
h≥3λas previously.
Optimization with Vandermonde Matrices Over Small Fields If we choose each of the∆ikeys to come from a small finite fieldF, with|F| ≥n, then we can optimize the compact MAC scheme even further, so that there isno overheadon top of the previous pairwise scheme. The idea is to use a Vandermonde matrix to extract randomness from all parties’ small MAC keys in a deterministic fashion, instead of using random vectors
ri as before. This technique is inspired by previous applications of hyper-invertible
matrices to MPC in the honest majority setting [BTH08].
Letv1, . . . , vn be distinct points inF, where Fis such thath· |F| ≥ λ. Now let
V∈Fn×hbe the Vandermonde matrix given by
V=
1 v1 . . . vh1−1
1 v2 . . . vh2−1 ..
. . .. . .. ...
1vn . . . vhn−1
PartyPi defines the new MAC key share∆˜i =vi·∆i, wherevi is thei-th row
ofV. This results in a new global key given by∆˜ = (∆1, . . . , ∆n)·V ∈
Fh. From the fact that at leasthcomponents of∆are uniformly random, and the property of the Vandermonde matrix that any square matrix formed by takinghrows ofVis invertible, it follows that∆˜ is a uniformly random vector inFh. More formally, this means that ifn−hcomponents of ∆are fixed and we define∆H to be thehhonest MAC key
components, then the mapping∆H 7→∆·Vis a bijection, so∆˜is uniformly random
as long as ∆H is. Therefore we can choose h ≥ λ/|F| to obtain ≤ 2−λ cheating probability in the resulting MAC scheme.
Allowing leakage on the MAC keys. In our subsequent protocol for generating MACs, to obtain an efficient protocol we need to allow someleakageon the individual MAC keys∆i∈ {0,1}`, in the form of allowing the adversary to guess a single bit of
infor-mation on each∆i. For both the pairwise MAC scheme and the compact, SPDZ-style
4
Correlated OT on Short Strings
As a building block, we need a protocol for random correlated oblivious transfer (or random∆-OT) on short strings. This is a2-party protocol, where the receiver inputs bitsx1, . . . , xm, the sender inputs a short string∆ ∈ {0,1}`, and the receiver obtains
random strings ti ∈ {0,1}`, while the sender learns qi = ti+xi· ∆. The ideal
functionality for this is shown in Figure4.
The protocol we use to realise this (shown in in the full version of this paper) is a variant of the OT extension protocol of Keller et al. [KOS15], modified to produce correlated OTs (as done in [NST17]) and with short strings. The security of the protocol can be shown similarly to the analysis of [KOS15]. That work showed that a corrupt party may attempt to guess a few bits of information about the sender’s secret∆, and will succeed with probability2−c, wherecis the number of bits. In our case, since∆is
small, a corrupt receiver may actually guessall of ∆with some noticeable probability, in which case all security for the sender is lost. This is modelled in the functionality F∆-ROT, which allows a corrupt receiver to submit such a guess. This leakage does not
cause a problem in our multi-party protocols, because an adversary would have to guess the keys ofallhonest parties to break security, and this can only occur with negligible probability.
Communication complexity. Recall thatλis the statistical security parameter andκ the computational security parameter. The initialization phase requires`random OTs, which costs `κ bits of communication when implemented using OT extension. The communication complexity of theExtendphase, to createm∆-ROTs, is`(m+λ)bits to create the OTs, andκ+ 2λbits for the consistency check (we assumePSonly sends
aκ-bit seed used to generate theχi’s). This gives an amortized cost of`+ (κ+ 3λ)/m
bits per∆-ROT, which is less than`+ 4bits whenm > κ.
FunctionalityF`
∆-ROT
Initialize: Upon receiving(Init, ∆), where∆∈ {0,1}`
fromPSand(Init)fromPR, store
∆. Ignore any subsequent (Init) commands.
Extend: Upon receiving(extend, x1, . . . , xm)fromPR, wherexi∈ {0,1}, and(extend)
fromPS, do the following:
– Sampleti∈ {0,1}`, fori∈[m]. IfPRis corrupted then wait forAto inputti.
– Computeqi=ti+xi·∆, fori∈[m].
– IfPSis corrupted then wait forAto inputqi∈ {0,1} `
and recomputeti=qi+xi·∆.
– OutputtitoPRandqitoPS, fori∈[m].
Key queries:IfPR is corrupt then on receiving an efficiently computable predicate P : {0,1}` → {0,1}
from the adversary, send 1 to the adversary ifP(∆) = 1. IfP(∆) = 0 then the functionality aborts.
5
Bit Authentication with Short Keys
FunctionalityFP(h),P(1),m,`
aBit
PARAMETERS:mnumber of authenticated bits;`key length.
Initialize:On receiving(Init, ∆i)from Pi ∈ P(h) and(Init)fromPj ∈ P(1), store all
∆i∈ {0,1}`.
aBit:On receiving(aBit, m)fromPi ∈ P(h)and(aBit,xj = (x
j
1, . . . , x
j
m))from every
Pj∈ P(1):
1. Run(P(h),P(1))-Bracket({xjh}j∈P(1))(see below), for everyh∈[m]. 2. Output∆i,{ki,j[xjh]}j∈P(1)\{i}to everyPi ∈ P(h)andxjh,{m
j,i
[xjh]}i∈P(h)\{j}to everyPj∈ P(1).
Key queries: Upon receiving(i, P) from the adversary, whereP is an efficiently com-putable predicate P : {0,1}` → {
0,1} and i ∈ P(h), output 1 to the adversary if
P(∆i) = 1. Otherwise, abort.
Fig. 5.Functionality for authenticated bits
In this section we describe our protocols for authenticating bits with short MAC keys. To capture the short keys used for authentication we need to define a series of different functionalities.
5.1 Authenticated Bit FunctionalityFaBit
We begin with the description of the ideal functionalityFaBitdescribed in Figure5that
formalises the MACs we create. Each partyPi ∈ P(h)chooses a global∆i ∈ {0,1}`, thenFaBit calls the subroutine(P(h),P(1))-Bracket(Figure6) that uses these global MAC keys{∆i}
i∈P(h)stored by the functionality to create pairwise MACs of the same
length, as illustrated in Section3.
5.2 Bit Authentication Protocol
We now present our bit authentication protocolΠaBit, described in Figure7,
implement-ing the functionalityFaBit(Figure5). The protocol first runs the∆-OT protocol with
short keys between every pair of parties inP(h)× P(1) to authenticate the additively shared inputs, in a standard manner. We then need to adapt the consistency check from the TinyOT-style authentication protocol presented by Hazay et al. ([HSS17]) to our setting of MACs with short keys distributed between two committees, to ensure that all parties input consistent values in all theCOTinstances.
Macro(P(h),P(1))-Bracket
On input{xj}
j∈P(1), authenticate the sharexj∈ {0,1}, for eachj∈ P(1), as follows:
PjCORRUPT: Receive a MACmj,i∈F`2fromAand compute the keys{ki,j=mj,i+xj·
∆i}
i∈(P(h)\{Pj}).
OTHERWISE:
1. Sample honest parties’ keyski,j←F`2, forPi∈ P(h)\(A∪ {Pj}).
2. Receive keyski,j∈
F`2, for eachPi∈A∩ P(h), from the adversary. 3. Compute the MACsmj,i=ki,j+xj·∆i, wherePi∈ P(h).
Output[x]P∆(h),P(1).
Fig. 6.Macro used byFaBitto authenticate bits
of the individual sharesxj. To see correctness when all parties are honest, notice that in
the first check, fori∈ P(h)we have:
zi+ X j∈(P(1)\{Pi})
zj,i= 0
⇐⇒ (yi+y)·∆i+ X j∈(P(1)\{Pi})
(ki,j[y] +mj,i[y]) = 0
⇐⇒ (yi+y)·∆i+ X j∈(P(1)\{Pi})
(yj·∆i) = 0 ⇐⇒ y·∆i+y·∆i= 0.
For a corrupt party who misbehaves during the protocol, there are two potential devia-tions:
1. A corruptPi, i ∈ P(Ah) provides an inconsistent∆
i,j when acting as a sender in
F∆m,`-ROTwith different honest parties, i.e.∆i6=∆i,jfor somej∈ P
(1)\A. 2. A corruptPj, j∈ P(1)A provides an inconsistent inputxi,jι when acting as a receiver
inF∆m,`-ROTwith different parties, i.e.xi
ι 6=xi,jι , for somej∈ P(h)\A.
Note that in the above, the ‘correct’ inputs∆i, xjι for a corruptPi ∈ P(h)orPj ∈
P(1)are defined to be those in theF∆-ROTinstance with some fixed, honest partyPi1 ∈
P(1)orPj1 ∈ P(h), respectively. We now prove the following two claims.
Claim 5.1 Assuming a non-abort execution, then for every corrupted party Pi, i ∈
PA
(h), all∆
iare consistent.
Proof: In order to ensure that all∆i are consistent we use the first check. More
pre-cisely, we fixPj ∈ P(Ah) and check that
P i∈[n]z
i,j = 0,∀j. Since we require that y ∈ {0,1}λ, the probability to pass the check is1/2λ. More formally, let us assume
that a corruptPj∗ uses inconsistent∆j,iinF∆-ROT with somei 6∈ P(Ah), then to pass
or in step3d, when committing to the valueszj,i. Lete
y ∈ {0,1}λdenote an additive
error so thatP i∈[n]y¯
i =y+e
y, and letez∈ {0,1}λdenote an additive error so that P
j∈PA
(h) ˆ
zj,i =P j∈PA
(h)z j,i+e
z. Finally, letδj,i = ∆j+∆j,i. Then if the check
passes, it holds that:
0 =X
i
zi,j =ez+zj+ X
i6=j
zi,j =ez+ (y+ey+yj)·∆j+ X
i6=j
yi·∆j,i
⇐⇒ ez+ey·∆j = X
i6=j
yi·δj,i,
which implies that the additive errorsez andey, that make the above equation equal
to zero, depend on the yi values, and that the adversary has to guess at least one of
them in order to pass the check. This event happens with probability2−λsince the only
information the adversary has about these values is that they are uniform additive shares
ofy, due to the randomization in step3c.
Claim 5.2 Assuming a non-abort execution, then for every corrupted party Pj, j ∈
PA
(1), allx
i,j
ι are consistent.
Proof: We need to check that a corruptP∗
j cannot input inconsistentxj,ito different
honest parties without being caught. For every ordered pair of parties(Pi, Pj), we can
definePj’s MACmj,i[y]andPi’s keyki,j[y]respectively as m
X
ι=1
χι·mj,i[xι] + λ X
k=1
Xk−1·mj,i[rk] and m
X
ι=1
χι·ki,j[xι] + λ X
k=1
Xk−1·ki,j[rk].
A corruptPj can commit to incorrect MACszˆj,i, so thatzˆj,i =zj,i+ej,iz andyˆ j
= yj,i+ej,iy . In order to have the check passed, we have:
zj,i+ej,iz =k[y]i,j+ (yj,i+ejy)·∆i, Which happens if and only if:
ej,iz + (yj,i+ejy)·∆i=mj,i[y] +k i,j [y] = m X ι=1
χι·(xjι +δ j,i ι ) +
λ X
k=1
Xk−1·(rkj+δ0kj,i)·∆i
⇐⇒ ej,iz = yj,i+ejy+ m X
ι=1
χι·(xjι +διj,i) + λ X
k=1
Xk−1·(rkj+δ0kj,i)·∆i
= (ejy+ m X
ι=1
χι·δj,iι + λ X
k=1
Xk−1·δ0kj,i)·∆i.
1. In caseej,i
z = (ejy+
Pm
ι=1χι·δj,iι + Pλ
k=1X
k−1·δ0j,i k )·∆
i6= 0the adversary needs
to guess∆i, which can only happen with probability2−`. Note that in order to pass
this check the adversary needs to guess all honest parties’ keys. This is due to the fact that a corruptedPjopens the sameyˆjto all parties, so if it cheats and provides
an inconsistent value then it must pass the above check with respect to all honest parties. Therefore, the overall probability of passing this check is2−`h≤2−λ.
2. In caseej,i
z = 0andejy=
Pm
ι=1χι·δj,iι + Pλ
k=1X
k−1·δ0j,i
k ,∀i6∈ P(1)A. Assuming that there is at least onei6∈ PA
(h)s.t.δ
j,i
ι =δi = 0(recall that we view the inputs
ofPjin the interaction with partyPj1as the ‘correct’ inputs, then there must be at
least one party for which this condition holds). This implies thatej
y = 0as well.
Thus, for everyi /∈ PA
(h)∪j1it needs to holds that
0 = m X
ι=1
χι·διj,i+ λ X
k=1
Xk−1·δk0j,i.
Since eachχιis uniformly random inF2λand independent of theδj,iι , δι0j,ivalues,
it is easy to see that this only holds with probability2−λif anyδj,i
ι is non-zero.
In the full version we prove the following theorem.
Theorem 5.1 ProtocolΠP(h),P(1),m,`
aBit securely implements the functionalityF
P(h),P(1),m,`
aBit
in the(F∆m,`-ROT,FRand,FCommit)-hybrid model.
5.3 Efficiency Analysis
ProtocolΠP(h),P(1),m,`
aBit
PARAMETERS:m, number of authenticated bits;`, key length.
Initialize: On input∆i
from eachPi ∈ P(h), every pair of parties(Pi, Pj) ∈ P(h)×
P(1), i6=jcallsF∆-ROT` functionality with input(Init, ∆
i
)fromPiand(Init)fromPj.
aBit: On input(xj1, . . . , xjm)∈ {0,1}mfrom eachPj∈ P(1):
1. EachPj∈ P(1)samplesλrandom bitsrkj, k∈[λ].
2. CallF`
∆-ROTwith inputs(xjι, r j
k)fromPj, soPjgetstj,iandPigetsqi,j, such that for
ι∈[m], k∈[λ],
tj,iι +q i,j
ι =x
j ι·∆
i
tj,ik +qi,jk =rkj·∆i
Forι∈[m], define[xι]P(h),P(1)as follows.
EachPi ∈ P(h) setski,j[xι] = qi,jι forj ∈ (P(1)\ {Pi})and eachPj ∈ P(1)sets
mj,i[xι] =tj,iι fori∈(P(h)\ {Pj}).
Fork ∈ [s], the parties define[rk]P(h),P(1): EachPi ∈ P(h) setski,j[rk] =qi,jk for
j∈(P(1)\ {Pi})and eachPj∈ P(1)setsmj,i[rk] =tj,ik fori∈(P(h)\ {Pj}).
3. Check consistency of the inputs as follows:
(a) CallFRandto obtainmfield elementsχι∈Fλ2, ι∈[m]. (b) Locally compute, overF2λ, the shares
[y]P(h),P(1) =
m
X
ι=1
χι·[xι]
P(h),P(1) +
λ
X
k=1
Xk−1·[rk]
P(h),P(1)
,
so that eachPj∈ P(1)holds a shareyj∈Fλ2, and MACs{mj,i[y]}i∈P(h)\Pjand
eachPi∈ P(h)holds keys{ki,j[y]}j∈P(1)\Pi.
(c) The parties inP(1)callFZero` so that eachPj ∈ P(1)obtains a zero-shareρj ∈
{0,1}`
.Pjthen broadcastsy¯j:=yj+ρj, and reconstructsy=Pj∈P
(1)y¯
j
. (d) EachPi ∈ P(h)defines and commits, to all parties inP(h), the following values.
Note thatyi= 0
ifPi∈ P/ (1):
zi= (yi+y)·∆i+ X
j∈P(1)\Pi
ki,j[y].
(e) EachPj∈ P(1)defines and commits, to all parties inP(h):
yj, {zj,i=mj,i[y]}i∈P(h)\Pj.
(f) Each party inP(h)∪ P(1)opens its commitments and parties inP(h)check that:
∀i∈ P(h), z
i
+ X
j∈P(1)\Pi
zj,i= 0
and
∀j∈ P(1), i∈ P(h)\Pj, zj,i=ki,j[y] +yj·∆i.
6
Actively Secure MPC Protocol with Short Keys
Similarly to prior constructions such as [DPSZ12,NNOB12,FKOS15,KOS16], our protocol is in the pre-processing model where the main difference is that the computa-tion is carried out via two random committeesP(h)andP(1). The preprocessing phase is function and input independent, and provides all the correlated randomness needed for the online phase where the function is securely evaluated .
6.1 The Online Phase
Our online protocol, shown in Figure 8, runs mostly as that of [DPSZ12,DKL+13] within a small committeeP(1)⊆ Pwith at least1honest party. The main difference is that we need the help of the biggerP(h) ⊆ Pcommittee with at leasthhonest parties to authenticate the inputs of anyPi ∈ P using the [·]P(h),P(1)-representation before
converting them to the more compactJ·K-representation described in Section3.2.
The Boolean MPC Protocol -ΠBBB
Prep: Parties callFPreprocessing with(Prep, m, M)to generatemrandom[·]P(h),P(1) bits andMrandom multiplication triples with compact MACs.
Input: To authenticate an inputxofPi∈ P:
1. Call the Private Open command in ΠPrivateOpenP(h),P(1),Pi on an unused bit ([r]P(h),P(1), P
i)fromPrep, so onlyPilearnsr.
2. Call theBatch Checkcommand inΠPrivateOpenP(h),P(1),Pion all the privately opened values in the previous step. If the check fails, abort.
3. Pibroadcastsd=x+rtoP(1), who compute[x] P(h),P(1)
= [r]P(h),P(1)+d.
4. CallΠMACCompacton input[x]P(h),P(1)to obtainJxK.
Add: On input(JxK,JyK), locally computeJx+yK=JxK+JyK. Multiply: On inputJxK,JyK, parties inP(1)do the following:
1. Pick an unused random multiplicative triple fromPrep(JaK,JbK,JcK).
2. ComputeJK=JxK+JaK, andJρK=JyK+JbKand callΠJOpenKon these to reveal
, ρtoP(1).
3. Parties setJx·yK=JcK+·JbK+ρ·JaK+·ρ.
Output: To output a valueJxKtoPor a subset of it, do the following: 1. CallBatchCheckonΠ
JOpenKfor allJ·Kvalues opened so far. If the check fails,
abort.
2. Call commandsOpenandSingle CheckofΠ
JOpenKon inputJxK. If the check fails,
abort, otherwise acceptxas a valid output.
Fig. 8.The Boolean MPC Protocol
6.2 The preprocessing Phase
The task ofFPreprocessing is to create random authenticated bits under the[·]P(h),P(1)
7
Triple Generation
Here we present our triple generation protocol implementing the functionality described in Figure9. First, protocolΠHalfAuthTriple(Figure11) implements the functionalityFHalfAuthTriple
(Figure 10) to compute cross terms in triples: each partyPi ∈ P(h) inputs random sharesyi
k, k ∈[m], and committeesP(h),P(1)obtain random representations[xk]∆as
well as shares of the cross terms defined byP i∈P(h)
P
j6=P(1)\{Pi}x
j k·y
i
k, k∈[m].
Given this intermediate functionality, protocolΠTriple(Figure12) implementsFTriplem,`
(Figure9) computing correct authenticated and non-leaky triples(JxkK,JykK,JzkK)such
that(P j∈P(1)x
j k)·(
P j∈P(1)y
j k) =
P j∈P(1)z
j
k. Checking correctness and removing
leakage is achieved using classic cut-and-choose and bucketing techniques. Note that even though the final triples are under the compactJ·K-representation we produce them first using[·]P(h),P(1)-representations in order togenerateMACs more efficiently and
having an efficient implementation ofFHalfAuthTriple.
It is crucial to note that the security ofΠHalfAuthTripleis based on the hardness of
RSD, and for this reason the number of triples rgenerated by this protocol depends on the security RSD. So while essentially an unlimited number of random correlated OTs and random authenticated bits can be produced as described on previous sections, a naive use of short keys would actually result in an upper bound on the number of triples that can be produced securely. To fix this issue, duringΠHalfAuthTriplewe make
the parties ‘switch the correlation’ on representations[x]∆, so they output a new
repre-sentation under an independent correlation[x]∆˜, with∆6= ˜∆being the relevant value for the RSD assumption. Finally, the fact that∆˜is short combined with the adversarial possibility of querying some predicates about it requires the reduction to use an inter-active version of RSD, which we denote byL-DRSDas in Definition2.1.
FunctionalityFm,`
Triple
PARAMETERS:m, number of multiplications;`, key length.
This functionality runs in committeeP(1)only.
On input(Triples, m, `)from all parties, generatemrandom authenticated triples as follows. Initialize: Receive∆ifrom the adversary for each corruptP
i∈ P(1)A and sample∆
i←
Fλ2 for eachPi∈ P(1)\ P(1)A.
Honest parties:
1. Sample random sharingsJxkK,JykK,JzkK, withxk, yk, zk ← {0,1}such thatzk =
xk·yk, k∈[m].
Corrupt parties: Corrupt parties choose their own randomness in the MAC shares.
7.1 Half Authenticated Triples
Here we show howΠP(h),P(1),r,`
HalfAuthTriplesecurely computes cross terms in triples. The main
difficulty arises from modelling the leakage due to using short keys in the real world, and proving that it cannot be distinguished from uniformly random. Looking at indi-vidual parties, security relies on the fact that on step6aof the protocolsi,jk is a fresh, random sharing of zero and henceyki,jis perfectly masked. Nevertheless, when consid-ering thejoint leakage from all honest parties, theL-DRSDassumption kicks in and requires a more thoughtful consideration.
Functionality for Half Authenticated Triples -FP(h),P(1),r,`
HalfAuthTriple
PARAMETERS:r, number of multiplications;`, key length. The functionality runs between a
set of partiesP={P1, . . . , Pn}, containing two (possibly overlapping) subsetsP(h),P(1), such thatP(h) has at leasthhonest parties andP(1) has at least one honest party and an adversaryA.
1. The functionality receives correlations ∆i from each Pi ∈ P(h), picks random [xk]
P(h),P(1)
∆ fork ∈ [r]and sends the relevant part of the representation to the
rele-vant parties.
2. The functionality receives bits{yki,j}j∈(P(1)\{Pi}),k∈[r]from eachPi ∈ P(h). Then it
samples random bits{vτ
k}τ∈(P(h)∪P(1)),k∈[r], such that:
X
τ∈(P(h)∪P(1))
vkτ=
X
i∈P(h) X
j∈(P(1)\{Pi})
xjk·yki,j,
and sendsvτk, k∈[r], toPτ ∈(P(h)∪ P(1)).
Global Key Queries: Upon receiving(i, P)fromA, wherePis an efficiently computable predicateP :{0,1}`→ {
0,1}, output 1 toAifP(∆i) = 1. Otherwise, output 0 toA
and abort.
Fig. 10.Functionality for Half Authenticated Triples
Security is showed in the following theorem, proved in the the full version.
Theorem 7.1. ProtocolΠP(h),P(1),r,`
HalfAuthTriplesecurely implementsF
P(h),P(1),r,`
HalfAuthTriplein the
(FaBit,FZero)-hybrid model as long asL-DRSDr,h,`is secure.
7.2 Correct Non-Leaky Authenticated Triples
Here we describe the protocolΠTriple(Figure12) to createmcorrect random
authenti-cated triples with compact MACsJxkK,JykK,JzkK,k∈[m].
First, parties inP(h)∪ P(1) callFaBit obtaining m0 = m·B2+c random
ProtocolΠP(h),P(1),r,`
HalfAuthTriple
REQUIRE:r, number of multiplications;`, key length. The protocol runs between a set of
partiesP ={P1, . . . , Pn}, containing two (possibly overlapping) subsetsP(h),P(1), such thatP(h)has at leasthhonest parties andP(1)has at least one honest party.
INPUT: From allPi∈ P(h):∆i∈F`2andyi,j = (y
i,j
1 , . . . , y
i,j
r )∈Fm2, wherejranges for everyPj∈ P(1)\ {Pi}.
COMMON INPUT: Random functionsHi,j : [r]× {0,1} × {0,1}` → {0,1}forPi ∈
P(h), Pj∈ P(1). OUTPUT: Values[x1]
P(h),P(1)
∆ , . . . ,[xr]
P(h),P(1)
∆ and sharesv j
1, . . . , v
j
rforPj∈ P(1).
1. Parties call FP(h),P(1),m,`
aBit on input random{x
j
k}k∈[r] from Pj ∈ P(1) to obtain [xk]
P(h),P(1)
∆ , k∈[r].
2. Parties initialize a newFP(h),P(1),r,`
aBit instance with∆
i+ ˜∆i
, and then call this on input the shares(xj1, . . . , x
j
r)to obtain[x1] P(h),P(1)
∆+ ˜∆ , . . . ,[xr]
P(h),P(1)
∆+ ˜∆ .
3. EachPi∈ P(h)setski,j∆˜[xk] =k
i,j
∆[xk] +ki,j∆+ ˜∆[xk]fork∈[r], j∈ {P(1)\Pi}.
4. EachPj∈ P(1)setsmj,i∆˜[xk] =m
j,i
∆[xk] +mj,i∆+ ˜∆[xk]fork∈[r], i∈ {P(h)\Pj}.
5. PartiesPi∈ P(h)callFZeroso that eachPiobtains shares{(si,j1 , . . . , s
i,j
r )}j∈P(1) s.t. P
i∈P(h)s
i,j
k = 0,∀k∈[r].
6. For eachk∈[r],Pi∈ P(h)andPj∈ P(1): (a) Pi∈ P(h)computes:
dki,j=Hi,j(k,0,k∆i,j˜[xk]) +Hi,j(k,1,k
i,j
˜
∆[xk] + ˜∆ i
) +yi,jk +si,jk ,
and privately sends it toPj, for eachPj∈(P(1)\ {Pi}).
(b) EachPj∈ P(1)computes, fori∈(P(h)\ {Pj}):
tj,ik =Hi,j(k, xjk,m j,i
˜
∆[xk]) +x j k·d
i,j k .
(c) EachPi∈ P(h)computes (wherexik=s i,i
k = 0ifPi∈ P/ (1)):
ti,ik =
X
j∈(P(1)\{Pi})
Hi,j(k,0,k∆i,j˜[xk]) +xik·s i,i k .
7. Parties inP(h)∪ P(1)callFZeroso that eachPτ obtains shares(ρτ1, . . . , ρτr)such that
P
τ∈(P(h)∪P(1))ρ
τ
k= 0,∀k∈[r].
8. Fork∈[r], eachPj∈ P(1)computesvjk=
P
i∈P(h)t
j,i
k +ρ
j
kand eachPi∈(P(h)\
P(1))setsvki =t i,i
k +ρ
i k.
Fig. 11.Protocol for Half Authenticated Triples
ΠTripleBucketing(Figure13). Then, eachPj ∈ P(1)reshares their valuesy
j
k to parties in
P(h)obtaining[ˆyk] P(h),P(h)
k∈m0 such thatPi∈P
(h)yˆ i
k=yk, k∈[m].
This allowsP(h)∪P(1)to callF
P(h),P(1),r,`
HalfAuthTriple mˆ =m/rtimes, on inputs{yˆ(ι−1)·r+k}k∈[r], for eachι ∈ mˆ. The outputs of each of these calls are the sharingsvτ
P(h)∪ P(1)andk∈[r], ofrcross terms products, i.e.
X
τ∈P(h)∪P(1)
v(τι−1)·r+k = X i∈P(h)
X
j∈P(1)
x(jι−1)·r+k·yˆi(ι−1)·r+k.
Notice that the number r of cross terms computed byFP(h),P(1),r,`
HalfAuthTripledepends on the
leaky DRSD problem, and for this reason the protocol needs to call the functionalitymˆ
times to obtain all them0outputs it needs.
After this, parties inP(h)reshare all thevki, k∈m0toP(1), so that eachPj∈ P(1)
getsvˆkj, k∈[m0], where
X
j∈P(1) ˆ
vjk= X j∈P(1)
xjk X
i∈P(1)\j
yik= X τ∈P(h)∪P(1)
vτk, (1)
so that parties inP(1)can locally add sharesxjk·yjktovˆkj obtainingzjk,k∈[m0].
Finally,P(h)∪ P(1) callFaBit to obtain [zk]P(h),P(1), and run theΠTripleBucketing
subprotocol. This subprotocol is similar to the bucket-based cut-and-choose technique introduced by Larraia et al. [LOS14] and optmized by Frederiksen et al. [FKOS15], but adapted to run with two committees. It takes as inputm0 = B2·m+c triples. First, in Step I and II, it ensures that all the triples are correctly generated sacrificing B·m·(B−1) +ctriples, and then (Step III) it uses random bucketing technique to remove potential leakage on thexkvalues obtainingmprivate and correct triples. All
the MACs on previously opened values are eventually checked (Step IV) calling the
Batch Checkcommmand inΠ[Open](Figure1). Finally, on that last step, the remaining triples are converted to SPDZ-style triples inP(1)usingΠMACCompact.
Correctness easily follows form the discussion above:
X
j∈P(1)
zkj = X j∈P(1)
xjk·ykj+ ˆvkj, (2)
whereˆvkj is the re-sharing insideP(1)ofFP(h),P(1),r,`
HalfAuthTriple’s output. More precisely, using
Equation1we can rewrite Equation2as follows:
X
j∈P(1)
zkj= X j∈P(1)
xjk·yjk+ X j∈P(1)
xjk· X
i∈P(1)\j
yik
= X
j∈P(1)
xjk· ykj+ X i∈P(1)\j
yki
= X
j∈P(1)
xjk
· X
j∈P(1)
yjk
.
Security is showed in the following theorem, proved in the full version.
Theorem 7.2. ProtocolΠTriplesecurely implementsFTriplem,` in the
(FRand,FaBit,F
P(h),P(1),r,`
HalfAuthTriple)-hybrid model.
Protocol for triples generation -ΠTriplem,r
PARAMETERS: LetB, cbe parameters as needed forΠTripleBucketingandm0 =m·B2+c.
Letrbe as needed for the security of the leaky DRSD problem inFP(h),P(1),r,`
HalfAuthTriple . Initialize:Parties initializeFaBitwhich outputs∆ito eachPi∈ P(h).
Triple Computation:
1. Parties inP(h)∪ P(1)callF
P(h),P(1),m0,`
aBit on input random{y
j
k}k∈[m0]fromPj∈ P(1) and obtains random authenticated shares{[yk]P(h),P(1)}k∈[m0].
2. Reshareyk, k∈[m0]fromP(1)toP(h)as follows: – EachPj ∈ P(1)\ P(h)secret sharesyjk =
P
i∈P(h)y
i,j
k and sendsy i,j k toPi ∈ P(h).
– EachPi∈ P(h)setsyˆki =yki+
P
j∈P(1)y
i,j
k , wherey i
k= 0ifPi∈ P/ (1). 3. Let mˆ = dm0/re. For ι ∈ [ ˆm], the parties call FP(h),P(1),r,`
HalfAuthTriple on input
{yˆi,j(ι−1)·r+k}k∈[r],j∈P(1)fromPi∈ P(h), whereyˆ(i,jι−1)·r+k = ˆy i
(ι−1)·r+k,∀j∈ P(1), to obtain random {[x(ι−1)·r+k]P(h),P(1)}k∈[r], and {vτ(ι−1)·r+k}τ∈P(h)∪P(1),k∈[r],
∀ι∈[ ˆm]. 4. Resharevτ
k, k∈[m
0
], fromP(h)∪ P(1)toP(1)as follows: – EachPi∈ P(h)\P(1)secret sharesvik=
P
j∈P(1)v
j,i
k and sendsv j,i
k toPj∈ P(1). – EachPj∈ P(1)setsˆvkj=v
j k+
P
i∈P(h)\P(1)v
j,i k .
5. Fork∈[m0]eachPj∈ P(1)computeszkj=x j k·y
j k⊕ˆv
j
k, wherey j
k= 0ifPj∈ P/ (h). Parties inP(h)∪P(1)callF
P(h),P(1),m0,`
aBit on input{z
j
k}k∈[m0]fromPj∈ P(1)to obtain
{[zk]P(h),P(1)}k∈[m0].
Triple Checking:RunΠTripleBucketingto outputmcorrect and secure triples.
SubprotocolΠTripleBucketing
The protocol takes as inputm0 = B2m+ctriples, which may be incorrect and/or have leakage on thexcomponent, and producesmtriples which are guaranteed to be correct and leakage-free.
Bdetermines the bucket size, whilstcdetermines the amount of cut-and-choose to be per-formed.
Input: Start with the shared triples{[xk]
P(h),P(1)
∆ ,[yk]
P(h),P(1)
∆ ,[zk]
P(h),P(1)
∆ }k∈[m0]. Output: Correct, leakage-free and SPDZ-style triples{JxkK,JykK,JzkK}k∈[m].
I: Cut-and-choose: UsingFRand, the parties select at random and openc triples using
Π[Open]P(h),P(1)(Figure1). If any triple is incorrect (i.e. ifx·y6=z), abort.
II: Check correctness:The parties now haveB2munopened triples.
1. UseFRandto sample a random permutation on{1, . . . , B2m}, and randomly assign the triples intomBbuckets of sizeB, accordingly.
2. For each bucket, check correctness of the first triple in the bucket, sayT= ([x],[y],[z]), by performing a pairwise sacrifice betweenTand every other triple in the bucket. Con-cretely, to check correctness ofT by sacrificingT0= ([x0],[y0],[z0]):
(a) Compute[d] = [x] + [x0]and[e] = [y] + [y0]and call(Open,[d],P(h)∪ P(1)), (Open,[e],P(h)∪ P(1))inΠ
P(h),P(1) [Open] .
(b) Using the opened values, compute[f] = [z] + [z0] +d·[y] +e·[x] +d·e. (c) Call(Open,[f],P(1))inΠ
P(h),P(1)
[Open] and check thatf= 0. Otherwise, the parties abort.
III: Remove leakage:Taking the first triple in each bucket from the previous step, the parties are left withBmtriples. They remove any potential leakage on the[x]bits of these as follows:
1. Place the triples intombuckets of sizeB.
2. For each bucket, combine allBtriples into a single triple. Specifically, combine the first triple([x],[y],[z])withT0= ([x0],[y0],[z0]), for every other tripleT0in the bucket:
(a) Compute[d] = [y] + [y0]and call(Open,[d],P(h)∪ P(1))inΠ P(h),P(1) [Open] . (b) Compute[z00] =d·[x0] + [z] + [z0]and[x00] = [x] + [x0].
(c) Output the triple[x00]P(h),P(1)
∆ ,[y]
P(h),P(1)
∆ ,[z
00
]P(h),P(1)
∆ .
IV: Check MACs and compact them:CallBatch CheckinΠ[Open]P(h),P(1)for every item that was opened in Steps I-III. If the batched MAC check fails, abort. Otherwise callΠMACCompact on input the first triple from each of thembuckets in the previous stage, which are renamed and output as{JxkK,JykK,JzkK}k∈[m].
8
Complexity Analysis
We now analyse the complexity of our protocol and compare it with the state-of-the-art actively secure MPC protocols with dishonest majority. As our online phase is essen-tially the same (even better) than that of SPDZ and TinyOT mixed with committees, we focus on the preprocessing phase.
Furthermore, since the underlying computational primitives in our protocol are very simple, the communication cost in the triple generation algorithm will be the overall bottleneck. We compare the communication cost of our triple generation algorithm with that of the corresponding multiparty Tiny-OT protocol by Wang et al. [WRK17b].
The main cost for producingmtriples in this work, is3mB2calls toF
aBit using
keys∆i ∈ {0,1}`, plusmB2calls toF
aBitusing new keys∆i+ ˜∆i ∈ {0,1}`every
rtriples. The latter calls under new keys are more expensive, as the setup costs that incurs is roughly128·`· |P(h)| · |P(1)|bits and is amortized only across thosertriples.
Measuring the cost ofFaBitafter setup as|P(h)| · |P(1)| ·`bits, we obtain an amortized
communication complexity ofB2· |P(h)| · |P(1)| ·`·(3 + (r+ 128)/r)bits per triple.
The main cost for producingmtriples in [WRK17b] is3mB calls to their long-key equivalent of FaBit with long keys, plus sending 2mB outputs of a hash
func-tion. On the other hand, all their communication is within the smaller committeeP(1). Their main (amortized) cost is then of B· |P(1)|2·128·(3 + 2)bits per triple. De-fineα=|P(h)|/|P(1)|. We can then conclude that the improvement in communication complexity of our work w.r.t. WRK is roughly that of a multiplicative factor of:
128·5
α·B·`·(4 + 128/r)
Given the total number of partiesnand honest partiesh, we first consider the case of two deterministic committeesP(h)andP(1)such that|P(h)|=nand|P(1)|=n−h+1,
respectively. To give a fair comparison, we have chosen the parameters in such a way thatn−h+ 1in our protocol is equal tonin WRK. The estimated amortized costs in kbit of producing triples are given in Table1. Notice that givennandh, the key lenght` and the number of triplesrare established according to the corresponding leaky-DRSD instance withκbits of security. We considerκ= 128and bucket sizeB= 3and4. As we can see from the table, the improvement of our protocol over WRK becomes greater as(n, h)increase (and`consequentely decreases). The key lenght greatly influ-ences the communication cost as a smaller`reduces significantly the cost of computing the pairwise OTs needed both for triple generation and authentication.
Whennis larger we can use random committeesP(h) andP(1) such that, except with negligible probability2−λ,P
(h)has at leasth2 ≤ hhonest parties andP(1) has at least 1 honest party. Let|P(h)| =n2,|P(1)| = n1 andλ = 64, Table2 compares the communication cost of our triple generation protocol with random committees with WRK, where we taken=n1.
![Fig. 3. Protocol for transforming [x]P(h),P(1) representations to �x� representations](https://thumb-us.123doks.com/thumbv2/123dok_us/7974944.1322435/12.612.136.479.103.348/fig-protocol-for-transforming-p-p-representations-representations.webp)
