Parag Mali - tag: fully-homomorphic-encryption

How Fully Homomorphic Encryption Would Break: The Seams Above the Lattice

noreply@paragmali.com (Parag Mali) — Mon, 20 Jul 2026 00:00:00 GMT

Fully homomorphic encryption lets you compute on data you never decrypt, on a lattice foundation no known quantum attack can break [@regev-lwe]. Yet its likeliest failure is not that foundation. It is the *scheme layer* above it: a noise budget that must not overflow, a circular-security debt every bootstrap silently signs, and above all the **IND-CPA-D line**, where in 2021 Li and Micciancio showed that *releasing a correct decryption* from the approximate scheme CKKS hands an attacker the secret key -- a passive, polynomial-time, total break that never solves a lattice [@limicciancio-21]. The repair (worst-case noise flooding) broke in 2024 from a *single* released decryption [@guo-usenix-24], the *exact* schemes fell the same year through decryption failures [@checri-crypto-24], and the fixes are a live, unfinished discipline [@aahe-24]. This is a structural map of where FHE breaks first -- and why it is the seams, not the floor.

1. A Strongbox You Can Compute Inside

Fully homomorphic encryption is the closest thing cryptography has to magic: a strongbox you can reach inside and compute on -- add, multiply, run a whole statistical model -- without ever opening it, and without the machine doing the work ever seeing what it holds. Its foundation is a lattice problem that not even a quantum computer is known to break [@regev-lwe].

And yet the likeliest way this system fails has nothing to do with that foundation. In 2021, Baiyu Li and Daniele Micciancio showed that computing an average over encrypted data and publishing the correct, decrypted answer -- the entire point of the exercise -- may have just handed the attacker your secret key [@limicciancio-21].

That sentence should feel wrong. If the answer is correct, how can it also be a leak? The resolution is the whole story of this article, and it starts with a single idea: FHE's security is layered. At the bottom sits the lattice -- the Ring-LWE assumption most FHE schemes use, part of the same Module-LWE family that underpins the post-quantum standard ML-KEM [@lpr-rlwe].

That base is a catastrophic single point of failure in theory, but in fifteen years nothing has cracked it. Everything that has actually broken lives above it, in the machinery bolted on to turn a hard lattice problem into a usable computer.

Key idea: The floor holds; the seams leak. FHE's base lattice is a catastrophic-but-hypothetical single point of failure that has never fallen. Its likeliest real failures are all in the scheme layer above -- the noise budget, the circular-security debt, the IND-CPA-D line, and the drift between chosen parameters and community security levels.

Hold two images in mind, because the article turns on the difference between them. In the first, you keep multiplying ciphertexts until an internal error term grows past a threshold, and decryption returns not a wrong number but garbage -- noise where your answer should be. In the second, decryption works perfectly, returns exactly the average you asked for, and that correct value is the linear equation an attacker needed. The first image is a correctness failure. The second is a key leak. Almost everyone conflates them, and the conflation is the topic's central trap.

This piece walks four seams in order: the noise budget as a correctness cliff; the circular-security debt that bootstrapping signs to compute forever; the IND-CPA-D line where a released decryption returns the key; and the parameter drift between the numbers a deployment chose and the community's security tables. Each is a place FHE would break before the lattice does. The spoiler is already on the table: not one of these breaks touches the lattice.

Before we can rank where FHE breaks, we have to draw a clean line around what "break" even means here -- and deliberately put the one thing everyone fears, the lattice, inside a black box.

2. The Line We Draw, and the Black Box

"Break" is an ambiguous word, so let us fix it. This article is Track A: structural cryptanalysis. It asks where FHE would fail by mathematics and definition -- where the math runs out, where a proof rests on an assumption that might be false, where a security definition quietly models the wrong game. It does not ask where a specific library shipped a bug or where a power trace leaked a bit.

Note: This is a structural analysis. Timing and power side channels, fault-injection attacks, and buggy library implementations are real ways FHE deployments fail, but they are not structural -- they are the charter of the sibling real-life track. We name that boundary once, here, and then stay on the side of mathematics and definitions.

To see the scheme layer clearly, we put the lattice inside a black box and assume it is hard. That is not a dodge; it is the honest reflection of what fifteen years of cryptanalysis found. So the analysis needs only the shape of what is inside the box, not its internals.

Encryption that supports *both* addition and multiplication on ciphertext, without a bound on how many, so that any computation can run on encrypted data and only the holder of the secret key can read the result [@gentry-09]. The base assumption of lattice cryptography. A ciphertext is, in effect, a *noisy linear equation in the secret key*: recover the key and you have solved a lattice problem believed hard even for quantum computers. Ring-LWE is the efficient algebraic variant most FHE schemes actually use [@regev-lwe] [@lpr-rlwe].

The one mechanical fact we carry forward is that every ciphertext hides a small error term, the noise, and that noise is where both the correctness story and the security story begin.

The margin between a ciphertext's growing internal error and the decryption threshold -- a scheme-dependent fraction of the modulus $q$ (roughly $q/2$; precisely $q/4$ for a single-bit message and $q/(2t)$ in general). Every homomorphic operation spends some of it; cross that threshold and decryption no longer returns the right value [@gentry-09].

That noise budget plays two roles, and conflating them is the mistake this whole article is built to prevent. As a correctness budget, it bounds how much you can compute before the answer turns to garbage. As a security surface, the residual error left in a ciphertext is a function of the secret key -- so if you ever reveal that error, you have revealed a linear constraint on the key. The first role is famous. The second is where FHE actually breaks.

flowchart TD subgraph SEAMS["Scheme layer -- the seams that leak"] N["Noise budget: overflow corrupts the answer"] K["Circular-security / KDM debt of bootstrapping"] D["IND-CPA-D: a released decryption returns the key"] P["Parameter drift vs community security levels"] end subgraph FLOOR["Base lattice -- the floor that holds"] L["Ring-LWE and Module-LWE, assumed hard, post-quantum"] end N --> L K --> L D --> L P --> L How you *mechanically* compute on ciphertext -- the encoding, the packing, how bootstrapping is wired, why ciphertexts expand, why it is slow -- is the job of the constructive sibling, "Never Decrypted: FHE." This article recaps only what the failure analysis needs and hands the build-it story to that post.

The floor was assumed hard from the very first day FHE existed. So was the first seam. To see why, we go back to a thirty-year-old question -- and to the answer that arrived already in debt.

3. The Question, and the Noise That Came With the Answer

In 1978, one year after they co-invented RSA, Ron Rivest and Len Adleman, with Michael Dertouzos, asked a question that would stay open for three decades: could a "data bank" compute on ciphertext it can never read [@rad78]? They called the goal a privacy homomorphism. Time-shared computers were new, outsourcing was new, and the privacy problem was obvious -- you hand a machine your data and you have to trust it. RSA already hinted that the idea was not absurd.

RSA, introduced in 1977 (published in 1978), is multiplicatively homomorphic almost by accident: the product of two ciphertexts decrypts to the product of the two plaintexts. That single free operation is exactly why the 1978 privacy-homomorphism question was natural to pose [@rad78].

The trouble was that one free operation is not enough. RSA multiplies but cannot add; later schemes such as Paillier add but cannot multiply [@paillier-99]. Arbitrary computation needs both, unboundedly, and every attempt to get both ran into the same wall: each operation injected error into the ciphertext, and after a few multiplications the error drowned the signal. For thirty-one years, "somewhat" homomorphic was the best anyone could do. The community's own retrospective still opens on exactly this lineage, from the 1978 conception to the 2009 breakthrough [@security-guidelines-24].

Then, in 2009, Craig Gentry -- a Stanford PhD student advised by Dan Boneh -- broke the impasse with a move that sounds circular until you see why it works. If a noisy ciphertext could be refreshed to low noise without ever exposing the key in the clear, you could compute forever. His mechanism for that refresh is bootstrapping [@gentry-09].

Homomorphically evaluating the scheme's own decryption circuit on a noisy ciphertext, using a published encryption of the secret key, to produce a fresh ciphertext of the same plaintext with the noise reset low. Bootstrapping is the refresh that turns bounded, leveled homomorphic encryption into unbounded FHE [@gentry-09].

Read that definition again, because it plants both of the debts this article collects. To refresh, the scheme runs its own decryption homomorphically, which means it must publish an encryption of the secret key. And the noise it is fighting never goes away -- bootstrapping only pushes it back down, so the noise budget becomes the permanent weather of every FHE computation.

timeline title The base holds while the scheme layer keeps breaking 1978 : Rivest, Adleman and Dertouzos pose the privacy-homomorphism question 2005 : Regev introduces LWE, the base assumption 2009 : Gentry builds the first FHE with bootstrapping 2011 to 2017 : BGV, BFV, GSW, FHEW, TFHE and CKKS refine the scheme layer 2021 : Li and Micciancio break CKKS with the IND-CPA-D attack 2022 to 2025 : noise flooding, exact-scheme breaks, application-aware HE and HintLWE

Notice the shape of the timeline. The bottom track -- the base assumption, LWE in 2005 and Ring-LWE just after -- never breaks. The top track keeps breaking and getting re-patched. That asymmetry is not an accident of this diagram; it is the thesis, drawn as history. The base was always assumed hard, and the fragility was always in the machinery on top.

Gentry's breakthrough arrived owing two debts. The first is the one everyone has heard of -- the noise -- and the honest reading of it is not the one you have been told.

4. The First Seam: The Noise Budget as a Correctness Cliff

Every ciphertext is a noisy linear equation in the secret key. Addition of two ciphertexts adds their errors; multiplication roughly multiplies them, so noise compounds fastest under multiplication. Decryption works only while the noise stays below that threshold, a scheme-dependent fraction of $q$ on the order of $q/2$. Cross the line and the answer is not slightly wrong -- it is pseudorandom. This is the famous noise budget, and almost everyone reads its danger backwards.

Multiplicative depth is the real budget. Additions are cheap because errors merely add; multiplications are what compound the noise toward the ceiling, which is why "how many multiplications deep" is the number that matters, not "how many operations total" [@brakerski-si].

The last fifteen years of scheme design are, from one angle, a single long campaign to spend that budget more slowly. Gentry's 2009 scheme refreshed noise by bootstrapping, made feasible by squashing the decryption circuit down to low degree -- at the cost of an extra sparse-subset-sum assumption [@gentry-09]. In 2011, Brakerski and Vaikuntanathan rebuilt FHE on standard LWE with re-linearization and dimension-modulus reduction, explicitly abandoning squashing [@bv11].

BGV added modulus switching: after each multiplication, rescale the ciphertext to a smaller modulus so noise grows only additively across the levels, letting a bounded-depth circuit run with no bootstrapping at all [@bgv]. Brakerski's scale-invariant construction then made noise grow only linearly, $B \to B \cdot \mathrm{poly}(n)$, instead of quadratically, and Fan and Vercauteren ported it to Ring-LWE as BFV, the workhorse exact scheme with tight worst-case noise bounds [@brakerski-si] [@bfv].

A parallel line attacked the refresh cost instead of the growth rate. The Gentry-Sahai-Waters scheme recast homomorphic operations as matrix arithmetic with no evaluation key [@gsw]; FHEW turned that into a bootstrap in about half a second, against roughly six minutes per batch in the then-latest HElib [@fhew]; and TFHE, working over the torus, cut the bootstrap to under a tenth of a second and shrank the bootstrapping key from about a gigabyte to twenty-four megabytes [@tfhe]. The last rung of this ladder is the scheme that will matter most.

The scheme of Cheon, Kim, Kim and Song that treats the LWE noise as part of an *approximation error*, so decryption returns the plaintext *plus a small, key-dependent error*. That trade makes real-number and complex arithmetic efficient -- ideal for encrypted machine learning -- and it is the scheme at the center of the break [@ckks].

Here is the toy version of the correctness cliff. Watch the noise compound until it crosses $q/2$ and the decryption flips from a clean answer to garbage. This is a caricature -- real noise growth is gentler than squaring -- but the shape is exactly right.

{` // A ciphertext hides a message plus a small error term. // Each homomorphic multiply compounds that error. // Cross q/2 and decryption returns garbage -- a CORRECTNESS failure. const q = 1 << 20; // ciphertext modulus const half = q / 2; // decryption fails once noise passes this let noise = 4; // a fresh ciphertext starts with small noise const message = 7; // the value we are protecting

for (let mult = 1; mult <= 6; mult++) { noise = noise * noise; // multiplication compounds noise fastest const ok = noise < half; const out = ok ? message : Math.floor(Math.random() * q); console.log('after ' + mult + ' multiply(s): noise=' + noise + (ok ? ' decrypts to ' + out : ' OVERFLOW -> garbage ' + out)); if (!ok) break; } // The key was never exposed. You just lost the answer. `}

The point the demo makes is the one the field spent a decade internalizing and the public never did: crossing the noise ceiling costs you the answer, not the key. Nothing about an overflow reveals a secret. You recompute with bigger parameters and move on.

Note: Spending the noise budget past $q/2$ yields a wrong answer -- garbage -- and nothing more. It is a correctness failure. The security consequence of noise arrives two sections from now, and from the opposite direction: not from noise that overflowed, but from residual noise you deliberately revealed by publishing a decryption. Overflow loses the answer; a released decryption can lose the key. Do not conflate them.

That reframe is the article's first genuine shift. You arrived believing the noise budget is FHE's fragile part, and that a secure base plus no overflow equals a safe system. Both halves are the wrong worry. The scheme families below all manage noise well enough to be useful; every one of them still has a primary fracture line, and not one of those fractures is an overflow.

Scheme	Base assumption	Arithmetic	Noise control	Primary IND-CPA-D fracture
CKKS	Ring-LWE	approximate real/complex	rescaling; modulus linear in depth	released approximate error is linear in the key [@limicciancio-21]
BGV	Ring-LWE	exact integer/modular	modulus switching; modulus ladder	decryption failures under heuristic correctness [@checri-crypto-24]
BFV	Ring-LWE	exact integer	scale-invariant; linear noise growth	decryption failures under heuristic correctness [@cheon-ccs-24]
TFHE / CGGI	torus (TLWE/TGLWE)	exact Boolean / small LUT	fast programmable bootstrapping	decryption failures under loose correctness [@cheon-ccs-24]

Overflow only ruins an answer. The second debt is quieter and stranger: to compute forever, FHE must publish an encryption of its own secret key -- and simply hope that is safe.

5. The Debt Bootstrapping Silently Signs

Refreshing a ciphertext without exposing the key in the clear sounds impossible, and the way Gentry made it possible carries a hidden price. To run decryption homomorphically, the scheme needs the secret key inside the homomorphic computation. It cannot use the raw key -- that would defeat the purpose -- so it uses an encryption of the key, published as part of the evaluation material. Bootstrapping then evaluates "decrypt this ciphertext" under encryption, and out comes a fresh, low-noise ciphertext of the same value [@gentry-09].

Publishing an encryption of your own secret key is not something the base assumption ever promised was safe.

The assumption that a ciphertext encrypting the secret key itself stays secure -- that seeing an encryption of the key reveals nothing useful about the key. Bootstrapping requires it, and it does *not* follow from LWE or from plain IND-CPA security [@gentry-09].

Why does it not follow? Because ordinary security makes a promise only about messages an adversary chooses without knowing the key. The IND-CPA game, by construction, never lets the challenge plaintext depend on the secret. So it simply says nothing about what happens when you encrypt the key and hand it over. The gap is real, not pedantic.

In general, no. Chosen-plaintext security quantifies only over adversaries whose messages are independent of the key, so by definition it cannot constrain a ciphertext whose plaintext *is* the key. Cryptographers have exhibited schemes that are perfectly IND-CPA secure yet collapse the instant they encrypt their own secret key [@gkw-lwe-17]. That is why key-dependent-message security has to be assumed separately, or designed around -- it cannot be inherited for free from the base assumption.

So unbounded FHE runs on credit. Every bootstrap cashes a key-dependent-message assumption that no one has reduced to LWE, and Gentry flagged exactly this in 2009: whether FHE can be built from standard assumptions without circular security is an open problem, and it is still open [@gentry-09]. This is a place FHE could break with no attack on the lattice at all. If circular security turned out to be false for the deployed schemes, bootstrapping would leak -- and the floor would not have moved an inch.

There is one clean way out, and it is architectural rather than a fix.

Homomorphic encryption that evaluates circuits up to a pre-chosen depth $L$ *without* bootstrapping. Because it never publishes an encryption of the secret key, leveled FHE sidesteps the circular-security assumption entirely -- at the cost of giving up unbounded depth [@bgv].

BGV made this escape hatch practical: modulus switching controls noise well enough that a depth-$L$ circuit needs no refresh, so a large class of useful computations never signs the debt at all [@bgv]. The catch is in the definition -- once your circuit is deeper than the level budget you chose, you must bootstrap again, and the debt comes right back. Leveled FHE does not retire the assumption; it declines to take it on for bounded work.

flowchart TD A["Noisy ciphertext near the budget ceiling"] --> B["Bootstrap runs decryption homomorphically"] B --> C["Consumes the published encryption of the secret key"] C --> D["Fresh low-noise ciphertext, keep computing"] D --> A C --> E["Debt: safety of publishing an encryption of the key is a circular / KDM assumption, not implied by LWE"] A --> F["Leveled branch: cap depth at L, never bootstrap"] F --> G["No published key-encryption, so no KDM debt"]

Gentry's original scheme also leaned on an extra sparse-subset-sum assumption from squashing, which Brakerski and Vaikuntanathan removed in 2011 [@bv11]. The field sheds assumptions when it can. It has not shed this one.

The noise is a correctness debt; circular security is an assumption debt. Neither is an attack. The cryptanalyst's breakthrough was to find a real one -- and it was hiding in the answers themselves.

6. The Cryptanalyst's Breakthrough: The IND-CPA-D Line

The wound was the celebrated feature. CKKS decryption returns the plaintext plus a small, key-dependent error, and that is precisely the trade that made encrypted machine learning practical -- you accept a little imprecision and you get real-number arithmetic that fits in a reasonable modulus [@ckks]. In 2021, Baiyu Li and Daniele Micciancio looked at that returned error and saw an oracle [@limicciancio-21].

To understand why, recall the bar every FHE scheme was measured against.

Indistinguishability under chosen-plaintext attack: no efficient adversary, given an *encryption* oracle, can tell apart encryptions of two plaintexts it chose. The adversary can encrypt anything, but it never sees a decryption [@limicciancio-21].

Read the last sentence again. The IND-CPA game never lets the adversary see a decrypted output. But seeing decrypted outputs is the entire point of FHE -- you compute on encrypted data so that you can publish the result. The security definition modeled a world that FHE deployments do not live in.

IND-CPA extended so the adversary also sees decryptions of ciphertexts whose plaintexts it is supposed to already know. This is the correct security bar for any scheme that releases computed results, and it is the bar CKKS failed [@limicciancio-21].

Under the decryption oracle, CKKS falls to a startlingly simple attack. Each released decryption is the plaintext plus an error, and that error is, in essence, a linear function of the secret key. The plaintext is known -- it is the answer to a computation the adversary requested on inputs it chose -- so subtracting it isolates a linear equation in the key.

One equation is not enough to pin down a key with thousands of coefficients. But CKKS is used to compute many results, and each one yields another equation. Collect enough, stack them into a linear system, and solve it with ordinary linear algebra. The key falls out [@limicciancio-21].

Key idea: The correct answer is the attack. CKKS's own marketed output -- the decrypted mean, variance, or logistic fit -- is a linear function of the secret key. Nothing has to be "broken." The scheme hands you the equations, and you solve them.

The properties of this attack are what make it the article's cleanest evidence. It is passive: the adversary is honest-but-curious, requesting only the computations CKKS is normally used for and reading the outputs. It runs in expected polynomial time and recovers the complete secret key with high probability. And Li and Micciancio demonstrated it against four real libraries -- HEAAN, SEAL, HElib and PALISADE -- on exactly the workloads CKKS is sold for: means, variances, and Maclaurin-series approximations of logistic and exponential functions [@limicciancio-21].

sequenceDiagram participant A as Adversary participant O as CKKS evaluation and decryption oracle participant S as Linear solver A->>O: Request evaluations on known inputs O-->>A: Return plaintext plus key-dependent error A->>A: Treat each returned error as a linear equation in the key A->>S: Stack enough equations into a linear system S-->>A: Solve the system for the secret key Note over A,S: Passive, expected polynomial time, no lattice solved

Here is the attack in miniature. The "leak" function stands in for a released CKKS decryption; the recovery is a few lines of Gaussian elimination with no libraries at all.

CKKS hands back plaintext + a small error that is linear in the secret key. Known plaintexts let the attacker isolate that error and solve for the key.

secret = [3.0, -5.0, 2.0] # the hidden key (attacker does not know this)

def leak(a): # What a released CKKS decryption reveals: plaintext + dot(a, secret). plaintext = 10.0 err = sum(ai * si for ai, si in zip(a, secret)) return plaintext, plaintext + err

The attacker knows each plaintext and each public coefficient vector a.

rows = [[1.0, 0.0, 0.0], [1.0, 1.0, 0.0], [1.0, 1.0, 1.0]] b = [] for a in rows: p, dec = leak(a) b.append(dec - p) # isolate dot(a, secret)

Solve rows @ x = b by Gaussian elimination (no libraries needed).

M = [row[:] + [bi] for row, bi in zip(rows, b)] n = len(M) for i in range(n): piv = M[i][i] M[i] = [v / piv for v in M[i]] for j in range(n): if j != i: f = M[j][i] M[j] = [mj - f * mi for mj, mi in zip(M[j], M[i])]

recovered = [round(M[i][n], 6) for i in range(n)] print("recovered key:", recovered) # -> [3.0, -5.0, 2.0] `}

Standard IND-CPA security "does not adequately capture" the security of homomorphic encryption on approximate numbers: a passive adversary recovers the complete CKKS secret key in expected polynomial time [@limicciancio-21].

Note: A raw CKKS output is not an inert answer. It is the plaintext plus an error term that is a linear equation in your secret key. Publish enough of them and you have published the key. If you take one operational rule from this article, it is this one [@limicciancio-21].

Private inference, encrypted analytics, and outsourced statistics all exist *to publish a result* -- an aggregate, a prediction, a fitted model. Releasing decryptions is not an exotic attack setup; it is the product. That is what makes IND-CPA-D the realistic bar and IND-CPA the wrong one.

HEAAN, SEAL, HElib and PALISADE appear here as the places the attack landed, not as targets of a library audit. Which library did what belongs to the real-life sibling track; the point here is definitional [@limicciancio-21].

Name a disease and you invite a cure. The cure arrived -- and then it broke, and was re-patched, and broke again. That cycle is the state of the art.

7. Patch, Break, Re-Patch

The cure looks obvious. If a released decryption leaks the key-dependent error, drown that error in fresh noise before you publish. The story of why that obvious fix took four years, fell over in deployment, and is still being rewritten is the real state of the art.

Adding large fresh noise to a decryption before releasing it, so the key-dependent error is masked. The idea predates CKKS -- it comes from threshold FHE, where parties smudge their partial decryptions -- and it is provably safe only when the added noise is sized to the *worst case* [@ajw-11] [@lmss-22].

The first instinct was to size that noise cheaply -- to the average error a computation produces, or to a per-ciphertext estimate, or to sample it deterministically to save randomness. Every one of those shortcuts is provably insufficient. In 2022, Li, Micciancio, Schultz-Wu and Sorrell proved the surprising part: noise tuned even to a dynamic, key-dependent per-ciphertext estimate still leaks. The only thing that works is noise calibrated to the worst-case error growth of the computation, and they proved it with nearly matching upper and lower bounds -- you cannot do meaningfully better, and you cannot do meaningfully less [@lmss-22].

The same paper split bit-security into a computational parameter and a statistical one, which is what lets "how much noise is enough" be stated as a provable bound rather than a rule of thumb [@lmss-22].

That principled fix has a price. Worst-case noise costs real precision, and precision is the whole reason people reach for CKKS. So implementers did what the incentives pushed them toward: they reached for cheaper, average-case parameters. In 2024, Qian Guo, Denis Nabokov, Elias Suvanto and Thomas Johansson cashed that gap. Against non-worst-case flooding as configured in libraries, they achieved full key recovery from a single released decryption in OpenFHE, and they showed that generating the flooding noise deterministically is no defense at all [@guo-usenix-24].

"A single shared decryption can be enough for key recovery" against approximate FHE protected only by non-worst-case noise flooding, shown in practice on OpenFHE [@guo-usenix-24].

You can watch the gap with your own eyes. Flooding noise is zero-mean, so an attacker who collects enough decryptions can average it away -- unless the noise is large enough that a feasible number of queries cannot resolve the signal beneath it.

{` import random

secret_bias = 0.75 # a key-dependent quantity the attacker wants queries = 40000 # released decryptions the attacker averages over

def estimate(flood_bound): total = 0.0 for _ in range(queries): flood = random.uniform(-flood_bound, flood_bound) # zero-mean flooding released = secret_bias + flood # what the attacker sees total += released return total / queries # averaging cancels the flood

avg_case = estimate(2.0) # flooding sized to typical error: too small worst_case = estimate(20000.0) # flooding sized to worst-case sensitivity

print("average-case flooding -> attacker estimate:", round(avg_case, 3)) print("worst-case flooding -> attacker estimate:", round(worst_case, 1))

Average-case flooding collapses to ~0.75: the secret leaks. Worst-case flooding keeps the estimate too noisy to read -- and the bound must grow with the number of queries, which is why the provable fixes either size to the worst case or make the noise query-count independent.

The re-patch is where the field is now, and it is not a checkbox. Alexandru, Al Badawi, Micciancio and Polyakov argue the real gap is between the application-agnostic security definition and how libraries actually instantiate CKKS. Their application-aware homomorphic encryption supplies security definitions matched to a declared application, with a specification language, and a proof-of-concept in OpenFHE that counters the Guo attacks and also addresses the exact-scheme attacks of the same year [@aahe-24].

In 2025, Tabitha Ogilvie cut the cost of the provable fix. By treating CKKS rescaling noise as a linear "hint" on the secret and reducing to a HintLWE problem, she restores provable IND-CPA-D and key-recovery security with as little as about two bits of extra precision loss in rescale-dominated regimes, using a noise strategy independent of the number of oracle queries [@hintlwe-25].

flowchart LR A["2021: IND-CPA-D break on CKKS"] --> B["2021 to 2022: heuristic noise flooding"] B --> C["2022: LMSS worst-case DP flooding with matching bounds"] C --> D["2024: Guo breaks non-worst-case flooding from a single decryption"] D --> E["2024 to 2025: application-aware HE and HintLWE reduced noise"]

Attack	Target	Leak mechanism	Attack cost	Data needed	Where it landed
Li-Micciancio 2021	CKKS	released key-dependent error	expected polynomial time	enough result pairs	HEAAN, SEAL, HElib, PALISADE [@limicciancio-21]
Guo et al. 2024	CKKS, non-worst-case flooding	mis-sized flooding still leaks	practical	a single decryption	OpenFHE [@guo-usenix-24]
Checri / Cheon 2024	exact BFV/BGV/TFHE, threshold	decryption failures	under an hour on a laptop	a few thousand ciphertexts	BFV in OpenFHE, CGGI simulated [@checri-crypto-24] [@cheon-ccs-24]

Defense	Year	Guarantee	Noise cost	Status against attacks
Heuristic flooding	2021	none	low	broken: one decryption suffices [@guo-usenix-24]
Worst-case DP flooding	2022	provable IND-CPA-D	high, at the lower bound	secure only if sized worst-case [@lmss-22]
Application-aware HE	2024	provable per application	model-level	counters Guo and the exact attacks [@aahe-24]
HintLWE reduced noise	2025	provable IND-CPA-D / KR-D	about two bits	counters passive key recovery [@hintlwe-25]

Flooding fixes the approximate scheme. But in 2024 the ground moved under the schemes everyone thought were safe: the exact ones. They were supposed to be immune. They were not.

8. It Is Not Just Approximate: The Exact Schemes Fall Too

The comforting belief was that IND-CPA-D was CKKS's private problem. The exact schemes -- BGV, BFV, TFHE -- return the plaintext with no approximation error, so there is nothing key-dependent to leak. Li and Micciancio even proved that for exact schemes, ordinary IND-CPA security does imply IND-CPA-D security. The status quo looked safe on paper.

It looked safe because of a footnote. That equivalence holds only under negligible decryption failure -- the idealized assumption that an exact scheme essentially never returns a wrong value. Real implementations do not honor that assumption. They analyze correctness heuristically and tolerate noticeable decryption-failure probabilities, because tightening them costs performance. In 2024, two independent teams walked straight through that gap [@cheon-ccs-24] [@checri-crypto-24].

Cheon, Choe, Passelegue, Stehle and Suvanto exploited the imperfect correctness directly. Observing which ciphertexts decrypt incorrectly is itself information about the key, and they turned it into distinguishing and key-recovery attacks -- demonstrated on BFV in OpenFHE, simulated for CGGI in TFHE-rs, and extended to CKKS over discrete data and to threshold variants [@cheon-ccs-24].

Checri, Sirdey, Boudguiga and Bultel came at it from another direction: a CPA-D key-recovery attack on the linearly-homomorphic Regev cryptosystem that generalizes to BFV, BGV and TFHE, practical in under an hour on an average laptop, needing a few thousand ciphertexts and on the order of a million evaluations for full key recovery [@checri-crypto-24].

The two 2024 results share the decryption-oracle model with Li-Micciancio but leak through different physics, and holding that distinction is the whole point.

A single approximate-error repair -- flooding the released CKKS error -- cannot cover an exact-scheme leak that comes from decryption failures. Different cracks need different fixes, which is why "just flood everything" is not an answer here [@cheon-ccs-24].

flowchart TD O["Decryption oracle: adversary sees results it can predict"] --> P1["Approximate path: CKKS returns plaintext plus a key-dependent error"] O --> P2["Exact path: BGV, BFV and TFHE occasionally return a decryption failure"] P1 --> R["Full secret-key recovery, no lattice solved"] P2 --> R

Dimension	Approximate (CKKS)	Exact (BGV / BFV / TFHE)
Leak source	released approximate error	observed decryption failures
Trigger	any released decryption	heuristic correctness, noticeable failure rate
Where it landed	HEAAN, SEAL, HElib, PALISADE, OpenFHE [@limicciancio-21]	BFV in OpenFHE, CGGI in TFHE-rs simulated [@cheon-ccs-24]
Direct fix	worst-case noise flooding	tighten the failure probability; smudge threshold partials [@checri-crypto-24]
Same oracle model	yes	yes

Threshold FHE is the sharpest edge of this. When decryption is distributed across parties, each party publishes a partial decryption, and that partial share carries key-dependent information all on its own.

In threshold BFV, BGV and CKKS, the protocol combines partial decryptions from several parties. Checri and colleagues found these variants "especially exposed" unless each party adds fresh smudging noise *after* its partial decryption, masking its share before it is combined. The fix is the old threshold-FHE smudging idea, applied at exactly the step the CPA-D model exposes [@checri-crypto-24] [@ajw-11].

This is the second level of the article's deepest shift. It was tempting to file the CKKS break under "approximate schemes are quirky" and assume a return to solid ground was one scheme away. Instead, both branches of FHE -- approximate and exact -- leak under a decryption oracle, through unrelated mechanisms. The problem was never one scheme's bug. It is a property of releasing results from a noisy system.

And yet none of this touched the lattice. Which raises the last scheme-layer question: how do we even know the lattice is safe? The answer is not a proof. It is a measurement.

9. The Parameter Line: Chosen Numbers Versus the Community Levels

Ask "is this deployment 128-bit secure?" and you are not invoking a theorem. You are asking whether someone picked the right numbers from a community table, computed by a piece of software that is revised every year. Security at this seam is a measurement, and measurements move.

The ruler has three parts. The Homomorphic Encryption Standard v1.1 fixes recommended Ring-LWE parameter tables for 128-, 192-, and 256-bit security [@he-standard-v11]. The 2024 Security Guidelines update those parameter sets and survey how open-source libraries actually select them [@security-guidelines-24]. Both are computed with the lattice-estimator, which runs the best known classical and quantum lattice-reduction models against candidate dimension, modulus, and error triples to output a concrete bit-security number [@aps-estimator]. A deployment is only ever as safe as the parameters someone actually selected from that ruler.

That creates three structural failure modes, all distinct from a library bug. The first is estimator drift: today's "128-bit" is the output of today's best attacks, and it erodes as lattice reduction improves.

The lattice-estimator carries its own disclaimer that concrete hardness is a moving target. That is exactly why drift is a structural failure mode and not a coding mistake -- the number is designed to change [@aps-estimator].

The second is stale tables: parameter sets copied from an old paper or an old library default, never re-checked against the current estimator. The third is the simplest and the most dangerous: parameters chosen, whether by error or by optimism, that sit below the security level they are advertised to meet. None of these is exotic. All of them silently under-secure a system whose users believe a specific number.

There is a naming trap here that this article has to defuse, because getting it wrong would overstate FHE's assurance.

Note: The 128-, 192-, and 256-bit levels are a de facto community standard: the Homomorphic Encryption Standard and the 2024 Security Guidelines. There is no ISO/IEC- or NIST-blessed FHE security level. An ISO/IEC standardization effort is described only as upcoming and is unpublished, so no document number should be attached to it. Read "128-bit FHE" as "computed against the current community table," never as an ISO guarantee [@security-guidelines-24] [@he-standard-v11].

Element	What it is	Structural failure mode
Target levels	128/192/256-bit tables in the HE Standard v1.1	copied or outdated parameter sets [@he-standard-v11]
The estimator	lattice-estimator: concrete bit-security against lattice reduction	estimator drift as attacks improve [@aps-estimator]
The 2024 guidelines	updated parameter sets and a library-selection survey	parameters chosen below the advertised level [@security-guidelines-24]
Standardization status	community standard; ISO/IEC upcoming and unpublished	implying an ISO- or NIST-blessed level exists [@security-guidelines-24]

This seam fails gradually and quietly rather than catastrophically, but it is still a scheme-layer failure: it is about the numbers a deployment chose against a moving table, not about the lattice problem itself being weak. Every seam so far is a place FHE breaks first. There is exactly one break that would take everything at once -- and the most important thing about it is that it is not here yet.

10. The One Break That Would Take Everything

There is exactly one way FHE breaks all at once, and it is at the floor, not a seam: an efficient algorithm for Ring-LWE or Module-LWE. Such a solver would collapse every lattice-based FHE scheme at the foundation, and it would take ML-KEM down with it, because they rest on the same family of assumptions [@lpr-rlwe]. It is a genuinely structural single point of failure -- and it is also the one break for which there is no evidence at all.

Start with the fear most people carry: a quantum computer. It is misplaced here, and the reason is precise.

Note: Shor's algorithm breaks factoring and discrete logarithms because those are abelian hidden-subgroup problems with the exact structure Shor exploits. Lattice problems do not have that structure, so Shor does not apply to them. The other quantum tool, Grover's search, buys only a generic square-root speedup -- a discount already accounted for in the parameter tables. This is why "FHE is post-quantum" is a claim about the floor, not the seams [@regev-lwe] [@peikert-survey].

There is a beautiful twist buried in the foundations. Regev's original hardness argument for LWE is itself a quantum reduction: it shows that solving average-case LWE would let a quantum algorithm solve worst-case lattice problems [@regev-lwe]. The post-quantum confidence in FHE does not come from ignoring quantum computers; it comes from a hardness argument that already has one built in, surveyed and reinforced across a decade of lattice cryptography [@peikert-survey]. And after all of it, no efficient solver -- quantum or classical -- is known.

Now the deeper ceiling, the one that does not go away even if the lattice never falls: no FHE assumption is proven hard. This is not a gap waiting to be filled. The decision lattice problems underlying Ring-LWE, such as approximating the shortest vector within a $\sqrt{n}$ factor, sit in $\mathrm{NP} \cap \mathrm{coNP}$ [@aharonov-regev].

Membership in $\mathrm{NP} \cap \mathrm{coNP}$ buys a ceiling, not a floor. It tells you the problem is almost certainly not NP-complete, so hardness cannot be inherited from the hardest problems in NP. It does not tell you the problem is hard. Both facts point the same way: FHE security is an assumption, permanently [@aharonov-regev].

A problem in $\mathrm{NP} \cap \mathrm{coNP}$ cannot be NP-complete unless the polynomial hierarchy collapses, an outcome complexity theorists treat as effectively impossible. So the hardness that FHE rests on can never be a theorem derived from NP-completeness. It is necessarily an assumption. That is not a special weakness of FHE -- it is the same epistemic position every public-key cryptosystem occupies. FHE simply occupies it on a younger, less-tested foundation, and openly.

Two facts sit side by side without contradiction. FHE is post-quantum -- a statement about the floor. And FHE's scheme layer keeps cracking -- statements about the seams. They do not conflict because they describe different layers of the same system. For the lattice FHE shares with the post-quantum standard, see the sibling "Two Standards, One Lattice"; for why Shor cannot reach that lattice, see the Q-Day sibling.

It is worth noting that FHE does not have to be lattice-based in principle. An early scheme built FHE over the integers, reducing to an approximate-greatest-common-divisor assumption rather than lattices, which proved the concept was not tied to lattices -- but its impractical key sizes left it a curiosity, and no practical FHE lives outside the Ring-LWE, Module-LWE, and torus families today [@dghv-09]. The single point of failure is real precisely because the practical schemes all share it.

So the theoretical picture resolves into two very different kinds of risk. The base lattice is a catastrophic-but-hypothetical failure: if it fell, everything falls, but nothing suggests it will, and Shor cannot reach it. The scheme layer is a likely-and-practical failure: it has cracked repeatedly, along four separate seams, every crack demonstrated, none of them touching the floor. Weigh those against each other and the thesis stops being a claim and becomes an accounting.

Now the argument can be settled. Line up every fracture line, rank it by how it fails and how likely that is, and the pattern is unmistakable.

11. Where It Would Break First

The thesis has been earned section by section. Now it collapses into a single table you can read down one column to see the whole argument. Each row is a fracture line this article walked; the columns are how it fails, what kind of claim its failure is, how likely it is, and what it costs.

Fracture line	Mechanism	Epistemic class	Likelihood	Cost of failure
Noise / correctness overflow	error crosses $q/2$	engineering	common, but not a key leak	a wrong answer [@gentry-09]
Circular-security / KDM debt	bootstrapping publishes an encryption of the key	assumption	no known attack	catastrophic if the assumption is false [@gentry-09]
IND-CPA-D on approximate CKKS	released error is linear in the key	definition	demonstrated	full key recovery [@limicciancio-21]
IND-CPA-D on exact and threshold	decryption failures under loose correctness	definition / correctness	demonstrated in 2024	full key recovery [@checri-crypto-24]
Parameter versus level drift	estimator movement, stale tables	measurement	gradual	silent under-security [@security-guidelines-24]
Base-lattice solver	efficient quantum or classical Ring-LWE break	hypothetical	no known attack	everything [@regev-lwe]

Read down the epistemic class column and the shape of the argument appears. Five of the six rows are scheme-layer: an engineering limit, an unproven assumption, two definitional breaks, and a measurement that drifts. Four of those five are either demonstrated in practice or a live assumption every bootstrap depends on. Only the last row, the lattice, is purely hypothetical -- and it is the only row whose cost is the entire word "everything."

Key idea: The likeliest failures are all in the scheme layer -- noise, the KDM assumption, the two IND-CPA-D breaks, and parameter drift. The base lattice is the lone catastrophic-but-hypothetical outlier: the highest cost, the lowest evidence it will ever be paid.

That distribution is not a coincidence to be explained away; it is the argument. If FHE's real risk lived in the lattice, the table would be top-heavy with hypothetical rows and the demonstrated attacks would be lattice reductions. Instead the demonstrated attacks are a linear solve on a released error, a mis-sized noise mask, and a heuristic decryption-failure rate. Every one of them lives above the floor.

Not one of these breaks solved a lattice. Every one of them lived in the machinery above it.

There is one honest caveat that keeps "likeliest" a probabilistic claim rather than an absolute one. The base-lattice row has the lowest probability and the highest cost, so it is never something to ignore -- a low-probability, total-loss event still deserves conservative margins. The thesis is not that the lattice is safe forever. It is that, on every piece of evidence available today, FHE would break in the scheme layer first, and by a wide margin.

A verdict is only useful if it tells you what to do. This one does -- item by item.

12. How Not to Be the Break

Every fracture line in this article is also an instruction. Here is the checklist a team shipping FHE in 2026 can act on, each item pointing back to the section that earned it.

Start with the single rule that prevents the centerpiece attack.

Note: A released decryption is an oracle. Flood it to the worst case, or do not release it. Everything else on this list is a refinement of that sentence [@limicciancio-21] [@lmss-22].

If you use CKKS for analytics or machine learning and you will release results, never publish a raw decryption; add noise flooding sized to the worst-case error growth, or use an application-aware configuration, and prefer HintLWE-grade noise where your library supports it [@lmss-22] [@aahe-24] [@hintlwe-25]. Treat every value you release as a partial oracle on the key, not as an inert answer. Average-case flooding is not a lighter version of the fix; it is the thing Guo and colleagues broke from a single decryption [@guo-usenix-24].

If you use an exact scheme -- BGV, BFV, or TFHE -- do not rely on the folklore that exact means immune. Enforce a negligible decryption-failure probability rather than a heuristic average, and if outputs are released under an oracle, treat the scheme as CPA-D-exposed and smudge accordingly [@cheon-ccs-24]. In any threshold or multi-party protocol, add smudging noise after each partial decryption, before shares are combined [@checri-crypto-24].

Where your computation has bounded depth, choose leveled parameters and skip bootstrapping entirely -- that dodges the circular-security assumption at no extra cost [@bgv]. Select lattice parameters from the current estimator and re-check them against the 2024 Security Guidelines rather than copying a table from an old paper [@aps-estimator] [@security-guidelines-24].

Crypto-agility means being able to swap parameters or schemes without re-architecting, so a future estimator revision -- or, in the worst case, a lattice advance -- is a configuration change, not a rebuild.

And for the floor itself, hold conservative margins and keep the deployment crypto-agile. The base-lattice break is unlikely, but its cost is total, and margins plus agility are how you price a low-probability, total-loss risk.

Fracture line	What to do	Where it was earned
CKKS output leak	never release raw decryptions; flood to worst-case	Sections 6 and 7 [@limicciancio-21] [@lmss-22]
Non-worst-case flooding	size flooding to worst-case, or use an application-aware config	Section 7 [@guo-usenix-24] [@aahe-24]
Exact-scheme failures	enforce negligible decryption-failure probability	Section 8 [@cheon-ccs-24]
Threshold partial decryption	smudge after each partial decryption	Section 8 [@checri-crypto-24]
Circular-security debt	prefer leveled parameters when depth allows	Section 5 [@bgv]
Parameter drift	select from the current estimator; re-check the guidelines	Section 9 [@aps-estimator] [@security-guidelines-24]
Base lattice	conservative margins and crypto-agility	Section 10 [@regev-lwe]

The misconceptions this topic breeds deserve a direct answer -- so we end by naming them.

13. The Misconceptions This Topic Breeds

This topic breeds a predictable set of misreadings, and each one, answered honestly, restates the thesis from a different angle.

No. The breaks in this article are *definitional* and *parameter* breaks, and each has a repair -- worst-case flooding, application-aware configurations, tightened correctness [@limicciancio-21] [@aahe-24]. No strong, correctly parameterized, correctly used FHE deployment has fallen. The right reading is not "FHE is broken" but "FHE breaks in specific, understood, fixable places -- all above the lattice." Not by any known attack. Shor's algorithm does not apply to lattice problems, and Grover offers only a square-root speedup already priced into the parameters [@regev-lwe] [@peikert-survey]. If a quantum solver for Ring-LWE ever appeared, it would break the *lattice* -- the floor shared with ML-KEM -- not the scheme layer this article is about. No. CKKS remains the practical choice for encrypted real-number analytics, but you must never publish a raw decryption and must flood released results to the worst case [@limicciancio-21] [@lmss-22]. The lesson is operational, not a retirement notice: released decryptions are oracles, so treat them like oracles. No, not since 2024. Exact and threshold schemes leak through *decryption failures* under the heuristic correctness that deployments tolerate for speed -- a different mechanism from CKKS, but the same decryption-oracle model [@cheon-ccs-24] [@checri-crypto-24]. Immunity was a footnote assumption that real implementations quietly violate. Not yet. The 128-, 192-, and 256-bit levels come from a *de facto community* standard -- the Homomorphic Encryption Standard and the 2024 Security Guidelines -- computed by the lattice-estimator [@he-standard-v11] [@security-guidelines-24]. An ISO/IEC effort is described only as upcoming and is unpublished, so "128-bit FHE" is a measurement against a community table, not an ISO or NIST guarantee. Only if the circular-security assumption is false. Bootstrapping publishes an encryption of the secret key, which requires key-dependent-message security that LWE does not imply -- but no known attack exploits it, and *leveled* FHE avoids the assumption entirely by capping depth [@gentry-09] [@bgv]. It is a live assumption, not a demonstrated break. No. Overflow is a *correctness* failure: you get a garbage answer, and the key is never exposed [@gentry-09]. Do not conflate it with the IND-CPA-D key leak, which comes from *revealing* a decryption, not from noise crossing the ceiling. They are different fracture lines with different fixes.

The floor holds; the seams leak. Fifteen years of FHE show a base lattice that has never fallen and a scheme layer that has cracked along four seams -- the noise budget, the circular-security debt, the IND-CPA-D line, and parameter drift -- every crack demonstrated or assumed, none of them touching the floor. The purest of them is the one that still feels impossible: the correct answer you are allowed to publish is the equation that gives back the key.

Two siblings finish the picture. "Never Decrypted: FHE" is the constructive story -- how you actually compute on ciphertext, and what it costs. "Two Standards, One Lattice" is the floor itself -- the assumption FHE shares with the post-quantum standard ML-KEM.

The repair arc that runs through this article is not a closed chapter; it is a discipline still being written, one attack and one re-patch at a time. The most useful thing you can carry out of it is a habit: when an FHE system hands you an answer, ask not whether the lattice is safe, but what you just revealed by reading it.

Never Decrypted: How Fully Homomorphic Encryption Computes on Ciphertext It Cannot Read

noreply@paragmali.com (Parag Mali) — Mon, 20 Jul 2026 00:00:00 GMT

Fully homomorphic encryption (FHE) lets a server compute any function on encrypted data and return an encrypted result without ever holding the key or seeing a plaintext, so `Dec(Eval(f, Enc(m))) = f(m)`. The whole mechanism turns on one quantity: the **noise budget** every lattice ciphertext carries for security and spends as it computes. Gentry's 2009 **bootstrapping** -- running the scheme's own decryption homomorphically to refresh that noise -- turned *bounded* computation *unbounded*, and fifteen years of engineering cut the overhead from a billion-to-a-trillion times slower to ten-thousand-to-a-million. It ships today in narrow, high-value features (Apple's Live Caller ID, Zama's contracts, AWS's encrypted inference), but guards you against an honest-but-curious server, **not** a malicious one.

1. Send your data to a cloud that never sees it

When your iPhone meets an unknown caller, it can ask a server for a name and receive one while the server never learns the number it just answered. It does not glance at your query and promise to forget it. It computes the answer while your data stays sealed inside ciphertext it is mathematically unable to read. Apple ships exactly this in Live Caller ID Lookup on iOS 18, where "the server itself never decrypts the original data or even has access to the decryption key" [@apple-swift-he-2024].

"The server itself never decrypts the original data or even has access to the decryption key." -- Apple, on Live Caller ID Lookup

That sentence should stop you. Every encryption scheme you already trust protects data in two states: at rest on a disk, and in motion across a network under TLS. Both assume the data gets decrypted before anyone computes on it. Fully homomorphic encryption discards that assumption. It computes on the data while it is still encrypted, and returns a result that only the key holder can open.

An encryption scheme that lets anyone evaluate an arbitrary function on ciphertexts, producing a ciphertext of the result, with no access to the secret key. It satisfies the correctness identity $\mathrm{Dec}_{sk}(\mathrm{Eval}_{pk}(f, \mathrm{Enc}_{pk}(m))) = f(m)$: decrypting the evaluated ciphertext yields exactly $f(m)$, the function applied to the original plaintext [@apple-swift-he-2024].

Read the identity slowly, because one thing is missing from it. The evaluation step uses the public key, not the secret key. The server that runs your computation holds no secret and sees no plaintext. Decryption happens later, on the client, with a key that never left it. That absence is the whole magic and the whole difficulty: if the server never holds the key, what stops the arithmetic from turning into nonsense on the way back?

The answer, and the argument of this article, is a single quantity.

Key idea: The whole game is the noise budget. An FHE ciphertext hides your data inside deliberate mathematical noise. Every homomorphic operation grows that noise, and decryption returns the right answer only while the noise stays under a threshold. So "computing on ciphertext it cannot read" is really the discipline of spending a noise budget -- and one move, bootstrapping, is the only way to refill it. Read the whole field this way and every scheme family, every cost, and every shipping product becomes a different answer to one question: how much useful computation can you buy per unit of noise?

This is the first post in a series called Never Decrypted: five studies of privacy-preserving computation, where data is used, queried, transmitted, and proven about, yet never decrypted. FHE is the purest case, the one where the data is computed on directly. We will earn that lens section by section and pay the honest bill, because FHE is both remarkable and expensive, and the two facts are inseparable.

Two promises frame the rest. First, the mechanism is real and elegant: for thirty-one years the best cryptographers alive were unsure it could exist, and the person who settled it did so with a move that borders on self-reference. Second, the guarantee is precise and bounded: plain FHE protects you against an honest-but-curious server that follows the protocol but would love to peek, not against a malicious one that lies about the answer. That distinction, easy to blur in a product pitch, is where the series turns.

There is also a bonus the mechanism buys for free. Because FHE rests on the ring learning-with-errors problem, "which is quantum resistant" [@apple-swift-he-2024], the same math that hides your caller lookup would survive a quantum computer -- the shared reason the post-quantum standards ML-KEM and ML-DSA lean on the same lattice family.

To see why any of this is hard, and why it took thirty-one years, start where the dream started.

2. A thirty-one-year open problem

In 1978, within a year of publishing RSA, Ronald Rivest, Leonard Adleman, and Michael Dertouzos asked the obvious next question. If a hospital or a bank encrypts its records before handing them to a shared data bank, could that data bank still compute on them, tally them, search them, answer questions about them, without ever decrypting? They coined a name for an encryption scheme that would permit this, a privacy homomorphism, and sketched why it would matter [@rad-1978].Rivest, Adleman, and Dertouzos, "On Data Banks and Privacy Homomorphisms," appeared in an offline 1978 Academic Press volume with no free canonical URL. Secondary sources dispute the exact page range (169-180 versus 169-179), though the authors, title, volume, and 1978 date are firm [@rad-1978]. Then they could not build one. The problem sat open for a generation [@evervault-rad].

The term Rivest, Adleman, and Dertouzos introduced in 1978 for an encryption scheme whose algebraic structure lets a party compute on ciphertexts in a way that mirrors computation on the underlying plaintexts, without holding the decryption key [@rad-1978]. gantt title The siege from RAD 1978 to shipping FHE in 2026 dateFormat YYYY axisFormat %Y section Open problem RAD pose privacy homomorphisms :milestone, 1978, 0d Partial HE building blocks :1978, 1999 section Foundations BGN degree two and Regev LWE :2005, 2006 Gentry bootstrapping first FHE :milestone, 2009, 0d section Modern families Leveled BGV and BFV :2011, 2013 TFHE and CKKS branches :2016, 2018 section Deployment Vendors ship real pipelines :2024, 2026

It was not that nothing worked. Half the problem fell quickly, from both sides. RSA is multiplicatively homomorphic: multiply two ciphertexts and you obtain an encryption of the product of the plaintexts [@rsa-1978]. ElGamal, seven years later, supplies a second multiplicative scheme from the discrete-logarithm world [@elgamal-1985]. From the other side, the 1982 Goldwasser-Micali scheme, the one that founded semantic security, is additive over single bits (homomorphic for XOR) [@gm-1982], and Paillier's 1999 scheme is cleanly additive over integers: multiply two ciphertexts and you obtain an encryption of the sum [@paillier-1999, @wikipedia-paillier].

An encryption scheme homomorphic for exactly one operation, either addition or multiplication of the underlying plaintexts, but not both. RSA and ElGamal are multiplicative; Goldwasser-Micali and Paillier are additive [@wikipedia-he].

Each scheme below gives you one operation, an unlimited number of times.

Scheme	Year	Operation	Hardness assumption	Homomorphic identity
RSA, textbook [@rsa-1978]	1978	Multiplicative	Integer factoring	`E(m1)E(m2) = E(m1m2)`
ElGamal [@elgamal-1985]	1985	Multiplicative	Discrete log (DDH)	`E(m1)E(m2) = E(m1m2)`
Goldwasser-Micali [@gm-1982]	1982	Additive (XOR)	Quadratic residuosity	`E(b1)*E(b2) = E(b1 XOR b2)`
Paillier [@paillier-1999, @wikipedia-paillier]	1999	Additive	Composite residuosity	`E(m1)*E(m2) = E(m1+m2)`

Now the wall. One operation, unlimited times, is still not enough, and the reason is structural. Any function a computer can evaluate can be written as a circuit of AND, OR, and NOT gates, and over the two-element field GF(2) those gates collapse to just two arithmetic operations: multiplication for AND and addition for XOR. A scheme that can only add builds only linear functions; a scheme that can only multiply builds only monomials. Neither can express a general circuit, because a general circuit interleaves both operations on the same wires [@wikipedia-he].

Make it concrete. Suppose you want the server to answer one yes-or-no question: does encrypted record x equal my secret value y? Equality testing subtracts and then checks the result against zero, and any real comparison of bits mixes additions with multiplications. Paillier can form the sum but never the product; RSA can form the product but never the sum. Hand the data bank either scheme and it stalls at the first operation of the other kind [@wikipedia-he].

This is the first half of the article's first genuine shift in understanding. The barrier is not a missing optimization. It is that no single-operation scheme can be coaxed into generality, because generality is the ability to interleave the two operations it lacks.

So one operation cannot get you there. But the framing hands you the next move for free. What if a single scheme could do both, even just a little?

3. Somewhat homomorphic, and the noise appears

Two results in 2005 reset the board. The first showed that a little of both was possible. Dan Boneh, Eu-Jin Goh, and Kobbi Nissim built a scheme allowing an unlimited number of additions and then exactly one multiplication, enough to evaluate any formula of total degree two, using bilinear pairings on elliptic curves [@bgn-2005]. For the first time, a single scheme could add and multiply the same ciphertexts.

An encryption scheme that supports both addition and multiplication on ciphertexts, but only up to a bounded depth or degree. Boneh-Goh-Nissim (2005) is the classic waypoint: unlimited additions and a single multiplication [@bgn-2005].

BGN stops hard at degree two, and the reason is algebraic, not a matter of effort. A bilinear pairing maps two points from a group $G$ into a target group $G_T$, and that single pairing is the one multiplication. There is no further pairing out of $G_T$, no map that multiplies two elements of $G_T$ together, so once you have multiplied once you are stranded. Depth two and beyond are unreachable in the structure itself [@stanford-dfreeman-bgn-notes, @bgn-2005]. BGN proved a little of both was possible while making painfully clear that a fixed algebraic ceiling was not the road to "arbitrary."

The second 2005 result was the road. Oded Regev introduced Learning With Errors, and it reframed what a ciphertext even is [@regev-2005].

A conjectured-hard problem underlying modern lattice cryptography: given many noisy linear equations in a secret vector, recover the secret. The noise is exactly what makes it hard. Strip the error out and ordinary linear algebra solves the system instantly [@regev-2005].

Picture a ciphertext, in the ring variant, as a pair of ring elements $(a, b)$ with $b = a \cdot s + \Delta \cdot m + e$, where $s$ is the secret key, $m$ is your message, $\Delta$ is a fixed scaling factor, and $e$ is a small random error. To decrypt, the key holder computes $b - a\cdot s = \Delta\cdot m + e$ and rounds away the small $e$ to recover $m$. To anyone without $s$, the pair looks uniformly random, because the error smears out every linear relationship that would otherwise leak the secret.FHE schemes rest on Ring-LWE; the NIST post-quantum standards ML-KEM and ML-DSA rest on the closely related module-lattice problems (Module-LWE, and for ML-DSA also Module-SIS). It is the same lattice family, which is why both are believed quantum-resistant, and why a collapse of lattice hardness would touch both at once [@regev-2005].

Now hold both facts about $e$ at once: their collision is the center of the whole subject.

Note: The error $e$ is what makes the ciphertext secure: remove it and the scheme falls to linear algebra. But the error is also what limits computation. Add two ciphertexts and their errors add; multiply two ciphertexts and their errors multiply and swell. Compute long enough and the error grows until it overruns the scaling gap $\Delta$, at which point rounding lands on the wrong value and decryption returns nonsense. The thing that protects the data is the thing that runs out.

That collision is the second half of the article's first shift in understanding, and it deserves a name.

The margin between a ciphertext's current error and the threshold at which decryption fails. A fresh ciphertext has full budget; every homomorphic operation spends some, additions a little and multiplications a lot; when the budget hits zero the plaintext is gone. Managing this budget is the central engineering reality of FHE [@sok-ai-2504-11604]. "The noise prevents cryptanalysis but must remain below a threshold to ensure successful decryption." [@sok-ai-2504-11604]

A somewhat-homomorphic scheme, then, is one with a fixed noise budget and no way to refill it. It can compute until the budget runs out, and not one operation more [@sok-ai-2504-11604]. BGN's ceiling was algebraic; the LWE ceiling is a budget, and a budget, unlike an algebraic dead end, is the kind of limit you might be able to reset.

flowchart LR A["Fresh ciphertext with full noise budget"] --> B["Add ciphertexts, spends almost nothing"] B --> C["Multiply ciphertexts, spends a large chunk"] C --> D{"Is noise still below the threshold?"} D -->|Yes| E["Decryption recovers the exact result"] D -->|No| F["Decryption returns meaningless garbage"]

To feel the mechanism rather than just read about it, here is a deliberately tiny, insecure toy of LWE-style homomorphism. The server holds only pairs of numbers; it adds them without ever seeing a plaintext; and the decrypted result is the correct sum, carrying a small noise term.

{` // A deliberately tiny, INSECURE toy of LWE-style additive homomorphism. // Real schemes use long vectors modulo a large q; here each ciphertext // is a single pair (a, b). The secret key s never leaves the client. const q = 4096; // ciphertext modulus const t = 16; // plaintext space, values 0..15 const D = q / t; // scaling gap Delta; noise must stay below D/2 = 128 const s = 91; // secret key

const rnd = (n) => Math.floor(Math.random() * n); const err = () => rnd(7) - 3; // small error in [-3, 3]

function enc(m) { const a = rnd(q); const b = ((a * s + D * m + err()) % q + q) % q; return { a, b }; }

function add(c1, c2) { // homomorphic add: no secret key used return { a: (c1.a + c2.a) % q, b: (c1.b + c2.b) % q }; }

function dec(c) { const raw = (((c.b - c.a * s) % q) + q) % q; return Math.round(raw / D) % t; // round the small noise away }

const c1 = enc(3), c2 = enc(4); console.log("server stores only pairs, e.g. c1 =", c1); console.log("dec(c1 + c2) =", dec(add(c1, c2)), " // 3 + 4 = 7, on ciphertext"); `}

If the only thing stopping you is accumulated noise, and not algebra, then perhaps you do not need to avoid the noise at all. Perhaps you can reset it. That idea sat unclaimed for four years.

4. Gentry 2009: a scheme that decrypts itself

Here is the puzzle in its cruelest form. Noise is the enemy; it accumulates until it destroys the plaintext. Exactly one operation removes noise from a ciphertext, and it is decryption: run it and out comes a clean plaintext with the noise gone. But decryption needs the secret key, and the whole point is that the server does not have the secret key. You are trapped between the one operation that would save you and the one thing you are forbidden to use.

In 2009, a Stanford PhD student named Craig Gentry, advised by Dan Boneh and working in part at IBM, walked straight through the trap [@gentry-thesis-2009]. His solution took two moves.

The first move was a somewhat-homomorphic scheme built on ideal lattices, engineered so its error grows slowly enough to evaluate reasonably deep circuits before the budget is spent [@gentry-thesis-2009, @gentry-stoc-2009]. On its own that is merely a better SHE scheme, still bounded. The second move closed the thirty-one-year problem.

The operation that refreshes a noisy ciphertext by evaluating the scheme's own decryption circuit homomorphically. The server is handed an encrypted copy of the secret key and runs decryption on the noisy ciphertext under encryption. The result is a new ciphertext of the same plaintext whose noise has been reset to a low level. No plaintext is ever exposed, and the real secret key is never used in the clear [@gentry-thesis-2009].

Key idea: Bootstrapping is the scheme evaluating its own decryption homomorphically to refill the noise budget. Because decryption is the only operation that removes noise, performing it under encryption -- on an encrypted key the server can compute with but never read -- is the one move that resets the budget without exposing anything. Bounded computation becomes unbounded.

Read that twice, because the move is almost a sleight of hand. Decryption removes noise. You cannot run it on the server, because it needs the key. So you run it homomorphically, as a computation on ciphertexts, feeding the decryption circuit an encrypted copy of the secret key. Homomorphic evaluation of decryption yields an encryption of whatever decryption would have produced: a clean encryption of the original message. The noise on that output is not the old, nearly-overflowing noise; it is the fresh, small noise of this one homomorphic evaluation. You have removed noise without ever holding the key.

Note: A somewhat-homomorphic scheme that can evaluate its own decryption circuit, with a little budget left over, can refresh any ciphertext and then keep computing. Refresh, compute, refresh, compute. A scheme that can decrypt itself homomorphically lives forever. That one recursive idea converts bounded computation into unbounded, and turns "somewhat homomorphic" into "fully homomorphic."

The technical condition is exact: a scheme is bootstrappable if it can homomorphically evaluate its own decryption function plus at least one extra gate. Clear that bar and you can bootstrap indefinitely, which makes the scheme fully homomorphic by recursion [@gentry-thesis-2009]. The obstacle in 2009 was that Gentry's decryption circuit was too deep for his own scheme to evaluate within budget. His fix, called squashing, rewrites decryption into a shallower circuit the scheme can afford, at a price.Squashing shrinks the decryption circuit's depth by publishing a hint about the secret key, but it does so by importing an extra hardness assumption, the sparse-subset-sum assumption, on top of the underlying lattice assumption [@wikipedia-he].

A second honest asterisk: to bootstrap without limit, the server needs that encrypted copy of the secret key, an encryption of the key under its own public key, sitting in the public evaluation material.Publishing an encryption of the secret key under its own public key requires an extra assumption called circular, or key-dependent-message (KDM), security. Later leveled schemes avoid it entirely by capping how deep they will ever compute, so they never need to bootstrap [@gentry-thesis-2009].

flowchart TD A["Noisy ciphertext, budget nearly spent"] --> C["Evaluate the decryption circuit homomorphically"] B["Encrypted copy of the secret key"] --> C C --> D["Fresh ciphertext of the same plaintext"] D --> E["Noise reset low, budget refilled"] E -->|"Compute more, then bootstrap again"| A

A year later Gentry restated the result for a general audience, framing FHE as the ability to compute arbitrary functions of encrypted data [@gentry-cacm-2010].

Decryption is the one operation that removes noise. Bootstrapping performs it without the key, by performing it under encryption.

But proving the impossible possible is not the same as making it practical, and Gentry was the first to say so. The initial implementation, by Gentry and Shai Halevi, reported roughly thirty minutes to bootstrap a single basic bit operation [@wikipedia-he]. In his own decade-later retrospective, Gentry characterized first-generation FHE as something on the order of a billion times slower than computing in the clear [@gentry-eurocrypt2021-retro]. The dream now had a working existence proof and an unusable price tag.

Bootstrapping had made computation unbounded and, at first, unbearably slow. Everything that follows, four scheme families and a decade of engineering and three shipping products, is a sequence of answers to one question: how do you spend the noise budget without paying a billion-fold?

5. Four generations, each a smarter way to spend noise

One trick made computation unbounded. A decade of engineering made it survivable. Every family that followed answers the same question, how much computation can you buy per unit of noise, and every one was born from the specific limitation of the one before. The chain starts as a line and ends as a fan.

The first generation was Gentry's own. Ideal-lattice SHE plus bootstrapping worked, but a single bootstrap ran minutes to hours and the overhead sat around $10^9$ to $10^{12}$ times slower than plaintext [@gentry-eurocrypt2021-retro, @wikipedia-he]. In parallel, van Dijk, Gentry, Halevi, and Vaikuntanathan rebuilt the same idea over the integers, using only elementary modular arithmetic and an approximate-greatest-common-divisor assumption [@dghv-2009-616]. It is conceptually lovely and was never practical. The lesson of the first generation was blunt: the architecture was sound and the price was impossible.

The second generation moved onto Learning With Errors and learned to manage noise directly. Zvika Brakerski and Vinod Vaikuntanathan rebuilt FHE on standard LWE, replacing squashing with a dimension-modulus reduction technique and removing the extra assumption Gentry had needed [@bv-2011-344]. Then came the two schemes that still ship today.

A noise-management move that rescales a ciphertext to a smaller modulus, shrinking the accumulated error along with it. Applied as a ladder between multiplications, it keeps the noise budget from overflowing without any bootstrapping [@bgv-2011-277].

Brakerski, Gentry, and Vaikuntanathan introduced BGV, which uses modulus switching to evaluate an arithmetic circuit of known, fixed depth with no bootstrapping at all [@bgv-2011-277].BGV was published at ITCS 2012, not CRYPTO 2011, a frequent miscitation worth getting right [@bgv-2011-277].

A scheme that can evaluate any circuit up to a fixed multiplicative depth chosen in advance, with no bootstrapping. You pay for the depth you plan to use and never invoke the circular-security assumption, because you never encrypt the key under itself [@bgv-2011-277].

The companion scheme is BFV.The "B" in BFV is Brakerski's scale-invariant scheme (ePrint 2012/078, CRYPTO 2012), whose noise grows only linearly per multiplication; Fan and Vercauteren ported it to the Ring-LWE setting (ePrint 2012/144). Apple cites both ePrints [@brakerski-2012-078, @bfv-2012-144]. The critical precision to carry forward: BGV and BFV are both exact-integer schemes. They differ in where the plaintext modulus lives and how scaling is handled, not in exact-versus-approximate arithmetic [@bfv-2012-144]. Alongside them, Smart and Vercauteren showed how to pack many independent values into the slots of one ciphertext.

A packing technique that uses the Chinese Remainder Theorem to place thousands of independent plaintext values into separate "slots" of a single ciphertext, so one homomorphic operation acts on all of them at once. It is the amortization that makes leveled FHE affordable in practice [@smart-vercauteren-2011-133].

The second generation was fast enough to be interesting and left exactly two things wanting: it was still exact-integers-only, and bootstrapping, when genuinely needed, still took minutes. Those two residual limits are what fork the field.

The exact-integers limit led to CKKS (2017). Cheon, Kim, Kim, and Song asked a heretical question for real-number workloads like machine learning: why fight the leftover noise at all? Let it be the rounding error of approximate arithmetic. CKKS makes approximation a design feature, with a native rescaling operation that controls magnitude and noise together, and its precision loss over encrypted computation exceeds unencrypted floating point by at most about one bit [@ckks-2016-421]. CKKS is approximate by design; that is its purpose, not a defect.

The slow-bootstrapping limit led to the fast-bootstrapping branch. Gentry, Sahai, and Waters built GSW, whose ciphertexts are matrices and whose homomorphic addition and multiplication are just matrix addition and multiplication, with no evaluation key at all [@gsw-2013-340].GSW's approximate-eigenvector method needs no separate evaluation key, which is why it became the foundation of the fast per-gate bootstrapping branch [@gsw-2013-340]. Ducas and Micciancio's FHEW then cut a single-gate bootstrap from the roughly six minutes a batch took in HElib down to about half a second [@fhew-2014-816].

TFHE pushed it further, dropping bootstrapping from 690 milliseconds to 13 milliseconds on a single core while shrinking the bootstrapping key from 1 GB to 16 MB. Its bootstrapping is also programmable: it can fold a lookup table into the refresh, so the one operation that resets the budget also computes a function, which is what lets TFHE handle arbitrary Boolean logic and comparisons cheaply [@tfhe-2018-421].

The operation the second generation fled, bootstrapping, because it was too slow, became this branch's hot path once it cost milliseconds. Note the precision, though: BGV, BFV, and CKKS can all bootstrap too. Cheap, programmable, per-gate bootstrapping is TFHE's relative edge, not a capability the others lack [@tfhe-2018-421].

The FHE literature usually numbers generations one through four in a fixed order: first Gentry's ideal-lattice scheme, second BGV and BFV, third the GSW-FHEW-TFHE line, and fourth CKKS [@nist-stppa6-rohloff]. This article instead orders the story by the problem each family solved, which places CKKS before TFHE. Both are valid; they are just different axes. The honest picture is that TFHE and CKKS are best read as parallel branches from 2016 and 2017, not a strict succession, each answering a different leftover limitation of the leveled schemes. flowchart TD G0["Partially homomorphic, add OR multiply"] --> G1["Gentry 2009, ideal-lattice SHE plus bootstrapping"] G1 --> G2["Leveled RLWE, BGV and BFV, exact integers"] G2 --> C["CKKS 2017, approximate real arithmetic"] G2 --> T["GSW to FHEW to TFHE, fast programmable bootstrapping"] G1 -.-> D["DGHV, the same idea over the integers"]

Family	Year	Key idea	Speed then	Weakness it left	Status
Gentry ideal-lattice [@gentry-thesis-2009]	2009	Bootstrapping refills the budget	~30 min per bit op [@wikipedia-he]	Astronomically slow, extra assumption	Foundational, not deployed
DGHV over integers [@dghv-2009-616]	2010	Same idea via approximate-GCD	Impractical	Never fast	Pedagogical
BGV and BFV leveled RLWE [@bgv-2011-277, @bfv-2012-144]	2011-2012	Modulus switching, leveled, SIMD	Bootstrap still minutes	Exact integers only	Deployed, Apple ships BFV
CKKS [@ckks-2016-421]	2017	Approximation as a feature, rescaling	Fast for reals	Approximate by design	Deployed for ML
TFHE [@tfhe-2018-421]	2016-2020	Cheap programmable per-gate bootstrap	~13 ms per gate	Slow on large linear algebra	Deployed, Zama ships it

Each generation's residual limitation names the next generation's core idea, and by 2020 the four families are set. None of them wins outright. When there is no single best answer, the real question becomes how you choose.

6. The four-family decision matrix

The state of the art is not a leaderboard. It is a decision fan, and you enter it with two questions: what is your data, and what shape is your circuit?

Before the families diverge, fix what they share. Every deployed scheme rests on LWE or its ring variant, and every one spends and refills the same noise budget with the same small set of primitives: addition is cheap; multiplication is expensive and is followed by a maintenance step called relinearization, a form of key switching that rewrites the enlarged product ciphertext back under the normal key so multiplications can chain; modulus switching or rescaling shrinks accumulated noise; and bootstrapping resets it [@sok-ai-2504-11604, @openfhe-2022-915].

The families separate along two independent axes. The first is exact versus approximate: BGV and BFV compute exact modular integers, while CKKS computes approximate real and complex numbers by design. The second is word-wise versus bit-wise: BGV, BFV, and CKKS pack thousands of values into SIMD slots and excel at linear algebra, while TFHE bootstraps every gate and excels at Boolean logic and comparisons.Word-wise means computing on whole packed integers or reals at once; bit-wise means computing on individual encrypted bits, one gate at a time. Word-wise schemes run 100 to 1000 times faster than TFHE on linear algebra; TFHE wins on non-linear operations like sorting and comparison [@sok-ai-2504-11604].

Four short dossiers follow from those axes.

BGV is the exact-integer workhorse for deep leveled arithmetic. Its modulus-switching ladder lets you plan a fixed multiplicative depth and evaluate it without bootstrapping, which suits circuits whose depth you know in advance [@bgv-2011-277].

BFV is the other exact-integer scheme, scale-invariant in its noise handling, and it is the one Apple ships. Live Caller ID Lookup uses BFV for keyword private information retrieval, so the server matches an encrypted query against its database without learning the query [@bfv-2012-144, @apple-swift-he-2024].

CKKS is the approximate-arithmetic scheme for real numbers, which makes it the default for encrypted machine learning and analytics. Its rescaling operation ties magnitude and noise together, and its approximation is the point, not a flaw [@ckks-2016-421].

TFHE is the bit-wise scheme with cheap, programmable per-gate bootstrapping, which makes it the choice for arbitrary logic, comparisons, and the lowest single-operation latency [@tfhe-2018-421, @zama-protocol].

Note: Read the matrix by two separate axes. Exact versus approximate distinguishes BGV and BFV (both exact) from CKKS (approximate). Word-wise versus bit-wise distinguishes the three batched schemes from TFHE. Do not collapse these into one exact-versus-approximate ranking. BGV and BFV are equally exact, and TFHE is exact too, just computed one gate at a time.

flowchart TD A["What are you computing on?"] --> B{"Exact integers or real numbers?"} B -->|"Real numbers, approximation ok"| CKKS["CKKS"] B -->|"Exact integers"| C{"What shape is the circuit?"} C -->|"Deep word-wise arithmetic"| BGVBFV["BGV or BFV"] C -->|"Boolean logic and comparisons"| TFHE["TFHE"]

Scheme	Plaintext type	Granularity	Noise control	Best suited for	Ships in
BGV [@bgv-2011-277]	Exact integers	Word-wise (SIMD)	Modulus-switching ladder	Deep leveled integer arithmetic	OpenFHE and research stacks
BFV [@bfv-2012-144]	Exact integers	Word-wise (SIMD)	Scale-invariant	Keyword lookup and PIR	Apple Live Caller ID [@apple-swift-he-2024]
CKKS [@ckks-2016-421]	Approximate reals	Word-wise (SIMD)	Rescaling	ML and analytics on real data	OpenFHE and HElib CKKS [@openfhe-2022-915, @helib-repo]
TFHE [@tfhe-2018-421]	Bits and Boolean	Bit-wise (gate)	Bootstrap every gate	Arbitrary logic and comparisons	Zama fhEVM and Concrete-ML on AWS SageMaker [@zama-protocol, @aws-sagemaker-fhe-2026]

The tooling has caught up to the theory. A community standard fixes secure parameter sets for BGV, BFV, and CKKS [@hes-standard-2018], updated guidance now spans those schemes plus the TFHE family with an ISO/IEC standardization effort underway [@secguidelines-2024-463], and OpenFHE provides one reference implementation supporting all of them [@openfhe-2022-915].

Four families, four sweet spots, all real. But every one of them charges in the same currency, time and size. So what is the bill, actually?

7. The honest cost: two axes, kept apart

You may have heard that FHE is "about 1000 times too slow." That figure is wrong, and the way it is wrong is the most useful thing you can learn about FHE's cost. The number blends two different quantities that must be kept apart: how much slower the computation runs, and how much larger the ciphertext gets. They are separate axes, and a scheme can win one while losing the other.

Note: The popular claim that FHE is "about 1000 times too slow" merges two different costs into one wrong number. Time overhead and ciphertext expansion are separate axes. Modern general-purpose time overhead runs about $10^4$ to $10^6$ times, not $10^3$; the $10^3$ figure is closer to the best-case, hardware-accelerated speed regime than to the typical one. Ciphertext expansion, a size cost, runs about $10^3$ to $10^4$ times. Never quote a single blended multiplier [@accel-survey-2303-10877, @kbit-expansion-2019-521].

Take speed first, and treat it as a band, never a point, because it depends heavily on the workload and the hardware. Historical first-generation FHE ran roughly $10^9$ to $10^{12}$ times slower than plaintext, with bootstraps measured in minutes to hours [@gentry-eurocrypt2021-retro, @wikipedia-he].The historical anchor for these numbers is the first implementation: Gentry and Halevi's scheme took roughly thirty minutes per basic bit operation [@wikipedia-he]. Modern general-purpose FHE runs about $10^4$ to $10^6$ times slower, which DARPA states in plain terms.

"A computation that would take a millisecond ... would take weeks to compute on a conventional server running FHE today ... we currently estimate we are about a million times slower to compute in the FHE world." -- DARPA, DPRIVE program [@darpa-dprive-2021]

Only the best cases, SIMD-amortized or hardware-accelerated, approach $10^2$ to $10^3$ times [@accel-survey-2303-10877]. The concrete texture matters. TFHE bootstraps a gate in about 13 milliseconds [@tfhe-2018-421], yet multiplying two encrypted 16-bit integers with it takes on the order of 30 seconds, because that multiply is thousands of gates; meanwhile the word-wise schemes run 100 to 1000 times faster than TFHE on linear algebra [@sok-ai-2504-11604]. There is no single "FHE speed." There is a workload and a scheme and a machine.

The second axis is size, and it is genuinely separate.

The ratio between the size in bytes of an encrypted value and the size of the plaintext it hides. It is a storage-and-bandwidth cost, distinct from the time overhead of computing. A single encrypted value can balloon by roughly three to four orders of magnitude, and TFHE-class expansion has been measured as high as about 8000 times [@kbit-expansion-2019-521].

Bit-wise expansion runs orders of magnitude larger than word-wise, which is the same trade the speed axis shows in reverse: TFHE's cheap per-gate flexibility costs size, while the batched schemes amortize both [@sok-ai-2504-11604]. The folk "1000x" is plausibly a memory of the size axis pasted onto the speed axis. Keep them apart.

Regime	Time overhead (speed)	Bootstrap latency	Ciphertext expansion (size)
Historical first generation	~$10^9$ to $10^{12}\times$ [@gentry-eurocrypt2021-retro]	Minutes to hours [@wikipedia-he]	Very large
Modern general-purpose	~$10^4$ to $10^6\times$ [@darpa-dprive-2021]	Milliseconds to seconds [@tfhe-2018-421]	~$10^3$ to $10^4\times$ [@kbit-expansion-2019-521]
Best SIMD or hardware-accelerated	~$10^2$ to $10^3\times$ [@accel-survey-2303-10877]	Sub-second [@tfhe-2018-421]	Word-wise is far smaller [@sok-ai-2504-11604]

How did the historical billion-fold collapse to the modern band? Five engineering moves did most of the work. Leveled evaluation removed bootstrapping from fixed-depth circuits entirely [@bgv-2011-277]. Residue-number-system arithmetic combined with SIMD and CRT packing amortized each operation across thousands of slots [@smart-vercauteren-2011-133]. Fast programmable bootstrapping made the once-ruinous refresh cheap [@fhew-2014-816, @tfhe-2018-421]. Better standardized parameters and algorithms tightened the constants [@secguidelines-2024-463]. And GPU, FPGA, and ASIC acceleration, the target of DARPA's DPRIVE program, is attacking what remains in silicon [@darpa-dprive-2021].

FHE is not the only way to compute on data you would rather not expose. Secure multi-party computation and [secret sharing](/blog/nobody-broke-shamir-a-field-guide-to-secret-sharing-and-thre/) split a computation across parties so none sees the whole input. Garbled circuits let two parties jointly evaluate a function. [Trusted execution environments](/blog/inside-azure-confidential-vms-sev-snp-intel-tdx-and-the-para/) and enclaves protect data inside hardware while it is processed. [Zero-knowledge proofs](/blog/the-discrete-log-held-the-proofs-leaked-a-field-guide-to-com/) establish a statement without revealing the witness behind it. Each solves an adjacent problem under a different trust model. FHE's distinguishing trait is that it "relies on mathematics rather than hardware," which is also why it complements, rather than replaces, hardware enclaves [@aws-sagemaker-fhe-2026].

So the bill is real, nameable, and shrinking. But some costs are not engineering problems waiting on a faster chip. Some are theorems. What can FHE never promise?

8. What FHE can and cannot promise

FHE exists; Gentry proved the impossible was possible. But "possible" is not "free," and "private" is not "trustworthy." Here is the fine print, and some of it is permanent.

Start with the cost that can never reach zero. Hiding a message inside LWE noise means the ciphertext must be larger than the plaintext and must carry error. A literally free FHE, with size rate exactly one and time overhead exactly one, is not on offer, because the noise that provides security is not optional. The reassuring flip side is that breaking that confidentiality is at least as hard as solving worst-case lattice problems, the same foundation the post-quantum standards rest on [@regev-2005].

Now the limit that matters most in practice, and the one most often blurred.

Key idea: FHE gives you confidentiality, not integrity. It stops a curious server from reading your data. It does not stop a lying server from returning the wrong encrypted answer, because a homomorphic ciphertext carries no proof that the promised computation is the one that ran. Detecting a cheating server needs extra machinery, verifiable or maliciously-secure FHE, which is a different guarantee entirely.

IND-CPA (indistinguishability under chosen-plaintext attack) is the standard confidentiality guarantee: a ciphertext leaks nothing about its plaintext to an eavesdropper. Plain FHE meets it against an honest-but-curious server, one that runs the agreed computation faithfully but would read your data if it could. It says nothing about a server that deviates from the protocol [@vfhe-2024-032].

Note: Plain FHE assumes an honest-but-curious adversary. A malicious server can return a well-formed ciphertext that decrypts to a wrong result, and nothing in the scheme reveals the substitution. As the verifiable-FHE literature puts it, "these schemes make an honest-but-curious assumption about the adversary" [@vfhe-2024-032]. If you need to trust the answer, and not merely hide the input, you need verifiable FHE layered on top.

The tension is structural, not incidental. Because homomorphic evaluation must transform ciphertexts, the scheme is inherently malleable, which is the opposite of what the strongest confidentiality notions demand.Malleability means FHE cannot achieve IND-CCA2 security. The strongest notion an FHE scheme can reach is vCCA, which has been proven strictly stronger than CCA1 [@vcca-2024-202]. And the unbounded case carries one last assumption.Unbounded bootstrapping from plain LWE needs the circular, or key-dependent-message, assumption. Leveled schemes avoid it only by capping their multiplicative depth, so they never encrypt the key under itself [@bgv-2011-277].

There is a subtle piece of good news buried in the theory. Asymptotically, the upper and lower bounds nearly meet: time overhead can be made polylogarithmic for wide enough circuits [@ghs-2011-566], and ciphertext expansion can be pushed to rate one, where the encrypted value is barely larger than the plaintext [@rate1-2019-720]. So the ideal is not forbidden.

The catch is that those constructions carry enormous constant factors and are not the fast batched schemes anyone runs, so deployed systems still pay the modern bands: $10^4$ to $10^6$ times in time and $10^3$ to $10^4$ times in size. The remaining gap is between asymptotics and deployment, which makes closing it a matter of engineering, not a missing theorem [@darpa-dprive-2021].

One further limit belongs to the companion article rather than this one. CKKS's approximate decryption opens a security subtlety, the IND-CPA-D gap, in which handing back decrypted approximate results can leak information about the secret key. It is a genuinely open and active issue, and the sibling post on how FHE would break takes it apart in detail. Here it is named at the boundary and left there.

The limits are real, and several are permanent. But every one of them is also somebody's active research program. Where is that frontier actually live right now?

9. Where the research is live

Every limit in the last section is somebody's active program. Here are six, each at its true temperature.

Cheaper, ideally instant, bootstrapping. Word-wise bootstraps still run seconds to hours when they are needed, and TFHE's 13 milliseconds is per gate, which adds up fast on a wide computation. No lower bound says milliseconds-per-gate is the floor, so the races here are incremental and hot rather than blocked on a theorem [@tfhe-2018-421, @sok-ai-2504-11604].

Transciphering, to shrink the wire. This one attacks the size axis directly. The client sends data under a compact symmetric cipher, and the server homomorphically evaluates that cipher's decryption to convert the payload into an FHE ciphertext on its own side, so the data crossing the network stays close to plaintext size [@transciphering-sok-2025-669]. A 2025 systematization surveys more than twenty FHE-friendly symmetric ciphers built for exactly this purpose. It is active engineering with a maturing body of cryptanalysis, which is the healthy sign that the idea is being stress-tested rather than merely proposed [@transciphering-sok-2025-669].

FHE plus integrity. This is the precise gap between an honest-but-curious server and an untrusted one. Recent lattice-based SNARK constructions can verify a small encrypted neural network, including the maintenance operations like modulus and key switching, in under a second [@vfhe-2024-032]. The field is young theory with early implementations that do not yet scale, but it is moving [@vfhe-survey-2301-07041].

Standardized threshold and multi-key FHE. The principle is that no single party should hold the key: split the secret key across several parties so that decryption requires a threshold of them to cooperate, removing the single point of trust that one key holder represents [@threshold-2025-699]. NIST has placed FHE explicitly in scope of its multi-party threshold call, as part of Class S [@nist-8214c], and a 2025 specification gives fault-tolerant threshold key generation and decryption for BGV, BFV, and TFHE using noise flooding and secret sharing over Galois rings, tolerating a malicious minority of participants [@threshold-2025-699]. This corner is active standardization.

Hardware acceleration to real time. Can silicon collapse the $10^4$ to $10^6$ overhead toward roughly ten times? DARPA's DPRIVE program funds custom accelerators aimed at the computational speeds seen in plaintext [@darpa-dprive-2021], and OpenFHE exposes hooks for such accelerators [@openfhe-2022-915].DPRIVE performers include Duality, Galois, SRI, and Intel Federal. Trade-press claims of specific chip speedups circulate widely but are not independently verifiable, so they are omitted here [@darpa-dprive-2021]. The work is hot, capital-intensive, and only partially proven.

CKKS precision versus security. The IND-CPA-D gap and its repairs are genuinely open, but they are the companion break post's territory. Named here, analyzed there.

Note: This is the exact seam the Never Decrypted series is built around. FHE delivers confidentiality: the server computes without seeing. The next installment, on zkVMs and zkML, delivers integrity: a prover convinces you a computation ran correctly without redoing it and without seeing the private inputs. Confidentiality here, integrity there, and the two composed are what a genuinely untrusted cloud requires.

Research aside, a practitioner has to ship today. What can you actually build, and how do you choose?

10. How a practitioner uses FHE today

You do not choose FHE the way you choose a hash function. You choose it the way you choose a material, by matching the workload to what the scheme is for.

Note: Exact integers: BGV or BFV. Keyword lookup, private set membership, or PIR: BFV, the scheme Apple ships. Real numbers, machine learning, or analytics where approximation is fine: CKKS. Arbitrary logic, comparisons, or the lowest single-operation latency: TFHE [@sok-ai-2504-11604, @apple-swift-he-2024].

The tools are mature enough to pick off a shelf. OpenFHE covers the broadest set of schemes [@openfhe-2022-915]; Microsoft SEAL implements BFV and CKKS and powers Edge's Password Monitor [@ms-password-monitor]; HElib implements BGV and CKKS [@helib-repo]; Lattigo brings lattice schemes to Go [@lattigo-repo]; Zama's TFHE-rs, Concrete, and Concrete-ML cover the TFHE family and encrypted ML [@concrete-ml]; and Apple's swift-homomorphic-encryption implements BFV [@apple-swift-he-2024]. Do not hand-roll parameters; use the standardized secure sets instead [@secguidelines-2024-463].

The design rules fall straight out of the noise-budget lens. Keep multiplicative depth shallow, because multiplications, not additions, spend the budget. Batch with SIMD, because failing to batch throws away three to four orders of magnitude of amortization [@sok-ai-2504-11604]. Budget the noise before you write code, not after. Keep the secret key on the client, where it never touches the server [@apple-swift-he-2024]. Consider hybrid designs that do the plaintext-safe parts in the clear.

The honest expectation: FHE wins on bounded, high-value, latency-tolerant privacy features -- a narrow function over a large private input, run leveled and amortized with SIMD -- not as a drop-in for general cloud compute [@sok-ai-2504-11604].

The canonical shape is Apple's: a client encrypts a query, the server evaluates a private lookup on the ciphertext, and only the client can open the answer.

flowchart LR A["Client encrypts the phone-number query"] --> B["Server evaluates keyword PIR on the ciphertext"] B --> C["Server returns an encrypted answer"] C --> D["Client decrypts with the key that never left it"] B -.-> E["Server never sees the number or the key"]

To make the central discipline runnable, here is a noise-budget simulator. Multiplications spend hard, additions barely register, and a bootstrap refills the budget before the next operation would push decryption into garbage.

{` // Illustrative, not a real scheme. Budget starts full; mul() spends hard, // add() barely spends, bootstrap() refills. Watch where the refill rescues // the computation from decrypting to garbage. const FULL = 100; let budget = FULL; const out = [];

function step(name, cost) { budget -= cost; out.push(name + " -> budget " + Math.max(budget, 0) + (budget <= 0 ? " (decryption would fail)" : "")); } const add = () => step("add ", 2); const mul = () => step("mul ", 20); function bootstrap() { budget = FULL; out.push("bootstrap-> budget " + budget + " (refilled)"); }

mul(); mul(); mul(); mul(); // four multiplications drain the budget: 100 -> 20 add(); add(); // additions barely cost anything: 20 -> 16 bootstrap(); // refill before the next multiply would fail mul(); mul(); add(); // keep computing on a fresh budget

console.log(out.join("\n")); console.log(budget > 0 ? "final: decryption OK" : "final: would decrypt to garbage"); `}

Remove the `bootstrap()` line and run it again. The two multiplications that follow now push the budget from 16 straight past zero, and the simulator prints "decryption would fail." That is the entire reason the refresh exists: without it, a deep-enough circuit always exhausts its budget and decrypts to garbage. Bootstrapping is what buys the next stretch of computation.

The 2026 deployments sit at three different maturities, and it is worth naming them precisely.Labeled PSI, the protocol behind Microsoft Edge's Password Monitor, is due to Hao Chen, Zhicong Huang, Kim Laine, and Peter Rindal; an oblivious pseudo-random function hides the query while FHE over Microsoft SEAL performs the set matching [@labeledpsi-2018-787].

"Shipping" hides three very different maturities. Apple's Live Caller ID Lookup is a shipped consumer feature running BFV keyword-PIR in iOS 18 [@apple-swift-he-2024]. Zama's fhEVM is production-scale but domain-specific, a confidentiality protocol for smart contracts that reached Ethereum mainnet in December 2025 [@zama-protocol]. The AWS SageMaker encrypted-inference post is a reproducible how-to on Concrete-ML, not a shipped product [@aws-sagemaker-fhe-2026]. Do not flatten these into "FHE is everywhere."

That is the map. The last stop clears the misconceptions that send people down the wrong path.

11. Frequently asked questions

No. Homomorphic evaluation uses only the public key and public evaluation material. The secret key never leaves the client, so the server computes on your data without ever being able to read it [@apple-swift-he-2024]. No. End-to-end encryption protects data in transit and at rest, but the data must be decrypted before anyone computes on it. FHE computes on the data while it stays encrypted, which is a different and strictly harder capability [@gentry-cacm-2010]. Yes. Deployed FHE rests on Ring-LWE, a lattice problem believed hard even for quantum computers, and Apple notes its scheme is based on the ring learning-with-errors problem, "which is quantum resistant" [@apple-swift-he-2024]. It is the same lattice family as the post-quantum standards ML-KEM and ML-DSA. No, and the round number hides the real story. Time and size are separate axes: modern general-purpose time overhead is about $10^4$ to $10^6$ times [@darpa-dprive-2021], while ciphertext expansion is about $10^3$ to $10^4$ times [@kbit-expansion-2019-521]. The folk "1000x" conflates the two. No. Plain FHE gives confidentiality against an honest-but-curious server, not integrity. A malicious server can return a well-formed ciphertext that decrypts to the wrong answer; catching that requires verifiable or maliciously-secure FHE [@vfhe-2024-032]. No. Every standardized and deployed scheme is noise-based, on LWE or Ring-LWE, and the community security standard fixes parameters for exactly those schemes [@hes-standard-2018]. Unvetted "noiseless FHE" proposals are neither standardized nor vetted and should not be treated as viable. For bounded, high-value features, yes. Apple ships a consumer feature, Zama runs a production protocol, and AWS documents a reproducible pipeline, all in the 2024 to 2026 window [@apple-swift-he-2024, @zama-protocol, @aws-sagemaker-fhe-2026]. It is not yet a drop-in for general cloud compute.

Never decrypted

Return to the iPhone from the opening. A server answered a question about a number it never learned, and the sentence is no longer magic but mechanism. The query lived inside a noise budget the server could spend but, with bootstrapping in reserve, never had to fully deplete; the answer came back sealed in a ciphertext only the client could open; and the whole exchange rested on lattice noise that doubles as quantum-resistant security [@apple-swift-he-2024].

Read back through the argument with the evidence now in hand. FHE is real: Craig Gentry closed a thirty-one-year open problem in 2009 [@gentry-thesis-2009]. It is remarkable: bounded computation became unbounded through a scheme that decrypts itself. It now ships, in bounded and high-value features, from Apple's caller lookup to Zama's confidential contracts [@apple-swift-he-2024, @zama-protocol]. And its costs are precisely nameable, two axes and never one: time overhead around $10^4$ to $10^6$ times [@darpa-dprive-2021] and ciphertext expansion around $10^3$ to $10^4$ times [@kbit-expansion-2019-521].

One honest sentence remains, and it is the seam the rest of this series follows. FHE buys confidentiality against an honest-but-curious server, not integrity against a malicious one [@vfhe-2024-032]. The companion post on how FHE would break presses on the noise budget as an attack surface; the next Never Decrypted installment, on zkVMs and zkML, supplies the integrity that FHE omits.

Privacy-preserving computation means data that is used, queried, transmitted, and proven about, yet never decrypted. Fully homomorphic encryption is the first and purest case: the data is computed on directly, and it is never read.