a590003

the clients jointly run a secure computation to verify the results of the computation sent by the server. The main
issue with this approach is that this solution requires the clients to interact (heavily) with each other in the online
phase - which we believe, as discussed earlier, to be a significant drawback.
A Failed Approach. Towards that end, we consider the following approach. Let us consider the two-client
setting first (where client D i holds input x i ). As before the clients will jointly generate the information needed
for pre-processing via a secure computation protocol. Our first idea is to have each client independently generate
a bit b i in the online phase and send either (Enc pk (x i ), Enc pk (r i )) or (Enc pk (r i ), Enc pk (x i )) to the server in the
online phase. Now, the server instead of computing two outputs will compute 4 ciphertexts (since the server
does not know bits b 1 and b 2 , it will compute ciphertexts corresponding to F (x 1 , x 2 ), F (x 1 , r 2 ), F (r 1 , x 2 ), and
F (r 1 , r 2 ). The clients can then in the offline phase verify the appropriate responses of the server and accept
F (x 1 , x 2 ) if all checks succeed.
Unfortunately, this solution completely fails in the case when a client (say D 2 colludes with the server). Very
briefly, the main problem with the above approach is that it does not guarantee any input independence, a key
requirement for a secure computation protocol. To see the concrete problem, recall that in order to realize the
standard real/ideal paradigm for secure computation, we need to construct a simulator that simulates the view
of the adversary in such a manner that output distributions of the real and ideal world executions are indistinguishable.
The standard way such a simulator works is by “extracting” the input of the adversary in order to
compute the “correct” protocol output (by querying the ideal functionality), and then “enforcing” this output in
the protocol. The main issue that arises in the above approach is that we cannot guarantee that the adversary’s
input extracted by the simulator is consistent with the output of the honest client in the real world execution. In
particular, note that in the real world execution, the clients simply check whether the output of the server contains
the correct F (r 1 , r 2 ) value, and if the check succeeds, then they decrypt the appropriate output value and accept it
as their final output. Then, to argue indistinguishability of the real and ideal world executions, we would need to
argue that the simulator extracts the specific input of the corrupted client that was used to compute the output by
the (colluding) worker. However, the above approach provides no way of enforcing this requirement. As such, a
colluding server and client pair can lead the simulator to compute an output which is inconsistent with the output
generated by the server, in which case the simulator must abort. Yet, in the real world execution, the honest client
would have accepted the output of the server. Thus, the simulator fails to generate an indistinguishable view of
the adversary.
Indeed, the above attack demonstrates that when requiring simulation-based security against malicious coalitions,
current techniques for single-client verifiable computation are not sufficient and new ideas are needed. The
main contribution of our paper is a technique to overcome the above problem.
Our Solution. On careful inspection of the above approach, one can observe that it does provide some weak
form of guarantee – that the server actually correctly computes the function F ; however, F is computed correctly
w.r.t. “some” input for the corrupted client. In particular, the input of corrupted client may not be chosen
independently of the honest client’s input.
In order to solve our problem, our main idea is to leverage the above weak guarantee by changing the functionality
that is being delegated to the worker. Roughly speaking, we essentially “delegate the delegation functionality”.
More concretely, we change the delegation functionality to G(X, Y ) = Eval pk (X, Y, F ), X, Y , where
X and Y are encryptions of the inputs x and y of the clients under the public key pk of the FHE scheme.
In order to understand why the above solution works, let us first consider an intermediate attempt where we
delegate the functionality ¯F (x, y) = F (x, y), x, y. The underlying idea is to use the weak correctness guarantee
(discussed above) to validate the input of the corrupted client. In more detail, note that if we delegate the functionality
¯F , then in the real world execution, we can have the clients perform the check (during the verification
protocol) that the output value contains the same y value that is extracted by the simulator. Indeed, a priori, it
may seem that this approach should indeed solve the above problem as we obtain a guarantee that the input of
the malicious party in the output value (y) was indeed the same input used in the computation (as we are guar-
5
11. How to Delegate Secure Multiparty Computation to the Cloud