Parag Mali - tag: privacy-preserving-computation

Never Decrypted: Reading the Row Without Revealing Which Row

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

Private information retrieval (PIR) lets you fetch record *i* from a server's database while the server provably never learns *i* -- the query itself stays sealed. The bar to beat is the absurd baseline of downloading the whole database ($n$ bits of communication *and* $n$ bits of server work). The thirty-year story is pushing both axes below $n$: two non-colluding servers and an XOR (1995), a single server plus homomorphic encryption (1997), and -- after a decade when PIR looked solved on paper but lost the wall-clock race -- a modern generation fast enough to ship.

By 2024 Apple runs homomorphic-encryption-based keyword PIR at consumer scale, so the answer is finally "yes, at a cost you can name in dollars and gigabytes, but never zero." One honest catch survives to the next post: PIR buys privacy, not correctness.

1. The library that watches what you read

You look up a drug interaction, a phone number that just called you, a landmark in a photo. Transport encryption hides that lookup from everyone on the wire -- your ISP, the coffee-shop Wi-Fi, a national firewall -- but not from the party that matters: the server decrypts your query and sees exactly which row you asked for. In 2007 a peer-reviewed paper concluded that fixing this was hopeless on real hardware [@sion-carbunar-2007]; by 2024 the same idea ran silently on the phone in your pocket [@apple-ml-he-research]. The gap between those poles is this article.

The problem sounds simple until you try to state it precisely: can you read one row of a database without the owner learning which row? Every tool you already trust misses the target. TLS encrypts the channel, so the eavesdropper sees ciphertext -- but the server terminates that channel, decrypts your request, and reads the index in the clear. The threat model has quietly inverted. The adversary is not on the network. The adversary is the party holding the data.

flowchart LR C["Client: read row i"] -->|"query under TLS"| N["Network path"] N -->|"ciphertext only"| S["Server holds all n rows"] S -->|"TLS terminates here"| D["Server decrypts the query"] D --> K["Server now knows i"] E["Eavesdropper, ISP, Wi-Fi"] -.->|"sees nothing useful"| N A protocol that lets a client retrieve the $i$-th record from a server-held database while the server provably learns nothing about $i$ -- not the index, not even a useful probability distribution over indices, nothing beyond the fact that *some* record was requested. Privacy is a property against the server itself, not against a network eavesdropper [@cgks-1995]. No, and the difference is the whole subject. TLS gives *confidentiality in transit*: it stops a third party on the wire from reading your data. PIR gives *query privacy*: it stops the party that answers your query from learning which record you wanted. TLS assumes the server is a trusted endpoint that may decrypt; PIR treats the server as the adversary and never lets it see the index at all. You can run PIR *inside* a TLS tunnel and still need every bit of the PIR machinery, because the two protect against different people.

So how could anyone possibly hide the index from the server? There is exactly one obviously private answer, and it is a joke: have the server ship you the entire database, and read the row you want on your own machine. The server treats every client identically, so it learns nothing about $i$. It also just moved $n$ records to answer a one-record question.

The only trivially private PIR protocol: the server sends its whole database, and the client reads the wanted record locally. It leaks nothing about $i$ because the server does the same thing for every query. Its price sets the bar -- $n$ bits crossing the wire and $n$ bits of database touched -- that every real scheme must beat [@cgks-1995].

That baseline gives us the measuring stick for the rest of the article: a two-axis ledger. The first axis is communication -- how many bits cross the wire per query. The second is server computation -- how many bits of the database the server must touch to answer one query. Downloading everything costs $n$ on both. Every generation of PIR is a different, quantified answer to one question: how far below $n$ can you push each axis, and what do you pay -- client storage, an extra hardness assumption, a preprocessing phase, a non-collusion requirement, or plain money?

Key idea: The server is the adversary. Encryption in transit protects your data from everyone except the one party that decrypts and answers your query -- and that party sees exactly which row you read. PIR moves the guarantee from the wire to the query itself, and the honest bar it must beat is the ridiculous one: just download the whole database.

This is Part 4 of Never Decrypted, a series on computation that uses, transmits, and reasons about data without ever decrypting it. The single-server story here rests on homomorphic encryption, built in the companion post on fully homomorphic encryption; the private set lookups PIR resembles but does not solve live in the earlier post on OPRFs and private set intersection. If downloading everything is the only thing that obviously works, how could anyone ever do better -- and why did it take until the 2020s to ship?

2. 1995: the problem gets a name and a wall

The field begins with a single paper. In 1995, Benny Chor, Oded Goldreich, Eyal Kushilevitz, and Madhu Sudan defined private information retrieval, gave it the two-axis framing we just built, and in the same stroke proved that the honest bar cannot be beaten by one server alone [@cgks-1995]. Their model is deliberately austere: the database is a string of $n$ bits, the client wants bit $D[i]$, and "privacy" means the server's view is independent of $i$. No cryptography, no assumptions -- just information.

Under that model they proved a wall: with a single server and perfect privacy, the client must download everything.

"To completely guarantee the privacy of the user, the whole database should be downloaded; namely $n$ bits should be communicated." -- Chor, Goldreich, Kushilevitz, and Sudan, 1995

The argument is a counting argument, and it rewards being felt in the gut rather than taken on faith -- as long as you run it in the right order. Start from what unconditional privacy forces: the whole transcript the server sees must be identical no matter which index the client wanted. If it shifted with $i$ even slightly, a server that studied the transcript could shift its guess, and privacy would not be perfect.

So the primitive is query-independence -- any transcript that can occur when the client wants row $i$ can also occur when it wants any other row $j$. The more familiar statement, that the answer carries no information about $i$, is a downstream consequence, not the starting point."Possible" here means possible with positive probability over the client's own private coins -- the secret decoding randomness the server never sees. The client reconstructs its bit from the transcript using those coins, so one fixed transcript together with fixed coins yields exactly one output bit. Making that caveat explicit is what turns the intuition into a proof [@cgks-1995].

Now count the transcripts. Fix the wanted index $i$ and suppose fewer than $2^n$ transcripts are possible for it. There are $2^n$ possible databases, so two of them, $x$ and $y$, must produce the very same transcript $C$ -- identical query and, crucially, identical server answer. By query-independence, that transcript is also reachable when the client instead wanted some index $j$ where the databases disagree, $x_j \neq y_j$.

But faced with $C$ and its private coins, the client emits a single fixed bit. Correctness demands that bit equal $x_j$ when the database is $x$ and $y_j$ when it is $y$ -- and those differ. Contradiction. So at least $2^n$ transcripts must be possible, and merely naming one takes $n$ bits. The download bar is not lazy engineering; for one server with perfect privacy it is provably the only solution [@cgks-1995, @gasarch-2004]. It is a theorem.

*Information-theoretic* (unconditional) privacy means the server's view of your query is statistically independent of $i$: even a server with unlimited computing power learns nothing, ever, under no assumptions. *Computational* privacy is weaker and cheaper: the server's view is merely indistinguishable from independent to an *efficient* adversary, and only while some problem (integer factoring, lattice hardness) stays hard. Break the assumption or add enough compute, and computational privacy can fail; information-theoretic privacy cannot [@cgks-1995, @gasarch-2004].

That distinction is the hinge of everything that follows, because the 1995 impossibility only bites under two conditions held at once: one server and unconditional privacy. Drop either and the wall has a door.

Relax "one server" -- put the database on two or more replicas that do not talk to each other -- and you keep perfect privacy while paying far less than $n$ in communication. That is the multi-server, information-theoretic line, where the next section builds a scheme by hand. Relax "unconditional" -- allow a computational hardness assumption -- and a single server can be private after all, the line that eventually ships. The impossibility did not close the field. It drew the two roads out of it.Cite the founding result carefully: the conference version is Chor, Goldreich, Kushilevitz, and Sudan at FOCS 1995, and the journal version is JACM 45(6), 1998. They are the same work; do not date the idea to 1998 or the journal to 1995 [@cgks-1995].

One server cannot beat the download bar without giving up perfect privacy. So what exactly breaks the impossibility when you add a second server -- and what new, fragile thing do you have to trust in exchange?

3. Two servers, one XOR, and privacy from nowhere

Here is the escape, and it is not the one you would guess. Do not encrypt anything. Instead, replicate the database onto two servers that never communicate, and split your question into two halves that each look like noise. The 1995 impossibility assumed one server; give the client two, and perfect privacy costs far less than a full download [@cgks-1995]. The tool is XOR and nothing else.

Work over bits. The database is $n$ bits, held identically by Server 1 and Server 2, and you want bit $D[i]$. The client picks a uniformly random mask -- an $n$-bit string where each position is an independent coin flip -- and calls it $q_1$. It builds $q_2$ by copying $q_1$ and flipping the one bit at position $i$, then sends $q_1$ to Server 1 and $q_2$ to Server 2.

Each server computes the parity of the database bits its mask selects -- the XOR of $D[j]$ over every $j$ where the mask is 1 -- and returns that single bit. The client XORs the two replies.

Watch what cancels. The two masks agree everywhere except position $i$, so in the XOR of the two parities every database bit is counted twice and vanishes -- except $D[i]$, which was selected by exactly one of the masks. The client is left holding $D[i]$ and nothing else.

sequenceDiagram participant C as Client participant S1 as Server1 participant S2 as Server2 Note over C: Pick random mask q1, build q2 as q1 with bit i flipped C->>S1: Send mask q1 C->>S2: Send mask q2 S1-->>C: Parity of selected bits, a1 S2-->>C: Parity of selected bits, a2 Note over C: XOR a1 with a2, all bits but i cancel, recover D of i

Now the privacy claim, which is where the magic actually lives. Server 1 sees $q_1$, a uniformly random string -- every mask is equally likely, so it reveals nothing about $i$. Server 2 sees $q_2$, which is also uniformly random, because flipping a fixed position of a uniform string leaves it uniform. Each server, alone, learns nothing about your index in the strongest possible sense: not "cannot compute it efficiently," but "the string it received is statistically independent of $i$." No assumption, no cipher, no key.

{` // Two-server information-theoretic PIR: the whole idea on one screen. // The n-bit DB is held by BOTH servers, which must NOT talk to each other. const DB = [1, 0, 1, 1, 0, 0, 1, 0]; // n = 8 bits const i = 5; // the row we want -- kept secret

// Client: pick a uniformly random mask, then flip only position i for q2. const rnd = () => DB.map(() => Math.round(Math.random())); const q1 = rnd(); const q2 = q1.map((b, j) => (j === i ? b ^ 1 : b));

// Each server returns the XOR (parity) of the DB bits its mask selects. const answer = (q) => q.reduce((acc, b, j) => acc ^ (b & DB[j]), 0); const a1 = answer(q1), a2 = answer(q2);

// Client XORs the two replies. Every bit but i cancels. console.log("recovered D[i] =", a1 ^ a2, " actual =", DB[i]); console.log("server 1 saw:", q1.join("")); console.log("server 2 saw:", q2.join(""), "-- both look like pure noise"); `}

Run it and change $i$: the recovered bit always matches, and each server's view is an unbiased coin-flip string that betrays nothing. This is the first genuine shift in understanding the article offers. The way past the impossibility was never encryption. It was replication plus XOR -- an idea from coding theory, not cryptography.That is not a coincidence. A PIR scheme is essentially a locally decodable code: any single database symbol can be recovered by reading only a few positions of an encoding. Yekhanin's survey makes the correspondence precise, and progress on one side has repeatedly moved the other [@yekhanin-2010].

Now the ledger, and the catch. The by-hand scheme names an arbitrary subset of all $n$ positions, so each query is itself $n$ bits long -- "each server sent only a single bit, but the messages sent by the user ... are $n$ bits long," as CGKS note [@cgks-1995]. Privacy came for free, but on the communication axis this buys nothing over downloading. The genuine sublinear win comes from shrinking the query description, and it is worth seeing rather than taking on faith.

Reshape the $n$ bits into a $\sqrt{n} \times \sqrt{n}$ grid. Instead of a subset of everything, the client sends each server a random subset of the $\sqrt{n}$ columns -- a subset to Server 1, and to Server 2 the same subset with the target's column toggled in or out. Each server returns one parity per row: a $\sqrt{n}$-bit vector whose entry for row $r$ is the XOR of the grid entries in row $r$ over just the columns it was handed.

XOR the two vectors and every column cancels except the target's, which survives in full; the entry in the target row is your bit. That is $\sqrt{n}$ up and $\sqrt{n}$ back per server -- $O(\sqrt{n})$ communication, genuinely below $n$ [@cgks-1995].

The same crank turns further. Recurse on that $\sqrt{n}$-bit answer, or reshape into a three-dimensional cube of side $n^{1/3}$ and query a sub-cube, and communication falls to $O(n^{1/3})$. The cube naively needs eight servers, one per corner, but a radius-1 covering code collapses them to two: every one of the eight corners lies within one bit-flip of either 000 or 111 -- 000 covers ${000, 001, 010, 100}$ and 111 covers ${111, 110, 101, 011}$ -- so two servers cover the whole cube and still reach $O(n^{1/3})$ (CGKS Table I) [@cgks-1995].

Server computation, though, does not improve -- each parity still sweeps a constant fraction of the database, so every server does $\Theta(n)$ work per query. And all of it rests on one load-bearing assumption that XOR cannot defend.

Multi-server PIR is private only if the replicas never pool what they received. Each query is uniformly random on its own, so each server alone learns nothing; but the two queries *together* determine $i$ exactly. Non-collusion is not a tuning knob -- it is the entire privacy guarantee, and a breach leaves no observable trace in the protocol [@cgks-1995].

Note: If the two servers compare the masks they were sent, they compute $q_1 \oplus q_2$, which is exactly the indicator of position $i$. The XOR that protected you now unmasks you: $q_1 \oplus q_2$ has a single 1, at index $i$. There is no alarm, no failed decryption, no anomaly a client could detect. The scheme is perfectly private and perfectly broken at the same time, depending entirely on a trust assumption that lives outside the mathematics.

The two-server escape is real, it is unconditional, and it is brittle: it demands at least two replicas that you trust never to whisper. The founding $O(n^{1/3})$ barrier was not even the end of the information-theoretic story.Dvir and Gopi shattered the two-decade-old $O(n^{1/3})$ two-server bound in 2015-16, reaching subpolynomial $n^{o(1)}$ communication -- proof that the information-theoretic line still has room to move [@dvir-gopi-2016]. But most real deployments have exactly one server and no willing, non-colluding twin. Can a single server give you privacy, with no replica to trust?

4. One server, an encrypted question, and the wrong race

In 1997 Eyal Kushilevitz and Rafail Ostrovsky answered that question with a paper whose title is a thesis: "Replication Is Not Needed." A single server can be private after all -- if you stop demanding unconditional privacy and let the server compute on an encrypted query instead [@ko-1997]. This is the birth of computational single-server PIR, and it is also, though nobody would notice for a decade, the birth of a strategic mistake.

The mechanism is the one the whole modern field still runs on. Lay the $n$-bit database out as a $\sqrt{n} \times \sqrt{n}$ matrix. To fetch the entry in column $c$, the client sends an encrypted selection vector: $\sqrt{n}$ ciphertexts that decrypt to 0 everywhere except a single encrypted 1 in position $c$.

The server, using only the public key, folds each row of the matrix against that encrypted vector and produces one output ciphertext per row -- each an encryption of that row's entry in column $c$. The client decrypts only the row it wanted. The server never learned $c$, because it only ever touched ciphertext [@ko-1997].

An *additively-homomorphic* encryption scheme lets anyone combine ciphertexts into an encryption of the *sum* of their plaintexts, with no secret key -- Kushilevitz-Ostrovsky used Goldwasser-Micali, whose security rests on quadratic residuosity. A *selection vector* is an encrypted indicator: ciphertexts of 0 in every position but the one you want, which holds an encrypted 1. Fold a database against it homomorphically and the server computes an encryption of exactly the selected entry, having never seen which entry that was [@ko-1997]. flowchart TD Q["Client encrypts a selection vector, a single 1 at column c hidden among 0s"] --> SV["Server holds the database as a matrix"] SV --> F["For each row, fold the row against the encrypted vector using the public key"] F --> R["Server returns one ciphertext per row, each encrypting that row entry in column c"] R --> D["Client decrypts only the wanted row and reads the record"] Read that flow again and you have described homomorphic evaluation of a table lookup: the client sends an encrypted query, the server evaluates the linear function "dot this selection vector with the database" *under encryption*, and the client decrypts the result. The [companion post on fully homomorphic encryption](/blog/never-decrypted-how-fully-homomorphic-encryption-computes-on/) builds exactly this capability -- computing on ciphertext the server cannot read -- from first principles. Here we only need the fact that it works; there you get the how [@ko-1997].

That $\sqrt{n}$-up, $\sqrt{n}$-back fold is only Kushilevitz-Ostrovsky's base case. Its answer is itself a bundle of $\sqrt{n}$ ciphertexts, of which the client wants exactly one -- so apply PIR again to that bundle, recursing $L = \lceil 1/\epsilon \rceil - 1$ levels (equivalently, viewing the database as an $(L+1)$-dimensional hypercube and folding one axis per level). That drives the $O(\sqrt{n})$ base case down to the $O(n^{\epsilon})$ the ledger records, for any constant $\epsilon > 0$ [@ko-1997].

That single-axis victory lit up a decade of relentless progress. Christian Cachin, Silvio Micali, and Markus Stadler drove communication to polylogarithmic in 1999,CMS rested on the $\Phi$-hiding assumption, a number-theoretic conjecture about the hidden prime factors of Euler's totient. We only name it; the number theory is not the point of this article [@cms-1999, @phi-hiding-wikipedia]. and by 2005 Craig Gentry and Zulfikar Ramzan reached constant communication rate, the response barely larger than the record itself [@gentry-ramzan-2005]. On the communication axis, PIR looked finished. On paper, the problem was solved.

Then someone finally timed the other axis. In 2007 Radu Sion and Bogdan Carbunar measured single-server computational PIR on real hardware and published a verdict that stopped the field cold.

Deploying non-trivial single-server PIR on real hardware "would have been orders of magnitude less time-efficient than trivially transferring the entire database." -- Sion and Carbunar, 2007

Read that against the thesis. The whole point of PIR is to beat the trivial download. Sion and Carbunar showed that every clever single-server scheme, timed end to end, lost to the very baseline it was built to beat -- because the server still ground through $\Theta(n)$ expensive modular-exponentiation operations per query, and moving a few kilobytes over a fast network is cheaper than a server doing a billion big-integer multiplies [@sion-carbunar-2007]. The community had spent ten years shrinking the wrong number.

Note: Communication and computation are separate axes, and only one of them was being measured. Driving bits-on-the-wire to polylogarithmic is a genuine theorem. But if the server still performs $\Theta(n)$ heavy public-key operations per query, wall-clock time is set by that computation, not by the tiny message. The field won the race it was timing and lost the race that decides whether anyone ships.

Worse, the computational wall was already a theorem. In work that culminated in the 2004 Journal of Cryptology, Amos Beimel, Yuval Ishai, and Tal Malkin proved that without preprocessing, any PIR server must do $\Omega(n)$ work -- it cannot answer a query while ignoring part of its database, or the ignored part could not have influenced the answer [@bim-2004]. Sion and Carbunar had measured, on silicon, a floor that theory guaranteed.

gantt title PIR milestones on two axes, 1995 to 2026 dateFormat YYYY axisFormat %Y section Communication axis CGKS two-server IT-PIR :milestone, 1995, 0d Kushilevitz-Ostrovsky single-server CPIR :milestone, 1997, 0d CMS polylog communication :1999, 2001 Gentry-Ramzan constant rate :milestone, 2005, 0d section Computation axis Sion-Carbunar impractical verdict :milestone, 2007, 0d XPIR lattice revival :milestone, 2016, 0d SimplePIR near memory bandwidth :milestone, 2023, 0d section Deployment Apple ships keyword PIR :2024, 2026

Two honest caveats keep this from being a hit piece. First, the verdict was contested: in 2011 Femi Olumofin and Ian Goldberg re-measured with better implementations and argued that multi-server and even some single-server PIR already beat trivial download for realistic parameters [@olumofin-goldberg-2011]. Second, the theory cuts the other way too: Beimel, Ishai, Kushilevitz, and Malkin proved that any nontrivial single-server PIR implies one-way functions exist [@bikm-1999].

So a computational assumption is unavoidable for one server -- but it is a claim about the necessity of some assumption, not about fully homomorphic encryption specifically. Homomorphic encryption is the efficient road, never a logical requirement.

Here is the running ledger so far, one row per generation:

Generation	Year	Communication	Server computation	What it pays
Trivial download	--	$n$	$\Theta(n)$	moves the whole database
Two-server IT-PIR (CGKS)	1995	$O(n^{1/3})$	$\Theta(n)$ per server	needs 2+ non-colluding replicas
Single-server CPIR (K-O)	1997	$O(n^{\epsilon})$	$\Theta(n)$ heavy public-key ops	a computational assumption
Polylog CPIR (CMS)	1999	polylog	$\Theta(n)$ slow modular work	loses the wall-clock race
Constant-rate CPIR (Gentry-Ramzan)	2005	constant rate	$\Theta(n)$ slow modular work	loses the wall-clock race

If $\Omega(n)$ server work is a theorem, single-server PIR seems condemned to lose the clock forever. There turn out to be exactly two honest ways out -- and confusing them is the most common mistake in the whole subject.

5. Two escapes from the computation trap

A theorem that says $\Omega(n)$ server work is unavoidable without preprocessing is not a dead end. It is a signpost with two arrows, because there are exactly two things you can change: keep the linear work but make each unit almost free, or break the "without preprocessing" clause and buy sublinear online time with an offline phase. The modern era of PIR is the parallel pursuit of both, and telling them apart is the single most important distinction in the subject.

flowchart TD W["Omega(n) server work without preprocessing, a theorem"] --> A["Escape 4a: keep it linear, make each unit cheap"] W --> B["Escape 4b: change the model with preprocessing and client state"] A --> A1["XPIR, SealPIR, Spiral, SimplePIR, DoublePIR, FrodoPIR touch every bit at memory bandwidth"] B --> B1["CGK, CHK, Piano, DEPIR buy genuinely sublinear online server time"]

Escape 4a: linear is fine if each unit is cheap. Stop fighting the wall. If the server must touch every bit, make touching a bit cost almost nothing. In 2016 Carlos Aguilar-Melchor and colleagues built XPIR by throwing out slow modular exponentiation and replacing it with fast lattice arithmetic -- Ring-LWE homomorphic encryption, whose per-operation cost is a small-integer multiply, not a big-integer power.

Their paper says it plainly: "the conclusion of Sion and Carbunar is not valid anymore: cPIR is of practical value" [@xpir-2016]. The wrong-axis decade ended not by beating the $\Omega(n)$ floor but by making the floor cheap to stand on.

The line then sprinted. SealPIR (2018) compressed the client's query so a single ciphertext expands, server-side, into the full selection vector -- roughly a 274-times smaller query -- and added probabilistic batch codes to amortize many queries at once [@sealpir-2018]. Spiral (2022) composed two lattice schemes to push the response rate toward 0.81, so the answer is barely larger than the record [@spiral-2022].

Then, in 2023, SimplePIR and DoublePIR shrank the server's online job to essentially one cheap matrix-vector product over a small modulus -- a single product in SimplePIR, plus a second, much smaller one in DoublePIR. They hit roughly 10 and 7.4 gigabytes per second per core, within a small factor of raw memory bandwidth [@simplepir-doublepir-2023].

SimplePIR's matrix-vector product is worth seeing in full, because it shows at once why the linear work is cheap and how the client scrubs off the encryption noise with no server-side decryption at all. Store the database as a $\sqrt{N} \times \sqrt{N}$ matrix $D$ over a small plaintext modulus $p$, and fix a public matrix $A$ that everyone derives from a short seed. Pick a ciphertext modulus $q$ and a scale $\Delta = \lfloor q/p \rfloor$. The scheme is four short steps:

Setup, once. The server publishes a hint equal to the product $D,A$. It depends only on the database and the public $A$, never on a query, so it is computed a single time and reused by every client forever after.
Query row $(i_{\mathrm{row}}, i_{\mathrm{col}})$. The client samples a secret vector $s$ and a tiny error $e$, and sends one vector $\mathrm{qu} = A,s + e + \Delta,u_{\mathrm{col}}$, where $u_{\mathrm{col}}$ is the indicator with a single 1 in the target column. That $\mathrm{qu}$ is an ordinary LWE ciphertext -- uniform-looking -- so the server learns nothing about the column.
Answer. The server returns $\mathrm{ans} = D,\mathrm{qu}$. This one matrix-vector product is the entire online cost: about $2N$ small-integer operations, roughly one multiply and one add per database byte.
Recover. The client subtracts the hint mask and rounds: it computes $\mathrm{ans}[i_{\mathrm{row}}] - \mathrm{hint}[i_{\mathrm{row}}]\cdot s$ and rounds to the nearest multiple of $\Delta$.

Why does that land on the wanted entry? Expand the answer and the structure falls out: $\mathrm{ans} = D,\mathrm{qu} = (D A),s + D,e + \Delta,(D,u_{\mathrm{col}})$, and the first term is exactly $\mathrm{hint}\cdot s$. The client downloaded $\mathrm{hint} = D A$ and knows its own secret $s$, so it recomputes that masking term and subtracts it away.

The vector $D,u_{\mathrm{col}}$ is just the target column of the database, so what remains at row $i_{\mathrm{row}}$ is $\Delta$ times the wanted entry plus the small residual $D,e$; rounding to the nearest multiple of $\Delta$ erases the residual and returns the entry. The hint cancels the mask; the rounding cancels the noise; and the server, having only ever multiplied by a ciphertext, never learns which entry you read [@simplepir-doublepir-2023].

{` // Toy SimplePIR: the server's entire online job is ONE matrix-vector product, // and a precomputed hint lets the client cancel the LWE mask. const p = 16, q = 1 << 20, DELTA = q / p; // plaintext modulus, ciphertext modulus, scale const sqrtN = 4, n = 8; // DB is sqrtN x sqrtN; lattice dimension n const mod = (x) => ((x % q) + q) % q; const randInt = (hi) => Math.floor(Math.random() * hi);

// Database: a sqrtN x sqrtN matrix of plaintext values in [0, p). const D = Array.from({length: sqrtN}, () => Array.from({length: sqrtN}, () => randInt(p))); // Public matrix A (sqrtN x n), uniform mod q -- in practice derived from a short seed. const A = Array.from({length: sqrtN}, () => Array.from({length: n}, () => randInt(q)));

// Setup, once and query-independent: hint = D * A (a sqrtN x n matrix). const hint = D.map((row) => Array.from({length: n}, (_, k) => mod(row.reduce((acc, d, c) => acc + d * A[c][k], 0))));

// Client wants entry (iRow, iCol); iCol is hidden in the query, iRow never leaves the client. const iRow = 2, iCol = 3; const s = Array.from({length: n}, () => randInt(q)); // secret vector const e = Array.from({length: sqrtN}, () => randInt(3) - 1); // small error in {-1,0,1} // qu = A*s + e + DELTA * u_col -- an LWE encryption of the column indicator. const qu = A.map((Arow, c) => mod(Arow.reduce((acc, a, k) => acc + a * s[k], 0) + e[c] + (c === iCol ? DELTA : 0)));

// Answer: ans = D * qu -- one matrix-vector product, the whole online server cost. const ans = D.map((row) => mod(row.reduce((acc, d, c) => acc + d * qu[c], 0)));

// Recover: subtract the hint mask, then round off the small noise. const mask = mod(hint[iRow].reduce((acc, h, k) => acc + h * s[k], 0)); const recovered = Math.round(mod(ans[iRow] - mask) / DELTA) % p;

console.log("recovered =", recovered, " actual D[iRow][iCol] =", D[iRow][iCol]); console.log("the server only ever saw qu, an LWE ciphertext -- never iRow or iCol"); `}

But the authors are scrupulous about what they did not do.

The SimplePIR server "must touch every bit of the database to answer even a single client query." -- Henzinger, Hong, Corrigan-Gibbs, Meiklejohn, and Vaikuntanathan, 2023

Note: This is the error the popular framing of PIR gets wrong, so state it once and hold it: SimplePIR, DoublePIR, XPIR, Spiral, and FrodoPIR are linear-computation schemes. The server provably reads the entire database for every query. Their breakthrough is throughput -- doing that linear work at memory-bandwidth speed -- not sublinearity. Calling SimplePIR "sublinear" conflates a fast constant factor with a lower asymptotic order, and it is exactly the confusion the $\Omega(n)$ theorem forbids [@simplepir-doublepir-2023, @bim-2004].

FrodoPIR (2023) added the piece deployment needs: a client-independent offline phase, so the server precomputes one batch of state that every client reuses, and then named the honest price. Its measured cost is under one second per query, a response blow-up under 3.6 times, and about $1 for 100,000 queries [@frodopir-2023]. That is the first time in this article we can write PIR's cost as a number you could put in a budget.

Key idea: "Linear" was never the enemy. Slow linear was. Once each unit of the unavoidable $\Theta(n)$ work costs about one 32-bit multiply-add at memory bandwidth, the server's full sweep of the database finishes in the time it takes to stream that database through the CPU. The right question flips from "how few bits can I send?" to "how cheap can I make each unit of work I already cannot avoid?"

Escape 4b: change the model. The other door accepts a one-time cost to break the no-preprocessing clause, and buys something 4a can never have: genuinely sublinear online server time.

*Sublinear server time* means the server reads $o(n)$ of its database per query -- strictly less than all of it. Beimel-Ishai-Malkin proved this is impossible without preprocessing: with no precomputed state, a bit the server never reads cannot influence the answer, so it must read $\Omega(n)$ bits. Sublinear *communication* and sublinear *computation* are different claims, and only the first is free [@bim-2004]. An *offline* phase does work once -- independent of, or amortized across, future queries -- to build state (a per-client "hint," or public tables) that makes each later *online* query cheap. The $\Omega(n)$ floor only forbids sublinear server time in the *no-preprocessing* model. Preprocessing is the door through it, paid for in client storage, one-time compute, or table size [@cgk-2020].

Henry Corrigan-Gibbs and Dmitry Kogan opened this model for PIR in 2020, showing an offline phase could buy sublinear online time [@cgk-2020]. In 2022, Corrigan-Gibbs, Alexandra Henzinger, and Kogan achieved sublinear amortized time on a single server, holding about $\sqrt{n}$ of client state, and proved a matching lower bound that says roughly that much state is necessary [@chk-2022].

Piano (2024) then stripped the assumptions to the floor: sublinear online time from one-way functions only -- pseudorandom functions, no homomorphic encryption -- in about 150 lines of code [@piano-2024, @cmu-piano-blog]. And the asymptotic endpoint arrived in Lin, Mook, and Wichs's 2023 STOC Best Paper.

A single-server PIR where, after a one-time *public* preprocessing of the database, the server answers each query in $\mathrm{polylog}(N)$ time with *no per-client state at all*. Lin, Mook, and Wichs achieved it in 2023 from Ring-LWE with no trusted setup: the asymptotic ideal -- stateless clients and sublinear server time together -- at the price of large preprocessed tables [@depir-lmw-2023].

So the disambiguation, stated once and enforced for the rest of the article: 4a is fast-but-linear (touches every bit, stateless, simple), and 4b is sublinear-but-stateful-or-preprocessing-heavy (touches few bits, but holds $\sqrt{n}$ client state or huge public tables). They are not competitors racing to one finish line. They are different trades. Two escapes, two price tags -- so which one actually ships to a billion phones, and why that one?

6. The 2026 toolbox, laid side by side

By 2026 there is no "best PIR." There are five living families, each parked at a different point on the same trade-off surface, and the honest way to present them is a single table that scores every one on the two-axis ledger plus the things the ledger hides: client storage, the hardness assumption, and the preprocessing model.

Family 1A, fast-linear single-server PIR, is the deployed line: SimplePIR and DoublePIR, Spiral, SealPIR, FrodoPIR, and two schemes newer than the breakthrough itself. YPIR (2024) removes the client hint entirely with "silent" preprocessing, reaching up to 83% of memory bandwidth with no offline communication [@ypir-2024]. Respire (2024) targets small records, retrieving one 256-byte record from a million-record database in about 6.1 KB of online communication [@respire-2024].

Family 1B, sublinear-online preprocessing PIR, is CHK and Piano [@chk-2022, @piano-2024]. Family 1C is DEPIR and its practicalization race [@depir-lmw-2023]. Family 1D is the multi-server information-theoretic line [@cgks-1995, @dvir-gopi-2016]. And Family 1E, keyword PIR, is an orthogonal layer that rides on top of any of the others.

Scheme (year)	Server comp/query	Comm/query (+ one-time)	Client storage	Assumption	Preprocessing	Sublinear server?	Reported perf
Trivial download [@cgks-1995]	$\Theta(n)$	$n$	--	none (IT)	none	No	streams the DB
Two-server IT-PIR, 1995 [@cgks-1995, @dvir-gopi-2016]	$\Theta(n)$/server	$O(n^{1/3}) \to n^{o(1)}$	--	none (IT)	none	No	--
SealPIR, 2018 [@sealpir-2018]	$\Theta(n)$	1 ciphertext (~274x smaller)	small keys	RLWE	none	No	batched
Spiral, 2022 [@spiral-2022]	$\Theta(n)$	rate ~0.81	keys	RLWE	none	No	~1.9 GB/s
SimplePIR, 2023 [@simplepir-doublepir-2023]	$\Theta(n)$ at 10 GB/s/core	242 KB + 121 MB hint	121 MB hint	LWE	client-dependent hint	No	10 GB/s/core
DoublePIR, 2023 [@simplepir-doublepir-2023]	$\Theta(n)$ at 7.4 GB/s/core	345 KB + 16 MB hint	16 MB hint	LWE	client-dependent hint	No	7.4 GB/s/core
FrodoPIR, 2023 [@frodopir-2023]	$\Theta(n)$ online	KBs + offline	client-independent	LWE	client-independent	No	~$1/100k, under 1 s
YPIR, 2024 [@ypir-2024]	$\Theta(n)$, high throughput	~2.5 MB, no hint	~none	LWE/RLWE	silent, no offline comm	No	~83% of bandwidth
Respire, 2024 [@respire-2024]	$\Theta(n)$	~6.1 KB (1M x 256 B)	~17x DB in memory	RLWE	none	No	200-400 MB/s
CHK, 2022 [@chk-2022]	$\tilde{O}(\sqrt{n})$ amortized	sublinear	$\tilde{O}(\sqrt{n})$, stateful	OWF	offline/online	Yes	matching lower bound
Piano, 2024 [@piano-2024]	$\tilde{O}(\sqrt{n})$ online	sublinear	$\tilde{O}(\sqrt{n})$, stateful	OWF only	offline/online	Yes	~12-40 ms, ~150 LoC
DEPIR, 2023 [@depir-lmw-2023]	$\mathrm{polylog}(N)$	$\mathrm{polylog}(N)$	none (public tables)	Ring-LWE	public $O(N^{1+\epsilon})$	Yes	theory to batch
Keyword PIR, 1997 [@cgn-keyword-1998]	inherits base	inherits base	inherits base	inherits base	inherits base	layer	--

Read the table as a map of trades, not a leaderboard. Family 1A wins wall-clock throughput and statelessness while conceding $\Theta(n)$ work per query. Within 1A, the axis being optimized is not the compute -- it is the offline hint.Trace the hint shrinking across 1A: SimplePIR needs a 121 MB per-client hint, DoublePIR cuts it to 16 MB, FrodoPIR makes the offline state client-independent so every client reuses it, and YPIR removes the client hint altogether with silent preprocessing [@simplepir-doublepir-2023, @frodopir-2023, @ypir-2024]. Family 1B wins sublinear online server time from the minimal assumption, paying $\sqrt{n}$ client storage and statefulness. Family 1C wins the asymptotic ideal -- stateless clients, $\mathrm{polylog}$ server time -- at the price of enormous public tables that are only now becoming tractable.DEPIR's preprocessing is huge but shrinking fast: Okada, Player, Pohmann, and Weinert reported orders-of-magnitude optimizations and a first implementation in 2024 [@towards-practical-depir-fc2024], and a 2026 preprint pushed the server state for an $N=2^{23}$ database from a prior 733 TB down to 171 GB, at about 21 ms amortized per query in a batch [@practical-depir-2026].

A layer that retrieves a record by a *keyword* or key -- a phone number, a URL, an image embedding -- rather than a numeric index, while hiding the keyword from the server. Chor, Gilboa, and Naor showed in 1997 how to run any search structure (a hash table, a binary search) *inside* any underlying PIR, turning index PIR into a private key-value store with no new hardness assumption. It is the form that actually ships [@cgn-keyword-1998].

Note: A frequent confusion: oblivious RAM (ORAM) hides the access pattern to your own outsourced data as you read and write it over time. PIR hides which row you read from someone else's database. Related tools, genuinely different guarantees -- do not swap one for the other.

The toolbox is real, fast, and honestly priced. So where, concretely, does it run for a billion people -- and what does that deployment quietly trade away?

7. PIR on a billion phones, and its honest bill

The thesis is now a shipping product. By 2024 Apple runs keyword PIR at consumer scale in two features, both on the homomorphic-encryption-based linear line -- family 1A -- and both wrapped in an Oblivious HTTP relay that hides the client's IP address from the answering server.

Enhanced Visual Search, in Photos, is the mass-scale one: it is on by default. When your phone wants to name a landmark in a photo, it computes an embedding of the image region, encrypts it under BFV, and runs a private nearest-neighbor search plus PIR against a global index Apple holds.

In Apple's own words, the system uses "homomorphic encryption (HE) along with technologies like private information retrieval (PIR) and private nearest neighbor search (PNNS)" and runs at "post-quantum 128-bit security" [@apple-ml-he-research]; Apple's privacy note says it "privately matches places in your photos to a global index Apple maintains on our servers ... using homomorphic encryption" [@apple-photos-privacy-legal].That Enhanced Visual Search ships on by default in iOS 18 and macOS 15 was surfaced less by Apple's launch messaging than by developers -- Jeff Johnson prominent among them -- who found the toggle already enabled and asked whether users had meaningfully consented [@iclarified-evs, @lapcat-evs-blog].

Live Caller ID Lookup is the opt-in, provider-dependent one: when enabled, it fetches caller-identification and spam information for an incoming number. Apple states it plainly: "Live Caller ID Lookup relies on Private Information Retrieval (PIR)," the implementation "relies on homomorphic encryption," it "implements the Brakerski-Fan-Vercauteren (BFV) HE scheme," and BFV is "quantum resistant" [@apple-swift-he-blog]. Unusually, the backend is open: Apple publishes a reference server and the swift-homomorphic-encryption library, so the deployed stack is not a black box [@apple-livecallerid-artifacts].

flowchart LR D["Device computes an embedding or a phone number"] --> E["Encrypt under BFV, client keeps the key"] E --> O["Oblivious HTTP relay hides the client IP"] O --> S["Server runs keyword PIR on ciphertext, never decrypts"] S --> A["Encrypted answer travels back"] A --> R["Device decrypts locally and reads the result"]

Both features rest on BFV, a Ring-LWE scheme whose internals belong to the FHE post, not here; enough that BFV lets the server fold an encrypted query against its index without a key, and that its lattice hardness is plausibly post-quantum [@bfv-primaries]. What matters for our ledger is which escape Apple chose, and it chose 4a: the server does full linear work per query, fast.

Note: Even a perfect PIR reveals when and from where you queried. Apple pairs its PIR with Oblivious HTTP so the answering server sees neither the plaintext query nor the client's IP address, and adds differential-privacy noise to some metadata. If you deploy PIR, budget for the network-layer and timing leaks too -- hiding the row index is necessary, not sufficient [@apple-ml-he-research].

Apple publishes no per-query CPU or bandwidth figures, so anyone quoting a precise cost is guessing -- this article will not. What we *can* name comes from the academic systems on the same line. FrodoPIR measured about \$1 to answer 100,000 queries, under one second per query, and a response blow-up under 3.6 times [@frodopir-2023]. SimplePIR and DoublePIR carry per-client hints of 121 MB and 16 MB [@simplepir-doublepir-2023]. Those are the right order-of-magnitude anchors: linear server compute billed in cents-per-thousand-queries, and a response several times larger than the record. Inventing Apple's undisclosed numbers would betray the whole point.

Why 4a and not the asymptotically superior sublinear lines?A labeled inference, not an Apple claim: a default-on, high-churn feature spread across a billion heterogeneous devices cannot ask each one to hold and periodically refresh $\sqrt{n}$ bytes of client state, which is exactly what the sublinear 1B and 1C lines require. The stateless, linear-but-fast 1A line is the only family whose operational shape fits a mass-consumer deployment, so that is the one that ships [@simplepir-doublepir-2023, @piano-2024]. The answer is not that 4a is faster in the abstract -- it is that statelessness beats asymptotics when your client population is a billion phones that churn constantly. It ships, and it works. But every choice on that stack traded something away. How does an engineer who is not Apple actually pick?

8. The decision fan: no single winner

Put the families on trade-off axes instead of a leaderboard, and the shape of the choice becomes clear. Three questions route you to a family, and each answer pairs a strength with the limitation it leaves standing.

The first axis is how many servers you trust. Two or more replicas that will not collude buy unconditional privacy with no hardness assumption -- the information-theoretic multi-server line [@cgks-1995] -- but you must operate non-colluding infrastructure, which most single-vendor deployments cannot. One server needs a computational assumption instead of a replica.

The second axis is how much state the client can carry. Fast-linear 1A is stateless and simple, paying $\Theta(n)$ server work per query [@simplepir-doublepir-2023]. Sublinear 1B (CHK, Piano) cuts online work to $\tilde{O}(\sqrt{n})$ but demands roughly $\sqrt{n}$ bytes of per-client state and a client long-lived enough to amortize its offline phase [@chk-2022, @piano-2024]. Doubly-efficient 1C keeps clients stateless and server time $\mathrm{polylog}$, but relocates the cost to enormous public tables [@depir-lmw-2023].

The third axis is which assumption you will accept. Spiral and DEPIR want lattice homomorphic encryption; Piano wants only a pseudorandom function, the weakest cryptography that can do the job [@spiral-2022, @depir-lmw-2023, @piano-2024]. Weaker assumptions are safer and often faster per operation, but so far buy sublinearity only in the stateful model.

flowchart TD Q1{"Two or more non-colluding servers?"} -->|"yes, unconditional privacy"| MS["1D multi-server IT-PIR"] Q1 -->|"no, single server"| Q2{"Clients can hold sqrt n state?"} Q2 -->|"no, stateless and high churn"| FL["1A fast-linear plus a keyword layer"] Q2 -->|"yes, few long-lived clients"| SUB["1B Piano or CHK, sublinear online"] Q2 -->|"want the asymptotic ideal, huge tables acceptable"| DE["1C DEPIR"]

Note: There is no fastest PIR in the abstract. There is only the fastest PIR for a given number of servers you trust, a given amount of client state you can carry, a given assumption you will accept, and a given query volume. A benchmark that ignores those constraints is timing the wrong race -- the precise mistake the field made before 2007.

Every option on this fan shares one silence. Each is only a privacy mechanism: it hides which row you read. None promises the row you got back is the right row, or that the database is hidden from you. What can no PIR promise -- and which gaps are engineering debt versus provable, permanent walls?

9. Four walls, and the row you cannot trust

Now that PIR demonstrably works, it is worth seeing exactly how far it cannot go -- because several of the ceilings are theorems, not engineering backlog. Four walls, then a fifth thing PIR was never built to do.

Wall one: one server plus unconditional privacy equals download everything. This is the 1995 impossibility, and it is permanent. No cleverness beats it, because it is an information-theoretic counting bound: the baseline is not the worst case, it is the optimal case for that threat model [@cgks-1995].

Wall two: no preprocessing means $\Omega(n)$ server work. Sublinear server time is impossible in the no-preprocessing model, full stop [@bim-2004]. This is the abstract statement of SimplePIR's practical confession that the server "must touch every bit of the database to answer even a single client query" [@simplepir-doublepir-2023]. You can move the cost with preprocessing, but you cannot make it vanish.

Wall three: some assumption is unavoidable for one server. Any nontrivial single-server PIR implies one-way functions exist [@bikm-1999]. So single-server privacy can never be unconditional -- but note precisely what that says. A one-way function is necessary; fully homomorphic encryption is not. HE is the efficient road, and Piano proves a pseudorandom function suffices for the sublinear line [@bikm-1999].

Wall four: the multi-server line is bounded by coding theory. Because a PIR scheme is essentially a locally decodable code, the best achievable multi-server communication is pinned to open questions about those codes -- which is why the two-server frontier is measured in the same breath as LDC lower bounds [@yekhanin-2010].

Then the ceiling that surprises people most, and the one the series turns on: basic PIR hides your index from the server, but it does nothing to hide the rest of the database from you.

*Symmetric PIR* additionally hides the database from the client: the client learns record $i$ and nothing about the other $n-1$ records, while the server still learns nothing about $i$. That two-sided guarantee is exactly *1-out-of-$n$ oblivious transfer*, where a sender holds $n$ messages, a receiver picks one, the receiver learns only that one, and the sender learns nothing about the choice. Gertner, Ishai, Kushilevitz, and Malkin showed how to upgrade PIR into SPIR and tied the two notions together [@gikm-1998].

Basic PIR gives only the server-side half of that guarantee.SPIR is the symmetric version -- privacy for both parties at once -- which is why it coincides with oblivious transfer, a strictly stronger and more expensive primitive than plain PIR [@gikm-1998]. A curious client running ordinary PIR can fish: nothing in the protocol stops it from asking for records it has no right to, because the whole design goal was to protect the client's query, not the server's data. If you need to protect the data from the client too, you do not want PIR, you want SPIR or oblivious transfer.

Note: Three corrections stack into humility. First, the deployed schemes are linear, not sublinear -- the server touches every bit [@simplepir-doublepir-2023]. Second, basic PIR hides your query but not the rest of the data from you; that is SPIR [@gikm-1998]. Third, and worst, PIR guarantees privacy, not correctness. A malicious server can return a perfectly well-formed wrong record, and nothing in the protocol catches it. "I read the row without revealing which row" says nothing about whether the row was real.

That third correction is not a settled theorem like the first four. It is a live gap -- the seam where privacy stops and integrity was never promised. It, and the size of DEPIR's tables, are where the frontier actually is.

10. The unfinished map

The mechanism is proven and shipping, which is exactly when the interesting problems start. Here is where a reader could actually push.

Shrink DEPIR's tables. Doubly-efficient PIR reaches the asymptotic ideal but pays with $O(N^{1+\epsilon})$ preprocessed state, and driving that toward $O(N)$ while keeping $\mathrm{polylog}$ online time is the central open engineering problem of the line [@depir-lmw-2023]. The trajectory is steep and public: concrete optimizations and a first implementation in 2024 [@towards-practical-depir-fc2024], open prototypes exploring algebraic-HE variants [@algebraic-he-depir-2024, @depir-open-impl-2024-829], and a 2026 preprint cutting server state from hundreds of terabytes to hundreds of gigabytes for a fixed database size [@practical-depir-2026].

Make sublinear single-server PIR stateless. The 1B line buys sublinear online time only by holding about $\sqrt{n}$ of per-client state, and CHK proved a matching lower bound suggesting that much state may be inherent to the client-hint model [@chk-2022]. Whether a stateless client can get sublinear online time on a single server, outside the huge-table DEPIR regime, is open.

Close the integrity seam. This is the one that matters most for the series.

PIR promises privacy, never correctness. A server that follows the protocol faithfully but substitutes a wrong record hands you an answer that decrypts cleanly and is simply false, and no PIR scheme in this article detects it. Closing the gap means adding verifiability -- authenticated data structures, or proofs that the returned record is the genuine one -- without sacrificing the memory-bandwidth throughput that made PIR deployable in the first place. This is the exact confidentiality-versus-integrity boundary the FHE post draws, and it is the seam the rest of *Never Decrypted* follows.

The rest of the frontier is a good to-do list:

Keyword PIR at web scale -- private safe-browsing blocklists, Certificate Transparency lookups -- pushes throughput and record-size limits that Respire and YPIR are actively chasing [@respire-2024, @ypir-2024].
Updatable and streaming databases strain the preprocessing lines, whose hints assume a database that does not change under them.
Batching and multi-query lower bounds ask how much cheaper $k$ queries can be than $k$ times one, the question SealPIR's probabilistic batch codes opened [@sealpir-2018].
Metadata leakage beyond the index -- when and from where you queried -- is only partly handled by Apple's Oblivious HTTP and differential-privacy scaffolding [@apple-ml-he-research].
The multi-server communication frontier reopened by Dvir and Gopi is still moving [@dvir-gopi-2016].

Note: Every scheme in this article is complete on the axis it targets -- the server provably never learns $i$. None of them, on its own, promises the answer is correct. A privacy mechanism that ships without an integrity story is not wrong; it is partial, and knowing exactly which half you bought is the difference between using PIR well and trusting it too far.

The row-hiding mechanism is settled. The guarantees around it -- small preprocessing, verifiable answers, metadata hygiene -- are the next decade, and the next post. Before then, one practical question remains: given all this, how do you actually choose, this week?

11. Choosing, and when not to use PIR at all

Here is a procedure you can act on this week. Start by trying not to use PIR, because the trivial baseline is genuinely optimal below a break-even size, and then route by the constraints that actually bind.

Situation	Use	Why
Small or rarely-queried database	Just download it	Below break-even the trivial baseline wins on every axis [@apple-swift-he-blog]
Mass-scale, stateless, high-churn, one provider	1A fast-linear + keyword layer	Statelessness beats asymptotics at a billion clients [@simplepir-doublepir-2023]
One long-lived client, many queries, light crypto	Piano (1B)	Sublinear online from a PRF, about $\sqrt{n}$ state [@piano-2024]
Two or more non-colluding servers, want unconditional privacy	1D multi-server IT-PIR	No hardness assumption, but needs true non-collusion
Need the asymptotic ideal, can afford huge tables	DEPIR (1C)	$\mathrm{polylog}$ server time, stateless clients [@depir-lmw-2023]
Must hide the database from the client too	SPIR / oblivious transfer, not PIR	Basic PIR does not protect the data [@gikm-1998]
Need the answer to be provably correct	Add integrity / verification	PIR guarantees privacy, not correctness
Private set intersection or contact discovery	OPRF / PSI, not PIR	A different primitive entirely

The budgeting rule for the deployed line is simple because the work is linear: a fast-linear server sweeps its whole database once per query, so at roughly 10 GB/s per core a $d$-gigabyte database costs about $d/10$ core-seconds of compute per query, plus a response several times larger than the record [@simplepir-doublepir-2023, @frodopir-2023]. Wrap the whole thing in Oblivious HTTP so the index is not the only thing you hide.

{` // Should you use PIR, or just download the database? // PIR server work is LINEAR: it streams the whole DB past the CPU once. const dbSizeGB = 8; // database size in gigabytes const downlinkGbps = 0.1; // client download speed, gigaBITS per second const pirThroughputGBs = 10; // SimplePIR-class server, gigaBYTES/s/core const pirCores = 8;

// Time to just download the entire database (the trivial baseline). const downloadSec = (dbSizeGB * 8) / downlinkGbps; // Time for one PIR query: the server sweeps the DB once at its throughput. const pirSec = dbSizeGB / (pirThroughputGBs * pirCores);

console.log("download everything:", downloadSec.toFixed(1), "s per query"); console.log("PIR linear scan: ", pirSec.toFixed(3), "s per query"); console.log(pirSec < downloadSec ? "PIR wins on wall-clock -- but you still pay server compute + response blow-up" : "below break-even: just download it, simpler and leak-free"); `}

Open implementations track the families in this article: SimplePIR and DoublePIR, Spiral, FrodoPIR, YPIR, and Respire on the fast-linear line; Piano on the sublinear line; and Apple's own `swift-homomorphic-encryption` with its `live-caller-id-lookup-example` reference backend for the deployed keyword-PIR stack [@simplepir-doublepir-2023, @spiral-2022, @frodopir-2023, @ypir-2024, @respire-2024, @piano-2024, @apple-livecallerid-artifacts].

Note: Reach for the baseline, not PIR, when the database is small or rarely queried -- below break-even, downloading everything is cheaper, simpler, and leaks nothing [@apple-swift-he-blog]. Reach for SPIR or oblivious transfer when you must hide the data from the client [@gikm-1998]. Reach for the OPRF and PSI toolkit when the task is private set intersection or contact discovery. And add an integrity layer whenever a wrong-but-well-formed answer would hurt, because PIR alone will never catch it.

Rules of thumb are cheap. Here are the questions people actually ask.

12. Frequently asked questions

No. Basic PIR hides your *query* from the server -- which row you read -- but does nothing to stop a curious client from fishing for records it did not ask for. Hiding the rest of the data from the client is a strictly stronger notion, Symmetric PIR, which is equivalent to 1-out-of-$n$ oblivious transfer [@gikm-1998]. No. TLS hides your data from parties on the network, but the server terminates the TLS tunnel, decrypts your request, and sees exactly which record you wanted. PIR hides the index from the *answering server itself* -- a different guarantee against a different adversary, provably impossible to get for free from one server [@cgks-1995]. No. Any nontrivial single-server PIR implies one-way functions exist, so *some* assumption is necessary -- but a one-way function is enough, and Piano builds sublinear single-server PIR from just a pseudorandom function, no homomorphic encryption at all [@bikm-1999, @piano-2024]. Homomorphic encryption is the efficient path for the fast-linear line, not a logical requirement. No, and this is the most common misconception. SimplePIR is *linear-computation*: its own authors state the server "must touch every bit of the database to answer even a single client query." Its breakthrough is throughput -- doing that linear sweep at roughly 10 GB/s per core -- not a lower asymptotic order [@simplepir-doublepir-2023]. Yes. By construction, PIR guarantees privacy, not correctness. A malicious server can return a perfectly well-formed record that is simply the wrong one, and nothing in the protocol detects it. Catching that requires an added integrity or verifiability layer -- the seam the rest of this series follows [@cgks-1995]. Privacy collapses to zero, silently. Each server's query is a uniformly random mask on its own, but XOR the two masks together and you get the indicator of exactly the index the client wanted. There is no failed decryption or anomaly to warn anyone -- non-collusion is the entire guarantee [@cgks-1995]. The lattice-based schemes are plausibly post-quantum -- Apple's deployed BFV runs at post-quantum 128-bit security [@apple-swift-he-blog]. And PIR only beats the trivial baseline above a break-even database size: below it, downloading everything is cheaper, simpler, and leaks nothing, which is why the honest cost is measured in cents per thousand queries and a response several times larger than the record, never zero [@frodopir-2023].

13. Reading the row, and trusting it

Return to the three lookups from the opening: the drug interaction, the number that just called, the landmark in the photo. You can now explain, mechanism by mechanism, how each stays private. The query leaves your device as an encrypted selection vector or an encrypted embedding; the server folds its database against that ciphertext without a key; an Oblivious HTTP relay strips your IP on the way; the answer comes back sealed, and only your device opens it. The server answered a question about a row it never identified.

Key idea: Thirty years turned an impossibility into a product. PIR lets a client fetch record $i$ while the server provably never learns $i$ -- won first on the communication axis (two-server XOR, then single-server homomorphic encryption, then polylogarithmic and constant-rate), then on the computation axis (fast-linear throughput and sublinear-preprocessing), and finally shipped to a billion phones. The baseline it beat was never lazy engineering: downloading everything is provably optimal for one server with perfect privacy, and PIR beats it at a cost you can name in dollars and gigabytes, but never zero.

The honest bill stays attached: linear server compute at cents per thousand queries, and a response several times larger than the record [@frodopir-2023]. That is the real price of running keyword PIR by default in a billion camera rolls [@apple-ml-he-research] -- and of the fact that a server sweeping every bit at memory bandwidth still never learns which bit you wanted.

Two threads run out of this post into the rest of Never Decrypted. The BFV and Ring-LWE machinery that lets the server compute on your encrypted query is built from first principles in the fully homomorphic encryption post; the private set operations PIR resembles but does not perform live in the OPRF and private set intersection post. And one honest sentence stays open, the same seam the FHE post left: PIR bought you privacy, not correctness [@cgks-1995].

Note: Part 5 turns to proving without showing -- zkVMs and zkML -- the integrity guarantee PIR omits. It answers the question this post leaves hanging: once you can read a row without revealing which row, how do you know the row you got back is the real one?

You can read the row without revealing which row. Whether you can trust the row you got back is the next story.

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.