We've discussed homomorphic encryption here, and elsewhere, and even mentioned it in other places, but I don't think we've really provided a good outline.
The basic concept is to be able to encrypt some data, and then still perform some useful calculations, or process the data, without decrypting (and thus exposing) it. (Microsoft seems to want to tie homomorphic encryption to the "cloud," but that's just one possible use.)
IBM seems to be usually creditted with the "invention" of homomorphic encryption. It's library, available on GitHub
https://github.com/shaih/HElib
is an implementation of the Brakerski-Gentry-Vaikuntanathan (BGV) form of homomorphic encryption. Microsoft also has a library on GitHub
https://github.com/Microsoft/SEAL
Both of these libraries offer addition and multiplication. Google has a somewhat variant process offering comparison and limited addition (and, again, a GitHub library
https://github.com/Google/private-join-and-compute ) (I'll come back to those functions.)
The thing is, as a concept, homomorphic encryption isn't new. We've been using it for decades. We've been hashing passwords, and storing them in hashed form. When we want to confirm one, we hash the submission, and then compare that against the stored hash. So we are encrypting data, and using it without decrypting it.
But that's only one, very specific, application. And that's the other thing about homomorphic encryption, as a concept. It isn't a single implementation. (Shades of "blockchain," anyone?) If you want to perform different functions, you have to use different algorithms. With BGV you can add, multiply, and shift. With BFV you can do modular arithmetic. With CKKS you can do addition and multiplication, but you only get approximate results.
As a horrendously simplified example, if you want to sort, you can use the Caesar cipher. It hides the data, but keeps it in (mostly) ordinal position. (Except near wraparounds.) (Most modular functions will have somewhat similar traits.)
Another not-terribly-useful case would be an exact match search. You can use any block cipher in electronic code book mode, as long as the block size matches the record size. Any identical record is going to match the ciphertext, and therefore you can search without having to decrypt anything.
Microsoft specifically says, of its library, that "other operations, such as encrypted comparison, sorting, or regular expressions, are in most cases not feasible to evaluate on encrypted data using this technology." So, if you want those functions, you've got to invent other algorithms. And it is very unlikely that any algorithm is going to be invented that gives you a whole bunch of functions. When I say algorithm, it's not just the processing part that I'm talking about. It's related to how you encrypt the data in the first place.
In order to do homomorphic encryption, you have to encrypt the data in a certain way that is going to be susceptible to the processing you want to do. And that means you are accepting certain weaknesses in the way you encrypt the data. In my earlier examples, the Caesar cipher is very weak in terms of key address space. Electronic code book is the weakest mode for block ciphers. In the same way, real homomorphic encryption algorithms are going to have weaknesses related to the type of function you want to be able to perform on the encrypted data. (The Google project, for example, notes that their protocol has security against "honest-but-curious" adversaries, but has weaknesses, and provides no protection against malicious input.) The implementations may add protections to defend against those weaknesses. But the more functions and operations you add to the list of what you want to do with the encrypted data, the more weaknesses are going to be built into the algorithm.
Now, homomorphic is a technology to watch. It's developing, and it can be useful for certain applications. But it's not magic. If you have an application, you are going to have to find the right algorithm for it. If you have multiple applications, you may have to use multiple algorithms (which probably means multiple copies of your database, and there are risks associated with that). All the protections that have to be built in to the algorithms are going to mean that homomorphic encryption, like asymmetric encryption, is going to be heavily processing intensive (probably very heavily processing intensive).
Pay attention to it. But don't expect it to solve all your security problems.
............
Other posts: https://community.isc2.org/t5/forums/recentpostspage/user-id/1324864413
This message may or may not be governed by the terms of
http://www.noticebored.com/html/cisspforumfaq.html#Friday or
https://blogs.securiteam.com/index.php/archives/1468
