# Does homomorphic encryption hide the algorithm itself?

The question is rather simple, but finding resources and answers quite tricky. Homomorphic encryption should enable us to compute over encrypted data. What if the algorithm for computing should be kept in secret as well? Given we have a functioning homomorphic encryption in place, is the algorithm which is applied to the input data also secure?

Is it possible for an intruder to understand how the data is computed and learn about the algorithm, given the intruder has access to the program which does the computation?

## Update

So the question should have been: Does FHE offer circuit privacy?

With this term I found some papers which answer my question.

• First off, no it does not. But second, why would you want to hide the algorithm? – forest Nov 17 '19 at 23:13
• On the (Im)possibility of Obfuscating Programs. Data and result are secure. – kelalaka Nov 17 '19 at 23:35
• @forest An algorithm can be a business secret. – Robin Nov 18 '19 at 7:14
• On closer reading, it sounds like Robin is asking not whether the homomorphic encryption algorithm can be kept secret, but whether the circuit that is computed homomorphically over the ciphertext can be kept secret. – Squeamish Ossifrage Nov 18 '19 at 16:28
• @Squeamish Ossifrag: The circuit. I'm sorry English is not my native language. So should I ask a follow up question where I ask more precisely? – Robin Nov 19 '19 at 20:49

FHE does not offer circuit privacy by default, but can it can be upgraded to do so:

In brief, the extra cost for circuit privacy is actually very small (just a few noisy-dummy bootstraps at the end of your circuit)... in the honest-but-curious model ! For stronger variants of circuit privacy, you need to certify that the FHE public key is correctly generated; and FHE public key are already quite large, so I let you imagine how proving ZK statements about them would be.

No, it does not. Modern cryptography never relies on the secrecy of the algorithm. The reason you're having trouble finding documentation is because this is basic textbook material, so it won't appear in white papers or research.

With crypto, you always assume the attacker knows the algorithm. This poses no threat to a secure crypto system; the secret key is the only knowledge prohibited to the attacker. Note that in the case where the attacker has access to the application, they may have access to the key (depending on the application design), which is a critical failure regardless of the encryption method.

In particular, regarding the comment about trade secrets: Secure crypto does not rely on intellectual property protection at all---there is no way for trade secrets, patents, copyright, etc to keep your data safe against a persistent adversary. Ideally, you should use a homomorphic library that supports your preferred algorithm to reduce the likelihood of programming errors that undermine security.

While there are some unique dangers associated with homomorphic encryption, disclosure of the algorithm doesn't uniquely affect them. The vulnerability to IND-CCA in that paper is worrisome, and, in practice, it requires strict limits on clients/applications. FHE (fully homomorphic encryption) is maturing rapidly, and new developments may eliminate some of these issues. Regardless, it is essential to follow the guidance of the library/framework developers---and in the case of Microsoft SEAL:

scenarios where multiple different private data owners wish to engage in collaborative computation, homomorphic encryption is probably not a reasonable solution.

(The SEAL guidance generalizes to most FHE algorithms and libraries.)

Bottom line: If you are using FHE today in accordance with best practices, disclosure of the algorithm is not a significant risk. Each algorithm offers different types/levels of security and performance, however, so choosing an algorithm requires careful consideration. Newer is generally much better, but good library/framework support takes time.

• I'm a little puzzled by the acceptance of this answer, because this answer seems to be addressing whether the homomorphic encryption algorithm is kept secret, not whether the circuit computed on the plaintext via the ciphertext is kept secret. That is, if we submit a circuit and a ciphertext of the circuit input to a utility computing service, so that what we get back is the ciphertext of the circuit output, can we keep the circuit secret? Obviously the homomorphic encryption scheme itself is not secret in any sensible system, but that's not what I understood the question to be about. – Squeamish Ossifrage Nov 19 '19 at 16:55
• The answer is maybe. Section 4 in the first reference has serious implications for BFV; however, BFV is not the only FHE algorithm. This does support Microsoft's stance that homomorphic encryption is not reasonable for collaborative efforts. FHEW may fix this, but it's fairly new. Not a crypto expert, and I've read very little on FHEW. – DoubleD Nov 19 '19 at 18:59
• It turns out there is a substantial literature on the subject of circuit privacy in FHE, and the answer to the question I thought OP was asking is definitely not negative. – Squeamish Ossifrage Nov 19 '19 at 19:18
• He asked about the algorithm, not the circuit, but you have a good point that he might have meant the circuit. Regardless, the right approach hinges on the particular algorithm. So if he's concerned about circuit privacy, he needs to be more specific. BFV is probably unsafe for a lot of scenarios, and TFHE or FHEW are likely better choices---but at that point, the question probably belongs on crypto.SE – DoubleD Nov 19 '19 at 20:21