Last time I looked at the market as an interested layman about three years ago was a no, but maybe we’d have something viable in or around an order of magnitude in decades optimistically, I’d feel there are probably some niche applications of partially homorphic schemes possible but folks like NIST, BSI etc are not running around with their hair on fire telling everyone to adopt so I’d say we’re a ways off, but I’d verify this with you own reading and other folks opinions.
A lot of the clallenges around involve speed and the practically of doing it on general compute - if your scheme needed to be useing ASICs then it’s tough on your compute being fungible.
The reality is currently we do have a working homomorphic encryption system and it is working: https://www.theregister.co.uk/2018/03/08/ibm_faster_homomorphic_encryption/
However, the main issue is processing power, because it runs so slow on normal computer hardware/systems = it is being also applied to Quantum Computers and waiting for this to come to maturity to speed it up and make it practical to use.
You can try it for yourselves under GitHub: https://github.com/shaih/HElib
Microsoft has also made its version open source too: https://duo.com/decipher/microsoft-open-sources-seal-homomorphic-encryption-library
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
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.
I'm giving a presentation on homomorphic encryption, and how overblown the hype is, on Friday, at the Vancouver Chapter. (If we don't get cancelled by coronavirus panic.)
Helpfully, the Canadian Centre for Cyber Security has announced that homomorphic encryption is the "Holy Grail" of encryption, so I have yet another example of the hype for my presentation.
(I was going to give the pressie at BSides Vancouver in a couple of weeks, but that's been cancelled due to coronavirus panic ...)