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.

Parag Mali - tag: privacy-preserving-computation