a590003

Experiment H 4 . This experiment is the same as H 3 , except that instead of encrypting the input of P 1 honestly,
S computes ̂X 1,1 , . . . , ̂X 1,n as encryptions of the all zeros string. Note that this experiment corresponds to the
ideal world.
Indistinguishability of H 3 and H 4 : From the semantic security of the (inner layer) FHE scheme
(Gen, Enc, Dec, Eval), it immediately follows that the output distributions of H 4 and H 5 are computationally
indistinguishable. In more detail, assume for contradiction that there exists a PPT distinguisher D that can distinguish
with non-negligible probability between the output distributions of H 3 and H 4 . Then, we construct an
adversary B that breaks the semantic security for the FHE scheme. Adversary B takes a public key pk from
the challenger C of the FHE scheme and then runs the simulator S to generate an output distribution for D.
Specifically, B follows the same strategy as S, except that in the pre-processing phase, S forces pk as the inner
layer public key. B then sends vectors ⃗m 0 , ⃗m 1 as its challenge messages to C, where each element in ⃗m 0 is set
to x 1 , and each element in ⃗m 1 is set to the all zeros string. On receiving the challenge ciphertext vector from
C, adversary B simply uses them to continue the rest of the simulation as S does. Finally, B outputs whatever
D outputs. Now, note that if the challenge ciphertexts correspond to ⃗m 0 , then the resultant output distribution
is same as in experiment H 3 , otherwise, it is the same as in H 4 . Thus, by definition D (and therefore B) must
succeed in distinguishing with non-negligible probability. Thus, we arrive at a contradiction.
D.2 Security of the Many-time Verifiable Computation Scheme
So far, we have shown that our protocol is one-time secure (namely, that soundness holds when one execution
of the online and offline phases are executed). We now proceed to show that the protocol is many-time secure
(i.e., we can run (unbounded) polynomially many online and offline phases after one run of the pre-processing
phase). As in the works of [GGP10, CKV10], we work in a model in which if the result of some computation
returned by the server is rejected by any of the clients, the clients execute a new pre-processing phase and
pick new parameters. To prove our security, let us first recall how [CKV10] go from one-time to many-time
security. [CKV10] show that if we have a one-time delegation scheme, then this can be converted into a manytime
delegation scheme simply by executing the entire protocol under another layer of fully encryption. A fresh
public key for the FHE scheme is chosen for every execution by the client in the online phase. Note that the
way we achieve multi-time security is also similar - the clients independently pick a fresh public key for the
multi-key homomorphic encryption scheme of [LTV12] and execute the one-time protocol under this layer of
fully homomorphic encryption. The proof that our protocol is also multi-time secure is quite similar to that of
[CKV10]; however, there are a few subtle changes that we need to make.
To see these changes, let us first understand the idea behind the proof of [CKV10]. [CKV10] reduce the
security of the multi-time scheme to that of the one-time scheme. That is, given an adversary that breaks the
security of the multi-time scheme, they construct an adversary that breaks the security of the one-time scheme.
Both adversaries execute the pre-processing phase in exactly the same manner. Let L be an upper bound on
the total number of times the one-time stage is executed by the adversary. The one-time scheme adversary that
they construct picks one of these executions, say i th , at random and chooses to break the one-time security of
that execution. In all other executions, the adversary will “simulate” the protocol by sending encryptions of allzeroes,
instead of sending the encryption of the actual message that is a function of ̂X (which is an encryption of
the client’s input), ̂R (which is an encryption of the client’s secret state used to verify the protocol), and the secret
bit b (which is chosen fresh in every execution). In these executions (all executions other than the i th ), one can
show (via the semantic security of the FHE scheme) that the messages sent in the real and simulated executions
are indistinguishable. An important point here is that the client never rejects any of these executions here and
always proceeds with the computation as if it accepted it. In the i th execution, the adversary will pick the public
key and secret key for the FHE scheme on its own. Now, the adversary encrypts the query under this public key
and once it obtains the response of the worker from the many-time adversary, it decrypts it using the secret key
to the obtain the response that the adversarial worker in the one-time game must produce.
We shall also follow the same overall strategy. The one-time adversary that we build will execute the pre-
21
11. How to Delegate Secure Multiparty Computation to the Cloud