Homomorphic Encryption

Description

Homomorphic encryption lets a server compute on data that stays encrypted, so the server never sees the underlying values. The data owner encrypts the inputs, the server performs the arithmetic directly on the encrypted data, and only the holder of the secret key can decrypt the result. For machine learning, the model is first rewritten using operations the scheme supports, such as additions, multiplications and polynomial approximations of other functions. Exact schemes return the same answer as the unencrypted computation, while approximate schemes, often used for neural networks, return a close one. The guarantee is confidentiality of the data while it is processed, on the usual assumption that the server follows the protocol.

Example Use Cases

Privacy

A hospital group wants a cloud service to score patients' readmission risk without the provider seeing patient records. The hospital encrypts the patient features, the cloud evaluates a logistic regression model on the encrypted values, and the hospital decrypts the scores. A linear model is chosen on purpose, since encrypted computation becomes costly as models get larger.

A research team outsources a genome-wide association study to a cloud server. The team encrypts participants' genotype and phenotype data, the server computes the association statistics on the ciphertexts, and only the final statistics are decrypted. One published prototype handled 1,000 individuals and 131,071 genetic variants in about ten minutes on a 28-core server.

Security

A bank outsources credit scoring to a third-party cloud host. It encrypts customer financial data under a key that never leaves the bank, so an attacker who breaches the host, or an administrator there, can only copy ciphertexts. The bank checks that the host holds no decryption key and that the chosen parameters meet its required security level.

Limitations

Computation is typically orders of magnitude slower than on unencrypted data and ciphertexts are much larger, so real-time use, large models and large datasets are often out of reach. A published encrypted logistic regression training run took about 116 minutes on a real-world dataset.
Only some computations are practical. Circuit depth is limited by noise growth unless costly bootstrapping resets it, and comparisons and non-polynomial functions, such as most neural-network activations, must be approximated or quantised to integers, which can lower accuracy compared with the unencrypted model.
The usual security model is an honest-but-curious server. Ciphertexts can be altered, so encryption alone gives no assurance that the server ran the intended computation correctly, and a malicious host could return a wrong result that still decrypts without error.
Encryption protects data during processing, not what the result reveals. Whoever decrypts the output can still learn about the model or the data behind it through attacks such as membership inference, and with the approximate CKKS scheme, sharing decrypted results can enable a key-recovery attack.
Correct use needs cryptographic expertise. Choosing scheme parameters, encodings and noise budgets wrongly can leave the system insecure or stop results decrypting correctly, and the right choices differ by scheme and library.

Resources

Research Papers

Fully homomorphic encryption using ideal lattices

Craig Gentry•May 31, 2009

We propose a fully homomorphic encryption scheme -- i.e., a scheme that allows one to evaluate circuits over encrypted data without being able to decrypt. Our solution comes in three steps. First, we provide a general result -- that, to construct an encryption scheme that permits evaluation of arbitrary circuits, it suffices to construct an encryption scheme that can evaluate (slightly augmented versions of) its own decryption circuit; we call a scheme that can evaluate its (augmented) decryption circuit bootstrappable.

Software Packages

concrete-ml

Mar 23, 2022

Concrete ML: Privacy Preserving ML framework using Fully Homomorphic Encryption (FHE), built on top of Concrete, with bindings to traditional ML frameworks.

SEAL

Nov 9, 2018

Microsoft SEAL is an easy-to-use and powerful homomorphic encryption library.

Tutorials

Getting started — Concrete ML documentation

Apr 10, 2025

Documentations

Welcome to OpenFHE's documentation! — OpenFHE documentation

Openfhe-development Developers•Jan 1, 2023

Related Techniques

Name	Description	Assurance Goals
Differential Privacy	Differential privacy puts a mathematical limit on what a published result reveals about any one person. The data holder adds random noise, drawn for example from a Laplace or Gaussian distribution, to each answer before release, such as a count, an average or a table of statistics, so the answer would look almost the same with or without any one person's data. The amount of noise depends on how much one person could change the answer (its sensitivity) and on a privacy budget called epsilon, which sets how far the two cases may differ (the Gaussian mechanism adds a second, small parameter, delta, for the chance of exceeding that limit). A smaller epsilon means more noise, a stronger guarantee and less accurate answers, and each release spends part of the budget. The guarantee covers whether a person's data took part, not conclusions about the wider population that the results legitimately show.	Privacy Transparency
Differentially Private Stochastic Gradient Descent	Differentially private stochastic gradient descent (DP-SGD) trains a neural network, or another model fitted by gradient descent, so that the finished model carries a formal differential privacy guarantee about the individual examples it was trained on. Differential privacy is more often applied by adding calibrated noise to the answer of a query or to a published statistic; DP-SGD instead changes the training algorithm itself. At each step it draws a random batch, computes the gradient (the direction in which an example pushes the model's parameters) separately for every example, scales down any gradient longer than a fixed clipping bound, adds Gaussian noise proportional to that bound to the sum, and updates the model with the noisy average, so that no single example can move the model by much and what influence remains is masked. A privacy accountant adds up the privacy cost of every step from the noise level, the sampling rate and the number of steps, and reports the total as epsilon and delta: epsilon limits how much more likely any trained model is with a given example in the training data than without it, and delta is a small probability that this limit fails. The output is a trained model with a stated (epsilon, delta) guarantee, which also covers anything later computed from the model, including its predictions.	Privacy
Federated Learning	Federated learning trains one shared model across several parties, such as phones or hospitals, without collecting their data in one place. Each party trains the current model on its own data and sends back only an update, such as the changed weights (the model's internal numbers) or the gradients (the direction of change). A central coordinator combines the updates, typically by averaging, into an improved shared model and sends it out again, and the cycle repeats over many rounds. Raw records stay with their owners, which limits how much sensitive data is stored or moved and can support data protection rules that favour collecting less. It is not a privacy guarantee on its own, because updates can still reveal information about the data behind them and the coordinator has to be trusted.	Privacy