Low Cost Constant Round MPC Combining BMR and Oblivious Transfer

Abstract

In this work, we present two new actively secure, constant-round multi-party computation (MPC) protocols with security against all-but-one corruptions. Our protocols both start with an actively secure MPC protocol, which may have linear round complexity in the depth of the circuit, and compile it into a constant-round protocol based on garbled circuits, with very low overhead.

• 1. Our first protocol takes a generic approach using any secret-sharing-based MPC protocol for binary circuits, and a correlated oblivious transfer functionality.

• 2. Our second protocol builds on secret-sharing-based MPC with information-theoretic MACs. This approach is less flexible, being based on a specific form of MPC, but requires no additional oblivious transfers to compute the garbled circuit.

In both approaches, the underlying secret-sharing-based protocol is only used for one actively secure $\mathbb {F}_2$ multiplication per AND gate. An interesting consequence of this is that, with current techniques, constant-round MPC for binary circuits is not much more expensive than practical, non-constant-round protocols. We demonstrate the practicality of our second protocol with an implementation and perform experiments with up to 9 parties securely computing the AES and SHA-256 circuits. Our running times improve upon the best possible performance with previous protocols in this setting by 60 times.

Protocol for GMW-Style MPC for Binary Circuits

Here, we describe the full protocol for realizing the $\mathcal {F}_{\scriptstyle \mathrm {n \text {-}TinyOT}}$ functionality. It essentially consists of the bit triple generation protocol from [22], with some minor modifications, and a method for producing random shared bits with a consistency check that is similar to the bit/string check from Sect. 3.3.

We first recall the two-party and n-party MAC representations from Sect. 4:

$$\begin{aligned} \begin{aligned}{}[x^i]_{i,j}&= (x^i, M_j^i, K_i^j) \\ [x]&= (x^i, \{M_j^i, K_j^i\}_{j \ne i}))_{i \in [n]}, \quad M_j^i = K_i^j + x^i \cdot R^j, \\ \end{aligned} \end{aligned}$$

where in the two-party sharing $[x^i]_{i,j}$, $P_i$ holds the share $x^i$ and MAC $M^i_j$, whilst $P_j$ holds the local key $K^j_i$ and a fixed, global key $R^j$. In the n-party sharing, each party $P_i$ holds $n-1$ MACs on $x^i$, as well as a key on $x^j$, for each $j \ne i$, and a global key $R^i$. Note that if $P_i$ holds $x^i$ and $P_j$ holds the key $R^j$, a sharing $[x^i]_{i,j}$ can easily be created using one call to the correlated OT functionality (Fig. 3), in which the correlation $R^j$ is fixed by $P_j$ in the initialization stage.

As required in the modified preprocessing protocol from Sect. 4, we need a method for opening [x]-shared values, both to all parties, and privately to a single party. These are straightforward, shown in Figs. 14 and 15.

Fig. 14

Subprotocol for opening and checking MACs on n-party authenticated secret shares

Fig. 15

Subprotocol for private opening to one party

The main protocol, shown in Fig. 16, consists of two main parts, for creating shared random bits, and for multiplication (AND) triples. Creating shared bits is straightforward, by using $\mathcal {F}_{\scriptstyle \mathrm {COT}}$ to MAC random bits, then opening a random linear combination of the MACs to ensure consistency.

To create shares of a random multiplication triple (x, y, z), each party first locally samples shares $x^i,y^i$ and then uses $\mathcal {F}_{\scriptstyle \mathrm {COT}}$ to authenticate these shares. The MAC on a share $x^i$ is used to obtain a sharing of the product of $x^i$ with a random bit $(u_\ell ^{i,j} + v_\ell ^{i,j})$ known to $P_j$ (using a hash function), and then $P_j$ converts this to a share of $x^i \cdot y^j$ by sending a correction bit in step 4a. This opens up an avenue for cheating, as $P_j$ may send an incorrect correction value to some $P_i$. This could result in the triple being correct, or, if $x^i=0$ the triple would still be correct but $P_j$ would learn the bit $x^i$. These issues are addressed by the bucket-based cut-and-choose procedure in Fig. 17, which first checks correctness by sacrificing triples and then removes any potential leakage on the x values by combining several triples together. Note that the complex bucketing procedure is necessary for these steps, as opposed to simple pairwise checks, because with triples over $\mathbb {F}_2$, one pairwise check (or leakage combiner) can only guarantee correctness (or remove leakage) if at least one of the two triples is correct (or leakage-free). So, the cut-and-choose and bucketing procedure are done so that each bucket contains at least one good triple, with overwhelming probability.

Fig. 16

Protocol for TinyOT-style secure multi-party computation of binary circuits

Fig. 17

Checking correctness and removing leakage from triples with cut-and-choose

Fig. 18

Subprotocol for multiplying secret shared values using a triple

1.1 Why the Need for Key Queries?

For completeness, we briefly explain why these are needed in $\mathcal {F}_{\scriptstyle \mathrm {n \text {-}TinyOT}}$, when using this protocol. After the protocol execution the environment learns the honest parties’ outputs, which include MAC keys $K_i$ and R. On the other hand, during the protocol the adversary sees values of the form (simplifying things slightly):

$$\begin{aligned} U = \textsf {H} (K_i) + \textsf {H} (K_i + R), \end{aligned}$$

where $\textsf {H}$ is modelled as a random oracle. In the security proof, U is simulated as a uniformly random value U, since the simulator, $\mathcal {S}$, does not know $K_i$ or $K_i + R$. This means that if the environment later queries both $K_i$ and $(K_i + R)$ to the random oracle, then they could distinguish, as $\mathcal {S}$ would not be able to detect this, so the response would be inconsistent with the simulated U. However, with a Key Query command in the functionality, the simulator can detect this (based on the technique from [39]):

• For each query Q, $\mathcal {S}$ looks up all previous queries $Q_i$, and sends $(Q + Q_i)$ to the Key Query of the functionality.

• If Key Query is successful then $\mathcal {S}$ knows that $Q + Q_i = R$, so can program the response $\textsf {H} (Q)$ such that $\textsf {H} (Q) + \textsf {H} (Q_i) = U$, as required (Fig. 18).

1.2 Security

In this section, we formalize the security of the implementation of the Prep command of $\mathcal {F}_{\scriptstyle \mathrm {n \text {-}TinyOT}}$ in our $\Pi _{\scriptstyle {\mathrm {n \text {-}TinyOT}}}$ protocol. More concretely, we focus on the consistency check in the production of m random bits. This guarantees that the MAC keys are consistent, after which the triple generation protocol can be proven secure similarly to [22]. The exact deviations that are possible by a corrupt $P_j$ in the bit generation are:

• 1. Provide inconsistent inputs $R^j$ when acting as sender in the Initialize command of the $\mathcal {F}_{\scriptstyle \mathrm {COT}}$ instances with two different honest parties.

• 2. Input inconsistent shares $b_\ell ^j, \ell \in [m]$ or $r_h^{j}, h \in [\kappa ]$ when acting as receiver in the Extend command of $\mathcal {F}_{\scriptstyle \mathrm {COT}}$ with two different honest parties.

Note that in both of these cases, we are only concerned when the other party in the $\mathcal {F}_{\scriptstyle \mathrm {COT}}$ execution is honest, as if both parties are corrupt, then $\mathcal {F}_{\scriptstyle \mathrm {COT}}$ does not need to be simulated in the security proof. We should also remark that preventing the first attack in the production of the random bits extends to preventing it everywhere else in the protocol, as the $R^j$ values are fixed in the Initialize phase.

These two attacks are modelled by defining $R^{j,i}, b_\ell ^{j,i}$ and $r_h^{j,i}$ to be the actual inputs used by a corrupt $P_j$ in the above two cases. Without loss of generality, we pick a honest party $P_{i_0}$ and fix $b_\ell ^j = b_\ell ^{j,i_0}, r_h^j = r_h^{j,i}, R^j = R^{j,i_0}$ to be the inputs by $P_j$ that should be consistent with every other honest party. Let I be the set of corrupted parties. For each $j \in I$, we can resume the previous statements by defining the values:

$$\begin{aligned} \begin{aligned} \Delta ^{j,i_0}&= 0,&\Delta ^{j,i}&= R^{j,i} + R^j, \quad i \notin (I \cup i_0) \\ \delta ^{j,i_0}_\ell&= 0,&\delta ^{j,i}_\ell&= b^{j,i}_\ell + b^j_\ell , \quad \ell \in [m], i \notin (I \cup i_0) \\ \hat{\delta }^{j,i_0}_\ell&= 0,&\hat{\delta }^{j,i}_h&= r^{j,i}_h + r^j_h, \quad h \in [\kappa ], i \notin (I \cup i_0). \\ \end{aligned} \end{aligned}$$

Note that $\Delta ^{j,i}$ is fixed in the initialization of $\mathcal {F}_{\scriptstyle \mathrm {COT}}$, whilst $\delta ^{j,i}_\ell$ may be different for every OT. Whenever $P_i$ and $P_j$ are both corrupt, or both honest, for convenience we define $\Delta ^{j,i} = 0$ and $\delta ^{j,i} = 0$. The above means that the outputs of $\mathcal {F}_{\scriptstyle \mathrm {COT}}$ with $(P_i,P_j)$ then satisfy:

$$\begin{aligned} M^j_{i}(b_\ell ^{j,i}) = K_{j}^i(b_\ell ^{j,i}) + b_\ell ^{j,i}, \cdot R^{i,j} \end{aligned}$$

or equivalently:

$$\begin{aligned} M^j_{i}(b_\ell ^j + \delta _\ell ^{j,i}) = K_{j}^i(b_\ell ^j + \delta _\ell ^{j,i}) + (b_\ell ^j + \delta _\ell ^{j,i}) \cdot (R^i + \Delta ^{i,j}), \end{aligned}$$

where $\delta ^{j,i} \ne 0$ if $P_j$ (the receiver) cheated, and $\Delta ^{i,j} \ne 0$ if $P_i$ (the sender) cheated. Remember from Sect. 4.1 that $M^j_i(b_\ell ^j + \delta _\ell ^{j,i})$ represents the receiver’s MAC on the value $b_\ell ^j + \delta _\ell ^{j,i}$ and $K_j^i(b_\ell ^j + \delta _\ell ^{j,i})$ and represents the sender’s MAC key on that same value.

We start by assuming that the corrupted party in the couple $(P_i, P_j)$ running $\mathcal {F}_{\scriptstyle \mathrm {COT}}$ is the sender $P_j$, trying to have inconsistent correlations $R^{j,i}$ with different honest parties $P_i, i \notin I$. We prove the inconsistency impossible in the next claim:

Claim A.1

If the Prep step of $\Pi _{\scriptstyle {\mathrm {n \text {-}TinyOT}}}$ succeeds, then all the global keys $R^j$ are consistent and well defined, i.e. $\Delta ^{j,i} = 0$ for every $i, j \in [n]$.

Proof

We enumerate the possible deviations by the Adversary affecting the check $\sum _{i=1}^n Z^i_j = 0$ in step 4g with which we want to catch inconsistent $R^{j,i}$ values to different honest parties. These possible disruptions are two:

In step 4e, the parties broadcast $\bar{C}^i$ values, every corrupted $P_\ell , \ell \in I$ can send instead some adversarial value $\hat{C}^\ell$ such that $\sum _{j=1}^n \hat{C}^j = C + e$, where e is some additive error of the Adversary’s choice. Finally, a similar active deviation is to commit to $\hat{Z}_j^\ell$ values, $\ell \in I$, in such a way that $\sum _{\ell \in I} \hat{Z}_j^\ell = \sum _{\ell \in I} Z_j^\ell + E^j$.

An active $P_j$ trying to cheat has to pass the aforementioned mentioned check, which becomes:

$$\begin{aligned} 0&= \sum _{i=1}^n \hat{Z}^i_j = E^j + Z^j_j + \sum _{i \ne j} Z^i_j = E^j \\&\quad + \left( \sum _{i \ne j} K^j_i(C^i) + (C + e + C^j) \cdot R^{j}\right) + \sum _{i \ne j} M^i_j(C^i) \\&=E^j + (C + e + C^j) \cdot R^{j} + \sum _{i \ne j} (K^j_i(C^i) + M^i_j(C^i)) \\&= E^j + (C + e + C^j) \cdot R^{j} + \sum _{i \ne j} C^i \cdot R^{j,i} \\&=E^j + (C + e + C^j + \sum _{i \ne j} C^i) \cdot R^{j} + \sum _{i \ne j} C^i \cdot \Delta ^{j,i} = E^j + e \cdot R^j + \sum _{i \ne j} C^i \cdot \Delta ^{j,i}. \end{aligned}$$

As having inconsistent keys requires that there exists $i_0, i_1 \notin I$ such that $\Delta ^{j,i_0} \ne \Delta ^{j,i_1} \ne 0$, the attack would require the adversary to set $E^j + e \cdot R^j = C^{i_0} \cdot \Delta ^{j,i_0} + C^{i_1} \cdot \Delta ^{j,i_1}$. But this is negligible in $\kappa$, as the only information the adversary has about $C^{i_0}, C^{i_1} \in \mathbb {F}_{2^\kappa }$ at the time of committing to the values $\hat{Z}_j^\ell , \ell \in I$ is that they are two uniform additive shares of C, due to the rerandomization in step 4d. $\square$

Finally, we prove that a corrupted receiver $P_j$ cannot input inconsistent values $b^{j,i}_\ell$ to different honest parties.

Claim A.2

If the Prep step of $\Pi _{\scriptstyle {\mathrm {n \text {-}TinyOT}}}$ succeeds, every ordered pair $(P_i, P_j)$ holds a secret sharing of $b_\ell ^j \cdot R^{i}$ for every $\ell \in [m]$. In other words, $\delta ^{j,i}_\ell =0$ for every $i, j, \ell$.

Proof

For every ordered pair $(P_i, P_j)$, we can define $P_j$’s MAC on $[C^j]_{j,i}$ as

$$\begin{aligned} M_i^j(C^j) = \sum _{\ell =1}^{m} \chi _\ell \cdot M^j_{i}(b_\ell ^{j,i}) + \sum _{h=1}^\kappa X^{h-1} \cdot M^j_i(r^{j,i}_h) \end{aligned}$$

and $P_i$’s key on the same value as:

$$\begin{aligned} {K}^i_j(C^j) = \sum _{\ell =1}^{m} \chi _\ell \cdot K_{j}^i(b_\ell ^{j,i}) + \sum _{h=1}^\kappa X^{h-1} \cdot K^i_j(r^{j,i}_h). \end{aligned}$$

In step 4f of Bits, an adversarial $P_j$ can also commit to incorrect MACs $\hat{Z}_i^j({c}^j) = M_i^j({c}^j) + E_i^j$ and $\hat{C}^j = C^j + e^j$. Nevertheless, in order to succeed an attack, the check $\hat{Z}_i^j = K^i_j(C^j) + \hat{C}^j \cdot R^i$ from step 4g would have to hold. This check implies the following:

$$\begin{aligned} \begin{aligned} M_i^j({C}^j) + E_i^j&= K^i_j(C^j) + ({C}^j + e^j)\cdot R^i\\ \Leftrightarrow E_i^j + ({C}^j + e^j) \cdot R^{i}&= M_i^j({C}^j) + K_j^i(C^j) = (\sum _{\ell =1}^{m} \chi _\ell \cdot b_\ell ^{j,i} + \sum _{h=1}^\kappa X^{h-1} \cdot r^{j,i}_h) \cdot R^{i}\\ \Leftrightarrow E_i^j&= \left( {C}^j + e^j + \sum _{\ell =1}^{m} \chi _\ell \cdot (b_\ell ^j + \delta _\ell ^{j,i}) + \sum _{h=1}^\kappa X^{h-1} \cdot (r^j_h + \hat{\delta }^{j,i}_h)\right) \cdot R^{i} \\&= (e^j + \sum _{\ell =1}^{m} \chi _\ell \cdot \delta _\ell ^{j,i} + \sum _{h=1}^\kappa X^{h-1} \cdot \hat{\delta }^{j,i}_h) \cdot R^{i}.\\ \end{aligned} \end{aligned}$$

An active $P_j$ has then just two options to cheat $P_i$, both with only probability $2^{-\kappa }$ to succeed:

• 1. Setting $E_i^j = (e^j + \sum _{\ell =1}^{m} \chi _\ell \cdot \delta _\ell ^{j,i} + \sum _{h=1}^\kappa X^{h-1} \cdot \hat{\delta }^{j,i}_h) \cdot R^{i} \ne 0$, which requires guessing the string $R^{i} \in \mathbb {F}_{2^\kappa }$ kept secret by the honest party $P_i$.

• 2. Setting $E_i^j = 0$ and $e_j = \sum _{\ell =1}^{m} \chi _\ell \cdot \delta _\ell ^{j,i} + \sum _{h=1}^\kappa X^{h-1} \cdot \hat{\delta }^{j,i}_h$ for every $i \notin I$. As $\delta ^{j,i_0}_\ell = \hat{\delta }^{j,i_0}_h = 0$, this implies that $e_j = 0$. Thus, for every $i \notin (I \cup i_0)$ it needs to hold that

  $$\begin{aligned} 0&= \sum _{\ell =1}^{m} \chi _\ell \cdot \delta _\ell ^{j,i} + \sum _{h=1}^\kappa X^{h-1} \cdot \hat{\delta }^{j,i}_h = \sum _{h=1}^\kappa X^{h-1} \cdot (\hat{\delta }^{j,i}_h + \sum _{\ell =1}^{m} \delta _\ell ^{j,i} \cdot \chi _{\ell , h} ), \end{aligned}$$

  where the $\chi _{\ell , h}$ values are defined in such a way that $\chi _\ell = \sum _{h=1}^\kappa X^{h-1} \cdot \chi _{\ell , h}$. This would need that, for every $h \in [\kappa ]$:

  $$\begin{aligned} \hat{\delta }^{j,i}_h = \sum _{\ell =1}^{m} \delta _\ell ^{j,i} \cdot \chi _{\ell , h} \in \mathbb {F}_2, \end{aligned}$$

  which can only happen with probability 1/2 for each of them, as $\chi _{\ell , h} \in \mathbb {F}_2$ are uniformly random sampled field elements after the deviations $\hat{\delta }^{j,i}_h, \delta _\ell ^{j,i}$ have been defined.

$\square$

1.3 Parameters

Based on the analysis from previous works [22, 23, 45], if roughly 1 million triples are created at once, then the buckets in the cut-and-choose stages can be of size $B = 3$, to guarantee security except with probability $2^{-40}$. The additional cut-and-choose parameter c can be as low as 3, so is insignificant as we initially need $m' = B^2m + c$ triples to produce m final triples.

1.4 Communication Complexity

Here, we analyse the communication complexity of $\Pi _{\scriptstyle {\mathrm {n \text {-}TinyOT}}}$. The cost of creating one shared random bit is the same as one invocation of the $\texttt {extend}$ command in $\mathcal {F}_{\scriptstyle \mathrm {COT}}$ between all pairs of parties, giving $n(n-1)(\kappa + s)$ bits. (We ignore the consistency check, since this cost amortizes away when creating many bits.)

The cost of one triple (not counting the bucketing stage) is 3 calls to $\mathcal {F}_{\scriptstyle \mathrm {COT}}$ between every pair of parties for authenticating shares of (x, y, z), plus sending one correction bit between every pair of parties, giving $n(n-1)(3(\kappa + s) + 1)$ bits. This is then multiplied by approximately $B^2$ to account for the bucketing. When creating a batch of at least a million triples (with $s=40$), we can set $B=3$, so the overall cost per party is around $(n-1)27\cdot (\kappa + s)$ bits.

We remark that when checking a large number of MACs using $\Pi _{\scriptstyle {\mathrm {Open}}}$ or $\Pi _{\scriptstyle {\mathrm {Open}}}^i$, the checks can be batched together, by first computing a random linear combination of all MACs, and checking the MAC on this, as in e.g. [17, 29]. This means that the cost of checking many MACs is roughly the cost of checking one, which is why we did not factor the MAC checks into the cost of the bucketing stage.

1.5 Round Complexity

Initializing the correlated OTs can be done with any two-round OT protocol. Extending the correlated OTs using [40] and [1] takes three rounds. Note that when authenticating random bits, the s additional bits in the consistency check can be created in parallel with the original m bits, giving an overall cost of five rounds for random bits.

The triple generation consists of one set of correlated OTs (2 + 3 rounds), plus one round, plus another round of correlated OTs (3 rounds). Then, there are two rounds for $\mathcal {F}_{\scriptstyle \mathrm {Rand}}$ in the bucketing (which can all be done in parallel), one round for the openings in step 2a and one round for step 2c. The openings in step 2a can be merged with the previous round. This gives a total of 13 rounds.

1.6 Realizing General Secure Computation

The previous protocol can easily be used to implement a general secure computation functionality such as $\mathcal {F}_{\scriptstyle \mathrm {Bit MPC}}$. The main feature missing is the ability for parties to provide inputs, since we only need to create random bits and triples for our application to garbled circuits. However, this is easy to do with a standard technique: if $P_i$ wishes to secret-share an input x, the parties do as follows:

• Create a shared random bit [b].

• Open b to $P_i$ using $\Pi _{\scriptstyle {\mathrm {Open}}}^i$.

• $P_i$ broadcasts $d = x - b$.

• All parties compute $[x] = [b] + d$.