Published Build3 min read
Encrypted inference stopped being a research question. Now it is a budget question.
A practical guide argues homomorphic encryption is in production pipelines. The useful decision is no longer whether CKKS runs, but whether its depth and packing math fit your model.
Written for builders.See today for builders

What happened
- 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.
- The guide asserts homomorphic encryption has crossed from conference papers into production pipelines: banks screen transactions against encrypted watchlists and hospitals run diagnostic models on data that never leaves their custody.
- The guide states that in August 2026 Google announced private AI features built on the same primitives.
- The guide describes the present moment as sixteen years after Gentry's 2009 result.
- In a homomorphic scheme, operations on ciphertexts correspond to operations on plaintexts, so Enc(a) combined with Enc(b) yields Enc(a + b); the server can add, multiply and combine encrypted values and return an encrypted result, and only the client holding the key decrypts.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
A practical guide published on dev.to puts homomorphic encryption in the past tense: banks screening transactions against encrypted watchlists, hospitals running diagnostic models on data that never leaves their custody, and, according to the same piece, a Google announcement in August 2026 of private AI features built on the same primitives [2][3]. If that is roughly the state of play, the question in front of a team has moved, and the guide says so itself: the thing that decides whether a private inference pipeline is worth building is the cost model, not the possibility proof [18].
The history explains why the arithmetic is the whole argument. Craig Gentry showed in 2009 that computing on encrypted data without decrypting it was possible, and the result was widely treated as a theoretical curiosity [1]. His construction had two halves: bootstrapping, in which a server homomorphically evaluates a sufficiently shallow decryption circuit to produce a fresh ciphertext with reset noise, and a scheme whose decryption circuit was shallow enough to actually do that [9]. Early bootstrapping took minutes per operation [10].
The reason there is a budget at all is noise. These schemes work over polynomial rings, where plaintexts are small polynomials and ciphertexts are pairs of larger ones, and security comes from an error term that grows with every operation; multiply too many times and the noise drowns the message [8]. That is the opposite of what a conventional cipher does. In AES, flipping one plaintext bit changes roughly half the output bits, and the ciphertext's algebraic structure has no relationship to the plaintext's, so there is no way to add two AES ciphertexts at all [7].
Which scheme you pick sets the shape of the bill. BGV and BFV do exact integer arithmetic [11]. TFHE, also known as CGGI, works over encrypted bits and is fast enough for small circuits such as database lookups and comparisons [12]. CKKS, published by Cheon, Kim, Kim and Song in 2017, does approximate arithmetic on encrypted real numbers with a noise budget that behaves like floating-point error [13] - eight years after Gentry's paper [16]. The fit for machine learning is not aesthetic: networks already tolerate small numerical error, so a scheme that presents noise as precision loss stops fighting the workload [14].
The counterweight to depth cost is packing. A CKKS ciphertext is not one number but a vector of hundreds of slots [15], which means the per-value cost of an operation is the ciphertext cost divided by the number of slots you actually fill [20]. A batched, wide layer amortises well. A latency-bound single query on a deep network does not, and that is where a multiplier becomes a product decision rather than an implementation detail.
Two cautions about the source. The supplied text breaks off mid-sentence in the packing discussion and never reaches the promised cost model, so no multiplier figures are in evidence here [19]. And its own dates do not line up: sixteen years after 2009 is 2025, not the August 2026 it attributes to Google [17].
Worth watching: whether vendors start publishing multiplicative depth budgets, bootstrap counts per inference, and slot utilisation, instead of a single hand-tuned latency number. Those three figures are the cost model. Anything else is a demo [18].
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
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.
- [2]
The guide asserts homomorphic encryption has crossed from conference papers into production pipelines: banks screen transactions against encrypted watchlists and hospitals run diagnostic models on data that never leaves their custody.
- [3]
The guide states that in August 2026 Google announced private AI features built on the same primitives.
- [4]
The guide describes the present moment as sixteen years after Gentry's 2009 result.
- [5]
In a homomorphic scheme, operations on ciphertexts correspond to operations on plaintexts, so Enc(a) combined with Enc(b) yields Enc(a + b); the server can add, multiply and combine encrypted values and return an encrypted result, and only the client holding the key decrypts.
- [6]
The server learns nothing about the inputs, intermediate values or output; for inference, the model owner never exposes weights and the data owner never exposes the query.
Sources & coverage · 1 publisher
The reporting this story was synthesized from, earliest first. Every link goes to the original.
- dev.toChen YuanAug 15Private AI Inference with Homomorphic Encryption: A Practical Guide to Computing on Encrypted Data
Cited in this coverage: dev.to guide, Private AI Inference with Homomorphic Encryption
Cited in this coverage: dev.to guide
Cited in this coverage: dev.to guide, supplied excerpt

