Homomorphic encryption is a form of encryption that allows computation directly on ciphertexts, so that decrypting the result gives the same output as performing the operation on the original plaintext. In privacy engineering, it is a privacy-enhancing technology that lets an untrusted party, such as a cloud server, process personal data without ever seeing it, while only the data owner holds the decryption key.
The idea dates back to the late 1970s, but a fully homomorphic scheme that supports arbitrary computation was first constructed by Craig Gentry in 2009. Since then, performance has improved by many orders of magnitude, yet the technique still costs far more computation than plaintext processing, which shapes where it is used today.
How computation on ciphertexts works
A homomorphic scheme maps operations on plaintexts to operations on ciphertexts. If Enc(a) and Enc(b) are added or multiplied in encrypted form, the result decrypts to a + b or a × b. Because addition and multiplication together can express any arithmetic or Boolean circuit, a scheme that supports both without limit can, in principle, evaluate any function.
Modern schemes are built on lattice problems, mainly Ring Learning With Errors. Each ciphertext carries a small amount of random noise that protects security. Every operation increases that noise, and multiplication increases it much faster than addition. Once the noise exceeds a threshold, decryption fails, so the number of sequential multiplications, called the multiplicative depth, is the central design constraint.
Gentry’s key insight was bootstrapping: homomorphically evaluating the decryption circuit itself, which produces a fresh ciphertext of the same value with reduced noise. Bootstrapping makes unlimited computation possible but is the most expensive operation in the whole system.
Levels of homomorphic encryption
Schemes are classified by which operations they support and how many times. The level determines both capability and cost, and many deployed systems deliberately use a weaker level to stay fast.
| Level | Supported operations | Typical example |
|---|---|---|
| Partially homomorphic | One operation, unlimited times | Paillier for addition, unpadded RSA for multiplication |
| Somewhat homomorphic | Both operations, limited depth | Early lattice schemes without bootstrapping |
| Leveled fully homomorphic | Any circuit up to a preset depth | BGV or CKKS with fixed parameters |
| Fully homomorphic | Any circuit, unlimited depth | Lattice schemes with bootstrapping |
Among fully homomorphic schemes, the main families differ in data type and arithmetic. Choosing the wrong family can make an application several times slower or produce unusable precision.
| Scheme | Data type | Best suited for |
|---|---|---|
| BGV and BFV | Exact integers modulo a plaintext modulus | Counting, exact statistics, private lookups |
| CKKS | Approximate real or complex numbers | Machine learning inference, numeric analytics |
| TFHE and FHEW | Bits or small integers | Boolean logic, comparisons, fast bootstrapping |
BGV, BFV and CKKS support SIMD packing, which places thousands of values into one ciphertext and processes them in parallel, greatly improving throughput. TFHE bootstraps quickly, often in the range of milliseconds per gate, and suits branching logic that the other families handle poorly.
Comparison with other privacy-enhancing technologies
Homomorphic encryption protects data in use, which ordinary encryption at rest and in transit does not. It is one of several techniques with that goal, and each rests on a different trust assumption.
| Technique | Trust assumption | Main trade-off |
|---|---|---|
| Homomorphic encryption | Only cryptography, no trusted party | High computation and ciphertext expansion |
| Secure multi-party computation | Parties do not all collude | Heavy network communication between parties |
| Trusted execution environment | Hardware vendor and enclave integrity | Exposure to side-channel attacks |
| Differential privacy | Correct noise calibration | Reduced accuracy of results |
These techniques are complementary, not competing. Homomorphic encryption hides inputs during computation but says nothing about what the output reveals; adding differential privacy to the decrypted result limits inference about individuals. Secure multi-party computation often uses homomorphic encryption internally for some steps.
Performance and practical parameters
The cost of homomorphic encryption depends on the polynomial ring dimension, the ciphertext modulus and the circuit depth. Typical ring dimensions range from 4,096 to 65,536, and larger values allow deeper circuits at the same security level but slow every operation. Parameters are normally chosen to reach about 128-bit security according to the community Homomorphic Encryption Standard.
- Ciphertext expansion is large: an encrypted value can be hundreds or thousands of times bigger than the plaintext.
- Simple encrypted additions are fast, while bootstrapping can take from milliseconds to seconds depending on scheme and hardware.
- Comparisons and divisions are costly in arithmetic schemes and often need polynomial approximations.
- Open-source libraries such as Microsoft SEAL, OpenFHE and TFHE-rs handle parameter selection and reduce implementation risk.
The most effective optimization is usually redesigning the computation to minimize multiplicative depth and avoid bootstrapping entirely, rather than tuning the cryptography itself.
Limitations and common pitfalls
Homomorphic encryption solves a narrow problem very well, and many failures come from expecting it to solve more. It ensures confidentiality of inputs during computation, but it does not guarantee that the server computed the right function or that the output is safe to release.
- No integrity by default: a malicious server can return a wrong result unless verifiable computation is added.
- CKKS outputs can leak: approximate decrypted results may reveal information if they are shared without care.
- Key management decides security: whoever holds the secret key can read every result.
- Access patterns still matter: which records are requested can leak even when their content is encrypted.
In a privacy by design review, homomorphic encryption should be paired with output controls, key governance and integrity checks, not treated as a complete answer on its own.
A non-technical view
Imagine a locked glove box with built-in gloves. You put your materials inside and lock it. A craftsman can reach in through the gloves and work on the materials, but he cannot take anything out or see it clearly. When he returns the box, only you have the key to open it and collect the finished work.
Homomorphic encryption works the same way with data. A company can send encrypted information to a computing service, the service performs the calculation without unlocking it, and only the company can read the answer. The catch is that working through the gloves is much slower than working by hand.
A concrete example
A hospital network wants a cloud provider to run a trained risk model on patient laboratory values, but its privacy officer will not allow the provider to see raw health data. The hospital encrypts each patient’s 20 lab measurements with CKKS, packs a batch of several thousand patients into one ciphertext and sends it to the cloud service.
The provider evaluates a logistic regression model whose sigmoid function is replaced by a low-degree polynomial approximation, keeping the circuit shallow enough to avoid bootstrapping. The encrypted risk scores return to the hospital, which decrypts them locally. Processing takes seconds per batch instead of milliseconds, but the provider never handles readable patient data, and the hospital’s data protection impact assessment records the cloud step as a low residual risk.