# Key distribution and computation for homomorphic encryption

How can a system where the party performing a computation also possess the private key and still not know the answer of computation be designed ? Also the other party who does not have the private key know the correct result ?

Involving a trusted third part seems a possible solution. But are there other ways to design such a system ?

Consider the following scenario: A has an input $x_1$, the public key and private key. B comes in with another input $x_2$. A sends the public key to B. B sends the encrypted value $enc(x_2)$ for A to perform a computation $C(enc(x_1), enc(x_2))$. A performs the computation and sends the result to B. A should not know the correct value of result. But here if A is performing the computation and also has the private key, then A can decipher the answer.

You are correct, if you do things the way you describe, A would be able to decrypt B's private data. So don't do it that way.

Instead, since B is to know the answer, let B encrypt his private input with his own public key. He sends that to A. A encrypts her private input with B's public key, then runs the computation. A then returns the encrypted answer to B. B decrypts it.

Since you added , you may be interested in how this extends to more than two parties. Here is a relevant quote from Craig Gentry's PhD thesis

Extending our application of fully homomorphic encryption from the two-party setting to the multiparty setting is not entirely trivial, since, in the two-party setting, Bob prevented Alice from seeing any intermediate values encrypted under Alice’s key simply by finishing the computation himself, and sending back the final encrypted value to Alice; in the multiparty setting, it is less clear how one prevents Alice from seeing intermediate value encrypted under her key.

A number of protocols using homomorphic encryption to enable secure multiparty computation have been proposed, the most practical of which is probably SPDZ.

• If A is a database of values, then for each user B, A has to encrypt each of its value. So the computation party cannot have the private keys ? – 1010101 Apr 22 '15 at 13:11
• @1010101 you are correct, though there are some tricks around this. Since FHE can evaluate any function, it can evaluate the AES decryption function. So, instead A can encrypt the database with AES, then encrypt the key with B's public key. B uses the encrypted key and the AES encrypted database to decrypt the database. The result of that decryption is not plaintext, however. It is the database encrypted with FHE. – mikeazo Apr 22 '15 at 13:14
• You shouldn't really use AES in this case, there are some ciphers way more "FHE-friendly". – Dillinur Apr 22 '15 at 13:47
• @Dillinur Could you suggest some ? – 1010101 Apr 22 '15 at 13:51
• @Dillinur but do they have the security history of AES? – mikeazo Apr 22 '15 at 13:57