Data is normally decrypted to be processed, which means whoever runs the computation can see it. Homomorphic encryption (HE) is a form of encryption that lets a party compute on ciphertexts and produce an encrypted result which, when decrypted by the key holder, matches the result of the same computation on the plaintext. The server never holds the decryption key and never sees the inputs or the output. This guide explains what HE is, how the main schemes work, where it is genuinely used today, its honest limits, and where standardisation stands (ISO/IEC 18033-6, the HomomorphicEncryption.org security standard and the draft ISO/IEC 28033 series). It is for security architects, data protection teams and engineers deciding whether HE fits a problem. It builds on the Privacy-Enhancing Technologies Guide, which compares HE with the other techniques.
Key takeaways
- HE protects data in use from the processor. The party that computes never holds the secret key, so a compromised or curious server learns nothing about inputs or outputs beyond sizes and the function it ran.
- Partial and fully homomorphic are different tools. Partially homomorphic schemes such as Paillier support one operation cheaply and are standardised in ISO/IEC 18033-6; fully homomorphic schemes (BFV, BGV, CKKS, TFHE) support arbitrary computation at much higher cost.
- Performance is the binding constraint. Ciphertexts are far larger than plaintexts and operations are orders of magnitude slower, so HE suits narrow, well-defined computations, not general workloads.
- HE gives confidentiality, not integrity. Ciphertexts are malleable by design and the client cannot tell from the result alone whether the server computed the right function.
- Standards are partly finished. ISO/IEC 18033-6:2019 is published, the community security standard dates from 2018, and ISO/IEC 28033-1 for fully homomorphic encryption was still a draft at the end of 2025.
What it is
An encryption scheme is homomorphic for an operation if combining ciphertexts in some way yields a ciphertext of the combined plaintexts. If Enc(a) and Enc(b) can be turned into Enc(a + b) without the key, the scheme is additively homomorphic. Some classical schemes have this property by accident of their maths: textbook RSA is multiplicatively homomorphic, and Paillier and exponential ElGamal are additively homomorphic. These are partially homomorphic encryption (PHE) schemes.
Fully homomorphic encryption (FHE) supports both addition and multiplication an unlimited number of times, which is enough to evaluate any computable function expressed as a circuit. Craig Gentry showed the first construction in 2009. Between the two sits somewhat or levelled homomorphic encryption, which supports a bounded number of multiplications chosen when parameters are set.
| Class | Operations | Example schemes | Typical cost | Standard status |
|---|---|---|---|---|
| Partially homomorphic | One operation (addition or multiplication), unlimited | Paillier, exponential ElGamal | Modest; similar to public-key operations | ISO/IEC 18033-6:2019 (published, confirmed 2024) |
| Levelled / somewhat | Addition and a bounded depth of multiplication | BFV, BGV, CKKS without bootstrapping | High; grows with depth | HomomorphicEncryption.org community standard (2018); ISO/IEC 28033 drafts |
| Fully homomorphic | Arbitrary circuits via bootstrapping | BFV, BGV, CKKS with bootstrapping; FHEW, TFHE (CGGI) | Highest; bootstrapping dominates | ISO/IEC DIS 28033-1 (draft, enquiry stage December 2025) |
How it works
Modern FHE schemes are built on lattice problems, mainly Learning With Errors (LWE) and its ring variant (RLWE). Encryption hides the message under a small amount of random noise. Each homomorphic operation increases the noise; addition only slightly, multiplication substantially. If the noise grows past a threshold, decryption fails. Managing that noise budget is the central engineering problem.
- Bootstrapping: Gentry's key idea. The scheme homomorphically evaluates its own decryption circuit on a ciphertext, using an encrypted copy of the secret key, producing a fresh ciphertext of the same message with reduced noise. This makes unlimited computation possible but is the most expensive operation.
- Relinearisation and rotation keys: after multiplication, ciphertexts grow and are shrunk back using public evaluation keys. Rotation (Galois) keys let the server move values between slots. These keys are given to the server; the secret key never is.
- Batching (SIMD): BFV, BGV and CKKS pack thousands of values into one ciphertext and operate on all slots at once, which is how practical systems recover throughput.
- Exact vs approximate arithmetic: BFV and BGV compute exactly on integers modulo a plaintext modulus. CKKS computes approximately on real or complex numbers, treating noise as part of rounding error, which suits statistics and machine learning inference.
- Boolean and lookup approaches: FHEW and TFHE (CGGI) bootstrap after every gate or lookup table, making comparisons and non-linear functions easier at the cost of throughput.
A typical deployment has three roles. The client generates the keys, encrypts its data and sends ciphertexts plus evaluation keys. The server runs the agreed function on ciphertexts. The client decrypts the result. In multi-party variants such as threshold FHE, the secret key is split so that no single party can decrypt alone; OpenFHE, for example, implements threshold FHE and proxy re-encryption for BGV, BFV and CKKS.
| Scheme | Data type | Good for | Watch out for |
|---|---|---|---|
| BFV | Integers, exact | Private lookups, counting, exact matching | Non-linear operations need polynomial tricks |
| BGV | Integers, exact | Similar to BFV; different noise management | Parameter selection is specialist work |
| CKKS | Real numbers, approximate | Statistics, ML inference, similarity scores | Approximate results; decryptions shared with others leak information (see below) |
| TFHE / FHEW | Bits or small integers | Comparisons, branching logic, arbitrary functions via lookup tables | Low throughput per operation |
| Paillier | Integers, additive only | Encrypted sums, tallies, simple aggregation | Based on factoring, so not post-quantum secure |
Why it matters
Encryption at rest and in transit leaves a gap while data is processed. Confidential computing closes it with hardware enclaves that trust the chip vendor; HE closes it with mathematics alone, with no trusted hardware. See the Confidential Computing Guide for the hardware route. In NIST CSF 2.0 terms HE serves PR.DS-10 (data in use is protected), and in NIST SP 800-53 it is a mechanism under SC-13 (cryptographic protection).
Where it is used today
- Private lookups at consumer scale: Apple uses the BFV scheme, with parameters chosen for post-quantum 128-bit security, for private information retrieval (for example business logos in Mail and caller information for incoming calls) and private nearest neighbour search behind Enhanced Visual Search in Photos. The server matches an encrypted query without learning it, and Apple has published its swift-homomorphic-encryption library.
- Encrypted aggregation: additive schemes such as Paillier sum values (votes, meter readings, survey responses) without revealing individual inputs.
- Outsourced analytics and inference: a data owner sends encrypted records to a cloud model and receives an encrypted score, for example in fraud or health screening pilots, where the computation is fixed and small.
- Cross-organisation matching: checking whether an identifier appears in another party's list, often combined with other techniques such as private set intersection.
When to choose HE, and when not
| Situation | Better fit | Reason |
|---|---|---|
| A small, fixed computation on sensitive data by an untrusted server | HE | No trust in the server or its hardware required |
| Large or changing workloads (training, joins, general SQL) | Confidential computing | Near-native performance; trust moves to the hardware vendor and attestation |
| Several parties jointly computing, each holding part of the data | Secure multi-party computation, or threshold HE | No single key holder |
| Publishing aggregate statistics | Differential privacy | HE hides inputs but not what the output reveals |
| Just protecting stored data | Ordinary encryption with good key management | HE adds cost without benefit. See the Encryption Guide. |
Small organisations will usually consume HE inside a product or platform feature rather than build it. Larger organisations with a specific privacy-critical computation can pilot it with an open-source library: Microsoft SEAL (BFV, BGV, CKKS; MIT licence) and OpenFHE (BFV, BGV, CKKS, FHEW, TFHE and LMKCDEY, with threshold extensions) are the most widely referenced. Note that SEAL 4.4 was flagged by its maintainers as a critical security update for untrusted-input handling, a reminder that HE libraries need patching like any other dependency.
Piloting HE: a practical sequence
- Define the function precisely: inputs, output, multiplicative depth and acceptable error. If the function cannot be written down, HE is not ready for it.
- Write the threat model: who holds the secret key, what the server may learn (sizes, timing, the function), and whether the server is honest-but-curious or potentially malicious.
- Choose scheme and parameters: use library defaults or the HomomorphicEncryption.org parameter tables for at least 128-bit security; do not hand-tune.
- Prototype on plaintext and ciphertext side by side: compare results, measure latency, ciphertext size and memory.
- Plan key management: secret keys stay client-side in a key management system; evaluation keys are versioned and rotated. See the Cryptographic Key Management Guide.
- Keep a fallback: the non-HE path (or an enclave path) stays available until performance and accuracy targets are met in production.
Measure success by latency per query against the target, ciphertext expansion and bandwidth per request, cost per thousand operations versus the plaintext path, result error (for CKKS) within agreed tolerance, and zero secret keys present on server infrastructure.
Common misconceptions
- "HE means the server cannot do anything harmful." HE hides data; it does not stop the server from computing the wrong function, returning stale results or tampering with ciphertexts. Malleability is the feature that makes HE work. Integrity needs separate measures such as verifiable computation, redundancy or trusted execution.
- "Everything about the data is hidden." Ciphertext sizes, the number of queries, timing and the function itself are usually visible. Access patterns can leak meaning.
- "CKKS decryptions are safe to share." Because CKKS results carry noise derived from the secret key, published research (Li and Micciancio, 2021) showed that sharing decrypted results with another party can, in some settings, allow key recovery. Libraries have added mitigations, but treat CKKS decryptions as sensitive unless the library documents protection for that use.
- "FHE is too slow to be real." It is too slow for general computing, but production systems already serve narrow, high-volume lookups with careful batching. The honest position is: real for specific functions, not a drop-in replacement for plaintext processing.
- "All homomorphic encryption is post-quantum." Lattice-based FHE schemes are believed to resist quantum attacks; Paillier and ElGamal-based PHE rely on factoring and discrete logarithms and do not. See the Post-Quantum Cryptography Migration Guide.
- "There is an approved FHE standard to comply with." Not yet in final form. ISO/IEC 18033-6 covers only Paillier and exponential ElGamal; ISO/IEC 28033-1 was a Draft International Standard at the close of voting on 11 December 2025; NIST tracks FHE through its Privacy-Enhancing Cryptography project and Threshold Call (category S5) but has not issued an FHE standard.
Related concepts
| Concept | Relationship to HE |
|---|---|
| Secure multi-party computation (MPC) | Parties compute jointly over secret shares; often combined with HE and usually needs more interaction but less computation |
| Confidential computing | Protects data in use with hardware enclaves and attestation instead of mathematics |
| Differential privacy | Limits what outputs reveal about individuals; complements HE, which limits what the processor sees |
| Private information retrieval (PIR) | A protocol often built on HE that fetches a record without revealing which one |
| Post-quantum cryptography | Shares the lattice foundations of FHE; ML-KEM is also lattice-based |
| Proxy re-encryption | Converts ciphertexts from one key to another without decrypting; supported by some FHE libraries |
For the broader comparison of these techniques see the Privacy-Enhancing Technologies Guide, and for how quantum-safe options compare see the QKD vs Post-Quantum Cryptography Guide.
Practitioner checklist
- Write down the exact computation you need on encrypted data before choosing a scheme; additions only, bounded-depth arithmetic and approximate maths point to different schemes.
- Prefer a maintained open source library and parameter sets that meet the HomomorphicEncryption.org security standard, and record the parameters you chose.
- Benchmark latency, ciphertext size and memory on realistic data before committing, and compare against confidential computing or secure multi-party computation.
- Protect the secret key with the same controls as any high-value key: hardware-backed storage where possible, named custodians, rotation and access logging.
- Add integrity protection separately, because homomorphic encryption alone does not stop a server returning a wrong result.
- Treat metadata, access patterns and decrypted outputs as data that can still leak, and never share CKKS decryption results with untrusted parties without review.
- Track the ISO/IEC 28033 drafts and NIST work, and plan to re-check parameters when new standards or attacks are published.
Standards and references
- ISO: ISO/IEC 18033-6 Encryption algorithms, Part 6: Homomorphic encryption
- ISO: ISO/IEC DIS 28033-1 Fully homomorphic encryption, Part 1: General
- HomomorphicEncryption.org: Homomorphic Encryption Security Standard
- NIST: Privacy-Enhancing Cryptography, Fully Homomorphic Encryption
- OpenFHE: Open-Source Fully Homomorphic Encryption Library
- Microsoft: SEAL homomorphic encryption library
- Apple Machine Learning Research: Combining Machine Learning and Homomorphic Encryption in the Apple Ecosystem
Related NHI Mgmt Group resources: Privacy-Enhancing Technologies Guide · Confidential Computing Guide · Encryption Guide · Cryptographic Key Management Guide · Data Security Guide