Homomorphic programs are designed to run without knowledge of the key. You have to process every piece of data in basically the same way. So I'm not entirely sure where you think the side-channel attack would arise.
My first guess would be conditionals, but I'd guess there is no real branching in the execution of operations on data. Another would be evaluating comparisons, but those aren't very easy to do in bitwise terms, and you can't read the output either.
But the thing about this setting is that you don't possess the secrets, so you can't reveal the secrets by noticing how long things take.
An analogy to think about might be blind signatures. In blind signatures you sign a blinded token and then the other party can unblind it to get a valid signature from you over a message whose content you don't know. This is classical public-key cryptography. In that case there is a secret key, and a timing attack against someone who can observe the signature creation might reveal that key. The connection between the blinded and unblinded message is also meant to be secret, and a timing attack against someone performing the blinding or unblinding operations might also reveal that relationship.
However, there is no timing attack that the signer can perform against itself to reveal the relationship between the blinded and unblinded messages, and there is no timing attack that the other party can perform against itself to reveal the secret key.
I think this analogy holds up for most purposes (indeed, blind signatures can be viewed as an extremely specific, narrow kind of homomorphic encryption), but I'd be happy to hear corrections if someone can see a way that it doesn't.
the "side channel" i am referring to is in however this impliments this mixing you refer to.
if you can observe how the internal state is changing given a cloud keyset you should be able to infer the secret key. in the same way you can infer the iv used in a mesernine twister from like 27 cycles (or whatever).
downvotes and promises definately wont reduce my skeptacism.
The "cloud keyset" is another name for "public key". Usually, public key enables encryption but no decryption, here, the cloud key enables computations on ciphertexts, but not decryption.
Like in public key cryptography, you can give a RSA public key to an adversary, he can use it as much as he want, he will not be able to get any information on the private key (in any practical time). Most importantly, the cloud key is not secret, nor obfuscated: the cloud already knows each bits of it (side channel attacks are not relevant).
The "cloud key" is the public part of the key given to the cloud so that he can perform his operations (circuit, bootstrapping). There are strong security proofs that show that it is impossible to recover the secret key from the cloud key.
In the case of TFHE, if there was a polynomial algorithm that would recover even a single bit of the secret key given the cloud key, this algorithm could be used to break the LWE problem, and also worst case instances of lattice problems (which are much harder than factorization or discrete log for instance).
because the simple fact you can process the data and examine the output reveals untold quantities of information about the key.
the known plaintext attack breaks pretty much every crypto system, mix that with statistical analysis of this "processing" and I'm sure whatever is in the cloud will surrender its secrets pretty quick.
And all that risk for what benefit? none of this processing will ever be faster than doing the processing in place.
You can examine the output and so on, but that's not a side-channel attack, which is what I was responding to.
And yes, it is a malleable cryptosystem, but that doesn't imply you can learn the key from an input/output pair, nor does it imply you can read the input given to you. It just means you can change the output in a way that can still be decrypted by the same key.
Usually people use padding and IVs and such to prevent that, but this system is made to allow computation with it instead.
Certainly there may be some flaw that we can't see yet, but to say you're "sure" some secrets will be quickly surrendered seems foolhardy.
> And all that risk for what benefit?
It's very interesting from a theoretical perspective, and it's good to know that if you need to carry out computation on devices you don't trust, it is at least possible to prevent your input and output from being stolen.
This is already a 30x increase in efficiency from the last generation. It may never be faster, but there's always a chance someone will find other reasons to use it.
you dont need to get the key, you just need to decrypt the data.
they do not need to be one in the same, if, statistically you can infer input given output.
And i never said sure in any way shape or form. what i said is i am skeptical of the motivations driving a project like this, when we know for an absolute fact bad men are trying to steal our secrets. It seems like a lot of work and very heavy math for something that will never tip the balance that is holding the cloud back with people not trusting it to keep their secrets.
for example, if you can do something as simple as compute a hash of the unencrypted data, you can instantly decrypt all data with known hashes with a high degree of certainty, without ever knowing the keys - side channel attack.
In homomorphic encryption, the cloud performs operations on encrypted data, and gets only an encrypted result. He does not have any information on the decrypted result.
That's the difference between FHE and IO or multilinear maps. The second ones are almost all broken, mostly because of the attacks you mention. FHE, on the other hand, has semantic security.
None of the other AES finalists were vulnerable to known plaintexts attacks. Neither is 3-DES or chacha20. DES and RC4 are now considered insecure, but in their day they were resistant known plaintext attacks as well.
Other than some toy examples, and cryptosystems that were used before cryptography was studied academically, I can't think of any that are vulnerable to known plaintext attacks.
> And all that risk for what benefit? none of this processing will ever be faster than doing the processing in place.
The benefit comes into play when you mix data from different sources that don't trust each other (to the point where they would never agree to one of them doing the processing in place). Homomorphic encryption allows combining the data without ever revealing it to the one doing the computation.
For example when two parties are interested in making a deal, but don't want to reveal it unless the other party is interested as well. (The example is usually a date, but it could be applicable to voting or other situations where both privacy and unanimity are desired.)
By performing a homomorphically encrypted computation, they can set it up to only reveal the final decision, but not the individual inputs that determined it, so nobody loses face.
So yes, for varying definitions of "fast".