19 Aug 2026
I wrote this a few months ago but forgot to post it.
Secure computation, in general, allows us to evaluate a function \(y=f(x)\) where a subset of \(\{y, f, x\}\) are hidden. Exactly which are hidden, and how, depends on the threat model and the specific primitive.
For example, obfuscation tries to hide \(f(\cdot)\), while multiparty computation tries to hide \(x\) (and sometimes \(y\)). I was curious what we could learn by enumerating all \(2^3=8\) possibilities.
In the following, I am imagining a cryptographic protocol is instantiated to run the computation, and values are either known to, or hidden from, the parties executing the protocol.
fully homomorphic encryption allows directly computing on encrypted data. Security rests on cryptographic assumptions.
multiparty computation distributes shares of secret data across multiple parties, who run an interactive protocol to compute shares of the result. Security comes from a non-collusion assumption between the parties, and sometimes cryptographic assumptions (in the case of non-information-theoretic MPC)
indistinguishability obfuscation hides the specific implementation of a function, and with some additional tricks, can be used to approximate “virtual blackbox obfuscation” – where an evaluator learns nothing more than what they could learn from oracle access to the function. Note that VBB, in full generality, is impossible, so we have to weaken our model slightly.
The most standard form of secure computation is one where the function (or circuit) is specified publicly in advance. When \(x\) is secret, we can evaluate with MPC, or (if the output is also secret) FHE. We can’t use FHE if the output is meant to be public, because the secret key (for decryption) would need to be known publicly. Perhaps some sort of functional decryption could work in that case? You would need to construct a predicate for “this value is the result of evaluating \(f(\cdot)\)“…
A strange case here is public \(x\) but secret \(y\). That doesn’t really make sense – how could the output of a public function evaluation, on public input, be secret? However, if we stretch our definitions slightly, this might apply to randomized functions. Then, exactly which output was generated on a specific run of the function is secret. This no longer fits the mathematical definition of a function; instead, “evaluation” now looks more like “sampling from some distribution” – but with the sampling party not knowing what value they’ve sampled!
Specifically, define \(f:\mathcal X\to\mathcal D\), where \(x\in\mathcal X\) and \(\mathcal D\) is some distribution. Then, our protocol should sample \(y\overset\$ \gets f(x)\), but somehow hide \(y\) from the sampling party. For example, we could have \(f(x)\mapsto \mathsf{Enc}_x(y)\) (\(f\) samples from the space of encrypted \(y\) under public key \(x\)). To make the sampling problem easier, we might require that \(\mathsf{Enc}\) is actually a trapdoor permutation. Then, \(f,x\) are both public, but the value that we output remains encrypted. In the distributed context, this is basically a distributed key generation protocol.
Note: under my definition, I’m requiring public \(f\) to mean that the function is unobfuscated.
| Input \(x\) is secret | \(x\) public | |
|---|---|---|
| Output \(y\) is secret | FHE or MPC | Randomized function / Public-key encryption / trapdoor permutation |
| \(y\) public | MPC with reconstruction @ end | (Plaintext Evaluation) |
With a secret function, we can achieve a slightly more convincing setup for the case of public input and private output: if the function is obfuscated, it can include an encryption circuit at the end (with a hardcoded key!). The security property of indistinguishability obfuscation means that the key is hidden, and thus so too is the output.
In the converse, we could also obfuscate a decryption circuit with a hardcoded private key, thus allowing the evaluation of secret functions with secret inputs which nonetheless produce public outputs.
| Input \(x\) is secret | \(x\) public | |
|---|---|---|
| Output \(y\) is secret | FHE w/ function privacy | Obfuscation w/ Encryption Circuit on Output |
| \(y\) public | Obfuscation w/ Decryption Circuit on Input | Obfuscation |
What have we learned? Well, obfuscation and trapdoor permutations are cool, and perhaps more related than I might have thought.