The only number that matters in Google's homomorphic encryption push is 10-50x, and it is unlabelled

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].