Homomorphic Encryption for ML

9 min read

Learn

Quick Reading

Estimated 9 mins

Prereq

Intermediate

Basic ML concepts helpful

Interactive

Static Playbook

Static guide & reference tables

Computing on data without ever seeing it

Most privacy-preserving ML techniques protect data by limiting what a trained model can reveal about it afterward. Homomorphic encryption (HE) takes a more radical approach: it allows mathematical operations to be performed directly on *encrypted* data, producing an encrypted result that, when decrypted, matches the result of performing those operations on the original plaintext — without the computing party ever having access to the unencrypted values at any point. A cloud provider could run inference on a hospital's encrypted patient data and return an encrypted prediction, never seeing a single real value in between.

Partial vs fully homomorphic encryption

Encryption schemes differ in which operations they support on ciphertexts. Partially homomorphic encryption (PHE) supports only one operation type indefinitely — e.g. the Paillier cryptosystem supports unlimited addition on ciphertexts, RSA supports unlimited multiplication, but neither supports both. Fully homomorphic encryption (FHE), first constructed by Craig Gentry in 2009, supports arbitrary computation — both addition and multiplication, and therefore (in principle) any function expressible as a circuit — on encrypted data. Gentry's breakthrough made FHE theoretically possible, but the original scheme was many orders of magnitude too slow for practical use, which is why FHE has spent over a decade being optimized toward practicality rather than deployed outright.

paillier_partial_he_demo.py

python

# Conceptual demo: Paillier encryption supports homomorphic ADDITION only.
# (Using a real library like python-paillier in practice; this illustrates the property.)

from phe import paillier  # pip install phe

public_key, private_key = paillier.generate_paillier_keypair()

a = public_key.encrypt(15)
b = public_key.encrypt(27)

encrypted_sum = a + b                      # addition happens WITHOUT decrypting a or b
result = private_key.decrypt(encrypted_sum)
print(result)  # 42 — correct, despite the server/computing party never seeing 15 or 27

The performance tax is still enormous

FHE schemes like BGV, BFV, and CKKS have brought massive speedups relative to Gentry's original construction, but FHE inference on even a modest neural network can still be several orders of magnitude slower than plaintext inference, and operations like non-linear activations (ReLU, softmax) are expensive or require approximation since FHE natively handles polynomial operations cleanly but struggles with arbitrary non-linearities. This is why FHE-based ML today is mostly deployed for small, carefully-optimized models on narrow tasks (e.g. encrypted logistic regression scoring) rather than large neural networks end-to-end.

Homomorphic encryption vs other privacy techniques

Technique	What's protected	Performance cost
Fully homomorphic encryption	Data never decrypted during computation	Extremely high (orders of magnitude slowdown)
Differential privacy	Bounds leakage about individuals in outputs	Moderate (noise reduces utility, not raw speed)
Secure multi-party computation	No single party sees the full data	High (communication rounds between parties)
Federated learning (alone)	Raw data stays on-device	Low, but gradients can still leak information

Approximation schemes: CKKS and approximate FHE

For machine learning specifically, the CKKS scheme has become particularly influential because it supports approximate arithmetic over real and complex numbers — a better fit for neural network weights and activations than schemes designed for exact integer arithmetic. CKKS trades exactness for efficiency: results carry a small, bounded numerical error, acceptable for ML inference where exact bit-for-bit precision was never required anyway (floating point already involves approximation). This makes CKKS the scheme behind most practical FHE-for-ML research and tooling, such as Microsoft SEAL and OpenFHE.

Where HE is actually used today

Given the performance cost, production use of homomorphic encryption for ML is still narrow: encrypted search over medical or genomic databases, privacy-preserving scoring in advertising and finance where a single party must never see a competitor's or customer's raw data, and secure aggregation steps within larger federated learning systems. It is rarely the sole technique in a privacy-preserving pipeline — more often combined with differential privacy or secure multi-party computation, each covering a different part of the threat model, since no single technique at today's performance level handles every stage of a large ML system end-to-end.

What's Next?

Homomorphic encryption protects data from the party doing the computing; a closely related but distinct problem is enabling multiple parties, none of whom fully trust each other, to jointly compute a result without any one of them seeing the others' inputs at all — the domain of secure multi-party computation.

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →