| There are a number of strong negative theoretical results in this space, and I mostly hear about people hand waving around them, making nonsensical claims, and then building insecure systems. For example, you can use outside information to run overly specific queries: “list the male students in woman’s studies 326 that got over a C”. Tricking me into running this, and observing the number of bytes returned will give you a nice approximation of Jim’s grade if you know he’s the only male in that class. The set of queries I can safely provide varies with the side channel information the attacker has. Also, if you have the ability to subtract and compare (I think those are the right two operators), then you can use that to decrypt the underlying data. There is also the best picture I have ever seen on wikipedia: https://en.m.wikipedia.org/wiki/Block_cipher_mode_of_operati... Scroll down to “electronic code book” to see why basic equality computationa break encryption guarantees. To make things worse, the attacker can keep track of what time each encrypted block is read/written, and infer communication patterns between users, and even infer which blocks contain information on which topics. (This is similar to the concerns over governments that gather “metadata”, because gathering “data” would be illegal) Anyway, I skimmed this article, but have spent days reading negative research results in this space that are pitched as though they are somehow practical, and I suspect I’m not the only one suffering from homomorphic encryption fatigue. |
About your query example, (F)HE never claimed to be secure against leaked information inherent to the query. This is more the resort of privacy, which is tackled by differential privacy researchers (and as such has nothing to do with FHE). Naturally you can put differential privacy on top of FHE but we're not there yet. The biggest problem here is that crypto is not magic: in your example, NO system can truthfully answer to the question without leaking the only male's grade, crypto or not. So maybe you'll restrict the system to run the query only when there are at least two male students. But then you're still leaking info to me if I'm the second student, and so on. Wanting crypto being able to do this kind of job is equivalent to wanting cars able to go fast anywhere anytime but that should never crash into a tree at more than 5 km/h: if you can go fast anywhere, you can go fast into a tree. Sad but true.
About the ability to subtract and compare, I don't understand what you are talking about, could you explain it?
About ECB, I mean, yeah, everyone in crypto knows ECB is insecure, this is stream cypher 101 and equivalent to "ROT13 is not secure, do not use it for crypto". But this has nothing to do with FHE.
Keeping track of time is a side-channel attack. Nothing to do with FHE in particular, it's common to all crypto. Most crypto libraries are secure against timing attacks, as it is one of the most obvious side-channel attack. FHE libraries will hopefully be too, just give them time. Also I think FHE is by nature more resilient to timing attacks as it must natively implement simultaneous computation of if/else branches, for instance.
Long story short, yeah, crypto is insanely hard to implement correctly. When your problem is well-defined (first difficulty), you must find the good tools (second difficulty), with the correct security parameters (3rd), and implement them correctly: no bugs (4th) and no side-channel attacks (5th). That's the reason why the first rule of crypto is "don't write your own crypto".