0
$\begingroup$

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.

$\endgroup$
0
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ 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 ? $\endgroup$ – 1010101 Apr 22 '15 at 13:11
  • 1
    $\begingroup$ @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. $\endgroup$ – mikeazo Apr 22 '15 at 13:14
  • $\begingroup$ You shouldn't really use AES in this case, there are some ciphers way more "FHE-friendly". $\endgroup$ – Dillinur Apr 22 '15 at 13:47
  • 1
    $\begingroup$ @Dillinur Could you suggest some ? $\endgroup$ – 1010101 Apr 22 '15 at 13:51
  • $\begingroup$ @Dillinur but do they have the security history of AES? $\endgroup$ – mikeazo Apr 22 '15 at 13:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.