Homomorphic Encryption Explained

Ordinary encryption protects data in two states well and leaves a gap in the third. Data at rest on a disk is encrypted. Data in transit over the network is encrypted. But the moment you actually want to compute on that data, add up figures, run a search, train a model, you decrypt it first. For that window the plaintext sits exposed in memory, and whoever runs the machine can see it. Homomorphic encryption closes that gap by letting computation happen on the ciphertext itself.

The result is genuinely strange the first time you see it. A server receives encrypted numbers, performs arithmetic on them, and returns an encrypted answer, all without ever learning what the numbers were. Only the owner of the secret key can decrypt the result. The server did useful work while completely blind to the data. That capability rewrites what you can safely hand to an untrusted cloud.

The core idea

An encryption scheme is homomorphic with respect to an operation if performing that operation on ciphertexts produces a ciphertext that decrypts to the same operation performed on the plaintexts. In plainer terms: if you encrypt 3 and encrypt 5, a homomorphic addition on those two ciphertexts yields a ciphertext that decrypts to 8. The server never saw 3, 5 or 8.

This is more than a party trick because computation is built from a small set of operations. If a scheme supports both addition and multiplication on ciphertext, it can in principle evaluate any function, since any computation can be expressed as a circuit of adds and multiplies. That is the leap from doing one useful thing to doing anything.

The levels of homomorphic encryption

The technology is usually described in three tiers, which matter because they trade capability against cost.

Type	What it supports	Practicality
Partially homomorphic (PHE)	One operation, unlimited times	Fast, used in real systems for decades
Somewhat homomorphic (SWHE)	Limited additions and multiplications	Workable for shallow computations
Fully homomorphic (FHE)	Any computation, unbounded depth	Possible today, computationally expensive

Partially homomorphic encryption supports a single operation but any number of times. Some familiar schemes already have this property: unpadded RSA is multiplicatively homomorphic, and the Paillier cryptosystem is additively homomorphic and is genuinely used in electronic voting and private aggregation. These are efficient because they ask for so little.

Somewhat homomorphic encryption supports both addition and multiplication, but only up to a limited depth before it fails. That is enough for many shallow computations and is often faster than the fully general version.

Fully homomorphic encryption supports arbitrary computation of unbounded depth. This is the version that captured everyone's imagination, and for decades it was an open question whether it was even possible.

The noise problem and bootstrapping

The reason full homomorphism was hard comes down to noise. Modern homomorphic schemes are built on lattice problems, and to be secure each ciphertext includes a small amount of random noise. Every operation you perform makes that noise grow. Additions grow it a little; multiplications grow it a lot. Once the noise exceeds a threshold, the ciphertext becomes garbage and decryption fails. This is exactly why somewhat homomorphic schemes hit a depth limit.

In 2009 Craig Gentry published the breakthrough: bootstrapping. The idea is to homomorphically evaluate the decryption function on a noisy ciphertext, which produces a fresh ciphertext of the same plaintext but with the noise reset to a low level. In effect the scheme decrypts and re-encrypts without ever exposing the plaintext, refreshing the ciphertext so computation can continue. With bootstrapping you can compute forever, which is what makes fully homomorphic encryption possible.

Where it fits today

The realistic framing is to match the cost to the value. FHE earns its overhead where the data is sensitive enough that the alternative is not computing at all.

Outsourced sensitive computation. A hospital or bank can send encrypted records to a cloud service, have statistics or scores computed on them, and receive an encrypted answer, without the cloud provider ever seeing patient or account data. This is the flagship use and the one that best justifies the cost.

Private analytics and machine learning inference. A model owner can run predictions on a client's encrypted input and return an encrypted prediction, so neither side reveals its secret. The input stays private and, depending on the setup, so does the model.

Privacy-preserving aggregation. Additively homomorphic schemes let many parties contribute encrypted values that are summed without any individual value being revealed, which is useful in voting, telemetry and federated statistics.

Encrypted database queries. Searching or filtering over encrypted data without decrypting it is an active area, though performance constraints keep most deployments narrow.

The common thread across these cases is a trust boundary you cannot move. In each one the computation has to happen somewhere you do not fully control, whether that is a public cloud, a business partner, or a shared analytics platform, and the data is sensitive enough that exposing it there is unacceptable. When you can simply run the computation on trusted hardware you own, ordinary encryption at rest and in transit is cheaper and sufficient. Homomorphic encryption earns its cost precisely when that easy option is closed to you.

Homomorphic encryption rarely stands alone. It composes with Zero-Knowledge Proofs Explained, which prove a computation was done correctly, and with secure multi-party computation, which splits a computation across parties so none sees the whole input. Together these privacy-enhancing techniques let you build systems where sensitive data stays protected through processing, extending the guarantees of End-to-End Encryption Explained into the compute stage.

What it does not solve

It helps to be precise about the limits, because homomorphic encryption is easy to oversell. It protects data while it is being computed on, and nothing more. The party running the computation still learns the shape of the work: how much data arrived, how long the computation ran, which functions were requested. Those side channels can leak information even when the values stay encrypted, so a full privacy design has to account for them.

It also does not verify that the computation was done correctly. A malicious server could return an encrypted answer to the wrong computation, and homomorphic encryption alone gives you no way to tell. This is exactly why it pairs so naturally with verifiable computation techniques: one keeps the data hidden, the other proves the work was honest. And it does not remove the need for key management. The secret key that decrypts the result is as sensitive as any other, and losing it or leaking it collapses the whole guarantee. Treat homomorphic encryption as one strong component in a system, rather than a single setting that makes computation private on its own.

A practical way to approach it

1. Confirm the gap is real. FHE pays off only when data-in-use exposure is a genuine risk, typically because you are outsourcing computation to a party you do not fully trust.
2. Pick the lightest scheme that works. If you only need summation, an additively homomorphic scheme like Paillier is dramatically cheaper than full FHE. Reach for the general tool only when you truly need general computation.
3. Keep the circuit shallow. Cost scales with multiplicative depth. Restructuring a computation to reduce depth can make an intractable workload practical.
4. Manage keys as carefully as ever. Homomorphic encryption protects data during computation, and the secret key still protects the result. See Cloud Key Management Explained.
5. Benchmark honestly and revisit. Performance is improving quickly. A workload that is too slow this year may be viable next year, so measure rather than assume.

A worked example: adding two salaries in the cloud

Make the abstract property concrete with an additively homomorphic scheme, the kind of scheme where multiplying two ciphertexts corresponds to adding the two plaintexts. Two employees want a payroll service to compute the sum of their salaries so it can report a department total, and neither wants the service to learn either individual figure.

Employee A has salary 60 and employee B has salary 40. Each encrypts their number with the same public key, producing ciphertexts that look like large random values. Call them Enc(60) and Enc(40). Both send only the ciphertext to the service. The service holds no secret key, so to it these are meaningless blobs.

The scheme is additively homomorphic, so the service computes a single ciphertext operation, in this scheme a modular multiplication of the two ciphertexts, and the result is a new ciphertext Enc(100). The service never performed addition on the numbers 60 and 40, because it never had them. It performed a defined operation on ciphertext, and the mathematics of the scheme guarantee that the result decrypts to the sum of the two hidden values.

The service returns Enc(100) to whoever holds the secret key, the payroll owner, who decrypts it to read 100. The department total is known. The two individual salaries were never visible to the service at any point: not on arrival, not during the computation, not in the result. That is the entire promise of homomorphic encryption in one transaction. Scale the same idea from two numbers to thousands of encrypted votes, telemetry samples, or model inputs, and you have private aggregation.

The reason this particular example is cheap is that it uses only addition, which an additively homomorphic scheme such as Paillier handles efficiently and unbounded times. The cost climbs sharply the moment you also need multiplication of hidden values, because that is where noise growth and the need for bootstrapping enter, which is the subject of the next distinction.

Addition, multiplication, and why depth is the cost driver

Any computation can be written as a circuit of additions and multiplications over the inputs. That is why a scheme that supports both operations on ciphertext can in principle evaluate any function. The catch is that the two operations are not equally expensive in a lattice-based scheme.

Addition of two ciphertexts grows the internal noise only slightly. You can chain many additions before the noise threatens correctness. Multiplication of two ciphertexts grows the noise sharply, often multiplying the noise magnitude rather than adding to it. The number of multiplications you must perform in sequence, the multiplicative depth of the circuit, is therefore the dominant factor in whether a computation is cheap, expensive, or infeasible without bootstrapping.

This has a direct practical consequence. Two circuits that compute the same answer can have very different costs if one is structured to keep multiplications shallow and the other stacks them deep. A large part of applied FHE engineering is rewriting a computation to reduce its multiplicative depth: batching many values into one ciphertext, replacing a deep chain of multiplications with an equivalent shallower form, or choosing an algorithm whose circuit is naturally flat. Getting the depth down can turn an intractable workload into a practical one without any change to the underlying scheme.

How homomorphic encryption compares to related privacy techniques

Homomorphic encryption is one of several ways to compute over data you want to keep private. Each makes a different trade, and they are often combined rather than chosen in isolation.

Technique	What stays hidden	Main cost or limit
Fully homomorphic encryption	Input data, from a single computing party	Large compute overhead, especially at depth
Secure multi-party computation	Each party's input from the others	Network rounds and communication between parties
Trusted execution environment	Data from the host, inside a hardware enclave	Trust in the hardware vendor and enclave integrity
Differential privacy	Individual records within an aggregate result	Adds noise to outputs, reducing exact accuracy
Zero-knowledge proofs	The witness, while proving a statement is true	Proves correctness, does not itself compute on hidden data

The distinctions matter when you choose. Secure multi-party computation shines when several parties each hold a piece of the input and no single machine should see the whole, at the price of network communication between them. A trusted execution environment can be far faster than FHE because it computes on plaintext inside a protected enclave, at the price of trusting the hardware. Differential privacy protects individuals inside a published result by adding calibrated noise, which is a different guarantee from keeping the input itself encrypted. These compose: a system might run an FHE computation and attach a zero-knowledge proof that the computation was the one requested, getting privacy of the input and assurance of correctness at once.

Detection and verification: knowing the guarantee holds

Homomorphic encryption is a building block, and like any building block it can be deployed in a way that quietly fails to deliver what people assume. A few concrete things to check when you evaluate or operate an FHE system:

• Where the secret key lives. The entire guarantee rests on the computing party never holding the secret key. If the key material is present on the same machine that runs the computation, whether through a misconfiguration or a convenience shortcut, the property collapses. The key holder and the compute party must be genuinely separate.
• Whether results are verified. Homomorphic encryption hides the input; it does not prove the computation was the correct one. A dishonest server can return an encrypted answer to a different computation, and decryption will produce a plausible-looking wrong result. Pair FHE with verifiable computation or zero-knowledge proofs when the compute party is not trusted to run the right function.
• Metadata leakage. The computing party learns the shape of the work even when the values stay encrypted: how much data arrived, how long the computation ran, which functions were requested, and the sizes of the ciphertexts. These side channels can reveal information on their own. A full privacy design accounts for them, for example by padding inputs to fixed sizes or fixing the computation regardless of the data.
• Parameter choices. Lattice-based schemes are secure only with appropriately chosen parameters. Parameters that are too small for the depth of the computation can either fail correctness as noise overruns the threshold or weaken the security margin. Follow the parameter guidance from the standardization efforts rather than hand-tuning for speed.

Common misconceptions

"Homomorphic encryption makes all cloud computing private for free." It carries a real performance cost and it fits specific high-value workloads. When you can run the computation on hardware you control, ordinary encryption at rest and in transit is cheaper and sufficient. FHE earns its cost when the computation must happen somewhere you do not fully trust.

"FHE proves the server did the right thing." It does not. It hides the input. Verifying the computation is a separate property that requires verifiable computation or a proof system layered on top.

"Fully homomorphic means everything is homomorphic, so any code just works." Any function can in principle be evaluated, because any computation is a circuit of adds and multiplies. Turning real code into an efficient circuit is hard, especially anything with comparisons, branches, or division, which have high multiplicative depth.

"There is no key to manage because the data stays encrypted." The secret key that decrypts the result is as sensitive as any other key. Losing it destroys access to results; leaking it destroys the guarantee. Key management is as important here as anywhere.

"It is too slow to ever be useful." Performance has improved by orders of magnitude since 2009 and continues to fall. For the right narrow workloads, FHE is practical today, and a workload that is too slow this year may be viable next year.

Frequently asked questions

What does homomorphic mean here? A scheme is homomorphic with respect to an operation if performing that operation on ciphertexts yields a ciphertext that decrypts to the same operation on the plaintexts. Encrypt 3 and 5, apply a homomorphic addition, and the result decrypts to 8, with the server never seeing 3, 5, or 8. The word describes this structure-preserving property between operations on ciphertext and operations on plaintext.

What is the difference between partially, somewhat, and fully homomorphic encryption? Partially homomorphic encryption supports one operation any number of times, such as RSA for multiplication or Paillier for addition. Somewhat homomorphic encryption supports both addition and multiplication but only up to a limited depth. Fully homomorphic encryption supports arbitrary computation of unbounded depth, which requires bootstrapping to control noise and is the most expensive of the three.

What is bootstrapping and why does it matter? Every operation on a lattice-based ciphertext grows an internal noise term, and once the noise passes a threshold the ciphertext no longer decrypts correctly. Bootstrapping homomorphically evaluates the decryption function on a noisy ciphertext, producing a fresh ciphertext of the same value with the noise reset. It is what lets computation continue indefinitely, and it is the single most expensive operation, which is why it dominates FHE performance.

Is homomorphic encryption practical today? For targeted, high-value workloads, yes. Private aggregation with additively homomorphic schemes is efficient and has been used in production for years. General fully homomorphic computation carries a large overhead and is practical for specific kernels rather than general-purpose computing at scale. The honest framing is to match the cost to the value of keeping the specific data private.

Does it protect data while it is being computed on, and is that all? That is exactly its scope. It protects data-in-use, closing the gap that ordinary encryption leaves when plaintext sits exposed in memory during computation. It does not by itself verify the computation, remove metadata side channels, or eliminate key management. Treat it as one strong component of a privacy design rather than a single setting that makes computation private on its own.

When should I choose secure multi-party computation instead? When several parties each hold part of the input and no single machine should ever see the whole, MPC is often the better fit, because it splits the computation across parties so none sees the full input. FHE is stronger when one party outsources a computation to another it does not trust with the plaintext. The two can also be combined, and the right choice depends on how many parties hold inputs and how much network communication you can afford.

Homomorphic encryption turns a long-standing assumption on its head: that to use data you must first expose it. For the right workloads that assumption no longer holds. The technology is real, it is standardising through ongoing privacy-enhancing cryptography efforts, and its cost is falling year over year. The discipline is in choosing where the guarantee is worth paying for, rather than reaching for it everywhere. For how it relates to the classic public-key world, see Symmetric vs Asymmetric Encryption.

Related guides

• Zero-Knowledge Proofs Explained
• End-to-End Encryption Explained
• Cloud Key Management Explained
• Symmetric vs Asymmetric Encryption