In 2009, Craig Gentry proved that it is possible to compute on encrypted data without ever decrypting it, and the result was widely treated as a theoretical curiosity.
Sixteen years later, homomorphic encryption has crossed from conference papers into production pipelines: banks screen transactions against encrypted watchlists, hospitals run diagnostic models on data that never leaves their custody, and in August 2026 Google announced private AI features built on the same primitives.
The gap between "possible in theory" and "usable in practice" is still wide, but it is no longer an argument against trying.
This guide walks through what homomorphic encryption actually computes, how the CKKS scheme turns encrypted vectors into a workable substrate for machine learning, and the cost model that decides whether a private inference pipeline is worth building at all.
The Promise: Compute Without Reading Ordinary encryption has a hard property: a ciphertext reveals nothing about the plaintext.
AES-CTR, ChaCha20, RSA — all of them scramble data so thoroughly that an attacker holding the ciphertext and a supercomputer cannot recover the message without the key.
That property is also the problem.
If a server stores customer data encrypted at rest, every query requires shipping the data (or the key) somewhere a human or a process can read it.
The moment the data is decrypted for computation, the confidentiality boundary moves from the storage layer to the memory of whatever process is doing the work.
Homomorphic encryption changes the terms.
A homomorphic scheme is one where operations on ciphertexts correspond to operations on plaintexts: .
A server can add, multiply, and combine encrypted values and return the encrypted result, and the client — the only party holding the key — decrypts the final answer.
The server learns nothing about the inputs, the intermediate values, or the output.
For inference, this is the entire ballgame: the model owner never exposes weights, and the data owner never exposes the query.
Why Plain Encryption Breaks Computation To see why this is hard, consider what AES does to a single byte.
The S-box substitution and the ShiftRows/MixColumns rounds mix the input so completely that flipping one plaintext bit changes roughly half the output bits.
That avalanche effect is what makes AES secure, and it is exactly what makes it unusable for computation.
There is no way to run on AES ciphertexts because the algebraic structure of the ciphertext has no relationship to the algebraic structure of the plaintext.
Fully homomorphic encryption takes the opposite approach.
Instead of starting with a scrambling cipher and hoping arithmetic survives, it starts with an algebraic structure that naturally supports both operations.
The classic construction works over polynomial rings: plaintexts are small polynomials, ciphertexts are pairs of larger polynomials, and addition and multiplication in the ring map to addition and multiplication of the encrypted messages.
Security comes not from destroying structure but from noise — every operation grows a random error term that must stay small enough for decryption to still recover the message.
Multiply too many times and the noise drowns the signal.
From Gentry's Bootstrapping to CKKS Gentry's 2009 breakthrough had two parts.
The first was the observation that a scheme with bounded noise can still be made unbounded: if the decryption circuit is shallow enough, the server can evaluate it homomorphically, producing a fresh ciphertext with reset noise.
That process, bootstrapping, was the theoretical missing piece.
The second part was a working scheme with a decryption circuit shallow enough to bootstrap.
The catch was performance — early bootstrapping took minutes per operation.
The decade after Gentry produced a family of practical schemes.
BGV and BFV handle encrypted integers with exact arithmetic.
TFHE (CGGI) works over encrypted bits and is fast enough for small circuits like database lookups and comparisons.
And CKKS, published by Cheon, Kim, Kim, and Song in 2017, introduced approximate arithmetic over encrypted real numbers, with a noise budget that behaves like floating-point error.
That last property is what made machine learning viable: neural networks already tolerate small numerical errors, so a scheme that treats noise as precision loss fits the workload instead of fighting it.
CKKS also inherits a trick called SIMD packing from its predecessors.
A single ciphertext in CKKS is not one number but a vector of hundreds of slots, and operations apply element-wise across the whole vector.
A dot product — the inner loop of almost every inference step — becomes one ciphertext multiplication and a few rotations instead of hundreds of separate operations.
How CKKS Works Under the Hood The construction is a polynomial ring , typically with or .
Plaintexts are polynomials of degree less than whose coefficients are the numbers you actually care about, scaled by a large factor and rounded.
The scale factor is the scheme's version of fixed-point arithmetic: it sets how many bits of fractional precision survive a multiplication.
After each multiply, the scale of the result grows, and the scheme provides a rescaling operation that brings it back down.
Noise is the real constraint.
Each addition adds noise linearly; each multiplication roughly squares it.
The scheme allocates a noise budget at encryption time, and every operation spends some of it.
When the budget hits zero, decryption produces garbage.
This is why parameter selection matters more in FHE than in any other part of a machine learning stack: the ring degree sets the maximum vector size and the top of the noise budget, the scale factor sets precision, and the multiplication depth you need sets how many levels the chain must provide before bootstrapping becomes necessary.
A minimal encrypted vector in Python, using a research-oriented binding, looks like this: That is the entire setup. is now a ciphertext the server can store, transform, and return without ever seeing the values inside.
A Minimal Private Inference Pipeline The classic private inference flow is split between a client that owns the data and a server that owns the model.
The client encrypts its input, the server evaluates the model homomorphically, and the client decrypts the result.
For a logistic regression — a single affine transform followed by a sigmoid — the encrypted computation is small enough to show in full: Three details matter here.
First, the sigmoid must be replaced by a polynomial approximation such as a Taylor or Chebyshev expansion, because CKKS supports only addition and multiplication.
Second, the approximation degree is a direct trade against the noise budget: every extra multiply spends a level.
Third, the whole vector of slots is processed in parallel, so one encrypted call classifies an entire batch of inputs, not a single sample.
For deeper networks, the same recipe repeats layer by layer: convolution becomes a sum of shifted and multiplied ciphertexts, ReLU becomes a polynomial like -based approximation or a TFHE-style comparison, and pooling becomes rotations plus additions.
The engineering problem is not expressing the model — it is keeping the depth inside the budget.
The Real Cost Model Homomorphic inference is slow, and the honest framing is to say how slow and why.
Ciphertexts are two or three orders of magnitude larger than the plaintexts they hold.
Multiplication on a packed ciphertext is roughly a thousand to ten thousand times more expensive than the equivalent plaintext float operation, depending on ring degree and security level.
Bootstrapping, when the noise budget runs out, costs on the order of tens of milliseconds to seconds per ciphertext — cheap enough to amortize over a packed batch, ruinous if applied per element.
The practical consequence is that private inference shifts the bottleneck from model quality to arithmetic budget.
A model that run