Cryptography & Protocols

Homomorphic Encryption: Computing on Data You Can't Read

May 29, 2026 8 min read Haven Team

Almost every encryption scheme you use shares one limitation: to do anything useful with the data, you first have to decrypt it. Homomorphic encryption breaks that rule. It lets a server add, multiply, and compute over numbers it cannot read — and after decades as a theoretical curiosity, it is starting to ship in products you already use.


Imagine handing a locked box of jewels to a jeweler, asking them to assemble a necklace, and getting back a locked box containing the finished piece — without the jeweler ever opening the box or seeing the jewels. That analogy, popularized by IBM researcher Craig Gentry, is the promise of fully homomorphic encryption (FHE): arbitrary computation on encrypted inputs, producing an encrypted result that only the key holder can unlock.

It sounds impossible, and for thirty years it nearly was. The idea was floated in 1978 by Rivest, Adleman, and Dertouzos — shortly after RSA — but nobody could build a general scheme. That changed in 2009, when Gentry's PhD thesis described the first plausible construction. The field has moved fast since.

What "Homomorphic" Actually Means

A homomorphism is a structure-preserving map. An encryption scheme is homomorphic if an operation on ciphertexts corresponds to a meaningful operation on the underlying plaintexts. Concretely: if you can compute Encrypt(a) ⊕ Encrypt(b) and decrypting the result gives you a + b, the scheme is additively homomorphic.

Some schemes you already know have partial homomorphic properties almost by accident:

These are partially homomorphic: they support one operation, unlimited times. The holy grail was supporting both addition and multiplication arbitrarily — because with those two operations you can build any computation, the same way logic gates build any circuit.

The Noise Problem and Bootstrapping

Modern homomorphic schemes are built on lattice problems — specifically Learning With Errors (LWE) and its ring variant. Security comes from deliberately injecting small random "noise" into each ciphertext. The catch: every homomorphic operation makes that noise grow. Multiply two ciphertexts and the noise grows fast. Let it grow past a threshold and decryption returns garbage.

Gentry's breakthrough was bootstrapping: a way to refresh a ciphertext by homomorphically evaluating the decryption circuit itself, producing a fresh ciphertext of the same value with the noise reset. With bootstrapping, you can compute indefinitely. Without it, you are limited to a fixed "depth" of operations — a regime called somewhat or leveled homomorphic encryption.

The honest caveat

Bootstrapping is what makes FHE "fully" homomorphic — and it is also what makes it slow. A single bootstrap can take milliseconds to seconds depending on the scheme. This is why most real deployments avoid full bootstrapping and design their computation to fit within a leveled budget.

The Schemes That Matter

You will see a small alphabet soup of scheme names in this space. Each makes a different trade-off:

Scheme Best for Data type
BGV / BFV Exact integer arithmetic Integers, modular
CKKS Machine learning, statistics Approximate reals/complex
TFHE Fast bootstrapping, boolean circuits Bits, small integers

CKKS is particularly important because it works on approximate real numbers — accepting a small, controlled loss of precision in exchange for the ability to do the kind of floating-point math that neural networks need. TFHE, by contrast, makes bootstrapping cheap enough to do after every gate, which suits boolean logic and comparisons.

The reference implementations are open source: Microsoft's SEAL, the community-driven OpenFHE (which absorbed PALISADE and HElib lineage), and Zama's TFHE-rs. You do not need to implement lattice math yourself.

Where It's Actually Used

For years, "real-world FHE" was an oxymoron — the overhead was thousands of times slower than plaintext computation. That gap is closing for specific, narrow workloads, and one shipped example stands out.

In 2024, Apple open-sourced swift-homomorphic-encryption and described using a BFV-based scheme for two production features: Live Caller ID Lookup, which checks an incoming number against a server database without revealing the number to the server, and Enhanced Visual Search in Photos. The query is encrypted on-device; the server computes over it homomorphically; only your phone can read the answer. This is paired with metadata-minimizing techniques so the server learns as little as possible about who is asking.

The most realistic near-term use of homomorphic encryption is not "compute anything on anything" — it is narrow, high-value lookups where revealing the query itself is the privacy risk.

Other active areas include privacy-preserving machine-learning inference (send an encrypted image, get back an encrypted classification), encrypted database queries, and secure aggregation in privacy-preserving analytics. Homomorphic encryption is also a building block for private information retrieval, where you fetch a record from a database without revealing which record you wanted.

What It Is Not

Homomorphic encryption is sometimes oversold as a cure-all for cloud privacy. A few honest limits:

Why It Matters for Privacy

The dominant privacy model today is "trust the server not to look." End-to-end encryption improves on that for data in transit and at rest, but the moment a service needs to compute on your data — search it, rank it, match it — that data usually has to be decrypted somewhere. Homomorphic encryption is one of the few tools that attacks this final gap directly: it lets a server be useful without being trusted.

It will not replace transport encryption or end-to-end messaging. But as the performance curve bends, expect to see it quietly powering more of the lookups and matches that today require handing your query to a server in the clear.

Try Haven free for 15 days

Encrypted email and chat in one app. No credit card required.

Get Started →