"Are electric cars ready?" Depends on the trip.
For someone who drives 40 km a day in town with a plug in the garage, electric cars have been ready for years. For someone crossing the country towing a trailer, not yet. "Is it ready?" has no single answer; it has one answer per trip.
Homomorphic encryption (FHE: computing on encrypted data without ever opening it) is the same. There are uses where it is a sober engineering decision, and uses where the budget changes by an order of magnitude. The difference is not the library’s maturity: it is the shape of the computation.
The costs below come from the same bench that produced the FHE frontier (sixteen tests on the same machine). This page is the next layer: not where the cryptography stops, but what you can put in production today.
Large batch, few multiplications, decision at the client.
There is a real set of uses where FHE is a sober decision, not a bet. They all share the same shape: many records at once, few multiplications in a row, and every decision made on the key holder’s side.
| Use | Why it ships | Measured cost |
|---|---|---|
| Batch aggregation: sum, mean, count, vote | no decision under encryption; adding spends no budget | dot product of 2,048 numbers: 115 ms |
| Last layer of an AI model | the heavy part runs in the clear on the device; only the summary is encrypted | same |
| Private lookup in a table of up to 10⁴–10⁵ rows | the pattern Apple and Microsoft already ship | 10⁴: 1.2 s / 20 MB (proj.) · 10⁵: 14.1 s / 196 MB |
| Matching lists (PSI) | linear cost, with a good constant | measured on universes of 10⁶ and 10⁷ |
| Small logic with branches (TFHE) | no depth limit, ~54 ms per gate | 1 comparison: 1.74 s |
| Confidential blockchain | tiny data, high value per transaction | outside the bench · in production (mainnet) since Dec 2025, per the vendor |
Works, with a condition.
Many multiplications in a row
Each multiplication spends part of a fixed budget. With real-security parameters (128-bit), the budget is short: our own bench found that the "8 multiplications" it used to cite ran on weaker parameters, and that at the real ceiling 2 levels fit. Beyond that, the "cleanup" (bootstrapping) kicks in: 1 min 18 s each time and 10.26 GB of keys sent before starting.
A new shortcut changes the math: sending the package back to the client, who decrypts and re-encrypts, costs 1.04 s and needs no cleanup keys. The price is that the client stays online and sees mid-computation values. Without that, it is a batch job, not an API response.
Mixing arithmetic and logic
Switching dialect mid-computation exists and was measured: 13.9 s per position. Worth it for very few decisions, and nothing more.
Single lookups
A lone encrypted number takes a package 229,428 times its size. FHE rewards batches and punishes single lookups: the opposite of what database people expect, and the origin of most badly sized architectures.
And it is not a matter of waiting for the next release.
The right pattern for deciding is always the same: return the encrypted scores and decide at the client. On the key holder’s side the same decision costs microseconds and no privacy at all, because whoever decides is already who can decrypt.
A point vendor material tends to blur: FHE’s two big dialects (one for batch arithmetic, CKKS and BGV; one bit-by-bit, TFHE) differ by ~6 million times one way and ~170 the other. The difference is structural, not maturity. Faster hardware shifts both; it does not bring them together.
| Operation | Measured cost | The problem |
|---|---|---|
| Picking the largest of 1,000 under encryption | 130 h (anchored) | at real 128-bit; and precision fell to 3 bits in some slot: slow and wrong |
| Lookup by encrypted position in 10⁷ rows | 19 GB (projected) | if the server jumps to the right row, the jump reveals which: the whole table must be touched |
| Comparing near-equal ciphertexts | difference < 2⁻³⁰ | blind zone: the operation has no defined result |
| A whole deep neural network under encryption | — | the usual activation (ReLU) costs a comparison; that is why networks are retrained with x² |
Where the frontier can move.
Hardware: the promise is not silicon yet
Third-party numbers
DARPA’s DPRIVE program produced a wave of dedicated chips: Niobium partnered with Semifive to fabricate on Samsung 8 nm, Fabric Cryptography raised US$ 33 million, Optalysys around US$ 30 million for a photonic approach, Intel continues with Heracles. It is real investment and the direction is right. But the 5,000× to 17,000× quoted for this generation are simulation and projection, not shipped, measured chips.
In practice: when you get a vendor number, ask the parameter size (logN). On this bench, the "toy" one (logN=13) is ~40 times faster than real security (logN=16), and almost no published material says which one it quotes.
Bandwidth, which silicon does not solve
In lookup uses, the measured limit is not CPU: it is the network. A 1-million-row table cost 1.91 GB of traffic per query; 10 million project 19 GB. A chip speeds up the math and moves not one byte less. The research line that attacks the right half (transciphering: sending AES-encrypted data and converting inside FHE) is not mature yet, and we did not measure it.
Integrity: the cost nobody budgets
FHE gives confidentiality, not integrity. The same property that allows computing on ciphertexts prevents noticing a tampered result. The attack needs nothing exotic: the application opens the result and checks it ("it must be in this range"); if not, it reacts (error, retry, log). That reaction is a bit the server observes. By adding chosen values and reading "accepted or rejected", the server recovers the data in the clear in 47 questions, without attacking the key.
The cheap defense, the "canary" (positions with known values), catches 100% of blind tampering and only 0.37% of tampering that chooses where to hit. A canary is hygiene, not integrity. The real fix (a proof over the computation or attested hardware) costs, per the literature, from ~2% to over 1,000%: three orders of magnitude of uncertainty.
When the decrypted result is shared
Literature
For the approximate dialect (CKKS), classical security is not enough if the decrypted result is shown to third parties. Li and Micciancio (EUROCRYPT 2021) showed that the decrypted result allows key recovery; Guo and coauthors (USENIX Security 2024) showed recovery from a single shared result, on a widely used open library. The good news, from 2025: about 2 bits less precision restore security at standard parameters.
In practice: "does the decrypted result go to third parties?" is a triage question on its own. If yes, the parameter changes, and the cost is small as long as the question is asked before generating keys.
Standardization, and the silent error
The field has left the normative vacuum: ISO/IEC 28033 is under way (general and CKKS parts at final draft, BGV/BFV voting until April 2026, table lookup and dialect switching in preparation), and NIST is following. What is still missing is what would prevent the most dangerous failure we measured: with a 4-level budget, BFV mode gets the 7th multiplication right and the 8th wrong silently, returning 28,323 where the answer is 282.
One bit per question is enough.
The reaction attack, measured on 24 16-bit secrets: 46.7 ± 1.3 questions on average, 24 of 24 recovered, 79 ms per value. The server never decrypts anything; it only watches whether the client accepted.
What this changes: every project where the server may be malicious, not just curious, carries a cost whose plausible size ranges from negligible to prohibitive. Until that price settles, it has to enter the budget as declared uncertainty.
FHE ships when all five hold together.
- Large batchMany records at once. A single lookup pays for the whole package.
- Few multiplications in a rowFits the budget without a cleanup. At real 128-bit, the budget is short.
- Decision at the clientComparing, picking the largest and branching stay with the key holder.
- Small table to searchUp to 10⁴–10⁵ rows. Above that, bandwidth rules.
- Honest-but-curious serverIt follows the protocol, it just must not see the data. If it can cheat, the cost is unknown.
Remove one, and the cost changes by an order of magnitude. Remove the last one, and the cost is unknown. That is why the answer to "is FHE ready?" is: it depends on which of the five you are missing. It is a one-hour conversation with numbers, not six months of proof of concept.
The operation that wipes the noise from encrypted arithmetic and restores budget. Possible, and expensive: 1 min 18 s and 10.26 GB of keys at real 128-bit.
The server follows the protocol to the letter but would like to see the data. It is the scenario where FHE protects well. The cheating server is another problem.
The larger, the safer and slower. logN=16 is real 128-bit security; logN=13 is a "toy" and ~40× faster. Always ask which.
Where this could be wrong.
One bench, one machine
The costs come from an Apple M-series laptop, on a single core, with the Lattigo library. Ratios between operations carry; absolute times do not. On a server with an accelerator the numbers change, and the shape of the frontier does not.
Integrity came from another bench
The reaction attack and the canary were measured on an integrity bench separate from the cost bench. The ~2% to over 1,000% range for the fix is from the literature, not ours.
Third-party numbers
Chips, funding rounds, the 5,000× to 17,000× and the blockchain production date are third-party statements, flagged as such. We did not measure silicon.
The rule of five is a simplification
It gets the order of magnitude right, not the number. A case with four conditions may ship with a protocol shortcut; a case with all five may fail on bandwidth. That is what the assessment is for.
← FHE: computing without opening the data · stickybit.com.br
- Our own measurements: cost bench (FHE repository,
12_reality_check, Lattigo v6.2.0, mean of 3 runs, August 2026) and integrity bench (reaction attack, canaries). - Viand, Knabenhans and Hithnawi, Verifiable Fully Homomorphic Encryption (arXiv:2301.07041).
- Li and Micciancio, IND-CPA-D security of approximate schemes (EUROCRYPT 2021) · Guo et al., USENIX Security 2024 · IND-CPA-D with HintLWE (2025) · OpenFHE: security of CKKS.
- Standard: ISO/IEC 28033-1, part 2, part 3 · NIST, privacy-enhancing cryptography (FHE).
- Hardware and market: DARPA DPRIVE · Niobium and Semifive · Intel Heracles (IEEE Spectrum) · Zama fhEVM.