Craig Gentry proved it was possible in 2009, after roughly three decades of cryptographers wondering whether it could exist at all. The idea: you encrypt your data, hand it to someone else, they run computations on it, hand back a result, and when you decrypt that result, it’s correct. The person who did the computing never saw your data. Not a scrubbed version. Not a hash. The actual underlying values, never exposed, not even for a microsecond. That’s fully homomorphic encryption — a form of encryption that lets a third party run computations on your data without ever decrypting it.
So, what is FHE (Fully Homomorphic Encryption)? This is not a trick. It’s a mathematical property of certain encryption schemes. You send someone a locked box. They rearrange the contents. You unlock it, and the arrangement is correct. They never had the key.
Why the alternatives don’t cut it
Before getting into how FHE works, it’s worth being specific about the problem it solves, because most approaches to “compute on sensitive data” involve a tradeoff people have learned to accept without questioning.
The standard approach: encrypt data at rest and in transit, decrypt before processing. Your cloud provider, your analytics vendor, your ML service—all of them need plaintext to do their job. You extend trust to them by necessity. This works until it doesn’t: a breach, a subpoena, an insider threat, a misconfigured access policy.
Trusted execution environments (TEEs) like Intel SGX create a shielded memory region that even the operating system can’t read. Sensitive computation happens inside the enclave. This is genuinely useful, but you’re trusting the hardware vendor and betting that the enclave implementation has no exploitable flaws. SGX has had several.
Differential privacy adds calibrated statistical noise to query results, which limits how much an attacker can infer about individuals from aggregated outputs. It protects aggregations, not computations on individual records.
FHE is the only approach where the data is never decrypted on the server at all, and the security proof doesn’t require trusting any hardware or any third party. The guarantee is mathematical.
The mechanics, briefly
FHE schemes define arithmetic operations directly on ciphertexts. Homomorphic addition and homomorphic multiplication on encrypted values produce, when decrypted, the same result as performing those operations on the underlying plaintexts.
Two operations sounds limited. It isn’t. Addition and multiplication over binary fields give you AND and XOR gates, which give you arbitrary digital circuits. Any function a computer can compute can be expressed in terms of these two operations. That’s the bridge from “arithmetic on encrypted numbers” to “arbitrary computation on encrypted data.”
The structural problem is noise. Each FHE operation introduces a small error into the ciphertext. Errors accumulate. Push through enough operations and the noise overwhelms the signal—the ciphertext becomes undecryptable. Gentry’s insight was bootstrapping: evaluating the decryption circuit homomorphically on the noisy ciphertext to produce a fresh, low-noise ciphertext with the same plaintext value. In other words, you run decryption inside the encryption. The noise resets without the data ever being exposed.
Schemes that handle a bounded number of operations before noise becomes fatal are called leveled or somewhat homomorphic. Bootstrapping is what earns the “fully” in FHE.
Where it’s being deployed now
For most applications, FHE is still too slow. The applications running today share a profile: bounded circuit depth, high sensitivity of the data, and a party on one side who can absorb compute costs in exchange for a mathematical privacy guarantee.
Private ML inference is the clearest fit. A client has sensitive inputs. A server has a proprietary model. FHE lets the server evaluate the model on encrypted inputs and return an encrypted result. Neither party exposes what they’re protecting. Zama ships this for specific model architectures. The circuit depth is predictable and manageable.
Private genomic analysis has been a benchmark workload since iDASH began running encrypted genomics competitions in 2014. Disease risk scoring, genome-wide association studies, and sequence alignment all have FHE constructions. Genomic data is one of the few data types where the privacy risk is both permanent and extends to people who never consented to share anything.
Confidential financial queries cover range queries, encrypted database lookups, and fraud scoring on encrypted transaction histories. These workloads run infrequently enough, and the data is sensitive enough, that the compute overhead is acceptable.
Blockchain confidentiality is an active area. Smart contracts execute publicly on-chain by default. TFHE-based systems let you run contract logic on encrypted state, which enables things like private auctions, confidential voting, and sealed-bid mechanisms where correctness is publicly verifiable but inputs aren’t exposed. Zama’s fhEVM project targets this specifically.
Security foundations
FHE security reduces to the hardness of Learning With Errors (LWE) and its ring variant (RLWE). These problems ask: given many approximate linear equations over a ring or lattice, recover the secret. No polynomial-time algorithm is known for either, on classical or quantum hardware.
This puts FHE in the post-quantum cryptography family. NIST’s post-quantum standardization is built on LWE-family problems, which gives the underlying assumptions additional scrutiny and confidence. That said, LWE has been under serious attack for less than 20 years. RSA and elliptic curves have 40+ years of failed cryptanalysis behind them. The confidence level is high but not identical.
Parameters govern security. Polynomial degree, modulus size, and noise distribution must be chosen to make the LWE instance hard at the desired security level. The HomomorphicEncryption.org consortium publishes recommended parameter sets. Using library defaults that have been validated against these recommendations is strongly preferred over custom configurations.
The competitive context
FHE is one of several privacy-preserving computation technologies, and they’re increasingly used together rather than as substitutes.
Secure multi-party computation (MPC) distributes a computation across multiple parties, none of whom sees the full input. It’s often faster than FHE for specific functions and is a natural fit when the parties are defined in advance. FHE works with a single untrusted server.
Zero-knowledge proofs (ZKPs) let one party prove a statement is true without revealing the witness. ZKPs prove; FHE computes. They’re complementary, and real systems use both: FHE for private computation, ZKPs for verifying the computation was done correctly.
Hybrid protocols combining FHE and MPC are an active research area. Neither technology alone satisfies every requirement; combining them can get you better performance and stronger guarantees than either independently.
