a590003

anteed correctness of the computation). Unfortunately, a subtle issue arises when trying to argue correctness of
the simulator. Note that the above discussed check involves decrypting the output. While this is indeed possible
in the real world execution, it is not clear how to perform the same check during simulation. Indeed, in the proof
of security, we would need to rely on the semantic security of the underlying FHE scheme, which conflicts with
performing decryption. We remark that the natural approach of having the simulator perform a related check
(e.g., perform Eval operation of the FHE scheme to match the ciphertexts) rather than perform decryptions can
be defeated by specific attacks by the adversary. We do not elaborate on this issue further here, but note that in
order to argue correctness of simulation, we need to ensure that the verification checks performed in the honest
execution and the simulated executions must be the same.
The above issue is resolved by delegating the functionality G (described above) instead of ¯F . The key idea
is that instead of performing the aforementioned consistency check via decryption (of the single layer of FHE),
we can now perform a similar check by first decrypting the outer layer, and then re-encrypting the input of the
client (the clients are supposed to provide the encryption randomness in the verification protocol) and matching
it with the values X and Y , respectively. The simulator can now be in possession of the outer layer FHE secret
key since we can rely on the semantic security of the inner layer FHE.
The above description is somewhat oversimplified for lack of space. We refer the reader to the protocol
description for more details.
Handling more than two clients. It is easy to see that the obvious extension of the above protocol to the case
of n clients requires the server to compute and return 2 n values. Here we informally describe how to avoid this
problem. Recall that each client picked a random bit b i and sent either (x i , r i ) or (r i , x i ), both doubly encrypted,
depending on the bit b i . To avoid the exponential blow up, we have the n clients jointly generate random bits
b 1 , · · · , b n such that exactly one b i = 1 (where i is random in [n]) and all other b j = 0, j ≠ i (Doing this without
interaction is a significant challenge, but we show that this can be achieved.). Now, the server only needs to
compute 2n ciphertexts: n that encrypt F (x 1 , . . . , x n ) and n that encrypt F (r 1 , . . . , r n ). In this case, we can
prove security of our protocol as long as at most a fraction of the clients are corrupted (even if they collude with
the worker). More details in Section 5.1.
1.4 Related Work
The problem of efficiently verifiying computations performed by an untrusted party has been extensively studied
in the literature for the case of a single client outsourcing the computation to a server. Various approaches have
been used: interactive solutions [GKR08], SNARG-based solutions [BCC88, Kil92, Mic94, BCCT12, GLR11,
DFH12, Gro10, Lip12, GGPR12], and pre-processing model based solutions [GGP10, CKV10, AIK10]. The
works of [KMR11] and [CKKC12] consider outsourcing of multi-party computation but consider only the case
where adversarial parties do not collude with each other or a semi-honest setting. Finally, with a focus on
minimizing interaction, the work of [CKKC13] considers non-interactive multi-client verifiable computation, but
only consider soundness against a malicious server when clients are honest and privacy, independently, against a
malicious server and a malicious client. For a more detailed description of related works, see Appendix A.
2 Preliminaries
2.1 Our Model
In this section, we present in detail, the computation and communication model as well as the security definition
considered in this paper. For simplicity, we shall deal with the two-party case of our protocol first and then show
how to extend this to the mult-party case. In other words, we consdier the setting of 2 clients (or delegators)
D = {D 1 , D 2 } who wish to jointly outsource the computation of any PPT function over their private inputs to
a worker W. Specifically, we consider the case where the clients wish to perform arbitrarily many evaluations
of a function F of their choice over different sets of inputs. Unlike the standard multiparty computation setting,
we wish to ensure that the computation of each client is independent of the amount of computation needed
6
11. How to Delegate Secure Multiparty Computation to the Cloud