The one-sentence version
Homomorphic encryption lets someone compute directly on ciphertexts without decrypting them, and the resulting ciphertext decrypts to exactly what the same computation on the plaintexts would give. In the language of abstract algebra: the decryption map is (approximately) a ring homomorphism on "valid ciphertexts", that is,
This article has three layers:
- The intuition: no mathematics needed
- Real-world use: private cloud computing, medical and genomic data, joint bank risk control, private machine learning, electronic voting, private information retrieval, the state of the industry and the performance cost
- The mathematics: RSA, Paillier, ElGamal, ring homomorphisms, LWE/RLWE, noise, modulus switching, bootstrapping and BGV/BFV/CKKS, with small worked examples
Layer 1: The Intuition
1.1 Working on a locked box through gloves
Imagine a jeweler with a craftsman he doesn't trust, fearing he will steal the gold. So the jeweler arranges this:
- The gold goes into a locked transparent glove box, with a pair of gloves reaching in from the side.
- The craftsman puts his hands in the gloves and can melt, draw and solder the gold into a necklace inside the box.
- But the craftsman can't open the lock, so he can't touch the gold or take it away.
- When he finishes, the box goes back to the jeweler, who alone has the key and opens it to get the finished piece.
The correspondence:
| Analogy | In homomorphic encryption |
|---|---|
| The gold | Your private data (plaintext) |
| The locked glove box | Ciphertext |
| The craftsman | A cloud server / third party |
| Working through gloves | Computing on ciphertexts |
| The key | The private key, which only you have |
| The finished necklace | The result, visible only after decryption |
The key point: the craftsman works the whole time, yet never learns what the gold looks like. Ordinary encryption only achieves "locked for storage and transport", and has to be unlocked before any computation; homomorphic encryption achieves "can be processed while locked".
1.2 What "computing directly on ciphertexts" means
Take the simplest example. You have two numbers, and , and want a cloud server to compute for you, without the server knowing the two numbers.
All the server sees is two strings of gibberish. It performs some "ciphertext addition" on them and gets a third string of gibberish. You decrypt the third string and get exactly . The server knows neither that the inputs were and nor that the result is .
Note that "ciphertext addition" is generally not adding the two strings of digits directly. For Paillier, it is multiplying two ciphertexts; for lattice schemes, it really is adding vectors or polynomials. The exact operation depends on the scheme, as Layer 3 explains.
1.3 Three levels: PHE, SHE, FHE
Any computation can ultimately be broken down into addition and multiplication (XOR and AND gates, on bits), so the key questions are which operations can be done on ciphertexts, and how many times.
| Type | Full name | What it can do | Typical examples |
|---|---|---|---|
| PHE | Partially Homomorphic Encryption | Supports only one operation (only addition or only multiplication), any number of times | RSA (multiplication), ElGamal (multiplication), Paillier (addition) |
| SHE | Somewhat Homomorphic Encryption | Supports both addition and multiplication, but a limited number of times; do too many and it can't be decrypted | Some lattice schemes before Gentry; BGV/BFV without bootstrapping |
| FHE | Fully Homomorphic Encryption | Supports both addition and multiplication without limit, computing any function | Schemes from Gentry 2009 on; BGV/BFV/CKKS with bootstrapping, TFHE |
One way to remember them:
- PHE: the glove box holds only a hammer. You can keep hammering, but hammering is all you can do.
- SHE: a full set of tools, but each step leaves a little dust in the box (mathematically called noise). Once enough dust builds up you can't see, and the box can never be opened again.
- FHE: SHE plus a way to "remove the dust without unlocking" (bootstrapping), so work can continue indefinitely.
A historical aside
In 1978, RSA's inventors Rivest and Adleman, together with Dertouzos, proposed the idea of a "privacy homomorphism", asking whether arbitrary computation on encrypted data was possible. The question stayed open for 31 years, until Craig Gentry gave the first fully homomorphic encryption scheme in his 2009 PhD thesis.
1.4 Why it's called "homomorphic"
"Homomorphism" is a mathematical word meaning literally "the same shape". In abstract algebra, a ring homomorphism is a map satisfying
It "carries" the operations of into : operate then map equals map then operate.
Homomorphic encryption says exactly this, usually viewed in the other direction: decryption, the map from ciphertexts to plaintexts, preserves operations, that is,
where are the corresponding operations in the ciphertext space. In other words, "computing in the ciphertext world" and "computing in the plaintext world" have the same shape, hence the name.
Strictly speaking, though, decryption in modern fully homomorphic schemes is only an approximate homomorphism, because each operation brings in a little noise. Layer 3 covers this in detail.
Layer 2: Real-World Use
2.1 Private cloud computing (outsourced computation)
This is the original motivation for homomorphic encryption. A company wants to use computing power in the cloud, but its data is sensitive (finances, medical records, user behavior):
- The traditional approach: upload plaintext, or decrypt in the cloud before computing, so the cloud provider and anyone who breaks into the cloud can see the data.
- Homomorphic encryption: upload ciphertext, and the cloud computes on it and sends back an encrypted result. The cloud only ever touches ciphertext.
It protects "data in use". Transport encryption (TLS) protects "data in transit" and disk encryption protects "data at rest", and the moment of computation is exactly the gap neither covers.
2.2 Medical and genomic data analysis
Data sharing among hospitals and research institutions is strictly limited by law (such as HIPAA in the US and GDPR in the EU). Homomorphic encryption allows:
- Several hospitals to pool encrypted records, with researchers computing statistics on the ciphertexts (means, regressions, chi-squared tests);
- Individuals to send an encrypted genome to a testing company, which compares disease risk loci on the ciphertext, with only the individual able to see the report.
Since 2014 academia has held the annual iDASH competition in privacy-preserving genomic analysis, with homomorphic encryption always a main track; tasks have included genome-wide association studies (GWAS) and logistic regression training on ciphertexts.
2.3 Joint risk control and anti-money-laundering among banks
Money launderers often scatter funds across many banks, and each bank sees only its own segment, not the whole picture; yet banks can't freely share customer data with each other.
Homomorphic encryption works like this: each bank encrypts transaction features and hands them to a joint analyst, who assembles a cross-bank flow graph and computes risk scores on ciphertexts, finally decrypting only the conclusion "this account is suspicious". Similar ideas are used for joint credit scoring and cross-institution blacklist queries. Real systems often combine homomorphic encryption with secure multi-party computation (MPC) and private set intersection (PSI).
2.4 Private machine learning inference
The model is on the server, the data is with the user, and neither wants to hand theirs over:
- The user encrypts the input (a chest X-ray, say, or speech features) and sends it to the server;
- The server runs inference with a plaintext model on the encrypted input, with matrix multiplication implemented by homomorphic addition and multiplication;
- An encrypted prediction comes back, which only the user can decrypt.
The difficulty is activation functions. Non-polynomial functions like ReLU and sigmoid can't be computed directly. Common approaches are low-degree polynomial approximation (where CKKS excels) or direct table lookup with TFHE's programmable bootstrapping. Zama's Concrete ML is a tool that automatically compiles scikit-learn and PyTorch models into FHE circuits.
2.5 Electronic voting
Voting was one of the earliest successful applications of homomorphic encryption, using additive homomorphism:
- Each ballot is or ;
- The tallier "adds" all the ciphertexts to get ;
- Only the total is decrypted, and no individual ballot is ever decrypted.
The open-source Helios voting system uses exponential ElGamal (see section 3.3) for homomorphic tallying, along with zero-knowledge proofs that each ballot really is or and not a cheating ballot like .
2.6 Private information retrieval (PIR)
You want to look up a record in a public database, without the database knowing which one you looked up.
With homomorphic encryption: encode the query as an encrypted "selection vector" (only position is ), and the server computes
The server performs the same operation on every record, so it has no idea what is. Real schemes compress the selection vector and use recursive layers to reduce communication.
2.7 The state of the industry
Main open-source libraries
| Library | Maintainer | Schemes supported | Notes |
|---|---|---|---|
| Microsoft SEAL | Microsoft Research | BFV, BGV, CKKS | C++, good documentation, the first choice for beginners |
| OpenFHE | Community (successor to PALISADE, with DARPA funding background) | BGV, BFV, CKKS, FHEW, TFHE-style schemes | The most complete, supporting many bootstrapping methods and scheme switching |
| TFHE-rs / Concrete | Zama (France) | TFHE | Rust; Boolean and integer circuits, programmable bootstrapping; also used for encrypted smart contracts on blockchains (fhEVM) |
| HElib | IBM | BGV, CKKS | An earlier implementation |
| Lattigo | Tune Insight / EPFL | BFV, BGV, CKKS | Go; supports multiparty (threshold) homomorphic encryption |
| swift-homomorphic-encryption | Apple | BFV | Used for Apple's own PIR deployment |
A real deployment: Apple
- Live Caller ID Lookup (iOS 18, 2024): when a call comes in, the phone has to ask a server "whose number is this, and is it spam?". Apple uses BFV-based private information retrieval: the phone sends an encrypted number query, the server does the lookup on ciphertext and returns an encrypted result, and the server doesn't know who called you.
- Enhanced Visual Search (recognizing landmarks in photos): also uses homomorphic encryption for encrypted nearest-neighbor search, combined with differential privacy and an anonymizing network relay.
In addition, Google has open-sourced FHE compilers (HEIR and others), Intel offers the HEXL acceleration library, and DARPA's DPRIVE program funds dedicated FHE accelerator chips. On standardization, ISO/IEC 18033-6 already includes partially homomorphic schemes like ElGamal and Paillier, while standardization of fully homomorphic schemes (driven by the HomomorphicEncryption.org community) is still under way.
2.8 The performance cost
The main problems of homomorphic encryption are that it is slow and big.
| Dimension | Cost (orders of magnitude, varying widely with scheme, parameters and hardware) |
|---|---|
| Compute speed | About to times slower than plaintext computation |
| Ciphertext expansion | One RLWE ciphertext is often several hundred KB to several MB |
| Bootstrapping | The most expensive operation. TFHE single-bit bootstrapping takes milliseconds on a CPU; one CKKS bootstrap may take seconds to tens of seconds, but handles thousands of slots at once |
| Programming difficulty | Everything must be written as a "circuit": no data-dependent branches (if x > 0 must be rewritten as a polynomial or table lookup), and loop counts must be fixed |
For an order-of-magnitude example: with parameters and , a ciphertext consists of two polynomials, about
Fortunately, with batching (see section 3.7), one ciphertext can hold thousands of numbers for SIMD parallel computation, and the amortized cost is much lower.
Why it's still worth using
Where "data absolutely can't leave a certain boundary" (medicine, finance, government, cross-border data flows), being able to use it beats not being able to; and many applications (PIR, voting, simple statistics, small-model inference) need only shallow circuits, with entirely acceptable overhead.
Layer 3: The Mathematics
3.1 RSA's multiplicative homomorphism
Textbook RSA: choose two large primes , let and , take with , and .
The multiplicative homomorphism is almost obvious:
In the language of abstract algebra, is a homomorphism from the multiplicative monoid to itself (restricted to the unit group , it is a group automorphism). But it doesn't preserve addition: in general . So RSA is only PHE.
A worked example: RSA's multiplicative homomorphism
Take and , so and . Take ; from we get .
- Multiply the ciphertexts:
- Encrypt directly: , and the two agree
- Decrypt:
So , that is, . (Checked with Python.)
Why textbook RSA is insecure
- Determinism: the same encrypts to the same result every time. If the plaintext space is small (a vote has only "yes/no"), an attacker can encrypt every possible plaintext and compare. Secure public-key encryption must be randomized to achieve semantic security (IND-CPA).
- Malleability: without knowing , an attacker can replace with , and the recipient decrypts . For something like "transfer amount" this is a disaster. Note that homomorphism itself is malleability, so no homomorphic encryption can reach the strongest IND-CCA2 security, and it can only aim for IND-CPA.
- Small-plaintext attacks: if and , then never wraps around in the integers, and taking the cube root gives directly.
RSA in actual use always applies random padding first (such as OAEP), and padding happens to destroy the homomorphism. So RSA's homomorphism is more a teaching example than a practical tool.
3.2 Paillier: additive homomorphism
Paillier (1999) is the most widely used additively homomorphic scheme, based on the composite residuosity assumption: distinguishing "-th powers" from "random elements" in is hard.
Key generation: take large primes , with , and . Define and let . The public key is and the private key is .
Encryption: for plaintext , pick a random ,
Decryption:
Why decryption works:
- The binomial theorem gives , because and higher terms vanish.
- By the Chinese Remainder Theorem , and the orders , of the two factors both divide , so every element's order divides , that is, .
- So , , and multiplying by gives .
Additive homomorphism:
Multiplying ciphertexts corresponds to adding plaintexts. There is also scalar multiplication: . So Paillier can compute "linear combinations of encrypted data", such as weighted sums and averages, but not the product of two encrypted plaintexts.
The group homomorphism view
The map , is a group isomorphism: the operation on the left is , and on the right it is multiplication. Both sides have order . Paillier's additive homomorphism is a direct corollary of this isomorphism.
A worked example: Paillier's additive homomorphism
Take and , so , , and . Since , , so (because ).
Encrypt with :
Encrypt with :
Multiply the ciphertexts:
Decrypt :
This gives . For comparison, decrypting alone: , , , which is correct.
Two additional points (both checked with Python):
- Scalar multiplication: , which decrypts to .
- Plaintexts add in : decrypts to , so in practice must be much larger than any possible result.
3.3 ElGamal: multiplicative homomorphism, and the additive "exponential" version
Let be a cyclic group with a hard discrete logarithm (such as a subgroup of or an elliptic curve group). The private key is and the public key is .
It is naturally randomized (a fresh each time) and IND-CPA secure under the DDH assumption. Multiplying componentwise gives
so ElGamal is multiplicatively homomorphic.
A worked example: ElGamal
Take and (a generator of ), with private key and public key .
- Multiply componentwise:
- Decrypt: , ,
This gives . (Checked with Python.)
Exponential ElGamal: put the plaintext in the exponent, encrypting instead of :
Multiplying then gives , which makes it additively homomorphic. The cost is that decryption yields only , and another discrete logarithm must be solved to get , so it suits only small . Tallying votes fits exactly (the total can't exceed the number of voters), and this is what Helios does.
The common limits of PHE
RSA, Paillier and ElGamal each have only one operation, and their security all rests on factoring or discrete logarithms, which Shor's algorithm breaks on a quantum computer. The lattice schemes below solve both problems at once.
3.4 Ring homomorphisms, and why encryption is only an "approximate ring homomorphism"
Recall the definition: a map between rings satisfying
is called a ring homomorphism.
Why we want a ring homomorphism: any function can be written as a polynomial over (addition XOR, multiplication AND), and similarly for functions on . If decryption is a ring homomorphism, then for any polynomial ,
That is, "computing on ciphertexts" equals "computing on plaintexts", which computes any function: full homomorphism.
Why it can't really be a ring homomorphism: if itself were a deterministic ring homomorphism , an attacker could mount an algebraic attack with the public operations. A ring homomorphism must satisfy , and is public, so an attacker can compute , and so on, listing the ciphertext of every plaintext in a table and looking up any ciphertext, with no security whatsoever. In abstract algebra terms, by the first isomorphism theorem , the structure of the image is completely determined by public algebraic data.
The solution: add noise. In modern schemes,
- Each plaintext corresponds to many ciphertexts (encryption is randomized),
- Decryption "first apply a true ring homomorphism, then round away the small noise".
What truly preserves operations is the phase map, an exact homomorphism; "rounding" is compatible with the operations only while the noise is small enough. So encryption is an approximate ring homomorphism: the homomorphism holds as long as the noise hasn't grown too large.
3.5 LWE and RLWE
The LWE problem (Learning With Errors, Regev 2005): take a modulus and a secret vector . You are given many pairs
where is uniformly random and is a small random error. The task is to find (the search version), or to distinguish these from uniformly random pairs (the decision version).
- Without the errors , this is just a system of linear equations, solved by Gaussian elimination.
- With small errors added, elimination amplifies them uncontrollably, and the problem becomes hard. Regev proved that average-case LWE is at least as hard as certain worst-case lattice problems (such as approximate GapSVP and SIVP).
- There is currently no known quantum algorithm that solves LWE efficiently, so lattice cryptography is post-quantum, and FHE is naturally quantum-resistant.
A minimal LWE encryption (symmetric key, encrypting one bit ): let ,
Decryption checks whether the phase is closer to or to . The key observation: the phase map is -linear (a module homomorphism), so adding two ciphertexts adds their phases:
A worked example: homomorphic addition on LWE (addition modulo 2)
Take , and secret .
Encrypt with and : and , so . The phase is , close to , so it decrypts to .
Encrypt with and : and , so . The phase is , which decrypts to .
Add: . , and the phase is . is close to , so it decrypts to , and , which is correct.
Here , so the phase equals . The noise went from to plus a rounding error, and decryption is correct as long as the absolute value of the total noise doesn't exceed . (Checked with Python.)
RLWE (Ring-LWE, Lyubashevsky–Peikert–Regev 2010): replace vectors with the polynomial ring
Samples become , where are all polynomials and has small coefficients. There are two benefits:
- Compact: one polynomial is worth LWE samples, so keys and ciphertexts are much smaller;
- Fast: polynomial multiplication can use the number theoretic transform (NTT, the FFT over a finite field), in .
Why : when is a power of , is the -th cyclotomic polynomial, irreducible over (Eisenstein's criterion applied after ). Because , multiplication in this quotient ring is a "negacyclic convolution", convenient to compute, and its geometric properties (the canonical embedding) are good, keeping noise growth under control. This is exactly the quotient ring from abstract algebra.
3.6 Noise growth, modulus switching, bootstrapping
Ciphertext multiplication and the "evaluation homomorphism"
In RLWE schemes, a ciphertext can be viewed as a linear polynomial in an unknown : . The first step of decryption is substituting :
This is exactly the evaluation homomorphism from abstract algebra, an exact ring homomorphism. So the product of two ciphertexts is defined as the polynomial product:
which after substituting is exactly . After multiplying, the ciphertext is quadratic in (three components), and relinearization (using a public encryption of , the key-switching key) turns it back into a linear one.
How noise grows: in BGV style, let the phase be (the plaintext is in the "low bits", read modulo ).
| Operation | Phase | Noise size |
|---|---|---|
| Addition | Adds: | |
| Multiplication | Roughly multiplies: |
Addition grows noise linearly, and multiplication grows it quadratically. After levels of consecutive multiplication, the noise is roughly , an exponential explosion. Once the noise exceeds the order of , reduction "wraps around" and decryption fails. This is why SHE can do only a limited number of multiplications.
Modulus switching (the core technique of BGV): after each multiplication, scale the whole ciphertext down,
The noise shrinks by the factor too, while (with suitable correction) the plaintext is unchanged. In other words, the absolute size of the noise is pressed back to its original level, at the cost of a smaller modulus and less "remaining room". In practice one takes as a product of a chain of primes, "dropping" one prime after each level of multiplication, turning exponential noise growth into growth linear in the number of levels . This chain of primes is represented using the Chinese Remainder Theorem (the RNS representation), also from abstract algebra.
Gentry's bootstrapping: what happens when the levels run out? Gentry's idea is to "run the decryption algorithm homomorphically":
- In advance, encrypt the private key under itself (or another public key), and publish , called the bootstrapping key.
- Take a ciphertext whose noise is nearly full. The server treats each bit of as a constant and as the encrypted input, and homomorphically computes the decryption circuit :
- The result is still a ciphertext of , but its noise comes only from "computing the decryption circuit", independent of the noise in the original .
As long as a scheme can homomorphically compute its own decryption circuit and still has room for at least one more multiplication (called bootstrappable), ciphertexts can be "refreshed" without limit, upgrading SHE to FHE.
Two details
- Publishing (encrypting under itself) needs an extra circular security assumption, which hasn't been proved, though no attack on it is known.
- In the glove box analogy: the contents of box A are nearly impossible to see, so put all of box A inside a new clean box B, and lock A's key in B as well (the key is encrypted, so no one can use it directly). Then, through B's gloves, use A's key to open A. The contents are now in the clean box B, and no one ever saw the plaintext.
3.7 The differences among BGV, BFV, CKKS (and TFHE)
The ciphertexts of the three main RLWE schemes all live in . They differ in where the plaintext sits in the phase:
| Scheme | Shape of the phase | Plaintext space | Good for |
|---|---|---|---|
| BGV (2011) | , plaintext in the low bits | , exact integer arithmetic | Exact integer arithmetic modulo ; manages noise with modulus switching |
| BFV (2012) | , , plaintext in the high bits | Also , exact integer arithmetic | Exact integer arithmetic; "scale-invariant" and simpler to implement (used by SEAL and Apple) |
| CKKS (2017) | , but is treated as approximation error | Complex (real) vectors, approximate arithmetic | Floating-point computation, machine learning, statistics; after multiplication, rescale divides by |
| TFHE / FHEW | LWE samples, with bits or small integers as plaintext | or (very small ) | Arbitrary Boolean circuits, comparisons, table lookups; every gate bootstraps, and bootstrapping is very fast |
The core idea of CKKS: floating-point arithmetic has rounding errors anyway, so treat encryption noise as part of the rounding error. The plaintext is "the true value times a scaling factor , rounded", and decryption yields . As long as is small relative to , you only lose a few bits of precision. After multiplication the phase becomes , and rescale (dividing by and lowering the modulus) restores the scale, which is the same operation as modulus switching.
Batching (SIMD) and the Chinese Remainder Theorem: for BGV/BFV, if the prime , then contains a primitive -th root of unity , so splits into linear factors over , and the Chinese Remainder Theorem gives
This is a ring isomorphism, so one multiplication in equals one multiplication in each of slots. One ciphertext handles numbers at once ( when ). CKKS uses a similar idea: the canonical embedding packs complex numbers into one polynomial.
3.8 Summary: homomorphic encryption through abstract algebra
| Abstract algebra concept | Role in homomorphic encryption |
|---|---|
| Group / ring homomorphisms | The definition of homomorphism itself; RSA and ElGamal are multiplicative group homomorphisms, and Paillier is a group isomorphism |
| Quotient ring | The ring where ciphertexts and plaintexts live |
| Evaluation homomorphism | The first step of decryption, , which also explains ciphertext multiplication |
| Irreducible polynomials | is irreducible, giving the ring a good structure |
| Chinese Remainder Theorem | Batching ; RNS representation and modulus switching |
| Ideals and kernels | If were an exact homomorphism, the structure of its kernel and image would leak information, so noise must be added |
Further Reading
- Craig Gentry, A Fully Homomorphic Encryption Scheme, Stanford PhD thesis, 2009
- Oded Regev, On Lattices, Learning with Errors, Random Linear Codes, and Cryptography, 2005
- Brakerski, Gentry, Vaikuntanathan, (Leveled) Fully Homomorphic Encryption without Bootstrapping, 2012 (BGV)
- Fan, Vercauteren, Somewhat Practical Fully Homomorphic Encryption, 2012 (BFV)
- Cheon, Kim, Kim, Song, Homomorphic Encryption for Arithmetic of Approximate Numbers, 2017 (CKKS)
- Pascal Paillier, Public-Key Cryptosystems Based on Composite Degree Residuosity Classes, 1999
- The official documentation and examples of Microsoft SEAL, OpenFHE and Zama TFHE-rs