The majority of encryption is merely a lockbox -You lock your data, then send it on. When it needs to be used, it has to be unlocked, which is the dangerous bit – short lives make you vulnerable to attacks.
Homomorphic encryption turns that model on its head. With it, systems perform operation on the encrypted data and only the encrypted output is returned. The data itself is never exposed during the process. Only the final result is decrypted.
That‘s a whole new level of upgrade. That‘s a whole new paradigm of dealing with data security.
Table of Contents
Why the “Encrypt Everything” Approach Has a Hidden Flaw
Encryption the world is familiar with it is what we use to protect data at-rest and in-transit. But on the moment a cloud server, a model, or an third-party service needs to do something with your data it has to decrypt it. You rely on that platform not to be hacked, compromised or malicious.
That‘s a pretty big ‘ask’ even more so when you‘re trying to access someone else‘s server.
This is the fundamental problem on which HE (homomorphic encryption) is founded. We are not decrypting data to manipulate it, but we are operating on the cipher text directly. The math behind is rather abstruse, yet the principle is simply: encrypt the input, perform the calculation, decrypt only the output.
The server doing the work will never actually see your data.
A Brief History That Most Articles Skip
It Started as a Math Problem, Not a Product
This idea originated in 1978, when Rivest, Adleman, and Dertouzos posed the question: can we compute on encrypted data without decrypting it? This was only theoretical at the time no one had a practical solution.
Craig Gentry broke it in 2009. His PhD thesis, from Stanford, gave us the first fully homomorphic encryption scheme. It worked, but it was vastly slow – so slow that encrypting just one bit of computation took minutes on hardware from that time.
That was a breathtaking moment. The confirmation that mathematically everyone was feasible.
The Decade of Refinement
A decade later, we saw the emergence of 2 new bsgs, as well as another: BGV and BFV in 2010 each specialized in different kinds of calculations, allowing users to choose which was best suited to the task at hand. CKKS the first to support approximate arithmetics was introduced in 2017.
Such schemes can be implemented practically by libraries such as Microsoft SEAL, OpenFHE and HElib, taking them from the pages of academic papers into working software. I have been exploring how to use the documentation and example implementations of SEAL, and it has been surprisingly straightforward considering it‘s so deeply mathematical.
What ‘Computing on Encrypted Data Without Decryption’ Is Really Like
A Real-World Scenario Worth Unpacking
Suppose that a hospital would like to deploy an AI model, hosted on the cloud, to scan their patient records for potential diagnoses. Here‘s the rub: patient data is protected, and the instant they‘re uploaded to a third-party cloud service (even through an encrypted tunnel), the hospital becomes liable as soon as the data is decrypted for processing.
In this scheme the encrypted hospital records transferred into the cloud will be encrypted by the homomorphic encryption. The encrypted file will then proceed to the cloud. AI model will perform analysis on the ciphertext. The output which also remains encrypted will then be returned. It can only be decrypted by the hospital.
The provider of the cloud could not had accessed the data of real patients, neither the model of AI had seen names, diseases, nor entries.
This is not speculative both IBM and Microsoft have implemented pilot projects in health care with this very architecture.
Financial Services Are Already Testing This
Banks face similar constraints. When running fraud detection models, transaction data is constantly being revealed to third-party systems. With HE, the bank can outsource neither the computation nor the data.
My limited impression from skimming a handful of fintech security whitepapers is that HE is edging out the field, taking place together with PETs the broader set including differential privacy, enclaves, anonymization. Comparing to the entire PETs, HE belongs to the stronger (but to that end more time-consuming) group.
The Three Types You‘ll Actually See Referenced
Not all homomorphic encryption is the same. There are three main categories:
Partially Homomorphic Encryption (PHE) Provides support for only one type of operation addition or multiplication and not both. RSA is technically partially homomorphic. It is faster, but limited in what computations you are able to run.
Somewhat Homomorphic Encryption (SHE) Implemented for both addition and multiplication, but only on a limited computation depth. Suitable for simpler ML models or simple analytics.
Supports unlimited operations of anything that is Fully Homomorphic Encryption (FHE).The strongest and the most impressive amount of use cases that make everything possible also the most expensive in terms of computation.
Currently most practical applications are experimenting with FHE, although very often with either FHE optimizations or a hybrid of FHE with other techniques implemented on top, so that the policy can be implemented at scale.
Where It Actually Works and Where It Struggles
Strong Use Cases Right Now
- Healthcare analytics elaborate on how you can analyze data in the cloud without revealing sensitive information to the cloud infrastructure
- Integrated financial modeling Running a joint risk model across competing institutions without exchanging nonaggregated data
- Genomics analyzing genetic data for research without disclosing individual sequences
- Private AI inference Submitting queries to a model without the provider of the model seeing your input
Third, this is by far the most intriguing in the AI epoch. If you‘re using a proprietary AI system and wants to hide your prompts or data, HE could in theory enable you to obtain results completely hiding your query from the model provider.
Where It‘s Not Ready Yet
The speed penalty is real. FHE operations can be 1,000x to 1,000,000x slower than the same operation on plaintext, depending on the scheme and hardware. For real-time systems, that‘s a killer.
Storage overhead is yet another problem encrypted data with HE is magnitudes greater than its plaintext counterpart. And the complicated deployment means even smart engineers need a couple weeks to get it properly working.
Just found out that almost all production deployments being used out there are all to use HE in the offline/batch processing instead of anything that need real-time response. That‘s an honest constraint to know upfront.
How It Connects to Federated Learning and Multi-Party Computation
It does not travel alone. Useless by itself, HE can be seen as part of a family of privacy-preserving techniques, and knowing its position in this family is quite interesting.
Federated Learning and Multi-Party Computation are two approaches with similar end goals – that of performing computations on data across multiple remote, confidential sites without aggregating that raw data. Federated learning enables local devices to own the data and only exchange model updates, while Multi-Party Computation protocols often allow several parties to simultaneously compute a function.
HE can also serve as a layer agnostic of either. Taking the federated learning paradigm as an example, model updates from edge devices can be encrypted with HE, so that the server in the middle can combine them without the actual gradients getting revealed even if they themselves are sometimes revealed and could give away information about training data.
Combining methods results in stronger privacy guarantees than any one method used on it‘s own would provide. There‘s been, for example, papers published by Google and Universities like MIT around theses hybrid architectures, and they are starting to emerge in more privacy-conscious AI research.
My Take After Going Through the Developer Experience
The tooling is improved than, but is still relatively niche.
Microsoft SEAL is arguably the most accessible starting point. Supports BFV and CKKS schemes, C++ and .NET API‘s, and the documentation is (somewhat) readable. OpenFHE is aimed more at research but is more flexible. HElib, of IBM, is robust for ‘real’ production experimentation.
With SEAL‘s sample code I learned that simple tasks adding, encrypting and decrypting a handful of integers can be picked up in an afternoon. What is more difficult is grasping noise budget, informing you how many tasks can be performed without decryptability failing. This is where the real knowledge of FHE is.
For the developer crowd: that‘s not something you become familiar with by doing a weekend side project. Yet it‘s no longer only in the hands of those PhDs in cryptography.
What the Cloud Providers Are Doing
There are teams working on HE acceleration (software, hardware) for all of AWS, Google cloud and Microsoft Azure. AWS has published work on hardware accelerated FHE. Intel has been integrating HE acceleration into its processor roadmap.
The message is loud and clear The major cloud players view this as an inevitable infrastructure need rather than a niche research one.
Two Things Most Articles Don‘t Tell You
Let‘s clarify two points initially. First: HE is not a panacea. Even if all the computations are encrypted, an attacker monitoring the computation process, by noting which operations are being executed, their frequency and their order, might have some knowledge on the data that was processed: it‘s an ‘access patterns attack’, and that‘s a true disadvantage of HE.
Second: fully in Fully Homomorphic encryption is not meant to be a reference to security, it is instead a reference to the kind of operations the scheme can perform. The implementation, scheme choice and parameter selection all have implications on security and performance. Do not treat FHE as a cure.
Honest Verdict: Who Should Be Paying Attention to This
If this is healthcare IT, finance, legal technology, or where external systems need to access and interpret sensitive data find out about this now, not second… In the future, the squeeze on data privacy (GDPR, HIPAA, future AI regulations) is only going to get tighter and HE give a technical solution that is compatible with that direction.
As a developer, engineer, working in AIEF: HE is clearly relevant to the paradigm we are moving toward, which is again privacy-preserving machine learning. If any of your algorithms have model inference over sensitive inputs, or collaborates between organizations, then your toolkit is becoming relevant.
For those working in highly technical fields, this is the sort of pile-of-mandatory-upgrades that you won‘t notice as a user, but which will have a huge impact on how reliable the system you access is. Can you search encrypted database without decrypting it? Can an AI infer anything about your data without ever seeing it? That is what this will enable at scale.
It‘s not quite there (yet). Though not as far off as most people think.
I’m a technology writer with a passion for AI and digital marketing. I create engaging and useful content that bridges the gap between complex technology concepts and digital technologies. My writing makes the process easy and curious. and encourage participation I continue to research innovation and technology. Let’s connect and talk technology!
