Actively Secure OT Extension with Optimal Overhead

. We describe an actively secure OT extension protocol in the random oracle model with eﬃciency very close to the passively secure IKNP protocol of Ishai et al. (Crypto 2003). For computational security parameter κ , our protocol requires κ base OTs, and is the ﬁrst practical, actively secure protocol to match the cost of the passive IKNP extension in this regard. The added communication cost is only additive in O ( κ ), independent of the number of OTs being created, while the computation cost is essentially two ﬁnite ﬁeld operations per extended OT. We present implementation results that show our protocol takes no more than 5% more time than the passively secure IKNP extension, in both LAN and WAN environments, and thus is essentially optimal with respect to the passive protocol. Update, 2022: Roy (Crypto 2022) showed that Lemma 1, which the core of our proof relies on, is incorrect, so our protocol does not currently have a security proof. Roy also presented a protocol with an alternative consistency check and complete security proof, which also ﬁxes issues with instantiating the hash function raised earlier by Guo et al. (IEEE S&P 2020) and Masny and Rindal (ACM CCS 2019). In Section 4, we show how to ﬁx our protocol using the techniques by Roy.


Introduction
Oblivious transfer (OT) is a fundamental primitive in cryptography, used in the construction of a range of protocols. In particular, OT is sufficient and necessary for secure multi-party computation [28,11,16], and is also often used in specialpurpose protocols for tasks such as private set intersection [24]. Due to a result of Impagliazzo and Rudich [13] it is very unlikely that OT is possible without the use of public-key cryptography, so all OT constructions have quite a high cost when used in a practical context. tation costs, the overhead on top of IKNP is negligible: our protocol requires 2 finite field (of size κ) operations per extended OT, plus a small communication overhead of O(κ) bits in a constant number of rounds, independent of the number of OTs being performed, which amortizes away when creating many OTs. We give extensive benchmarks (in both LAN and WAN settings) showing that the practical cost of our protocol for performing 10 million OTs is less than 6% more than the IKNP extension, and so is almost optimal. In contrast, the protocol of Asharov et al. [2] takes at least 80% more time than the passive protocol in the WAN setting and over 20% more in the LAN setting for 2 23 OTs, according to their implementation figures.
The comparison table below shows the concrete efficiency of various other OT extension protocols, in terms of the number of base OTs required and the total communication and computation cost for creating OTs. Our protocol is more efficient than all previous protocols in all of these measures. Note that these comparisons are for OT extensions on strings of length at least κ bits. For shorter strings, the passively secure protocol of Kolesnikov and Kumaresan [17] is more efficient, but it does not seem straightforward to apply our techniques to obtain an actively secure protocol in that setting. We also omit the protocol of Ishai et al. [15], since although asymptotically this has only a constant overhead, the protocol is based on the 'MPC-in-the-head' technique, which has not been shown to be practical.
Our protocol is similar in structure to previous protocols [22,2], in that we carry out one run of the passively secure IKNP extension, and then use a correlation check to enforce correct behavior. As in the previous protocols, it is possible that a cheating receiver may pass our check, in which case some information on the sender's secret is leaked. However, the leakage is such that we still only need κ base OTs, and then must sacrifice κ + s of the extended OTs produced from the IKNP extension, where s is a statistical security parameter, to ensure security. The check itself is extremely simple and only requires a constant number of hash computations on a fixed input length, unlike previous checks where the amount of data being hashed increases with the number of extended OTs.
Random Oracle Usage. We prove our OT extension protocol secure in the random oracle model, used for a functionality F Rand , which securely generates random values, and the hash function H used to randomize the correlated OT outputs. For the function H, Ishai et al. [14] prove security of their protocol in the standard model, under the assumption that H is a correlation robust function. The protocol of Asharov et al. [2] is proven secure with the additional requirement that H satisfies some kind of leakage resilience, and it is conjectured that the protocol of Nielsen et al. [22] is also secure in this model.
Note that in the case of random OT, where the sender's outputs are defined as randomly chosen by the functionality, the security of the protocol (using the optimization of Asharov et al. [1], which cuts the communication in half) has only ever been proven in the random oracle model, because of the need for the simulator to program the receiver's outputs from H to be as defined by the functionality. Random OT can be used for an offline/online scenario where random OTs are generated in advance of the inputs being known, and is also often used in practical protocols (e.g. [24,22]), so we take the pragmatic approach of using random oracles for our security proofs, which also simplifies the exposition. However, due to the similarities between our protocol and previous ones [2,22], we believe it is likely that our (non-random) OT extension protocol can also be proven secure under a form of correlation robustness for H.

Notation
We denote by κ the computational security parameter and by s the statistical security parameter. We let negl(κ) denote some unspecified function f (κ), such that f = o(κ −c ) for every fixed constant c, saying that such a function is negligible in κ. We say that a probability is overwhelming in κ if it is 1−negl(κ). We denote by a $ ← A the random sampling of a from a distribution A, and by [d] the set of elements {1, . . . d}.
Throughout the proofs we will often identify F κ 2 with the finite field F 2 κ . Addition is the same in both; we will use " · " for multiplication in F 2 κ and " * " for the component-wise product in F κ 2 . We use lower case letters to denote elements in F 2 and bold lower case letters for vectors in F κ 2 and elements in F 2 κ . We will use the notation v[i] to denote the i-th entry of v. Given a matrix A, we denote its rows by subindices a i and its columns by superindices a k . Given a vector v ∈ F κ 2 , we denote byv the vector in F κ 2 such that v +v = 1. We say that a vector , for each i, j ∈ [κ]; otherwise we say it is polychrome.
In our proofs we often use the notion of affine space. We recall that an affine space is a set X that admits a free transitive action of a vector space V .

Oblivious Transfer and OT extension
Oblivious transfer (OT) [27,25,10,4] is a two-party protocol between a sender S and a receiver R. The sender transmits part of its input to R, in such a way that S remains oblivious as what part of its input was transmitted and R does not obtain more information than it is entitled.
We use three main oblivious transfer functionalities. We denote by F OT the standard 2 1 -OT functionality, where the sender S inputs two messages v 0 , v 1 ∈ F κ 2 , and the receiver inputs a choice bit x, and at the end of the protocol R learns only the selected message v x . We use the notation F κ, OT to denote the functionality that provides 2 1 -OTs of messages in F κ 2 (see Fig. 1 for a formal definition). Another variant of OT is correlated OT, where the sender's messages are correlated, i.e. v 0 + v 1 = ∆ for a fixed ∆ ∈ F κ 2 ; in Fig. 3 we give a version of this functionality which allows "errors". Finally, in the random OT functionality , F ROT , the messages v 0 , v 1 are sampled uniformly at random by the functionality (Fig. 7).

OT
F running with R, S and an adversary S proceeds as follows:

COTe
The functionality is parametrized by the number of resulting OTs and by the key length κ. Running with parties S, R, and an adversary A it operates as follows.
Initialize: Upon receiving ∆ from S, where ∆ ∈ F2κ , the functionality stores ∆. Extend: -Upon receiving (x1, . . . , x ) from R, where xi ∈ F2κ , sample tj ∈ F2κ , j = 1, . . . , , and output them to R. Compute qj = tj + xj * ∆, j = 1, . . . , , and output them to S. -If R is corrupt, wait for A to input tj and output as before.  Fig. 2, we model the IKNP extension as a separate functionality, F COTe that incorporates a cheating receiver's behavior, and call this correlated OT with errors. Fig. 3 gives the implementation of this functionality: after the first phase and the local expansion of the seeds through a pseudorandom generator PRG, R holds two × κ matrices , while S holds the vector ∆ ∈ F κ 2 and the matrix {t i ∆i } i∈ [κ] . In the extension phase, we allow a cheating receiver R to input vectors x 1 , . . . , x ∈ F κ 2 , instead of inputting bits x 1 , . . . , x . To better understand this situation we can imagine R inputting an × κ matrix X, having x 1 , . . . , x ∈ F κ 2 as rows and x 1 , . . . , x κ ∈ F 2 as columns. If R is honest then x 1 = · · · = x κ and the rows x j are "monochrome" vectors, i.e. consisting either of all 0's or all 1's. At this point the receiver computes u i = t i . Clearly, if R is honest, they send the same vector x i for each i. After this step S computes having q i as columns and q j = t 0,j +x j * ∆ as rows. If x j is monochrome, i.e x j = x j ·(1, . . . , 1), then q j = t 0,j + x j · ∆, otherwise, rewriting x j as x j = x j · (1, . . . , 1) + e j , we get q j = t 0,j + x j · ∆ + e j * ∆, where e j is an "error" vector counting the number of positions in which R cheated.
Notice that, compared with the original IKNP protocol, the protocol COTe stops before hashing the output with the random oracle to break the correlation and performing the final round of communication. It is easy to see (and was shown e.g. by Nielsen [21]) that the protocol for COTe (given in Fig. 3) securely implements this functionality.

Our Actively Secure OT Extension Protocol
In this section we describe our protocol for actively secure OT extension based on the passive IKNP functionality, F COTe . We recall that to deal with malicious adversaries, all the known actively secure OT extension protocols add a consistency check to the passive secure IKNP protocol to ensure that R inputs consistent values.
For example, in previous works [22,2] this check is added before the "extension" phase, i.e. before the sender S "reverses" the base OTs and breaks the correlation, effectively checking on the OT seeds. In our construction we check the correlation for consistency after the extension step, precisely after the execution of COTe, actually checking the extended OTs.
The high level idea of our protocol in Fig. 7 is to perform a simple correlation check to ensure that the receiver used the same vector x i for each u i sent in Step 3 of the IKNP extension. If the check passes, then the correlated OTs are hashed to obtain random OTs. This check requires sacrificing κ + s extended OTs to ensure security, so we obtain a reduction from F κ, ROT to F κ, COTe , with = +(κ+s). The intuition in this reduction is that, if the check passes, the adversary can only learn few bits of the correlation vector ∆, and hence the values H(q j + ∆) are actually random except with negligible probability. Finally, if required, the Protocol for COTe κ, Initialize: This is independent of inputs and only needs to be done once.
Output: R outputs tj, S outputs qj and ∆.      random OTs obtained from ROT can be derandomized with an additional set of messages from the sender, using the standard reduction from F κ, OT to F κ, ROT . The relationship between all the functionalities used are described in Fig. 4. The first stage to F COTe essentially consists of the IKNP OT extension protocol (with some modifications from the protocol by Asharov et al. [1]) that we have seen in the previous section.

Protocol from COTe to ROT
Here we describe the protocol implementing the F κ, ROT functionality in Fig. 6. The main idea of our construction is to use a variant of the MAC check protocol from SPDZ [7], adapted for two parties where one party holds the MAC key, to check the correlation is consistent. The correlation check is performed on the correlated OTs of length κ output by F κ, COTe , i.e. after the vectors have been transposed. Recall that after running F COTe , the sender S has ∆, q 1 , . . . , q ∈ F κ 2 and the receiver R has x 1 , . . . , To carry out the check, both parties first securely generate random weights χ 1 , . . . , χ ∈ F κ 2 , and then compute weighted sums of their outputs from F COTe . Then R sends these values to S to check consistency with S's output. So, R computes x = j=1 x j · χ j , t = j=1 t j · χ j and S computes q = j=1 q j · χ j , where the vectors t j , q j , χ j are viewed as elements of F 2 κ and multiplications are performed in this finite field. S then checks that q = t + x · ∆.
Clearly, by linearity of the correlated OT output, the check will always pass for an honest receiver. If R is corrupted then it is possible they may pass the check despite having used polychromatic x j vectors; in this case they will learn

ROT
The functionality is parametrized by the number of resulting OTs and by the length of the OT strings κ. Running with parties S, R and an ideal adversary denoted by S, it operates as follows.
-If R is corrupt: if S inputs Abort, F sends Abort to S and it halts. Otherwise it waits for S to input xj for all j ∈ [ ]. Then it samples random (v0,j, v1,j), j ∈ [ ] and outputs them to S. It also sends vx j ,j to S for all j ∈ [ ]. -If S is corrupt it waits for S to input (v0,j, v1,j), j ∈ [ ], and then outputs as above using these values. ROT some information about ∆. We show that this leakage is optimal, in the sense that a cheating receiver can learn c bits of information on ∆ with at most probability 2 −c , and the possible errors in the resulting OTs do not provide the adversary with any further useful information. Looking ahead to the proof, the success probability of a receiver who passes the check in breaking the resulting OTs with q = poly(κ) queries to H will therefore be q/2 κ−c , giving an overall success probability of q/2 κ . This implies that κ base OTs suffice for computational security κ.
On the other hand, if the sender is corrupted, our correlation check introduces the possibility that the values of x and t could leak information about R's input bits x 1 , . . . , x . However, we show that it suffices to perform κ+s additional OTs with random choice bits to counter against this leakage, for statistical security s. Overall, this means our protocol requires only κ base OTs, which is optimal with respect to the IKNP extension, and an additive overhead of s + κ extended OTs, regardless of the number of OTs required, as well as just O(κ) additional communication in a constant number of rounds.

Analysis of the Correlation Check
Corrupt Sender. To ensure that the correlation check step is secure against a corrupt sender we must carefully choose the parameter , which determines the size of the batch each check is performed on. Recall that the elements in the field F are κ bits long; if ≤ κ then it is likely that the secret bits x j will be uniquely determined given χ j and x, so an adversary could attempt to solve the corresponding knapsack problem to recover these. As we will see in the proof in Theorem 1, to thwart this attack, we use a technical lemma giving a bound on the rank of a random binary matrix. This is also the reason why we do not let the sender sample {χ j } j=1 .
Corrupt Receiver. The case of a corrupt receiver is much more involved. We now investigate a cheating receiver's success probability in the correlation check stage of the ROT protocol in Fig. 7. Let x 1 , . . . , x be the vectors in F κ 2 input by R during the protocol. Taking these to be the rows of a × κ matrix, let x 1 , . . . , x κ be the columns of the same matrix, in F 2 . If R was honest then {x j } j∈[ ] are all monochrome and {x i } i∈ [κ] are all equal. The following Lemma gives the main properties needed from our correlation check.
Protocol for ROT κ, COTe , henceforth denoted as F COTe .
xj · χj and t = j=1 tj · χj and sends these to S.
i . -k ≤ |H s |, and |{∆ Hs } ∆∈S ∆ | = 2 k , where ∆ Hs denotes the vector consisting of the bits {∆ i } i∈Hs . In other words, S ∆ restricted to the bits corresponding to H s has entropy at least k. Furthermore, there existsŝ such that k ≤ |Hŝ|.
Proof. Roy [26] proved the lemma to be false.
We now give some intuition about the meaning of this statement. The set S ∆ is the set of all possible values of ∆ with which the correlation check could pass -note that since ∆ is uniformly random to the receiver, their probability of passing the check is therefore |S ∆ |/2 κ . For some vector s ∈ {x i } i∈[κ] , the set H s represents indices of all of the vectors equal to s. Clearly, for an honest receiver, H s is always just the set {1, . . . , κ}, and so the size of H s measures the amount of deviation in the protocol for a given s. The precise indices in H s are also important, as they correspond to a subset of the bits of the secret ∆, which could be learnt using 2 |Hs| queries to the hash function (causing the simulation to abort in our security proof).
The second part of the lemma implies that for any s, either the bits of ∆ corresponding to the indices in H s are constant for all possible ∆ ∈ S ∆ , or, the size of H s is at least k, which means the corresponding abort in the simulation occurs with probability at least 1−2 −k+κ . Clearly in the first case, the adversary gains no new information, but in the second case we have a bound on the amount of information an adversary can learn, which directly corresponds to the size of the set S ∆ , and hence also the success probability in the correlation check. The final part of the Lemma, concerningŝ, simply states that there is always a vector s that satisfies the second condition, so at least one block of k bits of ∆ remains hidden. A careful analysis of these possible deviations allows us to show that κ base OTs suffice for our protocol.

Proof of Security
Theorem 1. The protocol in Fig. 7 securely implements the F κ, ROT functionality in the (F COTe , F Rand , F RO )-hybrid model with computational security parameter κ.
The computational security parameter κ manifests itself in that the adversary is only allowed poly(κ) calls of the random oracle in the proof. Other than that, the simulation is statistically indistinguishable.

Simulator for ROT ,κ
Initialize: If S is corrupt, receive ∆ ∈ F2κ from A and store ∆. OT extension: For the sake of simplicity we describe separately the case when R is corrupt and the case when S is corrupt. -If the input is (j tj + xj * ∆ + xj · ∆), return vx j ,j .
3. Compute q = j=1 qj · χj, sample random x ∈ F2κ and compute t = q + x · ∆. 4. Output whatever A outputs and halt. Proof. We construct a simulator S that has access to F ROT , and show that no environment Z can distinguish between an interaction with S and F ROT and an interaction with the real adversary A and the real parties. To simulate a real world execution of the protocol, S starts an internal copy of A and runs an internal copy of the protocol with dummy parties π S and π R , as shown in Figure  8.
First we deal with the (simpler) case of a corrupt sender. Since the simulator gets the sender's secret ∆, it is straightforward to construct x and t that will pass the check. All we need to do is argue indistinguishability from the real world execution. We need the following lemma.
Lemma 2. Let A be a random (κ + m) × κ matrix over F 2 , where m > 0. Then A has rank κ except with probability less than 2 −m .

Proof. See Section A.
Recall that in the real world the sender receives The second summation corresponds to the image of a linear map from F − 2 = F κ+s 2 to F κ 2 . From Lemma 2, it follows that this map has full rank with probability 1 − 2 −s . In this case, the second summation is uniformly random in F 2 κ because (x +1 , . . . , x ) were chosen uniformly at random by R, and so indistinguishable from the simulated random x. Finally, t has the same distribution in both worlds because there is only one t fulfilling the equation q = t + x · ∆.
We now consider the case of R being corrupted. In steps 1-4, S simply emulates F COTe and the correlation check, choosing random values for the dummy sender's input. Lemma 1 states that (except with negligible probability) |S ∆ | = 2 k for some k ∈ N. For every s ∈ {x i } i∈[κ] , let H s = {i ∈ [κ] | s = x i } andŝ as in Lemma 1. Recall that the adversary knows (t j , x j ) such that t j = q j + x j * ∆. If x 1 , . . . , x are the bits ofŝ then this can be expressed as t j = q j + x j · ∆ + e j * ∆, where e j = (x j , . . . , x j )+x j is an adversarially chosen error vector. By definition, In step 7, the simulator responds to the adversary's random oracle queries. Notice that it is the queries q j = t j + x j * ∆ and q j + ∆ = t j + x j * ∆ that require the reply conforming to the output of F κ, ROT . The simulator knows v xj ,j , which is the output of H(j q j + x j · ∆) in the real-world protocol. On the other hand, if the adversary queries (j q j + x j · ∆), the simulator cannot give the right output and thus aborts.
We now investigate the probability that this happens, given that the correlation check has passed. It holds that For i ∈ Hŝ, x j [i] = x j and thus (x j + (x j , . . . , x j )[i] = 1. By Lemma 1, there are |S ∆ | = 2 k possibilities for (x j + (x j , . . . , x j )) * ∆ and hence q j + x j · ∆, given ∆ ∈ S ∆ . Therefore, the probability of one such query is 2 −k .
However, we must also show that the environment cannot learn any additional information from previous queries. For example, when R queries q j +x j ·∆ to get their correct OT output, the environment (who sees the honest sender output so can verify this has occurred) can learn e j * ∆ by computing q j +x j ·∆+t j . By definition, the bits of e j corresponding to any index set H s are constant. Furthermore, Lemma 1 states that either ∆ for all ∆ (1) , ∆ (2) ∈ S ∆ and i ∈ H s or |H s | ≥ k. In the first case, e j [i] · ∆ i is known by the fact that ∆ ∈ S ∆ . In the second case, consider that e j [i] is the same for all i ∈ H s . If e j [i] = 0 for all i ∈ H s , then e j [i] · ∆ i = 0 for all i ∈ H s . On the other hand, if e j [i] = 1, there are 2 k possibilities for e j * ∆ (given ∆ ∈ S ∆ as above) and thus for q j + x j · ∆. Hence, either the latter is known to the adversary already or the probability of querying it is 2 −k per query.
It follows that the probability the simulation aborts after the correlation check has passed is at most q · 2 −k , where q is the number of queries made by the environment. Now taking into account the fact that the check passes with probability |S ∆ | · 2 −κ + 2 −κ = 2 −κ · (2 k + 1), the overall success probability of distinguishing is at most q · 2 −κ · (1 + 2 −k ), which is negligible in κ.

From ROT to OT
Finally we show how to reduce F κ, OT to F κ, ROT .
Lemma 3. The protocol in Fig. 9 securely implements the F κ, OT functionality in the F κ, ROT -hybrid model.
Proof. It is easy to describe a simulator for a corrupt R. S runs a copy of A setting dummy parties π R and π S and then simulates for them a real execution of DeROT, running an internal copy of F ROT . We just need to show indistinguishably of the transcripts and of the outputs. In both worlds, {d xi,i } i∈[ ] and {v xi,i } i∈[ ] are distributed uniformly subject to the condition d xi,i + v xi,i = y xi,i for all i ∈ [ ], as the pads v 0,i and v 1,i provided by F ROT are random and independent of R's view, except with negligible probability.

Fixing the Consistency Check with SoftSpokenOT
As pointed out by Roy [26], the protocol from Fig. 7 is not as secure as we originally claimed, because Lemma 1 is incorrect and in certain cases a malicious receiver can break security. Roy presented a general protocol, called SoftSpo-kenOT, which addresses this issue, whilst also incorporating other improvements.
Protocol DeROT κ, 1. The parties run ROT κ, with R inputting x = (x1, . . . , x ) In Figure 10, to illustrate what we view as a straightforward way to fix our protocol, we show a simplified version of SoftSpokenOT for the case of 1-out-of-2 OT. We have not included various optimizations for reducing communication and computation.
Relation with SoftSpokenOT. [26] builds OT extension by first constructing subspace VOLE, which is a generalization of correlated OT, and then converting these into random OT. Subspace VOLE is defined over F k C p , where p is prime and C is a linear code with dimension k C . Subspace VOLE is then converted into random 1-out-of-p k C OT through hashing.
Steps 1-4 of the Extend phase in Figure 10 correspond to building a passively secure subspace VOLE (as in [26,) with p = q = 2 and C the repetition code with dimension k C = 1 and length n C = κ (larger values of q are used for an optimization that reduces communication). The consistency check in Figure 10 is the same as the consistency check in [26,Fig. 9], with k C = 1 and the linear universal hash function R given by where χ ∈ F m 2 s is the random seed defining the hash function. This is an F 2linear hash function, since multiplication in F 2 s is F 2 -linear, so defines a matrix R ∈ F s× 2 , which is F 2 -hiding [26, Definition 4.1] as required.
Instantiating the Hash Function. Care needs to be taken when choosing how to implement the hash function H. Subsequently to this paper, various works [12,20,26] pointed out that it is critical to include the index j as input to H, to prevent attacks. While a standard hash such as SHA-256 or SHA-3 should suffice, it is often more efficient to use a construction based on AES for fixed input lengths, since AES is commonly supported in hardware on modern CPUs. Guo et al. [12] showed that is a tweakable correlation robust hash function if π is modeled as an ideal cipher (which may in practice be implemented with fixed-key AES).

S computes
and checks that q i = t i + ∆i · x, for all i = 1, . . . , κ. If any check fails, output Abort.
Transpose and randomize: 1. Let qj denote the j-th row of the × κ bit matrix [q 1 | . . .   10. A simple instantiation of SoftSpokenOT [26], which fixes the issue with the consistency check of Fig. 7 More efficient instantiations can be obtained by combining the ideal cipher with a universal hash function [6,26], reducing the cost to as little as one call to π for each call to H.

Implementation
In this section, we evaluate the efficiency of our random OT extension protocol. As was done in previous works [1,2], we tested the protocol in a standard LAN setting and a simulated WAN environment, using the Linux tc tool to create an average round-trip-time of 100 ms (with standard deviation 1 ms) and limit bandwidth to 50 Mbps (comparable with the setting reported by Asharov et al. [2]). We used computational security parameter κ = 128 and statistical security parameter s = 64 throughout, and instantiated the PRG with AES-128 in counter mode (using Intel AES-NI) and the random oracle H with SHA-1. F Rand is implemented using a standard hash-based commitment scheme, where both parties commit to and then open a seed, then the XOR of the two values is used to seed a PRG, which is UC-secure in the random oracle model.
Our implementation was written in C++ using the Miracl library for elliptic curve arithmetic in the base OTs, which were executed using the actively secure protocol of Peikert et al. [23]. All benchmarks were taken as an average of 20 runs on Intel Core i7-3770S 3.1 GHz processors with 8 cores and 32 GB of memory. Implementation Optimizations. The correlation check stage of our protocol requires computing values of the form i x i ·y i where x i , y i ∈ F 2 κ . We used Intel PCLMUL instructions to efficiently compute carryless multiplications and then performed summations and the check itself in the polynomial ring (of length 2κ − 1) to avoid having to do expensive reduction by the finite field polynomial.
As was done by Asharov et al. [1], we use Eklundh's algorithm for transposing the matrices T and Q during the COTe protocol in a cache-friendly manner, which makes the time spent in this stage less than 3% of the total runtime. Our implementation also supports multi-threading, making use of the 8 cores available on our test machines. Table 2 shows the time taken for our implementation to compute 10 million OT extensions (excluding the base OTs) in a variety of settings. The one-directional setting is a traditional OT between a sender and a receiver, whilst in the bidirectional times, both parties perform both roles simultaneously (for a total of 20 million OTs). The bi-directional variant is often required for secure twoparty and multi-party computation protocols, and over a LAN is much more efficient than performing the one-directional protocol twice, but less so in the WAN setting where communication is the bottleneck.

Comparison of Protocols
The passive protocol is just the standard IKNP extension (with the random OT communication optimization of Asharov et al. [1]), which is essentially our  Table 2. Random OT extension runtimes in seconds, using either 1 or 8 threads. The one-directional time is for 10 million OTs between a sender and receiver, whilst for the bi-directional time both parties are playing each role for a total of 20 million OTs.
protocol without the correlation check. In the LAN setting, the time difference between the active and passive protocols is less than 5%. The WAN times for the passive and active protocols are very similar, however it should be noted that there was more variation in our WAN experiments -computing 95% confidence intervals for these means in the table gives a variation of up to ±3%. This is probably mostly due to network variation and can be taken as evidence that our protocol has roughly the same performance as the passive IKNP extension. The total amount of data sent (in all protocols) is almost identical, due to the very low overhead of our correlation check. Compared with the reported timings for the protocol of Asharov et al. [2], our runtimes are much improved: their actively secure times are between 40% and 80% higher than their passive implementation, whilst ours almost match the efficiency of the passive protocol. (We do not directly compare figures due to the different benchmarking environments involved.) Fig. 11 illustrates the performance of our protocol as the number of OTs computed varies, in both the WAN and LAN settings, tested in the one-directional and bi-directional modes of OT operation. Fig.12 presents profiling results for the main components of our protocol, run in a single thread creating 10 million OTs. It clearly demonstrates that the bottleneck of our protocol is communication from the IKNP extension phase, as was reported for the passive secure implementation of Asharov et al. [1]. The correlation check that we require for active security has a negligible impact on the runtime; the best way to further optimize our implementation in the LAN setting would be to target the hash function computations. The 'Other' section includes overhead from PRG computations, matrix transposition and allocating memory, which could also potentially be reduced a small amount.