Homomorphic encryption · Measurement
“Is FHE ready?” has no single answer — it has one answer per workload. Here are the three bands, with the measured number behind each, and the five things that have to move before the frontier does.
There is a real set of workloads where FHE is a sober engineering decision, not a bet. They all share the same shape: large batch, shallow circuit, decision on the client.
| Use case | Why it closes | Measured cost |
|---|---|---|
| Batch aggregation sums, averages, counts, voting |
shallow circuit, no decision under encryption | 2048-dim inner product: 115 ms |
| Final linear layer of ML | the heavy lifting runs in the clear on the device; only the last dense layer goes encrypted | same as above |
| Private lookup up to 10⁴–10⁵ | the PIR pattern Apple and Microsoft already ship | 10⁴: 1.2 s / 20 MB 10⁵: 14.1 s / 196 MB |
| PSI · set intersection | linear, with a good constant | measured up to 10⁶–10⁷ |
| Small branching logic TFHE | unlimited depth, ~54 ms per gate | 1 comparison: 1.74 s |
| Confidential blockchain | tiny payload, high value per transaction | off-bench — mainnet since Dec 2025 |
Outside that shape, the budget does not change by a percentage: it changes by an order of magnitude.
Multiplicative depth beyond 8. Past the budget, you pay for bootstrapping: 1 min 18 s per operation at real 128-bit security, with 10.26 GB of evaluation keys. It works — but that is a "batch job", not an "API latency".
Mixing arithmetic and logic in one circuit. Scheme switching exists and we measured it: 13.9 s per slot. Worth it for very few decisions, and no more than that.
Point queries. A single encrypted value carries an expansion factor of 229,428×. FHE rewards batches and punishes queries — the inverse of the intuition you bring from databases, and the origin of most badly sized FHE architectures.
| Operation | Measured cost | The problem |
|---|---|---|
| Argmax over 1,000 under encryption | 130 h | at real 128-bit security. And precision collapsed to 3 bits in at least one slot of the batch: it is slow and wrong |
| Encrypted index over 10⁷ | 19 GB | if the server jumps to the right row, the access pattern leaks the index — the whole table must be touched |
| Comparing near-identical ciphertexts | < 2⁻³⁰ | blind spot: the operation has no defined result |
| Deep network end to end | — | ReLU costs a sign; that is why the network is retrained with x² |
The correct pattern for decisions is always the same: return the encrypted scores and decide in the clear on the client. On the side that already holds the key, the same decision costs microseconds — and it costs no privacy at all, because whoever decides is already whoever can decrypt.
One point vendor material tends to blur: the gap between the two main branches — CKKS/BGV for batch arithmetic, TFHE for logic — is 6×10⁶ in one direction and 170× in the other. That gap is structural, not a maturity issue. Hardware acceleration shifts both; it does not bring them together.
DARPA's DPRIVE program seeded a wave of dedicated ASICs. Niobium signed with Semifive to fabricate on Samsung 8 nm; Fabric Cryptography raised US$ 33 million; Optalysys about US$ 30 million for a photonic approach; Intel continues with Heracles. The money is real and the direction is right.
The 5,000× to 17,000× figures quoted for this generation are
simulation and projection, not shipped, measured silicon. When a vendor hands
you a benchmark, ask for the logN: on this bench, the difference
between logN=13 (toy parameters) and logN=16 (real 128-bit security)
is ~40× — and almost no published material says which one it is quoting.
For lookup workloads, the measured limit is not CPU — it is bandwidth. A universe of 10⁶ records cost 1.91 GB of traffic; 10⁷ projects to 19 GB. A crypto accelerator improves compute time and does not move a single byte less across the network.
Which means: for a meaningful share of use cases, the silicon under development is attacking the wrong half of the problem. The line attacking the right half is transciphering, and it is not mature yet.
Here is the new measurement, and it is the one that most changes architecture decisions. FHE gives confidentiality, not integrity. The same malleability that lets you compute over ciphertext prevents you from detecting a tampered result.
The attack needs nothing exotic. The application decrypts and validates ("the result has to be in this range"). If it is not, the application reacts — error on screen, retry, log line, HTTP status, different latency. That reaction is one bit, and the server observes it. By adding a public value to the ciphertext and reading the accept/reject, the server recovers the plaintext:
| Measurement | Value |
|---|---|
| Queries to recover a 16-bit value | 46.7 ± 1.3 |
| Success rate | 24/24 secrets |
| Total attack time, per value | 79 ms |
| Canary-slot detection — blind adversary | 100% |
| Canary-slot detection — adversary targeting 1 slot | 0.37% |
47 requests. No key is attacked; the server never decrypts anything. And the cheap defence solves the wrong adversary: canary slots cost 0.39% of the slots and catch 100% of blind tampering, but only 0.37% of an adversary who picks where to tamper — which is exactly c/n, as theory predicts. Canaries are hygiene, not integrity.
Real integrity requires proof (a ZKP over the homomorphic computation) or attested hardware. Published overhead ranges from ~2% to over 1000% depending on the primitive — three orders of magnitude. Until that closes, every project with a potentially malicious server carries a cost whose plausible size runs from negligible to prohibitive.
A security point that rarely shows up in commercial material: for approximate schemes such as CKKS, classical IND-CPA security is not enough if the decrypted result is shared with third parties.
It is a triage question in its own right: is the decrypted result shared with third parties? If it is, the parameters change — and the cost is small, provided the question is asked before the keys are generated.
The field has left the normative vacuum: ISO/IEC 28033 is under way, with Part 1 (general) and Part 3 (CKKS) at Draft International Standard, Part 2 (BGV/BFV) balloting until April 2026, and Parts 4 (lookup tables) and 5 (scheme switching) in progress. NIST follows through its privacy-enhancing cryptography project.
What is still missing is what would prevent the most dangerous failure mode we measured:
With a 4-level budget, BFV gets the 7th multiplication right and the 8th wrong — in
silence. No error, no exception: it returns 28323 where the answer is
282. It is the most dangerous combination that exists in production, and the reason
the circuit has to be known before the keys.
FHE closes when five conditions hold together: large batch · shallow circuit (≤ 8 multiplications) · decision on the client · small index universe · honest-but-curious server.
Drop one, and the cost changes by an order of magnitude. Drop the last one, and the cost is unknown.
That is why "is FHE ready?" is never a yes or a no. It is: which of the five don't you have? — and that is a one-hour conversation, with numbers, not a six-month proof of concept.