Commodity-Based 2PC for Arithmetic Circuits

Abstract

We revisit the framework of Commodity-based Cryptography presented by Beaver (STOC’97) with a focus on updating the framework to fit with modern multiparty computation (MPC) protocols. We study the possibility of replacing the well-known preprocessing model with a commodity-based setting, where a set of independent servers (some of which may be corrupt) provide clients with correlated randomness. From this, the clients then distill correct and secure correlated randomness that they can use during the online phase of the MPC protocol. Beaver showed how to do OT with semi-honest security in the commodity setting. We improve on Beaver’s result as follows: In a model where one of two clients and a constant fraction of the servers may be maliciously corrupted, we obtain unconditionally secure multiplication triples and oblivious linear evaluations (OLEs) such that the amortized communication cost of one triple/OLE is a constant number of field elements (when the field is sufficiently large). We also report on results from an implementation of the OLE protocol. Finally, we suggest an approach to practical realization of a commodity based system where servers need no memory and can be accessed asynchronously by clients, but still a maliciously corrupt client cannot get data he should not have access to.

Research funded by: the Concordium Blockhain Research Center, Aarhus University, Denmark; the Carlsberg Foundation under the Semper Ardens Research Project CF18-112 (BCM); the European Research Council (ERC) under the European Unions’s Horizon 2020 research and innovation programme under grant agreement No. 669255 (MPPRO), No. 803096 (SPEC) and No. 731583 (SODA); the Danish Independent Research Council under Grant-ID DFF-6108-00169 (FoCC).

Appendices

A Our Constructions in the Big Picture

In this section we present a graphical overview of how our constructions fits in the bigger picture of performing secure 2-party computation (Fig. 1).

Fig. 1.

An overview of how our constructions (the blue boxes with dashed lines) fits in the bigger picture of performing secure 2-party computation. (Color figure online)

Construction 1: Commodity-Based OLEs. We construct commodity-based OLEs in the commitment-hybrid model with active, statistical security and in the standard model with active, information theoretic security (with slightly worse parameter). In this construction we allow a corrupt client to collude with a minority of the servers. Using the result from [DGN+17], we can use the commodity-based OLEs to construct authenticated multiplication triples, which are complete for multiparty computation.

Construction 2: Commodity-Based Multiplication Triples. We construct commodity-based authenticated multiplication triples in the standard model with active, information theoretic security. This construction has a slightly weaker corruption model: we do not allow collusion between clients and servers. Thus, the adversary can corrupt either one client or a minority of the servers.

B Preliminaries

Let [n] be the set of integers $\{1,\dots ,n\}$. Denote a field of size q as $\mathbb {F}_q$ and the set of all polynomials over such field as $\mathbb {F}_q [X]$. All variables and operations are over $\mathbb {F}_q$ unless stated otherwise. $\varvec{v}$ denotes a vector with entries in $\mathbb {F}_q$, the entries are usually denoted $v_1, v_2..$. If $\varvec{u}, \varvec{v}$ are vectors of the same length, say m, then $\varvec{v}*\varvec{u}$ denotes the vector containing the coordinate-wise products, $\varvec{v}*\varvec{u}= (v_1u_1, v_2u_2,..., v_mu_m)$. As a shorthand, we denote $\mathbb {F}$ to be a field of arbitrary size.

1.1 B.1 Security Model

We will use the UC framework of Canetti [Can01] to prove our protocols secure. Informally, we compare a real protocol $\pi$ between the parties to a setting in which the parties only talk with an ideal functionality $\mathcal {F}$, which by definition is secure. To model the information the adversary learns during the protocol execution, each ideal functionality is given a leakage port on which it leaks all the information the adversary is allowed to learn. Furthermore, to model the adversary’s influence over the protocol and the corrupt players, each ideal functionality is given a influence port on which it can receive messages from the adversary. To prove the real protocol secure, we construct a simulator $\mathcal {S}$ such that no adversary controlling all malicious players can make an environment distinguish between the real protocol execution and the simulator’s transcript. Intuitively, the adversary gains nothing from controlling the malicious players, that he could not have simulated himself offline. In particular we use the variant in which the environment plays the role of the adversary and will prove our protocols secure under static corruption for malicious adversaries.

1.2 B.2 Commodity Model

Commodity-based cryptography works in a client-server model, where a group of clients obtain some information (called commodities) from a set of servers. In the basic setting, the clients will send a request to a server, who will reply with a single response computed from the request, whereas other settings may extend this to multiple rounds.

Following the work of Beaver, we define a two-tiered (c, n)-protocol $\pi = (\mathcal {C},\mathcal {S})$ as a collection of $c+n$ probabilistic interactive Turing machines (PTM), which are divided into two groups: the clients $\mathcal {C}$ and the servers $\mathcal {S}$. The clients must be polynomial time PTM’s and are assigned a unique id $i \in [c]$, and the servers are likewise assigned a unique id $j \in [n]$. We consider the basic form of two clients $c=2$ and a variable number of servers n, with the servers being polynomial time PTM’s. Other settings, which we shall not consider, may include a variable number of clients, computationally unbounded servers, multiple rounds between clients and servers or even allowing communication between servers.

Definition 2

(Stateless Oblivious RPC, [Bea97]). Given a two-pass protocol between client $C_i \in \mathcal {C}$ and server $S_j \in \mathcal {S}$, where the $C_i$ sends a request $q_{i,j}$ to the $S_j$, who send back the response $r_{i,j}$. This protocol is called a stateless oblivious remote procedure call (RPC) if $q_{i,j}$ is independent of $C_i$’s input $x_i$ (apart from the length) and of any previous communications with $S_j$ or any other servers (apart from including tags for identifying and authenticating $C_i$ and $S_j$).

Definition 3

(Commodity-based Protocol, [Bea97]). A two-tiered protocol $\pi$ is commodity-based if

• 1. No communication between servers is necessary.

• 2. Servers do not need to know the identities, numbers of, or existence of other servers.

• 3. For each client $C_i \in \mathcal {C}$ and server $S_j \in \mathcal {S}$, $C_i$ interacts with $S_j$ only through stateless oblivious RPC’s.

1.3 B.3 Commitments

Some of our protocol make use of a UC-secure commitment scheme, which is modelled by an ideal functionality $\mathcal {F}_{\textsc {commit}}$. Committing to a value x is denoted $\textsc {commit}(x)$ and means that the committer sends x to the commit functionality which notifies the other party that the commitment has been made. Opening is denoted $\textsc {open}(x)$ and means the committer sends an open command to the functionality which then sends x to the other party. In a practical implementation, $\mathcal {F}_{\textsc {commit}}$ can be implemented using a random oracle (it is well known, and trivial to prove, that applying a random oracle to the string to commit to, concatenated by random coins, gives a UC-secure commitment scheme).

1.4 B.4 Oblivious Linear Evaluation

An oblivious linear evaluation (OLE) over the finite field $\mathbb {F}$ is a primitive in which Alice inputs $a,b \in \mathbb {F}$ and Bob inputs $x\in \mathbb {F}$. Alice learns nothing and Bob learns $y=ax+b$. This primitive can be seen as a natural generalization of Oblivious Transfer (OT) [Rab05] for the case $\mathbb {F}=\mathbb {F}_2$ or as a special case of Oblivious Polynomial Evaluation (OPE) [NP99] for the case of degree 1 polynomials. The ideal UC-functionality $\mathcal {F}_{\textsc {ole}}^m$ is defined in Fig. 2. It implements m OLEs in parallel.

Fig. 2.

Ideal functionality $\mathcal {F}_{\textsc {ole}}^m$ for Oblivious Linear Evaluation (OLE).

A variant called random oblivious linear evaluation (ROLE) is a similar primitive, but where Alice receives random values and Bob such that $uv = w_1 + w_2$. The ideal UC-functionality $\mathcal {F}_{\textsc {role}}^m$ is defined in Fig. 3. We show that a random oblivious linear evaluation (ROLE) is equivalent to an oblivious linear evaluation (OLE) in the same way oblivious transfer is shown to be equal to a random oblivious transfer. We define a protocol $\pi _{\textsc {ole}}^m$ that realizes $\mathcal {F}_{\textsc {ole}}^m$ with access to $\mathcal {F}_{\textsc {role}}^m$. This protocol (which is folklore) is formally given in Fig. 4 and can be proven secure as stated in the following:

Fig. 3.

Ideal functionality $\mathcal {F}_{\textsc {role}}^m$ for Random Oblivious Linear Evaluation (ROLE). It chooses random outputs for the parties, but lets a corrupt party choose his own outputs.

Lemma 3

The protocol $\pi _{\textsc {ole}}^m$ UC-realizes $\mathcal {F}_{\textsc {ole}}^m$ in the $\mathcal {F}_{\textsc {role}}^m$-hybrid model.

Correctness of the protocol can be trivially checked. Security can be proven similarly to other protocols in the correlated randomness model [IKM+13]: if Bob is corrupted, the simulator emulates the ROLE by picking random $\varvec{v}, \varvec{w}_2$, extracts $\varvec{x}$ from $\varvec{e}$ and $\varvec{v}$ and feeds it to the ideal functionality to receive $\varvec{y}$. Finally the simulator chooses a random $\varvec{s}$ and computes $\varvec{d} = \varvec{v}^{-1}* (\varvec{y} -\varvec{w}_2- \varvec{s})$, thus producing a view which is distributed identically as in the real world. Here, $\varvec{v}^{-1}$ means the vector with entries $v_1^{-1}, v_2^{-1},..$. In the case where Alice is corrupted, the simulator emulates the ROLE by picking random $\varvec{u}, \varvec{w}_1$ and sends a random $\varvec{e}$. Then, upon receiving $\varvec{d}$ and $\varvec{s}$ the simulator extracts $\varvec{a}= \varvec{d}+ \varvec{u}$ and $\varvec{b} = \varvec{s} -\varvec{w}_1- \varvec{a}*\varvec{e}$ and feeds them to the ideal functionality.

Fig. 4.

Protocol for OLE in the $\mathcal {F}_{\textsc {role}}^m$-hybrid model.

C More Details on Commodity-Based OLE

Concrete Efficiency. We remark on the overall communication of the OLE protocol: For a single OLE instance, the oblivious RPC’s consist of one tuple $\mathbb {F}^2$ sent from each server to each client totaling $4n \log _2 |\mathbb {F}|$ bits. In the computation phase, both parties send to each other one field element for each evaluation point from $d+2,\dots ,n$, which totals $2(n-(t+m+2)+1)$ field elements as $d=t+m$. In the check phase, each party sends 3 field elements to the other, and in addition we send a commitment (and its decommitting information). Let $\kappa$ be the security parameter (e.g., if SHA256 is used for the commitment $\kappa =256$). Then, the overall communication complexity (including the communication from the servers to the clients, and the communication between the two clients) for generating m OLEs using n servers tolerating up to t corruptions boils down to

$$ 2(3n-t-m+2) \log _2 |\mathbb {F}|+2\kappa . $$

Doing Without Commitments. The only reason we use a commitment is that if Bob would immediately send $B(t_A)$ to Alice, the proof of Lemma 2 would break down because Alice would now know $t+1$ and not t points on B(x), at the time where she has to answer Bob’s challenge. Therefore, in the view of Alice, there is only 1 degree of freedom for B(x) instead of 2, as we need in the proof. We can even show that there is an attack on the protocol in this case.

However, this is easy to fix, we just set the degree of polynomials A(x), B(x) to be $d= t+m+1$ instead of $t+m$, and change the protocol such that in the Check Phase, Bob sends $B(t_A), C_2(t_A)$ in the clear along with $t_B$. Alice can now do her check immediately and return her answer $A(t_B), C_1(t_B)$ to Bob. We can prove the equivalent of Lemma 2 for the modified protocol using the same proof: even if Alice now learns $B(t_A)$ before she has to answer she is still at least 2 points short of being able to determine B(x), and this is the crucial property that makes the proof go through. The simulation for the modified protocol and the proof that it works is the same as before. The price we pay for this is that we need $n= 2d+1= 2t+2m+3$, so we need 2 servers more than before. In summary, we have

Corollary 1

Assume that $n=2t+2m+3$ and that $|\mathbb {F}|$ is exponential in the security parameter. Then protocol $\pi _{\textsc {role}}^m$ is an implementation of $\mathcal {F}_{\textsc {role}}^m$ with statistical UC-security. The protocol tolerates a static adversary corrupting one client and at most $t \le \frac{n-2m-3}{2}$ servers. The simulation is perfect unless an error event occurs, which has probability at most $\frac{n}{|\mathbb {F}|-(n+m)}$.

Smaller Fields. The protocol can be modified to work even with small fields where $|\mathbb {F}|$ is not exponentially large in the security parameter: the argument that the check phase makes a mistake with probability a most $n/(|\mathbb {F}| - (m+n))$ holds for any field. In particular, we will get at most constant error probability p as long as $|\mathbb {F}| > n/p + m+n$. Then we can get negligible error probability if we repeat the check phase $\kappa$ times where $\kappa$ is the security parameter. This will give error probability at most $p^\kappa$.

D Allowing Servers to Be Memoryless

We now look at practical aspect of the commodity model. As mentioned in the introduction, it will clearly be an advantage if the servers in our model do not need memory in the sense that they do not have to remember who they talked to or what was sent. This would mean that a server will not have to administrate identities and log-in credentials, and could simply generate the required data on the fly, say, against payment in some cryptocurrency. An obvious problem with this goal is that the data sent to two clients Alice and Bob must be correlated and a memoryless server cannot make this happen on its own. We now informally sketch a solution to this: We will assume that clients can communicate with servers such that clients can authenticate the identity of servers, but not necessarily the other way around (in practice, one may think of 1-way TLS here).

We also assume that Alice and Bob interact before talking to the servers – indeed this is necessary to create any correlation if the servers have no memory. We assume a 2-way authenticated channel for this, indeed this seems necessary if there are several clients, otherwise an honest Alice could not know with whom she is doing secure computation. Alice and Bob would then agree on a common nonce $n_{AB}$, as well as a parameter par specifying what they will request from the server, as well as the identity id of the server. For the case of our protocol, we would have $par =(\mathbb {F}, s, id)$ where $\mathbb {F}$ is the field to use for the OLEs, s is the number of OLEs to request and id is the server identifier.

In a naive solution, Alice would send (“A”, $par, n_{AB}$) to the server who will use this and a private PRF key K to generate Alice’s data, and something similar is done for Bob. However, this is clearly not secure: if Alice is corrupt, she can send both (“A”, $par, n_{AB}$) and (“B”, $par, n_{AB}$) to each honest server, get Bob’s data and break the protocol.

We solve this by generating the nonce such that Alice and Bob each know different secrets relating to the nonce and hence cannot impersonate the other party towards the server. In the simplest case where a nonce is used for only one server, a straightforward way to do this is to make use of a one-way function $f: \{0,1\}^k \mapsto \{0,1\}^k$ where k is a security parameter. Then Alice chooses $x_A\in \{0,1\}^k$ at random, similarly Bob chooses $x_B$ and we let $n_{A,B} = f(x_A) || f(x_B)$ where || denotes concatenation.

Now, party $P \in \{A,B\}$ would send (“P”, $par, x_P, n_{AB}$). The server checks that $x_P$ is correct with respect to $n_{AB}$ and only then will it send data to P. In this case we can instantiate f efficiently using a hash function, for instance.

For the security of this solution, note that we just need to make sure that the data sent from an honest server to an honest client is secure, since all other data is known and can be modified by the adversary anyway. So assume Alice is honest and agrees on nonce $n_{AB}$ and par with corrupt Bob, and let $d_A$ be the data that honest server S will returns to Alice. Now, if Bob sends any request to S that contains something different from $par, n_{AB}$ then S will return something that is (pseudo)uncorrelated to $d_A$. If the request does contain $par, n_{AB}$, then S may return either nothing or the data Bob is allowed to get, which is fine. It will only return $d_A$ if the request contains $x_A$, and this happens only with negligible probability since f is one-way.

It is also possible to use one nonce for all servers. In that case we cannot let Alice simply reveal a preimage to the server. If the server is corrupt it can send $x_A$ to Bob who can then do the same attack as before on honest servers. Instead we can let Alice generate a public key $vk_A$ for a secure signature scheme, while Bob generates $vk_B$. Now, the request sent by Alice will be of form (“A”, $par, \sigma _A, n_{AB}$), where $\sigma _A$ is a signature on $n_{AB}$ and par, and where $par=(\mathbb {F},s,id,vk_A,vk_B)$. The server only sends back data if the signature verifies under the public key found in par, and if its own name occurs in par. Note that this last checks prevents a corrupt server from replaying a request to an honest server, and hence security can be argued in a similar way as before.

We remark that a practical implementation of any information theoretically secure MPC needs to implement the secure channels using encryption and (usually) a PKI, which is only computationally secure. We are in a similar situation, only we consider also the authentication aspect: if we assumed ideal authentic channels, the servers could generate data based on the ID’s of the parties they know they are talking to. If we do not assume this, we have to use computational assumptions.