up:: Foundations MOC

Fully Homomorphic Encryption (FHE)

Fully homomorphic encryption (FHE) lets a computer run calculations directly on encrypted data and produce an encrypted result, so a cloud server can process your information while it stays ciphertext the whole time and the server never sees the plaintext. It answers a question ordinary encryption cannot: how do you get useful work done on data you are unwilling to reveal, even to the machine doing the work. The reassuring part of the quantum story is that mainstream FHE is already post-quantum in its hardness assumption. The workhorse schemes, BFV, BGV, CKKS, and TFHE, are all lattice-based, built on the Learning With Errors problem and its ring variant Ring-LWE, the same family of hardness that the post-quantum standards rest on and that Shor’s algorithm does not solve.

Source: Homomorphic Encryption Standardization, “Homomorphic Encryption Security Standard,” version 1.1, November 2018, homomorphicencryption.org.

The short version:

  • FHE computes on ciphertext and returns ciphertext, so data can be processed by an untrusted server without ever being decrypted, and only the key holder can read the result.
  • The mainstream schemes are BFV and BGV (exact integer arithmetic), CKKS (approximate real-number arithmetic for machine learning), and TFHE (fast boolean and comparison operations).
  • All of them are lattice-based, resting on LWE and Ring-LWE, which is a post-quantum hardness assumption rather than factoring or the discrete logarithm.
  • Because the hardness is lattice-based, Shor’s algorithm has no purchase on FHE, so the schemes carry forward through the quantum transition unchanged in their foundation.
  • The quantum caveat is about parameters, not the algorithm: Grover’s and better lattice attacks factor into how the LWE parameters are sized, which is a tuning exercise the security standard already accounts for.

Picture a jeweler who can set and polish a diamond while it stays locked inside a sealed glass box, working through built-in gloves, never touching the stone directly and never able to pocket it. You hand over the box, they do the delicate work, and you get it back finished, still sealed, and only your key opens it. That is what FHE does for computation. The data goes to the server inside a cryptographic box, the server does real work on it through the math of the scheme, and the answer comes back still sealed, readable only by you. The lock on that box is a lattice problem, which is why a quantum computer, so devastating to RSA and elliptic curves, does not open it.

What is fully homomorphic encryption?

Fully homomorphic encryption is an encryption scheme with a special algebraic property: operations performed on ciphertexts correspond to meaningful operations on the underlying plaintexts. Concretely, if you encrypt two numbers, an FHE scheme lets anyone holding only the ciphertexts and the public key compute a new ciphertext that decrypts to the sum or the product of the originals, without ever learning either input. Chain enough additions and multiplications together and you can evaluate any computation at all on encrypted data, which is what the word “fully” marks. Earlier partially homomorphic schemes supported only one operation; the breakthrough, from Craig Gentry in 2009, was making both work at once so arbitrary programs run on ciphertext.

Source: Homomorphic Encryption Standardization, “Homomorphic Encryption Security Standard,” version 1.1, November 2018, homomorphicencryption.org.

The property that makes FHE work is also the property that makes it heavy. Every FHE ciphertext carries a small amount of random noise that grows each time you compute on it, and if the noise grows too large the result becomes undecryptable. Managing that noise, either by keeping the computation shallow or by periodically refreshing the ciphertext through an expensive operation called bootstrapping, is the central engineering challenge of the field. None of that noise machinery has anything to do with quantum computing. It is a consequence of building the scheme on lattices, which is the same choice that gives FHE its quantum resistance.

Which schemes are the mainstream, and what do they do?

FHE is a small set of schemes tuned for different kinds of computation rather than a single algorithm, and knowing which is which tells you where each fits. The ones that dominate deployment and standardization:

  1. BFV and BGV. These support exact arithmetic on integers, adding and multiplying whole numbers under encryption with no rounding. They suit applications that need exact results, like encrypted database queries and secure statistics.
  2. CKKS. This scheme does approximate arithmetic on real and complex numbers, trading a controlled amount of precision for far more efficient computation on the kind of fixed-point math that machine learning uses. It is the common choice for privacy-preserving inference on encrypted inputs.
  3. TFHE. This scheme specializes in fast boolean gates and comparisons, with very fast bootstrapping, which makes it strong for evaluating decision logic and arbitrary circuits on encrypted data.

Source: Homomorphic Encryption Standardization, “Homomorphic Encryption Security Standard,” version 1.1, November 2018, homomorphicencryption.org.

The schemes differ in what arithmetic they express and how they manage noise, but they share the one thing that matters for the quantum question: every one of them is lattice-based, with security resting on LWE or Ring-LWE. That shared foundation is why the quantum verdict is the same across the whole family, and it is the opposite of the public-key family, where different schemes rest on different quantum-broken problems.

SchemeArithmetic it expressesCommon useRests onQuantum verdict
BFV / BGVExact integersEncrypted databases, secure statisticsLWE / Ring-LWEPost-quantum secure
CKKSApproximate realsPrivacy-preserving machine learningLWE / Ring-LWEPost-quantum secure
TFHEBoolean gates, comparisonsArbitrary circuits, decision logicLWE / Ring-LWEPost-quantum secure

Is FHE quantum-safe?

Yes, in its hardness assumption. Mainstream FHE is lattice-based, and lattice hardness is a post-quantum assumption, so FHE carries forward through the quantum transition where RSA and elliptic-curve cryptography do not. The security of BFV, BGV, CKKS, and TFHE reduces to the difficulty of the Learning With Errors problem: recovering a secret from a system of linear equations that has been deliberately fuzzed with small random noise. That problem is provably as hard as solving worst-case lattice problems, and no efficient quantum algorithm is known to solve it.

Source: Homomorphic Encryption Standardization, “Homomorphic Encryption Security Standard,” version 1.1, November 2018, homomorphicencryption.org.

The reason this matters is the same reason lattice cryptography became the mainstream of the post-quantum standards. Shor’s algorithm breaks RSA and the discrete-log schemes by exploiting the periodic, number-theoretic structure inside factoring and the discrete logarithm problem. Lattice problems like LWE have none of that structure for Shor’s to grab, so the algorithm that demolishes public-key cryptography does nothing to FHE. This is exactly why NIST built ML-KEM on the same Module-LWE foundation: it is the hardness that is expected to hold against a quantum computer.

Source: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016, NIST.

The honest caveat is about parameters rather than the algorithm. Grover’s search and steady improvements in classical and quantum lattice-reduction attacks do apply pressure on how large the LWE parameters have to be, so a well-built FHE deployment sizes its parameters against the current best attacks. That is a tuning exercise the security standard already bakes in, and it is a different thing from the structural collapse Shor’s algorithm inflicts on the public-key family. FHE gets its parameters chosen carefully; RSA gets replaced.

Why is FHE already post-quantum when RSA is not?

The contrast is entirely about what each rests on. RSA rests on factoring and the discrete-log schemes rest on the discrete logarithm problem, both of which have the hidden periodic structure that Shor’s algorithm converts into a fast quantum attack. Take away the hardness of those two problems and the whole public-key family stops working, which is the core of the quantum threat.

FHE was built on lattices from the start, for reasons that had nothing to do with quantum computers. Gentry’s construction needed a hardness assumption that supported the noisy, additive-and-multiplicative structure homomorphic operations require, and LWE fit because its noise is exactly what makes both the homomorphism and the security work. That the same lattice hardness also resists Shor’s algorithm is a fortunate consequence: the field chose lattices for their algebraic flexibility, and inherited quantum resistance along with it. So while the rest of the migration is a scramble to replace a broken foundation, FHE simply already sits on the foundation everyone else is moving toward.

Source: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016, NIST.

Where does FHE fit in a post-quantum migration?

FHE belongs in the “keep and parameterize” pile rather than the “rip and replace” pile, but it still interacts with the migration in ways worth planning for. The points that matter:

  1. The hardness assumption is safe, so no algorithm swap is needed. Where an RSA key exchange needs a whole new cryptographic family to survive the transition, an FHE deployment already sits on its destination. The lattice foundation is the safe harbor, so the scheme stays.
  2. Parameters have to track the current best lattice attacks. The one live maintenance task is keeping LWE parameter choices sized against improving cryptanalysis, which is standard practice for any lattice deployment and is guided by the security standard.
  3. The surrounding stack still has to migrate. FHE almost never runs alone. The keys that authenticate the parties, the TLS channel that ships the ciphertexts, and the signatures that vouch for the results usually rely on RSA or ECDH, which are quantum-broken. Securing an FHE workload end to end means migrating that public-key surrounding layer even though the FHE core is already safe.

Source: Homomorphic Encryption Standardization, “Homomorphic Encryption Security Standard,” version 1.1, November 2018, homomorphicencryption.org.

The takeaway is a comfortable one for a change. Fully homomorphic encryption is one of the corners of modern cryptography that the quantum transition does not threaten at its foundation, because it was already built on the lattice hardness that the post-quantum standards adopted. The work is to size it well and to make sure the RSA and elliptic-curve plumbing around it moves too, which is a job for a cryptographic inventory and crypto-agility.

Common misconceptions

  • “Quantum computers break all encryption, so they break FHE too.” FHE is lattice-based, resting on LWE, which Shor’s algorithm does not solve. It is already on a post-quantum foundation, so its hardness carries forward.
  • “FHE is just RSA or ECC applied to more data, so it has the same quantum problem.” FHE rests on lattice hardness, a completely different assumption from factoring or the discrete logarithm. The quantum verdict is opposite: RSA and ECC break, FHE survives.
  • “FHE needs a post-quantum replacement like RSA does.” It does not. There is no new family to migrate the FHE core to, because it is already lattice-based. The maintenance task is sizing parameters, not swapping algorithms.
  • “If my computation uses FHE, my whole pipeline is quantum-safe.” The FHE core is safe, but the authentication, transport, and signatures around it usually rest on RSA or ECDH, which are quantum-broken and still have to migrate.
  • “The noise in FHE ciphertexts is a quantum weakness.” The noise is a feature of building on lattices and is what makes both the homomorphism and the LWE hardness work. It is an engineering constraint on computation depth, unrelated to quantum attacks.

Questions people ask

Is fully homomorphic encryption quantum-safe? Yes, in its hardness assumption. The mainstream schemes (BFV, BGV, CKKS, TFHE) are lattice-based, resting on LWE and Ring-LWE, which is a post-quantum assumption that Shor’s algorithm does not break.

Why does quantum break RSA but not FHE? RSA rests on factoring, which has the structured math Shor’s algorithm exploits. FHE rests on lattice problems like LWE, which have no such structure, so Shor’s has no purchase on it. FHE was built on lattices for their flexibility and inherited quantum resistance as a result.

Are BFV, BGV, CKKS, and TFHE all post-quantum? Yes. All four are lattice-based on LWE or Ring-LWE, so they share the same post-quantum hardness. They differ in what arithmetic they express (exact integers, approximate reals, boolean gates), not in their quantum standing.

Do I need to do anything to make FHE quantum-safe? The FHE core needs its LWE parameters sized against current lattice attacks, which is standard practice and guided by the security standard. The bigger job is migrating the RSA and ECDH plumbing around the FHE workload, since that surrounding layer is quantum-broken.

Is FHE the same as the post-quantum standards NIST released? They share a foundation. ML-KEM and mainstream FHE both rest on Module-LWE or Ring-LWE lattice hardness, which is why both resist Shor’s algorithm. FHE does a different job (computing on ciphertext) than a KEM (agreeing a key), but the quantum-hard math underneath is the same family.

Does harvest-now-decrypt-later threaten FHE? Not at the FHE layer, because its lattice hardness is expected to hold against a future quantum computer. The harvest-now-decrypt-later risk sits in any RSA or ECDH key exchange that ships the ciphertexts, which is one more reason to migrate the surrounding public-key stack.


Everything here is the map, given freely. When your team needs its own cryptography sorted into what already survives the quantum transition and what still has to move around it, that’s what an alignment briefing is for.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.