Homomorphic Encryption for Machine Learning: CKKS, TFHE and Secure Aggregation

A hospital wants a vendor’s model to score patient records, and the vendor refuses to ship the weights. The vendor, in turn, does not want the raw records on its servers. Encryption in transit and at rest solves neither problem, because the model has to see plaintext at the moment of computation. Homomorphic encryption machine learning attacks that last unprotected moment: the server computes on ciphertexts and never holds a key that can read them.

The idea has been theoretically solved since Gentry’s 2009 construction, and practically annoying ever since. Overheads of three to six orders of magnitude over plaintext are normal, and the right scheme depends on whether your model is mostly matrix multiplication or mostly comparisons. Meanwhile a much cheaper cousin, secure aggregation, quietly protects federated learning at very large scale. Knowing which tool answers which threat is the real skill.

What this covers: how BFV/BGV, CKKS and TFHE differ, where noise and bootstrapping dominate cost, how SIMD packing turns a dot product into one operation, what encrypted inference costs, how threshold FHE and the Bonawitz secure aggregation protocol work, how all of this compares with TEEs and differential privacy, which libraries to use, and two runnable Python examples.

Context and Background

Three families of privacy technology compete for the same budget. Trusted execution environments (TEEs) protect data in use by trusting hardware and an attestation chain; we covered that trade in confidential AI inference with TEEs and confidential GPUs. Differential privacy (DP) limits what a released output or model can reveal about any one individual, which we examined in DP-SGD, Opacus and privacy budgets. Cryptographic approaches, meaning homomorphic encryption and multiparty computation, protect the data itself by mathematics rather than by hardware trust or statistical noise.

Fully homomorphic encryption (FHE) lets anyone holding only the public evaluation keys apply arbitrary circuits to ciphertexts. Gentry’s 2009 scheme proved it possible. The second generation, BGV (Brakerski-Gentry-Vaikuntanathan) and BFV (Brakerski/Fan-Vercauteren), based security on the Ring Learning With Errors (RLWE) problem and introduced batching. The CKKS scheme (Cheon, Kim, Kim and Song, Asiacrypt 2017) added approximate arithmetic over real numbers, which is what machine learning wants. TFHE (Chillotti, Gama, Georgieva and Izabachene) took a different route: fast bootstrapping of a single encrypted bit or small integer, evaluated gate by gate or as a lookup table.

The security foundation is lattice-based and, as far as is publicly known, resists quantum attackers. Parameter selection follows the community’s HomomorphicEncryption.org security standard, which tabulates the maximum ciphertext modulus for a given ring dimension and security level; the standard’s tables are the reference every serious library cites when it ships default parameters.

Practical interest has three drivers in 2026. First, regulators in finance and health increasingly distinguish between “data processed under a contract” and “data the processor cannot read.” Second, GPU implementations of CKKS and TFHE have narrowed overheads enough that some inference workloads are tolerable. Third, federated learning needs aggregation that does not leak individual updates, and secure aggregation provides that cheaply. None of this makes FHE a default: it remains the most expensive option on the menu, and most deployed “private ML” today is DP, TEEs, or secure aggregation, with FHE reserved for narrow high-value paths.

Core Argument: Pick the Scheme by the Shape of the Computation

A neural network is a pipeline of linear algebra and nonlinearities. FHE schemes are good at one of those and bad at the other. CKKS is efficient at batched real-valued linear algebra and polynomial approximations, but weak at comparisons. TFHE is efficient at comparisons and arbitrary univariate functions via lookup tables, but weak at wide multiplications. BFV and BGV sit between them for exact integer SIMD. Choosing a scheme is therefore choosing which half of your model is cheap.

Figure 1: The encrypted inference loop. The server never sees a key capable of decryption, but every multiplication consumes noise budget that rescaling or bootstrapping must restore.

The figure shows the lifecycle. The client encodes its feature vector into polynomial slots, encrypts under its public key, and sends the ciphertext. The server evaluates the model, using plaintext weights (cheap, protects the client) or encrypted weights (expensive, protects both parties). Results return encrypted, and only the client’s secret key opens them. Everything interesting happens in the dotted loop: noise.

BFV and BGV: exact modular integers

Both schemes work over a plaintext ring of integers modulo a plaintext modulus t, with polynomial degree N typically a power of two such as 2^13 to 2^16. A ciphertext is a pair of polynomials modulo a large coefficient modulus Q. Each ciphertext carries a small error term injected for security. Addition adds the errors; multiplication multiplies them, so noise grows roughly multiplicatively with depth. BGV manages this by switching to a smaller modulus after each multiplication (modulus switching), while BFV scales the product and defers the management; the two end up with similar capability and different engineering ergonomics.

The strength of BFV and BGV is exactness. Counting, set intersection, private information retrieval, and integer-quantized models give identical answers to plaintext. The weakness is that there is no natural way to represent fractions, so floating-point models must be quantized, and quantization error shows up in accuracy rather than in the cryptography.

CKKS: approximate arithmetic as a feature

CKKS treats the encryption error as part of the number. A real value m is encoded as an integer scaled by a factor Delta (for example 2^40), and decryption returns m plus a tiny error, exactly like floating point rounding. After a multiplication the scale becomes Delta squared, so the scheme performs a rescale that divides by one prime of the modulus chain, restoring scale and discarding a level. A chain of L primes therefore allows about L multiplicative levels before bootstrapping.

That design is the reason the CKKS scheme dominates encrypted machine learning. A ciphertext with N = 2^15 holds N/2 = 16,384 complex slots, so a single homomorphic multiplication performs thousands of multiplications at once. Matrix-vector products use rotations, which are slot permutations implemented through Galois automorphisms and key switching, and rotations are the expensive primitive in practice. Many published speedups are really rotation-count reductions through diagonal encodings and baby-step giant-step decompositions.

CKKS has a subtle security caveat. Because decryption is approximate, the result reveals the error. Li and Micciancio showed in 2021 that sharing decrypted CKKS outputs with a party who knows the plaintext can leak key material, which is the IND-CPA-D problem. Libraries have since added noise flooding, so any protocol that decrypts and shares results must use a version with that defense and must be reviewed for it. This is a real deployment gotcha, not an academic footnote.

TFHE: bootstrapping every gate

TFHE encrypts a small message (a bit, or a few bits) under Learning With Errors (LWE) ciphertexts and performs a programmable bootstrap after each operation. The bootstrap resets noise to a fixed level and, in the same step, applies an arbitrary lookup table to the message. This is a superpower for ML: a ReLU, a sign function, or an argmax comparison is one table lookup, with no polynomial approximation and no accuracy loss from approximating the activation.

The price is that each bootstrap is a heavy operation, and ciphertexts hold one scalar rather than thousands of SIMD slots. TFHE therefore has high per-element cost and excellent latency for deep, branchy, small-width circuits such as decision trees, quantized low-bit networks, and comparison-heavy logic. Zama’s open-source stack builds on this and exposes it to ML engineers through Concrete ML. The practical constraint is precision: with current parameters, table lookups work on messages of roughly a handful of bits, so models must be quantized aggressively, typically to a few bits for activations.

Deeper Analysis: Noise, Bootstrapping, Packing and What Inference Costs

Noise budget as a resource

Treat noise like fuel. Each ciphertext starts with a budget determined by the ratio of the modulus to the noise. Additions burn almost none. Multiplications burn a lot. Rotations burn a small amount through key switching. When the budget hits zero, decryption yields garbage, silently. There is no error code, which is why encrypted pipelines need a static analysis of multiplicative depth before deployment, not a runtime check.

A worked, illustrative example: a two-layer MLP with a square activation after each hidden layer has multiplicative depth of roughly one per linear layer (plaintext-weight multiplication consumes one level in CKKS because of the rescale) plus one per square. Three nonlinear stages in a small model therefore need on the order of 6 to 8 levels. With 40-bit primes that is a modulus of roughly 300 bits, which for 128-bit security forces N toward 2^14 or 2^15 according to the standard’s tables. Doubling N doubles the ciphertext size and slightly more than doubles every operation, so depth directly sets cost. Reducing depth by one level is often worth more than any low-level optimization.

Figure 2: Scheme selection by computation shape. Linear-heavy models favor CKKS with sparing bootstrapping, while comparison-heavy models favor TFHE with a bootstrap at every nonlinear step.

Bootstrapping: the cost cliff

Bootstrapping homomorphically evaluates the decryption circuit to refresh a ciphertext, turning a leveled scheme into a fully homomorphic one. In CKKS it is approximate and complex: it raises the modulus, evaluates a polynomial approximation of modular reduction, and returns a ciphertext with restored levels at the cost of some precision. On a CPU it typically takes seconds for large parameter sets, and GPU implementations bring it into the tens-to-hundreds of milliseconds range (illustrative orders of magnitude; consult the OpenFHE and GPU-library benchmark pages for your exact parameters and hardware). A model deep enough to need multiple CKKS bootstraps per inference is usually a model to avoid encrypting end to end.

TFHE’s bootstrap is far cheaper per operation, on the order of milliseconds on a CPU core for a single-bit gate in the original papers, and its programmable form does useful work during the refresh. But you pay it once per nonlinear element rather than once per ciphertext of thousands of slots. The break-even depends on the ratio of linear to nonlinear work: wide layers favor CKKS because one bootstrap amortizes across thousands of slots, narrow decision logic favors TFHE.

The honest framing is that no scheme wins. Hybrid designs exist, such as scheme switching, which converts CKKS ciphertexts to TFHE for the activation and back. They work, but conversion costs and engineering complexity are non-trivial, and few production systems use them yet.

SIMD packing and the dot product

Packing is where the multiplicative speedup comes from. A single CKKS ciphertext holds a vector of N/2 values. Element-wise multiplication of two packed vectors is one homomorphic multiplication. A dot product of length n is one multiplication, followed by a sum across slots computed with log2(n) rotate-and-add steps. For n = 1,024 that is one multiplication plus ten rotations, versus 1,024 multiplications in a scalar scheme.

Matrix-vector multiplication, the heart of a fully connected layer, uses the diagonal method: a d by d matrix is stored as d generalized diagonals, each multiplied by a rotated copy of the input and summed. That costs d rotations and d plaintext multiplications. Baby-step giant-step reduces rotations from d to about 2 times the square root of d; for d = 1,024 that is roughly 64 rotations instead of 1,024. Because rotations dominate the runtime, this single algorithmic idea is often a 10x to 16x improvement before any hardware tuning.

Convolutions follow the same pattern by flattening images and using rotations to realize sliding windows. Frameworks such as the compiler-based approaches in Microsoft’s EVA, Intel’s HE toolkit and Google’s HEIR automate these layouts, which matters because choosing a bad packing layout can erase an order of magnitude of performance.

Encrypted inference cost: orders of magnitude, not benchmarks

I will avoid quoting a single “FHE is N times slower” figure, because the number depends on model, parameters, threads and hardware. Treat the following as illustrative orders of magnitude for planning only. Plaintext inference of a small CNN on CPU takes about a millisecond. The same network under CKKS with plaintext weights on one CPU typically lands in the range of seconds to tens of seconds, a factor of roughly 10^3 to 10^4. With GPU acceleration it may fall to hundreds of milliseconds to a few seconds. Large transformer-scale inference is a different story: published research prototypes of encrypted transformer inference exist, but the latencies are minutes per short sequence on current systems, and attention’s softmax and layer normalization are the hard parts because they need accurate polynomial approximations over wide input ranges.

Memory is the quieter constraint. A single CKKS ciphertext at N = 2^16 with several hundred bits of modulus can be tens of megabytes, and rotation keys are of similar size each. A model needing dozens of distinct rotation indices carries hundreds of megabytes to gigabytes of evaluation keys, which the client must upload once and the server must hold. Bandwidth and key storage, not arithmetic, are the first thing teams hit in a pilot.

Threshold and multiparty FHE

A single secret key held by the client is the simple model: the client encrypts, the server computes, the client decrypts. Real systems often have several data owners who want a joint result without any one of them holding the key to everyone’s data. Threshold or multiparty FHE (MPHE) splits the secret key among parties such that decryption needs a quorum (or all of them), and a collective public key is generated by combining each party’s contribution. Each party then encrypts under the collective key, the server computes, and the parties produce partial decryption shares that combine into the plaintext.

Lattigo, a Go library from Tune Insight, was designed around exactly this multiparty setting, and OpenFHE has added threshold features for several schemes. The costs are an interactive setup phase, one extra communication round at decryption, and a hard requirement for noise flooding in the partial decryptions to avoid leaking the secret key shares. The model is attractive for consortia such as hospitals or banks that cannot centralize data but can tolerate a few synchronous rounds.

Secure Aggregation: The Cheap Cryptography That Actually Ships

Secure aggregation solves a narrower problem than FHE. In federated learning, many clients each compute a model update, and a server needs only the sum or average. The privacy goal is that the server learns nothing about any individual update beyond what the sum implies. No client needs to compute on another’s ciphertext, and nobody needs bootstrapping. The result is overhead measured in small multiples rather than orders of magnitude, which is why it deploys at phone scale while FHE does not.

Pairwise masking: the core trick

The mechanism rests on a simple algebraic identity. Every pair of clients i and j agrees on a shared random seed, usually through Diffie-Hellman key agreement. From the seed each derives the same pseudorandom mask vector. Client i adds the mask if i is less than j and subtracts it otherwise. Each client uploads its update plus the sum of its signed masks, all computed modulo a fixed integer such as 2^32. To the server, each upload is statistically indistinguishable from random noise. When the server sums all uploads, every mask appears once with a plus sign and once with a minus sign, so they cancel and the true sum emerges.

The elegance is that the server does no cryptography beyond addition. The cost lies on the client: each client derives n minus 1 mask vectors, so computation is linear in the number of participants times the vector length, which matters when a model update has tens of millions of entries.

The Bonawitz protocol and dropouts

Pure pairwise masking breaks when a client drops out after others have already masked against it, because its masks no longer cancel. Bonawitz and colleagues (Google, ACM CCS 2017, “Practical Secure Aggregation for Privacy-Preserving Machine Learning”) fixed this with Shamir secret sharing. Each client secret-shares its pairwise seeds with the others, so if it vanishes, a threshold of survivors can reconstruct the missing masks and remove them. The original paper frames the protocol in four rounds, which Figure 3 summarizes.

Figure 3: The Bonawitz secure aggregation rounds. Masked updates are summed so pairwise masks cancel, and secret shares let survivors reconstruct masks for dropped clients.

There is a second subtlety. If survivors reveal shares of a dropped client’s seeds, a malicious server could lie about who dropped and ask for both a client’s pairwise-seed shares and its personal-mask shares, which would expose that client’s raw update. The protocol therefore gives each client a second, personal random mask added to its update. For each other client, survivors reveal either the pairwise-seed share (if the client dropped) or the personal-mask share (if it survived), never both. This double-masking design is what makes the protocol secure against an honest-but-curious or actively malicious server within its stated thresholds.

The protocol’s costs are worth stating. Communication and server work are quadratic in the number of clients in the original design, which the authors noted limits practical group sizes to hundreds or low thousands per aggregation group. Later work (for example SecAgg+ and LightSecAgg) reduced this to polylogarithmic or near-linear overhead by using sparse communication graphs. I mention these as the direction of the literature; check the specific papers for exact asymptotics before relying on them.

What secure aggregation does not give you

It hides individual updates from the server, but the aggregate itself still leaks. With few clients, or with a client who knows the other clients’ data, the sum can reveal the target’s contribution. Model inversion and membership inference against the aggregate remain possible. Secure aggregation also does not stop a malicious client from poisoning the model with a crafted update, and masking hides exactly the evidence a robust-aggregation defense would inspect. This is why serious deployments pair secure aggregation with differential privacy: the clients add calibrated noise before masking, so the revealed sum is itself private. Our differential privacy walkthrough covers the budget accounting for that combination.

A runnable toy

The snippet below implements pairwise additive masking with simulated shared seeds (a real system derives them with key agreement and adds secret sharing for dropouts). It demonstrates the cancellation property and the fact that an individual masked upload looks random. It has been run with NumPy 2.x.

import numpy as np

MOD = 2**32

def make_seeds(n, seed=7):
    # Stand-in for pairwise Diffie-Hellman agreement between users i < j
    rng = np.random.default_rng(seed)
    return {(i, j): int(rng.integers(0, 2**63))
            for i in range(n) for j in range(i + 1, n)}

def mask_update(i, x, n, seeds):
    y = x.copy() % MOD
    for j in range(n):
        if j == i:
            continue
        a, b = (i, j) if i < j else (j, i)
        m = np.random.default_rng(seeds[(a, b)]).integers(
            0, MOD, size=len(x), dtype=np.uint64)
        y = (y + m) % MOD if i < j else (y - m) % MOD
    return y.astype(np.uint64)

n, dim = 5, 4
rng = np.random.default_rng(1)
updates = [rng.integers(0, 1000, size=dim).astype(np.uint64) for _ in range(n)]
seeds = make_seeds(n)
masked = [mask_update(i, updates[i], n, seeds) for i in range(n)]

server_sum = sum(m.astype(object) for m in masked) % MOD
true_sum = sum(u.astype(object) for u in updates) % MOD
print("masked[0]:", masked[0], " true[0]:", updates[0])
assert list(server_sum) == list(true_sum)   # masks cancel exactly
print("aggregate:", list(server_sum))

Running it prints a masked vector of large pseudorandom integers for client 0, alongside the small true update, and the assertion confirms the server recovers exactly the true sum. Real models use fixed-point encodings of floats modulo 2^k, with clipping so the sum cannot overflow the modulus.

Libraries in 2026: What to Use and What State They Are In

Library choice follows from scheme choice, language, and whether you need GPU or multiparty support. I checked release tags and package indexes on 31 October 2026; versions move quickly, so confirm before pinning.

Library	Schemes	Language	Notes	Version observed
OpenFHE	BGV, BFV, CKKS, TFHE-style functional bootstrapping, scheme switching, threshold	C++ (Python bindings)	Broadest scheme coverage; builds on the PALISADE lineage	git tag v1.6.1; PyPI openfhe 1.6.1.0.24.4
Microsoft SEAL	BFV, BGV, CKKS	C++	Well-documented, no bootstrapping for CKKS	git tag v4.7.2
TenSEAL	CKKS, BFV via SEAL	Python/C++	Tensor-level API aimed at ML prototypes	PyPI 0.3.18
TFHE-rs	TFHE, integer and boolean APIs	Rust	Zama; GPU and HPU backends are documented by the vendor	crates.io 1.8.2
Concrete / Concrete ML	TFHE compiler; scikit-learn style models	Python/Rust	Compiles quantized models to TFHE circuits	concrete-python 2.11.0 on PyPI, dated July 2025, so check for a newer release
Lattigo	BGV, BFV, CKKS, multiparty	Go	Native multiparty protocols	git tag v6.2.0

Two caveats. SEAL’s CKKS has no bootstrapping, so depth is capped by the modulus chain; if your model is deeper, move to OpenFHE or Lattigo. And TenSEAL, though convenient, is a thin wrapper over SEAL and inherits its limits; treat it as a prototyping tool and review its CKKS noise-flooding behavior before exposing decrypted outputs to adversaries.

A runnable CKKS dot product with TenSEAL

This example encrypts a feature vector and computes a dot product against plaintext weights, the core of an encrypted logistic regression or linear layer. It ran successfully with TenSEAL 0.3.18.

import tenseal as ts

ctx = ts.context(ts.SCHEME_TYPE.CKKS,
                 poly_modulus_degree=8192,
                 coeff_mod_bit_sizes=[60, 40, 40, 60])
ctx.global_scale = 2**40
ctx.generate_galois_keys()          # needed for rotations inside dot()

x = [0.5, -1.2, 3.0, 0.1]           # client features
w = [0.3, 0.8, -0.5, 2.0]           # server plaintext weights

enc_x = ts.ckks_vector(ctx, x)      # client encrypts
enc_y = enc_x.dot(w)                # server computes on ciphertext
print(enc_y.decrypt())              # approx -2.11, error near 1e-7

The plaintext answer is 0.15 minus 0.96 minus 1.5 plus 0.2, which is minus 2.11, and the decrypted result differs only in the seventh decimal place, which is the approximation CKKS promises. Note what the middle coefficient list means: the two 40-bit primes are the multiplicative levels available, matching the 2^40 scale. The 60-bit end primes hold the special modulus and the final precision. In a real deployment the secret key stays with the client and the server receives a public copy of the context (call ctx.make_context_public()), so the server cannot decrypt.

Comparing FHE, TEEs, Differential Privacy and MPC

The question is never “which privacy technology is best” but “which adversary am I defending against.” Each technology has a different threat model, and conflating them is the commonest architectural mistake.

Figure 4: Mapping the adversary to the technique. FHE or MPC is chosen when the hardware vendor and the operator are both untrusted, while secure aggregation plus DP covers federated learning.

Property	FHE	TEE (confidential GPU/CPU)	Differential privacy	Secure aggregation
Protects	Input and output confidentiality from the compute operator	Data and model in use from host and operator	Individuals in the training set or the output	Individual client updates from the server
Trust assumption	Math only (lattice hardness)	Hardware vendor and attestation chain	None for the guarantee; trust in accounting code	Honest majority or threshold, per protocol
Overhead (illustrative)	10^3 to 10^6 times	Low single-digit percent to tens of percent	Accuracy loss rather than runtime	Small constant to moderate factor
Handles training	Rarely, very expensive	Yes	Yes (DP-SGD)	Yes, for federated aggregation
Main failure mode	Cost, noise budget, CKKS decryption leakage	Side channels, firmware bugs, attestation misuse	Weak epsilon, composition errors	Dropout handling, small-group leakage, poisoning

The table makes the complementarity clear. TEEs are the only option today for running large models at near-native speed over confidential data, but they put the hardware vendor in your trust base. FHE removes that trust at a cost that confines it to small models and narrow queries. DP protects against what the output reveals, which neither FHE nor TEEs address: an FHE server can return a perfectly encrypted answer that still leaks a training record through memorization. That is why supply-chain and provenance controls matter alongside these protocols, as we discussed in AI model supply chain security and provenance.

A reasonable layered design

For a cross-hospital risk model: each hospital trains locally with DP-SGD; updates are masked by secure aggregation so the coordinator sees only the noisy sum; the final model is served inside a TEE for latency, or, for the most sensitive queries from external parties, evaluated under CKKS with the client holding the key. Each layer answers a distinct adversary. No single layer is asked to do everything.

Trade-offs, Gotchas, and What Goes Wrong

Silent decryption failure. Exhausted noise budget produces plausible-looking garbage. Test with known-answer vectors at the maximum expected depth and input magnitude, and add canary ciphertexts of known plaintext to production pipelines.

Activation approximation error. CKKS has no native ReLU or softmax. Low-degree polynomial replacements work on bounded inputs and diverge outside the fitted range. A model trained with ordinary ReLU and converted afterward often loses accuracy; training with the polynomial activation (and input clipping or normalization) in the loop is the standard fix. Unbounded activations in transformers are the reason encrypted large language model inference stays a research topic.

Parameter misconfiguration. Hand-picked parameters that violate the standard’s tables for the chosen security level produce a system that runs fine and is insecure. Use library-provided parameter presets, and never reduce N to fit memory without recomputing the modulus bound.

The IND-CPA-D trap. As noted, releasing CKKS decryptions to a party who can compare them with known plaintexts can leak keys unless the library applies noise flooding. Cheon and colleagues have also published attacks of similar flavor on exact schemes, so the safe stance is to treat any decryption oracle as a threat surface.

Metadata leakage. FHE hides values, not shapes. Ciphertext sizes, access patterns, circuit structure, and timing reveal the model architecture and sometimes input length. If the model is the secret, FHE with plaintext weights protects only the input.

Malicious server. Standard FHE gives confidentiality against an honest-but-curious evaluator, not integrity. A cheating server can return a wrong ciphertext and the client cannot tell. Verifiable computation is a separate and still immature layer.

Secure aggregation anti-patterns. Running it with groups of fewer than a few dozen clients, which makes the sum nearly as revealing as an individual update; treating it as a defense against poisoning; and omitting DP, leaving the aggregate open to inversion.

Operational cost. Key management for evaluation keys, rotation of keys on a schedule, and the sheer size of ciphertexts turn up in every pilot. Budget for network egress, not just compute.

Practical Recommendations

Start by writing down the adversary and the data flow. If the only concern is that a federated server sees individual updates, deploy secure aggregation plus DP and stop; that combination is mature and cheap. If the concern is a cloud operator who must not see inputs, ask first whether a TEE meets your assurance requirements, because it will be orders of magnitude cheaper. Reach for FHE when hardware trust is unacceptable by policy or contract, the model is small enough to evaluate in seconds, and the output is low-dimensional (a score, a class, a ranking).

When you do choose FHE, work backwards from depth and size. Design the model for encryption from the start: use square or low-degree polynomial activations, avoid layer norm over wide ranges, fold batch normalization into weights, and quantize for TFHE if the workload is comparison heavy. Prototype with TenSEAL or Concrete ML to learn the shape of the costs, then move to OpenFHE, Lattigo or TFHE-rs for production features such as bootstrapping, multiparty keys, or GPU backends.

Define the adversary (operator, other clients, output consumer) before choosing a technique.
Compute multiplicative depth and rotation count on paper; set N and the modulus chain from library presets that meet the 128-bit standard tables.
Test at maximum depth with known-answer vectors; monitor for silent decryption failure.
Use noise flooding whenever decrypted results leave the trust boundary.
For federated learning, combine secure aggregation with DP and a minimum cohort size.
Measure on your hardware; treat every overhead figure in public write-ups, including those here, as illustrative.

This article is a technical systems analysis, not legal, compliance or financial advice.

Frequently Asked Questions

What is homomorphic encryption in machine learning?

It is a family of encryption schemes that let a server run model inference, and in limited cases training steps, directly on encrypted data. The server returns an encrypted result that only the data owner can decrypt. In practice CKKS handles batched real-valued linear algebra, TFHE handles comparisons and lookup-table activations, and BFV or BGV handle exact integer workloads. The tradeoff is large compute, memory and bandwidth overhead compared with plaintext processing.

Is fully homomorphic encryption practical in 2026?

For small models, tabular classifiers, decision trees, and linear or shallow neural networks, yes, with latency from hundreds of milliseconds to seconds on modern hardware, especially with GPU backends. For large transformers, it is still mostly research. Practicality depends on multiplicative depth, ciphertext size and whether you can tolerate key-material bandwidth. Most production private ML combines cheaper tools such as TEEs, differential privacy and secure aggregation, and uses FHE for narrow high-sensitivity paths.

What is the difference between CKKS and TFHE?

CKKS packs thousands of real numbers into one ciphertext and computes approximately, making matrix products efficient but comparisons awkward. TFHE encrypts small values and applies a programmable bootstrap after each operation, so non-linear functions such as ReLU are a single lookup and noise never accumulates, but throughput per element is lower. Choose CKKS for wide linear layers and TFHE for deep, comparison-heavy, low-precision logic.

How does secure aggregation differ from homomorphic encryption?

Secure aggregation lets a server compute only a sum of client vectors without seeing any one of them, using pairwise random masks that cancel when added. It requires no computation on ciphertext, so overhead is small. Homomorphic encryption lets a server evaluate arbitrary circuits. Secure aggregation suits federated learning, while FHE suits outsourced inference. They can be combined, and additively homomorphic schemes are sometimes used as an alternative way to aggregate updates.

Does homomorphic encryption replace differential privacy?

No. FHE protects data while it is being processed, but it does not limit what the decrypted output reveals about training data. A model trained on sensitive records can memorize them even if inference is perfectly encrypted. Differential privacy bounds that leakage with a mathematical budget. Many designs use both: DP for the model and its outputs, FHE or secure aggregation for protecting inputs and updates in transit through computation.

Which library should I start with?

For Python prototyping of CKKS, TenSEAL gives a tensor API in minutes. For production features such as CKKS bootstrapping, scheme switching and threshold keys, OpenFHE has the broadest coverage. For TFHE with an ML workflow, Zama’s Concrete ML compiles quantized scikit-learn style models, and TFHE-rs is the Rust library underneath. For multiparty FHE in Go, Lattigo is purpose-built. Always verify the current release and the security presets before pinning versions.

Homomorphic Encryption for Machine Learning: FHE, CKKS, TFHE and Secure Aggregation Compared (2026)