<p>Indeed, while fully homomorphic encryption is very useful for executing code between multiple untrusting parties (see for example, <a href="http://people.seas.harvard.edu/~salil/research/delegation-abs.html">this paper</a>), you need some kind of interaction, when the party that computes the encrypted output sends it to the party that knows the secret key.</p>

<p>The notion you're looking for does sound suspiciously close to software obfuscation, for which we proved an impossibility result mentioned above. I also wrote once an <a href="http://www.cs.princeton.edu/~boaz/Papers/obf_informal.html">informal overview</a> of that paper, that some people may find useful.</p>

<p>Given this impossibility result, there are two (non disjoint) ways one can relax the definition: either by restricting the classes of programs/functions one is required to obfuscate, or giving a looser notion of security. </p>

<p>The second approach is perhaps possible, and we remark on some weak obfuscation-like notions in our paper. However, note that our attack completely recovers the original source code of some program, no matter how it's obfuscated. So you'd have to somehow make a security definition which trivializes for the case of our counterexamples.</p>

<p>The first approach was done for every restricted functionalities (e.g., point functions), but again one has to make sure the class doesn't contain our counterexample, which roughly means it shouldn't contain pseudorandom functions. </p>

CC BY-SA 2.5
2010-12-13T02:50:20.183Z
2010-12-13T02:50:20.183Z
Boaz Barak
<p>Unfortunately, there is a result that theoretically forbids &quot;oblivious code execution&quot;:</p>
<p>Boaz Barak, Oded Goldreich, Russell Impagliazzo, Steven Rudich, Amit Sahai, Salil Vadhan, and Ke Yang. <strong>On the (Im)possibility of Obfuscating Programs</strong>, <em>ADVANCES IN CRYPTOLOGY — CRYPTO 2001.</em></p>
<p>Here are the links:</p>
<ul>
<li><a href="http://www.wisdom.weizmann.ac.il/%7Eoded/p_obfuscate.html" rel="noreferrer">http://www.wisdom.weizmann.ac.il/~oded/p_obfuscate.html</a></li>
<li><a href="http://eprint.iacr.org/2001/069" rel="noreferrer">http://eprint.iacr.org/2001/069</a></li>
<li><a href="http://www.springerlink.com/content/telalqdcx3n600uf/" rel="noreferrer">http://www.springerlink.com/content/telalqdcx3n600uf/</a></li>
</ul>
<p>The abstract reads:</p>
<blockquote>
<p>Informally, an obfuscator <span class="math-container">$\cal O$</span> is an (efficient, probabilistic) &quot;compiler&quot; that takes as input a program (or circuit) <span class="math-container">$P$</span> and produces a new program <span class="math-container">$\cal O(P)$</span> that has the same functionality as <span class="math-container">$P$</span> yet is &quot;unreadable&quot; in some sense. Obfuscators, if they exist, would have a wide variety of cryptographic and complexity-theoretic applications, ranging from software protection to homomorphic encryption to complexity-theoretic analogues of Rice's theorem. Most of these applications are based on an interpretation of the &quot;unreadability&quot; condition in obfuscation as meaning that <span class="math-container">$\cal O(P)$</span> is a &quot;virtual black box,&quot; in the sense that anything one can efficiently compute given <span class="math-container">$\cal O(P)$</span>, one could also efficiently compute given oracle access to <span class="math-container">$P$</span>.</p>
<p>In this work, we initiate a theoretical investigation of obfuscation. Our main result is that, even under very weak formalizations of the above intuition, obfuscation is impossible. We prove this by constructing a family of functions <span class="math-container">$\cal F$</span> that are inherently unobfuscatable in the following sense: there is a predicate <span class="math-container">$\pi$</span> such that (a) given any program that computes a function <span class="math-container">$f$</span> in <span class="math-container">$\cal F$</span>, the value <span class="math-container">$\pi(f)$</span> can be efficiently computed, yet (b) given oracle access to a (randomly selected) function <span class="math-container">$f$</span> in <span class="math-container">$\cal F$</span>, no efficient algorithm can compute <span class="math-container">$\pi(f)$</span> much better than random guessing.</p>
<p>We extend our impossibility result in a number of ways, including even obfuscators that (a) are not necessarily computable in polynomial time, (b) only approximately preserve the functionality, and (c) only need to work for very restricted models of computation <span class="math-container">$\rm{TC}$</span> <span class="math-container">$0$</span>). We also rule out several potential applications of obfuscators, by constructing &quot;unobfuscatable&quot; signature schemes, encryption schemes, and pseudorandom function families.</p>
</blockquote>

CC BY-SA 2.5
2010-11-12T00:29:13.163Z
Well, that kind of puts a dampener on things. I just read how they proved their results: I was particularly baffled when I read that the obfuscator is assumed to have access to the source code of the adversarial program! (though I could just have misunderstood the paper)
Alex ten Brink
CC BY-SA 2.5
2010-11-12T05:06:59.567Z
It's my understanding that these results only apply to the "old" (unsuccessful) model of obfuscation using virtual black boxes, and that now the researchers in the field are looking to adopt a weaker notion of obfuscation with the hope some guarantees can be had. One of the research directions is to adopt Fully Homomorphic Encryption, and so I would say that the question is open. I remember sitting in on a talk from Microsoft Research this summer about fixed point obfuscators and virtual black boxes where the researcher made exactly this point.
Ross Snider
CC BY-SA 2.5
2010-11-12T05:08:12.980Z
Could a researcher in the field (or one of the impressive names from the authors list) comment?
Ross Snider
CC BY-SA 2.5
2010-11-12T07:59:35.913Z
@Ross: Yeah, I would like other researchers in the field to comment as well...
Sadeq Dousti
CC BY-SA 2.5
2010-11-12T22:42:33.000Z
@Ross,Sadeq: Some of the authors visit the site from time to time, hopefully they will notice the tag. Having the question on the featured questions pages might also help.
Kaveh
CC BY-SA 2.5
2010-11-11T11:29:43.620Z
2010-11-11T11:29:43.620Z
2020-06-17T09:38:08.363Z
Sadeq Dousti
<p>After reading <a href="https://cstheory.stackexchange.com/questions/189/algorithms-from-the-book/219#219">this answer</a> a while ago, I took an interest in fully homomorphic encryption. After reading the introduction of Gentry's thesis, I started wondering if his encryption scheme could be used for oblivious code execution as defined in the third paragraph.</p>

<p>In a fully homomorphic encryption scheme we typically encrypt some data, send it to a hostile environment where a certain function is computed on the data, the result of which is then sent back (encrypted), without the adversary finding out what the received data or the result of the function is.</p>

<p>With oblivious code execution I mean that we encrypt a piece of code $C$ designed to solve some problem $P$ and send it to a hostile environment. The adversary wants to use $C$ to solve $P$, but we don't want him to know how $C$ works. If he has an input $I$ for $P$, he can encrypt $I$ and then use (some encryption scheme on) $C$ with $I$, which then returns the (not encrypted) output $O$ (the solution of $P$ for the input $I$). The encryption scheme makes sure the adversary never finds out how the piece of code works, ie to him it works like an oracle does.</p>

<p>The main practical use (I can think of) for such an encryption scheme would be to make piracy more difficult or even impossible.</p>

<p>The reason I think this may be possible using a fully homomorphic encryption scheme is because we can execute arbitrary circuits on encrypted data, in particular an universal Turing machine. We could then encrypt the code as if it were data and then use the circuit for an universal Turing machine on this encrypted data to execute the code.</p>

<p>I pose this as a question here because I don't know whether this idea is usable: I never got much further than the introduction of Gentry's thesis, and my knowledge about cryptography is limited. Also, I don't know if there already is a often-used term for oblivious code execution: I tried searching Google for the idea but not knowing the proper term I found nothing.</p>

<p>There are multiple problems I can think of which may cause problems with this approach. Firstly, if we use a fully homomorphic encryption without modification, the result of the computation ($O$) would be encrypted. It would therefore be useless for the adversary who wishes to use your code to solve $P$. While this could still be useful for, say, cloud computing, this is not what I want to achieve.</p>

<p>Secondly, because we're using circuits and not arbitrary Turing machines, we can't use arbitrary amounts of memory: we're limited to a predetermined amount of memory. This means that if we want to run a program in this way, it's memory footprint will always be the same, namely it's peak memory usage.</p>

<p>Lastly, the constants involved would almost certainly kill off any practical use of such a system, but I think the idea is interesting nonetheless.</p>

CC BY-SA 2.5
2010-11-12T18:24:15.653Z
are you sure from the term "Oblivious code execution"? I searched about it for a while and got nothing !
Deyaa
CC BY-SA 2.5
2010-11-12T18:28:00.823Z
Not at all: I made up the term myself since I didn't know the proper term for it. Obfuscation and obfuscators are apparently the regular terms for the concept.
Alex ten Brink
<cr.crypto-security><homomorphic-encryption><obfuscation>
Can a fully homomorphic encryption be used for oblivious code execution?
Alex ten Brink
# Can a fully homomorphic encryption be used for oblivious code execution?

(Asked by: username_0 on 2010-11-11)

After reading [this answer](https://cstheory.stackexchange.com/questions/189/algorithms-from-the-book/219#219) a while ago, I took an interest in fully homomorphic encryption. After reading the introduction of Gentry's thesis, I started wondering if his encryption scheme could be used for oblivious code execution as defined in the third paragraph.

In a fully homomorphic encryption scheme we typically encrypt some data, send it to a hostile environment where a certain function is computed on the data, the result of which is then sent back (encrypted), without the adversary finding out what the received data or the result of the function is.

With oblivious code execution I mean that we encrypt a piece of code $C$ designed to solve some problem $P$ and send it to a hostile environment. The adversary wants to use $C$ to solve $P$, but we don't want him to know how $C$ works. If he has an input $I$ for $P$, he can encrypt $I$ and then use (some encryption scheme on) $C$ with $I$, which then returns the (not encrypted) output $O$ (the solution of $P$ for the input $I$). The encryption scheme makes sure the adversary never finds out how the piece of code works, ie to him it works like an oracle does.

The main practical use (I can think of) for such an encryption scheme would be to make piracy more difficult or even impossible.

The reason I think this may be possible using a fully homomorphic encryption scheme is because we can execute arbitrary circuits on encrypted data, in particular an universal Turing machine. We could then encrypt the code as if it were data and then use the circuit for an universal Turing machine on this encrypted data to execute the code.

I pose this as a question here because I don't know whether this idea is usable: I never got much further than the introduction of Gentry's thesis, and my knowledge about cryptography is limited. Also, I don't know if there already is a often-used term for oblivious code execution: I tried searching Google for the idea but not knowing the proper term I found nothing.

There are multiple problems I can think of which may cause problems with this approach. Firstly, if we use a fully homomorphic encryption without modification, the result of the computation ($O$) would be encrypted. It would therefore be useless for the adversary who wishes to use your code to solve $P$. While this could still be useful for, say, cloud computing, this is not what I want to achieve.

Secondly, because we're using circuits and not arbitrary Turing machines, we can't use arbitrary amounts of memory: we're limited to a predetermined amount of memory. This means that if we want to run a program in this way, it's memory footprint will always be the same, namely it's peak memory usage.

Lastly, the constants involved would almost certainly kill off any practical use of such a system, but I think the idea is interesting nonetheless.

**Tags:** cr.crypto-security, homomorphic-encryption, obfuscation

> **Comments:**
> **username_1**: are you sure from the term "Oblivious code execution"? I searched about it for a while and got nothing !  
> **username_0**: Not at all: I made up the term myself since I didn't know the proper term for it. Obfuscation and obfuscators are apparently the regular terms for the concept.  

---

## 2 answers

### Answer by username_3 on 2010-11-11. Score: 17 | Accepted answer

Unfortunately, there is a result that theoretically forbids "oblivious code execution":

username_2, Oded Goldreich, Russell Impagliazzo, Steven Rudich, Amit Sahai, Salil Vadhan, and Ke Yang. **On the (Im)possibility of Obfuscating Programs**, *ADVANCES IN CRYPTOLOGY — CRYPTO 2001.*

Here are the links:

* [http://www.wisdom.weizmann.ac.il/~oded/p\_obfuscate.html](http://www.wisdom.weizmann.ac.il/%7Eoded/p_obfuscate.html)
* <http://eprint.iacr.org/2001/069>
* <http://www.springerlink.com/content/telalqdcx3n600uf/>

The abstract reads:

> Informally, an obfuscator $\cal O$ is an (efficient, probabilistic) "compiler" that takes as input a program (or circuit) $P$ and produces a new program $\cal O(P)$ that has the same functionality as $P$ yet is "unreadable" in some sense. Obfuscators, if they exist, would have a wide variety of cryptographic and complexity-theoretic applications, ranging from software protection to homomorphic encryption to complexity-theoretic analogues of Rice's theorem. Most of these applications are based on an interpretation of the "unreadability" condition in obfuscation as meaning that $\cal O(P)$ is a "virtual black box," in the sense that anything one can efficiently compute given $\cal O(P)$, one could also efficiently compute given oracle access to $P$.
>
> In this work, we initiate a theoretical investigation of obfuscation. Our main result is that, even under very weak formalizations of the above intuition, obfuscation is impossible. We prove this by constructing a family of functions $\cal F$ that are inherently unobfuscatable in the following sense: there is a predicate $\pi$ such that (a) given any program that computes a function $f$ in $\cal F$, the value $\pi(f)$ can be efficiently computed, yet (b) given oracle access to a (randomly selected) function $f$ in $\cal F$, no efficient algorithm can compute $\pi(f)$ much better than random guessing.
>
> We extend our impossibility result in a number of ways, including even obfuscators that (a) are not necessarily computable in polynomial time, (b) only approximately preserve the functionality, and (c) only need to work for very restricted models of computation $\rm{TC}$ $0$). We also rule out several potential applications of obfuscators, by constructing "unobfuscatable" signature schemes, encryption schemes, and pseudorandom function families.

> **Comments:**
> **username_0**: Well, that kind of puts a dampener on things. I just read how they proved their results: I was particularly baffled when I read that the obfuscator is assumed to have access to the source code of the adversarial program! (though I could just have misunderstood the paper)  
> **username_4**: It's my understanding that these results only apply to the "old" (unsuccessful) model of obfuscation using virtual black boxes, and that now the researchers in the field are looking to adopt a weaker notion of obfuscation with the hope some guarantees can be had. One of the research directions is to adopt Fully Homomorphic Encryption, and so I would say that the question is open. I remember sitting in on a talk from Microsoft Research this summer about fixed point obfuscators and virtual black boxes where the researcher made exactly this point.  
> **username_4**: Could a researcher in the field (or one of the impressive names from the authors list) comment?  
> **username_3**: @Ross: Yeah, I would like other researchers in the field to comment as well...  
> **username_5**: @Ross,Sadeq: Some of the authors visit the site from time to time, hopefully they will notice the tag. Having the question on the featured questions pages might also help.  

---

### Answer by username_2 on 2010-12-13. Score: 15

Indeed, while fully homomorphic encryption is very useful for executing code between multiple untrusting parties (see for example, [this paper](http://people.seas.harvard.edu/~salil/research/delegation-abs.html)), you need some kind of interaction, when the party that computes the encrypted output sends it to the party that knows the secret key.

The notion you're looking for does sound suspiciously close to software obfuscation, for which we proved an impossibility result mentioned above. I also wrote once an [informal overview](http://www.cs.princeton.edu/~boaz/Papers/obf_informal.html) of that paper, that some people may find useful.

Given this impossibility result, there are two (non disjoint) ways one can relax the definition: either by restricting the classes of programs/functions one is required to obfuscate, or giving a looser notion of security.

The second approach is perhaps possible, and we remark on some weak obfuscation-like notions in our paper. However, note that our attack completely recovers the original source code of some program, no matter how it's obfuscated. So you'd have to somehow make a security definition which trivializes for the case of our counterexamples.

The first approach was done for every restricted functionalities (e.g., point functions), but again one has to make sure the class doesn't contain our counterexample, which roughly means it shouldn't contain pseudorandom functions.


---

