With homomorphic encryption (FHE), a server computes on encrypted data and returns the result still encrypted: only the key holder can read it. We picked 20 real uses and said, for each, whether it works today or sits at the frontier, using the costs measured on our bench.
Each application's band is our reading, based on the costs we measured (Apple M2, single thread, Lattigo v6.2.0, mean of 3 runs) and on the five-condition rule. Only voting was built end to end. Third-party numbers are marked.
Picture a locked glass box with built-in gloves. The owner puts the gold inside and keeps the key. The jeweller makes the piece through the gloves: working on the gold without ever being able to take it out. At the end, only the owner opens the box and sees the finished piece.
Homomorphic encryption does this with data. The hospital, the bank or the voter encrypts the data with their own key and sends it to the server. The server adds, multiplies, applies a model, all on the encrypted data, and returns the result still encrypted. Whoever computed never saw the data or the result.
The new post-quantum locks and homomorphic encryption rest on the same kind of math problem, the lattice. That is why homomorphic encryption also resists a quantum computer. The rest of the stack is in what breaks, what stays, what to swap.
Encrypted data carries deliberate "noise", which is what makes it secure. Each operation adds to that noise, and multiplication adds much more than addition. After about 8 multiplications in a row, the noise goes over the limit and the result comes out wrong.
Worse: it comes out wrong silently. On our bench, with a budget for four levels, BFV was right up to the seventh multiplication and at the eighth returned 28323 where the answer was 282, with no error or warning. That is why the circuit must be known before generating the keys.
To go past the budget there is the "cleanup" (bootstrap), which clears the noise: 1 min 18 s per operation at real security parameters, with 10.26 GB of keys. It works, but it becomes a batch job, not an app response.
Our maturity measurement produced a simple rule. Homomorphic encryption is a calm engineering decision when the five conditions below all hold at once. Remove one, and the cost changes by orders of magnitude.
The three bands, with the measured number for each, are in FHE maturity in 2026.
Filter by sector and by band. "With a condition" means the use works today if the final decision is made by the key holder; if the decision has to be made under encryption, it changes band.
20 applications shown
Computes without opening: the risk of a disease from glucose, BMI, age and blood pressure, with a simple model.
Shallow model. Works if the score comes back encrypted and the patient, who holds the key, reads it.
Computes without opening: whether risk markers (BRCA1, APOE4) appear in the patient's sequence.
Comparing segments needs comparison under encryption. With few markers, in batch, it works; open search over the genome does not.
Computes without opening: sum, mean and count of patients across hospitals, without one seeing another's data.
Batch aggregation: shallow circuit, no decision under encryption.
Computes without opening: the customer's score with a linear model, without the bank seeing income.
Works if the score comes back encrypted and the decision (approve or not) is made by the key holder. Deciding under encryption changes the band.
Computes without opening: the anomaly score of each transaction, without the model seeing amounts and destinations.
Fraud models usually exceed 8 multiplications in a row and need the noise "cleanup".
Computes without opening: "is this customer on the list?", without the bank revealing who it asks about and without the list leaking.
Set intersection grows in a straight line, with a good constant.
Computes without opening: that assets exceed liabilities, without showing the balance sheet.
Needs comparison under encryption and a proof that the computation was done right.
Computes without opening: the tax owed under a progressive table.
A bracket table is a chain of comparisons: with few brackets it works; it mixes arithmetic and logic.
Computes without opening: the result of each proposal, with votes weighted by shares.
Multiply by weight and add: shallow.
Computes without opening: the vote count, with the key split so nobody opens it alone.
Batch sum. Splitting the key is management, not computation cost.
Computes without opening: each department's average, without knowing who gave which score.
Batch aggregation.
Computes without opening: who placed the highest bid, without revealing the losing bids.
Finding the maximum is a chain of comparisons: with dozens of bids it works; with thousands, it does not.
Computes without opening: whether the sum of prices fits the budget, with each price in a valid range.
Adding is easy; proving each price is in range needs a separate proof.
Computes without opening: the average salary and whether each person is above or below it.
Works if the server returns the encrypted average and each person compares on their side.
Computes without opening: rules over encrypted values on a blockchain.
Tiny data and high value per transaction. Already in production, by third parties.
Computes without opening: a record in a database, without the server knowing which one was queried.
Works up to tens of thousands of records. At tens of millions, the server must touch the whole table and traffic explodes.
Computes without opening: the distance between a fingerprint or face and the enrolled template, without storing biometrics in the clear.
Verifying one person (1 to 1) is a distance, a shallow computation. Identifying among millions (1 to N) requires finding the closest under encryption, which does not work.
Computes without opening: counts of cars and people per area, without images or locations.
Adding counters.
Computes without opening: how many preferences two people share, without seeing anyone's.
One inner product.
Computes without opening: each item's score for the customer, without the server seeing what they bought.
Works if the server returns encrypted scores and the app picks the best. Picking the best under encryption changes the band.
There is no single FHE. There are three main families, and each application calls for one. CKKS works with approximate decimal numbers: averages, models, distances. BGV (and BFV) works with exact integers: counts and votes. TFHE works bit by bit: it is the one that can compare and decide "if this, then that".
The cost gap between families is structural. On our bench, one logical comparison takes 1.74 s with TFHE, and switching families mid-computation costs 13.9 s per position. Hence the rule of returning the score and deciding on the key holder's side: there, the same decision costs microseconds.
Homomorphic encryption hides the data, but it does not stop the server from tampering with the result. And there is a simple attack: the server adds a value to the encrypted data and watches whether the app accepts or rejects the result. That reaction is one bit, and repeated a few dozen times it gives the data away.
We measured it: about 47 queries and 79 ms to recover a 16-bit value, succeeding on 24 of 24 secrets. Control positions ("canaries") catch 100% of blind tampering but only 0.37% of an attacker who chooses where to tamper. If the server may be malicious, you need a proof of the computation or attested hardware, with published costs from ~2% to over 1000%.
Computing on encrypted data without opening it. Whoever computes sees neither the data nor the result.
The operation that clears the noise accumulated by computations. It allows long computations but costs over a minute per operation.
The server returns the encrypted score and the key holder decides. It is what makes most of these uses work today.
We classified each use from the measured costs and the five-condition rule. Only voting was built end to end; the other 19 are projections.
Apple M2, single thread, Lattigo v6.2.0. Between sessions the same test varies up to ~1.8×; ratios between operations are stable.
The "confidential blockchain in production" and the cost of integrity proofs come from third-party publications, not from our bench.
All bands assume a curious but honest server. If it can tamper, add the cost of a proof, which can range from negligible to prohibitive.
← FHE: computing without opening the data · stickybit.com.br