What Is Homomorphic Encryption?

Homomorphic encryption allows computation on encrypted data without decrypting it. The result, once decrypted, matches what the same computation would have produced on the plaintext. It addresses the hardest of the three encryption states — protecting data while it is in use.

It is genuinely remarkable and, for most purposes today, impractical. Understanding why is more useful than the capability itself, because it explains what to use instead.

The performance reality

Fully homomorphic schemes — supporting arbitrary computation — remain orders of magnitude slower than operating on plaintext. Ciphertexts are substantially larger, and complex operations compound both costs.

Partially homomorphic schemes, supporting a limited operation such as addition, are far more efficient and correspondingly narrower in application. Much of the practical use today sits in that restricted space rather than in the general case.

Where it is actually being used

The viable applications share a shape: high-value data, a computation that is simple, and a strong reason the processing party must not see the input. Privacy-preserving analytics across organisations that cannot share raw data, encrypted database queries where the provider must not learn the query, and secure aggregation in federated learning are the recurring examples.

It is not a general replacement for encrypting data at rest and in transit, and deploying it to protect ordinary application workloads is not currently a reasonable proposition.

The alternatives that usually apply

Confidential computing — hardware-based trusted execution environments — addresses much of the same problem with far better performance, at the cost of trusting the hardware vendor and the attestation mechanism. For most organisations wanting protection during processing, this is the practical route.

Secure multi-party computation is the other neighbour, allowing several parties to compute a joint result without revealing their individual inputs. It suits collaboration scenarios where no single party should hold the combined dataset.

Why it matters strategically even if unused

The capability shapes what becomes possible in data sharing. Several long-standing problems — collaborative analysis between organisations that cannot share records, processing by a provider who must not see the data, regulated analytics across jurisdictional boundaries — are blocked today by the requirement to decrypt before computing.

As the performance gap narrows, arrangements that are currently impossible become merely expensive, and then routine. Organisations with genuine cross-party analysis needs are worth revisiting this every couple of years rather than concluding once that it is impractical.

In the meantime, the honest advice is unchanged: confidential computing for protection during processing, secure multi-party computation for joint analysis, and conventional encryption everywhere else.

For now, the useful position is to know the boundary: where a processing party genuinely must not see the data, there are three credible approaches, and this is the one with the strongest guarantee and the highest cost. Choosing between them is a question of how much performance the use case can surrender.

Where to start

If you have a case where a third party must compute on your data without seeing it, investigate confidential computing first. It solves the same problem today at a cost you can actually carry.

See encryption in practice. GuardsArm runs security risk assessments.