Homomorphic Encryption Honestly

Fully homomorphic encryption is the closest thing modern cryptography has to a magic trick: you hand a server data that it cannot read, the server computes a function on it, hands you back a result it also cannot read, and you decrypt to find the correct answer. No trusted hardware, no splitting the computation across non-colluding parties, no decryption in the middle. The math holds. The catch — and there is always a catch — is that “the math holds” and “this is fast enough to use” are separated by three to six orders of magnitude, and closing that gap has been the entire story of the field since Craig Gentry proved it was possible in 2009. In 2026 the honest position is neither “FHE changes everything” nor “FHE is a research toy.” It is that FHE has found a handful of narrow, genuinely valuable deployments where the privacy is worth paying for, and remains catastrophically slow for the general case of “just run my program on encrypted data.”

This post is the map. What homomorphic actually means, the ladder from partial to fully homomorphic, the three or four schemes that matter in practice, why it is so slow at a mechanical level, what the real benchmarks look like, and the specific places — Apple’s Live Caller ID, private information retrieval, confidential blockchains, genomics — where someone decided the slowdown was worth it.

What “homomorphic” actually means

A homomorphism is a structure-preserving map. An encryption scheme is homomorphic with respect to an operation if doing that operation on ciphertexts produces a ciphertext of the result of doing it on plaintexts. Formally, for an operation * you want:

Dec( Enc(a) ⊗ Enc(b) ) = a * b

where ⊗ is some operation you can perform on ciphertexts without the secret key. This is not a new idea — textbook RSA has it for free. Unpadded RSA encryption is c = m^e mod N, and the product of two ciphertexts decrypts to the product of the two messages:

Enc(a) · Enc(b) = a^e · b^e = (ab)^e = Enc(ab)   (mod N)

That is multiplicatively homomorphic. Paillier (1999) is additively homomorphic — multiplying ciphertexts adds plaintexts. ElGamal is multiplicatively homomorphic. These are partially homomorphic encryption (PHE) schemes: they support one operation, unboundedly. PHE is old, fast, and quietly deployed everywhere — electronic voting tallies, privacy-preserving aggregation, and the additive layer inside many secure-aggregation protocols all lean on Paillier or its lattice cousins. PHE is not the hard part.

The hard part is supporting both addition and multiplication, because any computation you care about reduces to an arithmetic circuit of adds and multiplies (or, in the boolean world, ANDs and XORs). A scheme that does both, but only up to some bounded depth of multiplications, is somewhat homomorphic (SWHE) or, when the depth bound is a tunable parameter, leveled fully homomorphic. A scheme that does both to unbounded depth is fully homomorphic (FHE). The leap from “bounded depth” to “unbounded” is exactly Gentry’s 2009 contribution, and it has a name: bootstrapping.

The noise problem and bootstrapping

Every modern FHE scheme is built on lattice hardness — specifically Learning With Errors (LWE) or its ring variant RLWE. The security comes from deliberately adding small random noise to each ciphertext. Decryption works because the noise is small enough to round away. That same noise is the enemy.

Every homomorphic operation grows the noise. Addition grows it slowly (roughly additively); multiplication grows it fast (roughly multiplicatively). Each ciphertext has a finite noise budget, and once operations have consumed it, the noise overflows the rounding margin and decryption returns garbage. So a “leveled” scheme is one where you pick parameters big enough to absorb the multiplicative depth your circuit needs, then stop before the budget runs out.

Bootstrapping is the escape hatch. It is, conceptually, running the scheme’s own decryption circuit homomorphically: you take a noisy ciphertext, evaluate Dec on it under a fresh encryption of the secret key (the “bootstrapping key”), and out comes a ciphertext of the same plaintext with the noise reset to a low, fixed level. Because you can do this any time the budget runs low, you can compute circuits of unbounded depth. Bootstrapping is what makes FHE fully homomorphic — and it is also, by an enormous margin, the most expensive thing the scheme ever does.

   fresh ciphertext            after several multiplies         after bootstrap
   noise budget: ███████       noise budget: ██..... (low!)     noise budget: ██████
        |                            |                                |
        |   add / multiply           |   homomorphically              |
        +--------------------------->+   evaluate Dec()  ------------->+
                                     |   under bootstrap key          |
   each multiply eats budget;   when budget is nearly gone,     fresh budget, same
   noise grows multiplicatively  bootstrapping refreshes it     plaintext, ready again

The cost of that refresh is the single number that governs whether FHE is usable for a given workload.

The schemes that actually matter

By 2026 the field has consolidated around three or four schemes, each tuned for a different shape of computation. Confusing them is the most common way to get FHE wrong.

BGV (Brakerski–Gentry–Vaikuntanathan, 2011) and BFV (Brakerski / Fan–Vercauteren, 2012) operate on integers modulo a plaintext modulus t. Their superpower is batching: using the Chinese Remainder Theorem on the underlying polynomial ring, a single ciphertext encodes thousands of independent plaintext slots, and one homomorphic multiply operates on all of them in parallel — SIMD for encrypted data. If your computation is the same operation across a large vector, BFV/BGV amortize the cost beautifully.

CKKS (Cheon–Kim–Kim–Song, 2017) is the one that made FHE interesting to the machine-learning world. It treats the noise as part of an approximate arithmetic: you encode real or complex numbers, and decryption gives you the answer to a controllable precision, like floating point. That approximation is a feature — neural-network inference and statistics tolerate small numerical error fine — and it makes CKKS the natural fit for encrypted logistic regression, encrypted inference, and privacy-preserving analytics. The cost is that CKKS arithmetic requires careful rescaling after each multiply to manage the growing scale factor, and reasoning about precision is genuinely subtle.

TFHE (Chillotti–Gama–Georgieva–Izabachène, 2016–2020) takes the opposite bet. Instead of avoiding bootstrapping, it makes bootstrapping cheap — on the order of ten milliseconds per operation — and bootstraps after every gate. Crucially, its programmable bootstrapping evaluates an arbitrary lookup table during the refresh, so non-polynomial functions (comparisons, ReLU, sign, table lookups) that BFV and CKKS struggle with become natural. TFHE wins for control-flow-heavy, decision-heavy circuits; it loses badly for big batched arithmetic, because it has no SIMD batching to amortize across.

The practical rule: CKKS for numeric/ML, BFV/BGV for exact batched arithmetic, TFHE for arbitrary logic and comparisons. Real systems sometimes use two and switch between them.

Why it is so slow, mechanically

The slowdown is not a temporary engineering failure waiting on a 10x compiler. It is structural, and it comes from three compounding sources.

Ciphertext expansion. A single number, encrypted, becomes a pair of polynomials over a ring of degree typically 2^13 to 2^16, with coefficients hundreds of bits wide. One CKKS ciphertext is tens of kilobytes to a few megabytes. The expansion factor over plaintext is enormous — easily 1,000x to 10,000x — though batching claws much of it back by packing thousands of values into that one ciphertext. Still, the raw data you push through memory and over the network is large, and FHE is frequently memory-bandwidth bound, not compute bound.

Big-polynomial arithmetic. Every homomorphic multiply is a multiplication of large polynomials, done with the Number Theoretic Transform (NTT) — an FFT over a finite field — plus relinearization and modulus-switching steps that themselves involve key-switching keys megabytes in size. A single homomorphic multiply is thousands of native multiplications under the hood.

Bootstrapping. When you need it, it dominates. CKKS bootstrapping is a seconds-scale operation that consumes a large fraction of the noise budget just to run. TFHE keeps each bootstrap to milliseconds but pays it on every gate, so a circuit with a million gates is a million bootstraps.

Put together, a useful figure: a homomorphic multiply is roughly 10^4 to 10^6 times slower than a plaintext multiply, before batching. Batching recovers two to four orders of magnitude when the workload is wide and uniform. That is why FHE benchmarks look schizophrenic — “encrypted logistic regression in 100 ms!” (heavily batched, leveled, no bootstrapping) sits next to “one encrypted comparison takes 13 ms” (TFHE, single bit) sits next to “bootstrapping a CKKS ciphertext: 8 seconds.” They are all true, of different operations.

What the code actually looks like

Here is a realistic OpenFHE (the PALISADE successor, the de facto open standard) CKKS setup in C++. The parameters are the interesting part — they encode the security/performance trade directly.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

#include "openfhe.h"
using namespace lbcrypto;

int main() {
  CCParams<CryptoContextCKKSRNS> p;
  p.SetMultiplicativeDepth(6);          // how many multiplies before we run out
  p.SetScalingModSize(50);              // ~50-bit precision per level
  p.SetSecurityLevel(HEStd_128_classic);// 128-bit, per the HE.org standard tables
  p.SetBatchSize(8192);                 // SIMD slots packed per ciphertext

  auto cc = GenCryptoContext(p);
  cc->Enable(PKE); cc->Enable(KEYSWITCH);
  cc->Enable(LEVELEDSHE);

  auto keys = cc->KeyGen();
  cc->EvalMultKeyGen(keys.secretKey);   // relinearization key

  std::vector<double> x = {1.5, 2.0, 3.25, 4.0};
  auto pt = cc->MakeCKKSPackedPlaintext(x);
  auto ct = cc->Encrypt(keys.publicKey, pt);

  auto sq   = cc->EvalMult(ct, ct);     // element-wise square, eats one level
  auto poly = cc->EvalAdd(sq, ct);      // x^2 + x, cheap, barely touches budget

  Plaintext out;
  cc->Decrypt(keys.secretKey, poly, &out);
  out->SetLength(4);
  std::cout << out;                     // ~ (3.75, 6.0, 13.81, 20.0)
}

Two things deserve attention. SetMultiplicativeDepth(6) is the single most consequential choice: it determines how deep a circuit you can run before you must bootstrap or give up, and raising it inflates the ring dimension, which inflates ciphertext size and every operation’s cost super-linearly. SetSecurityLevel(HEStd_128_classic) points at the parameter tables published by the HomomorphicEncryption.org standardization effort — you do not get to invent your own ring dimension and modulus and call it secure; the community standard maps a security level to minimum ring dimensions for given modulus sizes, and straying from it is how people ship broken FHE.

For boolean/comparison work the equivalent in Zama’s tfhe-rs looks completely different — you work in bits and let the library bootstrap every gate transparently:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

use tfhe::prelude::*;
use tfhe::{generate_keys, set_server_key, ConfigBuilder, FheUint8};

let (ck, sk) = generate_keys(ConfigBuilder::default().build());
set_server_key(sk);

let a = FheUint8::encrypt(37u8, &ck);
let b = FheUint8::encrypt(64u8, &ck);

let gt   = a.gt(&b);          // encrypted comparison -> encrypted bool
let pick = gt.select(&a, &b); // encrypted branch, no plaintext leak
let clear: u8 = pick.decrypt(&ck);  // 64

That a.gt(&b) is the thing CKKS cannot do cheaply and TFHE does naturally — a data-dependent branch evaluated entirely under encryption, with no party ever learning which way it went.

Where FHE has actually shipped in 2026

This is the section that separates honesty from hype. FHE deployments in 2026 are real but they are narrow, and they almost all share one property: the function being computed is small and fixed, so you never need general bootstrapping at scale.

Private information retrieval — Apple. The flagship production deployment is Apple’s use of homomorphic encryption for Live Caller ID Lookup and Enhanced Visual Search in Photos, built on their open-sourced swift-homomorphic-encryption library (BFV under the hood). The shape is private information retrieval: your device wants to look something up in a server-side database — a caller’s identity, or which landmark is in a photo — without the server learning the query. The client encrypts the lookup key, the server homomorphically computes the matching row against its database, and returns an encrypted result only the device can read. Apple pairs it with an OHTTP relay so the server does not even see the client’s IP. This is FHE in hundreds of millions of pockets, and it works precisely because the homomorphic circuit is shallow and fixed.

Confidential smart contracts — Zama fhEVM. Zama’s fhEVM brings TFHE to blockchains, letting contracts operate on encrypted state — confidential token balances, sealed-bid auctions, private voting — where validators execute the logic without seeing the values. It is a genuine product line in 2026, and TFHE’s programmable bootstrapping is what makes the branch-heavy contract logic feasible.

Private set intersection and contact discovery. FHE-based PSI overlaps with the multi-party-computation toolkit; the trade-off between an FHE approach and an interactive MPC protocol is exactly the kind of decision covered in Multi-Party Computation in 2026. Microsoft’s Edge Password Monitor historically used homomorphic techniques to check your credentials against a breach database without revealing them. The pattern recurs: check membership in a sensitive set without exposing the query or the set.

Genomics and regulated analytics. Encrypted genome-wide association studies, encrypted logistic regression on pooled hospital data, and privacy-preserving statistics over financial records are where CKKS earns its keep. These are batch jobs where a multi-hour runtime is acceptable because the alternative is “the data legally cannot leave the institution at all.” When the baseline is no computation, a 1,000x slowdown is infinitely better than impossible.

What you will not find in 2026 is a general “encrypted cloud” where you upload your application and it runs on ciphertext at interactive speed. The shallow-fixed-function deployments work; the general one does not.

The hardware race

Because the slowness is structural, the field’s biggest bet is silicon. DARPA’s DPRIVE program funded purpose-built FHE accelerators aiming for multiple orders of magnitude speedup over CPUs, with Intel as a prime contractor and startups like Cornami, Optalysys, and Niobium building dedicated FHE processors and FPGA/photonic approaches. The bottleneck these chips target is exactly the one named earlier: enormous polynomial arithmetic and the memory bandwidth to feed it. NTT units, on-chip key-switching-key caches, and very wide datapaths are the recurring design motifs.

The honest read in 2026 is that GPUs already give a solid 10x–50x over CPUs for the batched arithmetic, dedicated ASICs are sampling and promising the 1,000x that would make CKKS inference interactive, but none of it has yet collapsed the general-purpose wall. Hardware is closing the gap for the batched, shallow workloads first — the same ones already deployable — rather than suddenly making deep, branchy, bootstrapping-bound computation cheap.

FHE versus the alternatives

FHE is one of several tools for computing on data you are not allowed to see, and choosing it over the others is a real engineering decision, not a default.

The clean distinction: FHE moves the computation to where the data is and keeps it encrypted; MPC splits the data across parties; a TEE decrypts inside trusted silicon; ZK proves a property without revealing the witness. FHE’s unique selling point is that it needs no second party and no trusted hardware — just one server that can compute but never read. Its unique cost is the slowdown. If you can tolerate a hardware root of trust, an enclave (see Hardware Security Modules and Secure Enclaves) is thousands of times faster. If you have multiple data owners on a fast network, MPC is usually faster. FHE wins specifically when interaction is impossible or undesirable and you refuse to trust hardware. It also shares the RLWE lattice foundation with the post-quantum migration, so the assumptions are the same ones tracked in Post-Quantum Cryptography in 2026 — and, reassuringly, those assumptions are believed to survive the machines discussed in The Quantum Computing Reality Check.

When FHE pays back the complexity

The deciding questions are always: How deep is the circuit? (deep means bootstrapping means slow), How wide and uniform is it? (wide means batching saves you), Is interaction possible? (if yes, MPC may beat FHE), and Will you trust hardware? (if yes, a TEE crushes FHE on speed). When the answers are “shallow, wide, non-interactive, no trusted hardware,” FHE is not just viable — it is the only tool that fits. Everywhere else, reach for it last.

Verdict

Homomorphic encryption earned its reputation as the holy grail honestly: the ability to compute on data nobody can read, with no trusted third party and no hardware to trust, is a genuine cryptographic miracle, and after Gentry’s 2009 breakthrough it is no longer theoretical. But the 2026 reality is disciplined, not magical. The schemes have stratified into clear roles — BFV/BGV for exact batched integer arithmetic, CKKS for approximate numeric and ML work, TFHE for arbitrary boolean and comparison logic — and each carries a slowdown of four to six orders of magnitude that batching and hardware can dent but not erase. The deployments that shipped — Apple’s homomorphic PIR in hundreds of millions of devices, Zama’s confidential contracts, encrypted genomics and analytics — all share the same DNA: a shallow, fixed, non-interactive function where the privacy is non-negotiable and a slow-but-possible computation beats an impossible one. Treat FHE as a precision instrument for exactly that shape of problem. Reach for an enclave when you can trust hardware, MPC when parties can interact, and plaintext when you can. The grail is real; it is just heavy, and you should pick it up only when nothing lighter will do.

Sources

• Gentry, “Fully Homomorphic Encryption Using Ideal Lattices” (STOC 2009) — https://crypto.stanford.edu/craig/craig-thesis.pdf
• Cheon, Kim, Kim, Song, “Homomorphic Encryption for Arithmetic of Approximate Numbers” (CKKS, 2017) — https://eprint.iacr.org/2016/421
• Brakerski, Gentry, Vaikuntanathan, “Fully Homomorphic Encryption without Bootstrapping” (BGV) — https://eprint.iacr.org/2011/277
• Fan, Vercauteren, “Somewhat Practical Fully Homomorphic Encryption” (BFV) — https://eprint.iacr.org/2012/144
• Chillotti, Gama, Georgieva, Izabachène, “TFHE: Fast Fully Homomorphic Encryption over the Torus” — https://eprint.iacr.org/2018/421
• OpenFHE library and documentation — https://www.openfhe.org/
• Microsoft SEAL — https://github.com/microsoft/SEAL
• Apple, “Swift Homomorphic Encryption” and Live Caller ID Lookup — https://github.com/apple/swift-homomorphic-encryption
• Apple Security Research, “Combining Machine Learning and Homomorphic Encryption in the Apple Ecosystem” — https://machinelearning.apple.com/research/homomorphic-encryption
• Zama, “fhEVM and TFHE-rs” — https://www.zama.ai/
• Homomorphic Encryption Standardization (security parameter tables) — https://homomorphicencryption.org/
• DARPA, “Data Protection in Virtual Environments (DPRIVE)” — https://www.darpa.mil/program/data-protection-in-virtual-environments