FHE isn't obfuscation, nor is it functional encryption. it's not the cryptographic equivalent of Intel SGX; all it lets you do is put encrypted inputs into a program and get encrypted outputs back.
the real holy grail is program obfuscation, which lets you build your programs as "black boxes," containing secrets but never divulging them. there's progress on that front, but it's less feasible than FHE (which is saying something!)
yeah, I was referring to iO. I'm not an expert at all, but the most promising avenue I see is to make iO decryptors of FHE programs, which would verify that the output came from the end of the FHE program and then decrypt it.
I'm not sure whether you could successfully hide the FHE decryption key with iO, though.
> all it lets you do is put encrypted inputs into a program and get encrypted outputs back.
Indeed.
> the real holy grail is program obfuscation
Why so? FHE is a way stronger fundamental improvement that enables a completely different way to compute on individual data without compromising privacy and secrecy, in a trustless way that TEEs/SGX can't.
Obfuscation implies FHE, but we the converse is not (necessarily) true. In fact the only realizable notion of obfuscation, indistinguishablity obfuscation, is so “weak” that it can exist even if things like symmetric encryption don’t.
program obfuscation could trivially implement FHE. the obfuscated program would simply:
1. decrypt the inputs using its embedded private key.
2. do the computation.
3. encrypt the outputs and return them.
I'm not saying SGX is the holy grail, it's as compromised as Intel. I'm saying that an actual cryptographic primitive, like SGX but actually trustless and made of math instead of hardware, is.
I think what they meant was that the secrets would be in a form that the black box would consider decrypted-equivalent (i.e. able to perform computation on), but that wouldn't be plaintext to an outsider.
it's actually stronger than FHE, which is what I was saying. virtual black-box obfuscation would mean that an attacker could only observe the outputs and the inputs - all intermediate states and data, such as the decrypted inputs or the decryption key or logic - would themselves be encrypted. it's like having FHE with an output decryptor circuit at the end.
unfortunately VBB was shown to be impossible, but indistinguishability obfuscation - producing a program that's indistinguishable from any other program that produces the same outputs for the same inputs - is possible, as recently demonstrated.
iO is weaker but still useful. imagine that I have a program that looks like "return input == secret". with iO, you couldn't recover the value of "secret" from the program, since "return Hash(input) == HashedSecret" is equivalent to the original, and iO guarantees that all alternate implementations of a function are indistinguishable.
I really want to understand this. Let's say my focus is on retrieving the input, not the secret.
I do not want the people who are running the program to know my input. I do not want the program to know my input. Does indistinguishability obfuscation help with that?
if you want the users of the program to know the output, but you want to keep the input a secret, you could use functional encryption (another special case of iO.) users can compute a function of the input without being able to decrypt the input or learn anything else about it.
if you want the output to be encrypted too (even potentially with a different key), you can use vanilla FHE.
There is a difference between an array of encrypted numbers (which fhe requires if I understand it correctly), and a completely encrypted bitstream (where the data could be put to hide the fact that it is a number array)
This does not make sense to me, I must be missing something important. If your input is an encrypted state of a Turing machine, then isn't FHE able to simulate the evolution of that Turing machine (hence keeping state and secrets without divulging them)? After all, there is no real difference between data and program.
oh yes. brainfreeze [0] is an example of an FHE Brainfuck machine. the problem is that your users can't decrypt any outputs at all from them. there's also a major possibility of confused deputy attacks if you blindly decrypt outputs returned to you by your users, since the users can "circuit-bend" your FHE program to a degree. for instance, nothing's stopping me from sending the output from brainfreeze back to you early - I can't even tell when it's halted!
edit: actually, that's the fatal flaw with FHEs as Turing machines. you can't ever tell when they halt, because that would require decrypting a bit and exposing it to the end user. you just have to keep running them until you get bored, or abandon Turing machines for circuits.
you might be able to use the user as an oracle, but the real issue is that the user has to be around. querying the user after every clock cycle will get old, fast.
What about programming in the style used to avoid timing attacks. My understanding is that there are plenty of situations even today where for security purposes (side-channel timing attacks) you need your program to execute in a fixed number of steps independent of the input. Is this not enough to solve the problem?
Could you please explain a bit more to the more uninitiated like me:
1) Is my understanding correct - FHE-C++ library allows me to encrypt a photo from the client (in the browser), send it to the server, perform image operations on it, return back the photo to the client in a transformed state without the server ever being able to see what its transforming?
2) Is the holy grail you're noting allows any piece of software to be compiled and encrypted, but still take inputs and produce outputs? do the inputs and outputs have to be encrypted with the same key as the compiled software?
2. for obfuscation, the inputs and outputs are unencrypted, but the behavior of the software can't be analyzed. as a motivating example, say that I've built some ransomware, but I can't trust my C&C server to stay up. instead, I have the worm embed the private key into a freshly-compiled black box. if you feed the black box a valid Bitcoin block containing a ransom transaction to my address, it spits out the private key and you can decrypt your files.
there are many less evil examples out there - wanting to protect your ML models but still make them redistributable, etc.
How is this possible (I have no clue about FHE)? If the server can do operations on the image, then the image can't look like random noise, or not? And if there are indeed patterns the server can operate on, then the image can be decrypted?
If you can write a program with few to no if statements that depend on the data, then you can run that program relatively efficiently under FHE.
A blur or sharpen filter would be an easy example. The server sees you take the random noise of each pixel, mix it with the nearby pixels, and output new random noise.
Sorry if I'm being too thick here, but a blur filter needs information about the neighbour pixels. It can't operate on a single pixel alone (well it changes things pixel by pixel, but needs the neighbour pixels as input). If I can extract these neighbour pixels from the encrypted image, why can't I extract the image itself?
Each pixel is encrypted separately. FHE lets the server take two encrypted numbers and add or multiply them to make a new encrypted number. There is no way for the server to ever know what any of those numbers actually are.
Doesn't it let you avoid decrypting the data anywhere while processing that data tho? I think that might be part of the magic that makes it valuable. It seems like if implemented well, it's another additional solid layer of security that makes an attackers job harder.
the real problem is that processing the data with FHE on someone else's computer is tens of thousands of times less efficient than doing it yourself, unencrypted, on your own computer, so there's no real benefit from offloading the computation.
except if you're mixing data sources.
for instance, say that I have a sweet Snapchat filter that I don't want to let off my servers. and you want to use my filter, but you don't want me to see your face in plaintext. in that case you can send me your encrypted photo, I run it through my filter, and send the results to you for you to decrypt.
its only real use case is that type of split data custody.
the real holy grail is program obfuscation, which lets you build your programs as "black boxes," containing secrets but never divulging them. there's progress on that front, but it's less feasible than FHE (which is saying something!)