Fully Homomorphic Encryption (FHE) – The Architecture of Privacy

We’ve spent decades perfecting how we lock up our digital lives. We have “safes” for our data when it’s sitting on a hard drive and “armored tunnels” for when it travels across the internet. But there has always been one glaring, dangerous gap: what happens when we actually want to use the data?

Historically, to analyze a medical record or process a financial transaction in the cloud, we had to decrypt it. For a few milliseconds, that sensitive information is “naked” in the computer’s memory, vulnerable to hackers or even the cloud provider itself. This is the “decryption gap,” and Fully Homomorphic Encryption (FHE) is the mathematical breakthrough that finally closes it.

What is Fully Homomorphic Encryption

Fully Homomorphic Encryption (FHE) is often called the “holy grail” of cryptography. It lets you perform any computation—addition, multiplication, comparisons, even entire machine-learning models—directly on encrypted data, so the result is an encrypted version of what you would have gotten in plaintext. No decryption is ever needed until the very end, when only the data owner (who holds the secret key) can see the answer. In other words, one can encrypt data and outsource computation (e.g. to the cloud) while the server never sees the plaintext. 

This is radically different from traditional encryption. Traditional encryption protects data at rest (e.g. encrypted files, databases) and data in transit (e.g. TLS, VPNs), but fails at data in use. To compute on data, systems normally decrypt it into cleartext. This creates a vulnerability “gap” where sensitive data is exposed (e.g. in memory or CPU) to insiders or malware.

• Symmetric encryption (AES, 3DES, ChaCha20) uses the same key for encrypt and decrypt. It protects data at rest or in transit but requires decryption before any useful work.
• Public-key encryption (RSA, ECC, ElGamal) lets anyone encrypt with a public key, but only the private-key holder can decrypt. Again, computation happens only after decryption.

FHE breaks this barrier. The ciphertext behaves like the plaintext under arithmetic operations: if you add two ciphertexts, you get the encryption of the sum; multiply them and you get the encryption of the product. The server (or cloud) never sees plaintext or the secret key.

The term “homomorphic” comes from Ancient Greek roots: homo- (same) + morphic (form/shape). It literally means “same shape”—operations on ciphertexts preserve the algebraic structure of the underlying plaintext operations. (Note: while “homo” appears in Latin as “same,” the cryptographic term derives from Greek roots.) In math, a homomorphism is a structure-preserving map. In our case, it means that if we perform math on encrypted data, the “shape” of the result stays the same as if we had done the math on the original, unencrypted numbers.

While the term sounds modern, the idea is quite old. Shortly after inventing RSA in 1978, Ronald Rivest and his colleagues theorized that we could create “privacy homomorphisms”. For thirty years, we could only do pieces of it—some schemes allowed you to add encrypted numbers, others allowed you to multiply them, but never both at once. That changed in 2009 when Craig Gentry, then a PhD student at Stanford, published a dissertation that showed the world it was actually possible to do both, infinitely.

A Brief History

The dream dates to 1978, when Rivest, Adleman, and Dertouzos asked whether “privacy homomorphisms” could exist. Early partial solutions emerged: RSA (multiplicative) and Paillier (additive). But no scheme supported both addition and multiplication arbitrarily deep until Craig Gentry’s breakthrough in 2009. Gentry’s PhD thesis constructed the first true FHE using ideal lattices and introduced “bootstrapping”—a technique to refresh noise in ciphertexts without decrypting. Subsequent work (Brakerski–Gentry–Vaikuntanathan 2011/2012, Fan–Vercauteren, Cheon–Kim–Kim–Song, Chillotti–Gama–Georgieva–Izabachene) produced practical, leveled, and fully homomorphic schemes that run in seconds or minutes instead of hours.

Why Traditional Encryption Is No Longer Enough

We live in a world of cloud computing, federated learning, and privacy regulations (GDPR, CCPA, HIPAA). Traditional encryption fails in three critical scenarios:

1. Cloud outsourcing — You cannot safely send encrypted data to a third-party server for analysis without giving the server the key (or decrypting first).
2. Secure multiparty computation — Banks, hospitals, insurance, universities or governments want to collaborate on sensitive data without revealing their inputs.
3. Privacy-preserving AI/ML — Training or inference on encrypted medical images, financial transactions, or personal data.

Think of traditional encryption like a secure envelope. You can send it through the mail (Data in Motion) or keep it in a filing cabinet (Data at Rest) quite safely. But if you want to edit the document inside, you have to open the envelope.

This creates a massive problem for the modern world. We want to use cloud-based AI to diagnose diseases or detect bank fraud, but we don’t necessarily want the cloud provider to “read our mail”. FHE allows the server to process the data while it is still inside the envelope. The server never sees the contents; it just manipulates the envelope in a way that changes the paper inside correctly.

FHE addresses this by providing a third layer of security: it keeps data encrypted during computation. For example, a medical analytics firm could run queries on patients’ encrypted health records in the cloud: the cloud computes results without ever seeing the raw data. Even if an attacker breaches the computation node, they only see ciphertexts. As one survey notes, homomorphic encryption “eliminates the need for processing data in the clear, thereby preventing attacks that would enable an attacker to access that data while it is being processed”.

In cloud computing or multi-organization collaborations, parties want to leverage third-party compute (AI/ML, data analytics) on private data without sharing secrets. FHE enables tasks like secure machine-learning inference, confidential database queries, or encrypted search (e.g. “does this encrypted image contain a face?”).

For instance, homomorphically scanning encrypted photographs for features is possible without revealing the photos. In finance or healthcare, FHE can enable privacy-compliant analytics: e.g. banks could run credit-scoring models on encrypted financial data from clients, or hospitals could aggregate encrypted patient data for research, all without exposing individual details.

Notably, FHE-based schemes are also believed to be post-quantum secure (lattice problems underpinning FHE are not efficiently solved by known quantum algorithms), making FHE attractive as a future-proof privacy tool.

Real-world necessity examples:

• Healthcare: A hospital uploads encrypted patient records; a cloud analytics provider runs statistical models or trains diagnostic ML models without ever seeing PHI.
• Finance: Banks compute joint fraud models across institutions without sharing client data.
• Blockchain: Smart contracts execute on fully encrypted state. FHE addresses blockchain privacy challenges, enabling confidential DeFi, secure voting, and private transactions.
• Governments perform secure census or tax computations.
• Private AI: You could ask a chatbot a sensitive question, and the provider would only ever see encrypted gibberish.

Without FHE, you must trust the cloud (or decrypt, exposing data). With FHE, trust is cryptographic, not contractual.

The Three States of Data

In the security world, we categorize data into three states:

1. Data at Rest: Files sitting on your hard drive or in a database. We usually use symmetric encryption like AES to lock these down or full-disk encryption, which secures the data except during use.
2. Data in Motion/transit (moving across a network): Information moving over the internet (like this webpage). We use TLS/SSL, VPNs to create a secure tunnel for it by encrypting data packets end-to-end.
3. Data in Use (being processed in memory or CPU): This is the most challenging and Information currently being crunched by a CPU. Typical encryption schemes must decrypt data for computation (exposing it). This is where FHE lives.

FHE and related techniques target data in use. For data in use, common approaches include searchable encryption, hardware based secure enclaves (Intel SGX/AMD SEV), and homomorphic encryption. Those still rely on trusting the hardware manufacturer. Unlike those, FHE allows general computations without decryption. In practice, one might use AES (symmetric) for data at rest, TLS/SSL for data in motion, but employ FHE when performing analytics or machine learning on live data. Thus, FHE “fills the gap” left by traditional encryption during data use. FHE relies on nothing but the laws of mathematics.

The Science of “Hard Problems”

Basically The Foundation of Security

Cryptographers love “Hard Problems”—puzzles that are easy to check but nearly impossible to solve. To understand where FHE fits, we look at computational complexity theory :

• P (Polynomial Time): The “easy” stuff. Computers can solve these quickly (e.g., sorting a list or multiplying numbers).
• NP (Nondeterministic Polynomial): The “verifiable” stuff. Hard to solve, but easy to check once you have the answer (like a Sudoku puzzle).
• NP-Complete: The hardest problems in the NP category (e.g., Travelling Salesman Problem, 3-SAT). If you solve one efficiently, you solve all NP problems.
• NP-Hard: The “nightmare” mode. These are at least as hard as the hardest problems in NP (may not even be in NP)., and some might not even have a solution you can check.

Cryptographic security rests on mathematical problems that are intractable (no known efficient solution).

• A polynomial-time algorithm is one whose running time is bounded by a polynomial function of the input size (e.g. O(n²)); such algorithms are considered efficient.
• Problems that require worse-than-polynomial (e.g. exponential) time are called non-polynomial or hard. Complexity classes formalize these notions. 
  • P is the class of problems solvable in polynomial time. 
  • NP (nondeterministic polynomial time) is the class of decision problems for which a “yes” solution can be verified in polynomial time.
  • A problem is NP-hard if solving it (in polynomial time) would solve all problems in NP, and NP-complete if it is both in NP and NP-hard. In practice, NP-hard/complete problems are believed to have no polynomial-time solutions (unless P=NP, which is considered unlikely).

A key foundation of modern FHE is lattice-based cryptography. A lattice in mathematics is a regular grid of points in space generated by integer linear combinations of basis vectors. Lattice problems used in FHE—Shortest Vector Problem (SVP) (asks for the shortest nonzero vector in a given lattice basis) and Closest Vector Problem (CVP) (asks for the lattice point nearest a given external point) —are believed to be NP-hard (worst-case) and average-case hard under the Learning With Errors (LWE) assumption. Example: Given a high-dimensional lattice, find the shortest non-zero vector. No known polynomial algorithm (classical or quantum) solves this efficiently for the parameters used in FHE.

The Traveling Salesman Problem (TSP) – find the shortest route visiting a set of cities – is NP-hard. The Subset Sum decision problem (“can a subset of given numbers sum to a target?”) is NP-complete. These problems can be solved in principle, but only by exponential-time algorithms for general inputs. Cryptography exploits such hardness: e.g., factoring large integers (used in RSA) is believed not to have polynomial algorithms (though factoring is not known NP-hard) and lattice problems (used in FHE) are proven NP-hard for certain approximations.

Simple analogy

• TSP → Planning a delivery route (shortest tour)
• SVP → Finding the shortest possible move in a grid (shortest vector)
• CVP → Finding the nearest parking spot to you (closest point)

In summary, encryption relies on hard problems: the easier (polynomial-time) such a problem were solved, the weaker the encryption. FHE schemes rely on lattice problems and Learning-With-Errors, which are conjectured to be infeasible to solve quickly (no known polynomial solutions), even with a quantum computer.

How FHE Works

Fully Homomorphic Encryption (FHE) is a revolutionary cryptographic technique that allows computations to be performed directly on encrypted data (ciphertext) without decrypting it first.

1. The Top Row: The “Standard” Way
   • In a normal world, if you have two numbers, a and b (like your salary and your partner’s salary), and you want to find the total:
     • You take the raw data.
     • You Compute (add them together).
     • You get the result: a * b.
   • The Problem: Whoever did the math saw your actual salaries.

2. The Vertical Arrows: The “Shield”
   • Instead of sharing your raw data, you Encrypt it.
     • a becomes E(a) (an unreadable scrambled mess).
     • b becomes E(b).
     • Now, even if a hacker or a cloud provider looks at the data, they just see gibberish.

3. The Bottom Row: The “Magic” of FHE
   • This is where FHE differs from regular encryption (like the kind used for your emails).
   • With standard encryption, if you try to add two encrypted files, you just get more broken gibberish.
   • With FHE, the math works through the encryption.
     • You can Compute on E(a) and E(b) directly.
     • The result is E(a * b)—an encrypted version of the correct answer.

The Big Reveal: $E(a) * E(b) = E(a * b)$

The diagram shows that the result you get from working on the encrypted data (bottom right) is exactly the same as if you had worked on the raw data and then encrypted it (top right).

The “Locked Box” Analogy:

Imagine you have raw gold $(a\,and\,b)$. You put them in a locked box (Encryption). You give that box to a worker. Through built-in gloves in the box, the worker can solder the gold together $(a\,*\,b)$ without ever actually touching the gold or opening the box. They hand you back the box; you unlock it, and the finished jewelry is inside.

FHE is a public-key encryption scheme with extra structure. In a typical FHE setup:

1. KeyGen
2. Encryption
3. Homomorphic Eval
4. Relinearization (Key Switching)
5. Bootstrapping

Underlying the above is the Learning With Errors (LWE) problem (and its ring variant). Let’s delve deeper into those mathematical concepts.

Mathematics and Comparison to Public-Key Encryption

Public-key encryption (e.g., RSA) relies on one-way functions (factoring). FHE relies on lattice-based problems that remain hard even after many homomorphic operations.

Core primitive: Learning With Errors (LWE) and Ring-LWE

Learning With Errors (LWE)

Think of it like this: If I give you a simple math equation like $10x = 20$, you know $x=2$ instantly. That’s too easy. But what if I add a tiny bit of random “noise”?

$10x + 0.1 = 20.1$ or $10x – 0.2 = 19.8$

Now, if you have hundreds of these “noisy” equations, finding the secret $x$ becomes incredibly difficult.

In FHE, we use this noise to hide the data.

• Encryption: We take our secret, add some random math, and a dash of noise.
• Math in the Dark: We can add or multiply these noisy ciphertexts. But there’s a catch: every time we do math, the noise grows.
• The Breakthrough (Bootstrapping): If the noise gets too loud, we can’t “hear” the data anymore and decryption fails. Gentry’s big idea was bootstrapping—a way to “refresh” the ciphertext and clean out the noise so we can keep working.

A simple LWE public key:

• Secret vector – s (private, A secret vector that must be kept secure.)
• Public matrix/Mask  – A (random, A public matrix of random values.)
• The Noise – e (Small, randomly generated errors added to every equation. This is the critical component that makes LWE hard to break.)$$
• The Result/$$Public vector – b (The output of the formula = $A.s + e (mod q)$)

Encryption of a bit m adds a controlled amount of noise. Decryption subtracts A s and looks at the noise distance to recover m

Ring-LWE

is a math problem used to build modern encryption systems that are believed to be secure even against quantum computers. Uses polynomials like expressions with x², x³, etc. and used in BFV/BGV/CKKS.

• Public key elements are ring elements.
• Operations become polynomial addition/multiplication.

Think of it like this:

• Secret = a hidden key
• You see scrambled equations with noise
• You try to recover the key

But:

• Noise makes it confusing
• Using polynomials makes it even more complex

So instead of: $2x + 3y$ You get something like: $(2 + x) · s + error$

Ciphertext format (simplified BFV/CKKS):

$ct = (c₀, c₁) c₀ = u·pk₀ + m + e₀ c₁ = u·pk₁ + e₁$

• u = random
• $e₀, e₁$ = small noise
• $pk = (pk₀, pk₁)$

Public key itself is RLWE-structured

• Typically:
  • $pk₀ = -(a·s + e)$
  • $pk₁ = a$
• So when you compute:
  • $c₀ = u·pk₀ + m + e₀$
  • $c₁ = u·pk₁ + e₁$

Homomorphic addition: ct₁ + ct₂ Homomorphic multiplication: ct₁ × ct₂ (produces a degree-2 ciphertext that must be “relinearized” back to degree 1 using an evaluation key—a special key-switching hint encrypted under the same secret).

Let me explain, let’s talk about

Homomorphic addition

• If:
  • $ct₁ = (c₀, c₁)$
  • $ct₂ = (d₀, d₁)$
• Then:
  • $ct₁ + ct₂ = (c₀ + d₀, c₁ + d₁)$

This corresponds to: $m₁ + m₂$

This is Easy, Stays the same size (still 2 parts)

Homomorphic multiplication

This is where things get interesting.

• When you multiply:
  • ct₁ × ct₂

You are multiplying two encrypted values

• But now:
  • $(c₀, c₁) × (d₀, d₁)$
• produces:
  • $(c₀d₀, c₀d₁ + c₁d₀, c₁d₁)$

• This is now 3 components: $(c₀’, c₁’, c₂’)$

Why is that a problem?

• Originally: $ct = (c₀, c₁) ← degree 1$
• After multiplication: $ct = (c₀, c₁, c₂) ← degree 2$
• The ciphertext “degree” increased
• Problem:
  • Decryption expects 2 parts, not 3
  • If you keep multiplying, size keeps growing

What is “relinearization”?

It’s a trick to shrink ciphertext back to 2 parts

$(c₀, c₁, c₂) → (c₀’, c₁’)$

So it becomes usable again.

What is the “evaluation key”?

Contains encrypted key-switching material (relinearization keys, rotation keys, etc.) that lets the server transform ciphertexts without knowing the secret.

The sentence says: “using an evaluation key—a special key-switching hint”

This means:

• You have a special key (not the secret key)
• It helps convert: $c₂ · s² → something\,using\,only\,s$
• Why?
  • Because:
    • After multiplication, terms involve s² (secret key squared)
    • But decryption only knows how to handle s

So we “rewrite” it using this helper key

Noise growth is the central enemy. Every multiplication roughly squares the noise. When noise exceeds a threshold, decryption fails.

• If noise becomes too large, rounding fails
  • m + big noise → wrong value
  • So: Decryption gives the wrong answer

Noise in addition	Noise in multiplication (the problem)
If you add two ciphertexts: small + small = slightly bigger Growth is slow and manageable	When you multiply: (m₁ + e₁)(m₂ + e₂) Expand it: = m₁m₂ + m₁e₂ + m₂e₁ + e₁e₂

• The noise becomes: new noise ≈ e₁e₂ + other terms.
• So noise roughly: multiplies with itself → grows very fast
• There is a threshold:
  • if noise > limit → decryption fails

Bootstrapping

Bootstrapping = cleaning a noisy ciphertext by “refreshing” it.

• It turns: noisy ciphertext → fresh ciphertext (same message, low noise)

Gentry’s genius: Craig Gentry realized: “What if we evaluate the decryption function itself on encrypted data?” Homomorphically decrypt the ciphertext using an encrypted version of the secret key. This produces a fresh ciphertext with tiny noise—resetting the noise budget. Modern TFHE-style schemes do “gate bootstrapping” in milliseconds.

1. You have a noisy ciphertext
   • $ct (contains\,m, but\,noisy)$
2. Encrypt the secret key
   • $Enc(s)$ – This is weird but crucial: The system now has an encrypted version of its own key
3. Homomorphically decrypt
   • Now compute: $Decrypt(ct, s)$
   • But Do it while everything is still encrypted
   • $Enc(Decrypt(ct, s))$
4. Outcome: A new ciphertext of the same message $m$
5. But:
   • Noise is very small again
   • It’s like a “reset”

In modern schemes like TFHE: Instead of refreshing big ciphertexts,

They:

• Work at the level of logic gates (AND, OR, NOT)
• Bootstrap after almost every gate

Concept	Meaning
Noise	grows with operations
Problem	too much noise breaks decryption
Bootstrapping	resets noise
Result	unlimited computations (FHE)

Making it Fast: The Fourier Connection

FHE is notoriously slow because it doesn’t just multiply two numbers; it multiplies massive polynomials with tens of thousands of terms. FHE schemes based on Ring-LWE (the most practical family) represent plaintexts and ciphertexts as polynomials in a ring $ℤ[x]/(x^N + 1)$. Doing this the “old fashioned” way takes O(n²) time—which is a disaster for performance.

To fix this, we use the Number Theoretic Transform (NTT), a cousin of the Fast Fourier Transform (FFT) used in audio processing. Just like an FFT turns a complex sound wave into simple frequencies, the NTT moves our math into a “domain” where multiplication becomes much faster. This reduces the complexity to $O(n log n)$, which is the secret sauce behind modern FHE speed. Every major FHE library (SEAL, OpenFHE, HElib, TFHE-rs) spends most of its cycles inside optimized NTT kernels.

On the algorithmic side, polynomial arithmetic in FHE often uses number-theoretic analogues of the Fourier transform. Many FHE schemes encrypt messages as coefficients of polynomials in a ring (e.g. $ℤ/qℤ[x]/(X^N + 1)$). Multiplication of polynomials then corresponds to cyclic convolution of their coefficients. To speed this up, implementations employ the Number Theoretic Transform (NTT), a finite-field analogue of the Fast Fourier Transform (FFT).

For example, the popular BFV/BGV schemes use a cyclotomic polynomial modulus $(X^N + 1)$ precisely so that polynomial multiplication can be done efficiently via a Discrete Fourier/NTT transform. In this way, the Fourier (or NTT) domain speeds up homomorphic operations on encrypted data.

In short: the mathematical “shape-preserving” property of FHE is powered by the same transform that makes signal processing efficient. Accelerators (GPUs, FPGAs, ASICs) are essentially building ultra-fast NTT engines.

“Moore’s Law” of FHE Performance

A persistent challenge is that FHE is currently much slower than plaintext computation. Early estimates (and even today) suggest FHE runtimes can be on the order of millions of times slower than unencrypted computation. Gentry’s 2009 scheme took ~30 minutes per multiplication.

In Jeremy Kun’s words, “running FHE on CPU is at least a million times slower than the corresponding unencrypted program”. In other terms, achieving practical performance may require roughly 20 doublings (2^20 ≈ 1,000,000) – akin to waiting for 20 “Moore’s Law” cycles of speedup. Research and hardware improvements are continuously closing this gap.

For example, several groups have ported core FHE operations to GPUs or custom accelerators. The startup Zama is even developing dedicated FHE ASICs, claiming these could boost throughput from tens of transactions/sec to thousands (e.g. projected “10,000+ TPS” with ASICs). More algorithmically, improvements in parameter selection, packing (SIMD slots), and optimized bootstrapping have steadily cut constants and orders of magnitude from runtimes.

As a result, modern FHE libraries (SEAL, OpenFHE, PALISADE, TFHE, etc.) can perform simple homomorphic additions in microseconds and bootstrappings in milliseconds for small messages. The pace is rapid: IBM, Microsoft and others continually release faster versions. In short, while FHE is not yet as “fast” as normal encryption, it is improving quickly – the community often compares it to needing dozens of “Moore’s Law” doublings, and progress suggests this is achievable over the coming years.

FHE Schemes and Variants

FHE comes in many flavors. Early schemes (Gentry’s 2009) were lattice/ideal-lattice based. Subsequent work produced various FHE schemes optimized for different use-cases:

1. BFV/BGV (Brakerski/Fan-Vercauteren or Brakerski-Gentry-Vaikuntanathan): These are integer/fixed-point arithmetic schemes based on RLWE. They support exact addition/multiplication on modular integers or scaled fixed-point numbers. Both use techniques like rescaling/modulus-switching to manage noise. These are very mature and available in libraries like SEAL, PALISADE.
2. CKKS (Cheon–Kim–Kim–Song): An approximate arithmetic scheme. It encodes real or complex numbers (with some precision loss) so that additions/multiplications compute approximate results. CKKS excels for machine learning tasks (e.g. inference, linear algebra, evaluations of Taylor series) where slight error is acceptable. It includes a rescaling operation (similar to modulus switching) to control noise and scale. For example, CKKS is widely used in encrypted ML inference on real-valued data.
3. TFHE/CGGI (Chillotti-Gama-Georgieva-Izabachene): A “boolean/bitwise” scheme. Often called TFHE or FHEW, this uses LWE and focuses on very fast bootstrapping (single gate bootstrap ~8ms). TFHE encrypts small (1-8 bit) messages and can evaluate arbitrary binary gates by programmable bootstrapping. It is useful for boolean circuits (e.g. encrypted boolean logic or lookup-table evaluation) and excels when rapid bootstrapping allows gate-by-gate evaluation.
4. Other Variants/Leveled FHE: There are also leveled (non-bootstrapping) FHE, somewhat-homomorphic encryption (SHE) supporting limited depth, and variants like HEAAN (an earlier name for CKKS). OpenFHE and PALISADE libraries support all major schemes (BGV, BFV, CKKS, TFHE, etc.). The FHE landscape also includes optimizations like packing (encrypting vectors of data in one ciphertext for SIMD operations) and batching (for parallelism). In summary, the main FHE algorithms differ by message type (integer vs real vs bit) and performance trade-offs, but all provide homomorphic addition and multiplication (with bootstrapping enabling full generality).

FHE and Quantum Computing

Finally, FHE is essentially “Quantum-Proof.” One worry in cryptography is whether quantum computers could break encryption. Fortunately, most FHE schemes are based on lattice problems (SVP, LWE) that are believed to be quantum-resistant. Shor’s quantum algorithm (which breaks RSA/ECC by solving discrete log/factoring) does not efficiently solve lattice problems. Indeed, modern FHE security proofs reduce the scheme to worst-case lattice assumptions (GapSVP) even under quantum reductions.

In practice, lattice-based cryptography (including FHE) is considered a leading candidate for post-quantum security. As one industry analysis notes, “FHE schemes are believed to be quantum resistant”. That said, quantum computers can still offer generic speed-ups (e.g. Grover’s algorithm halves security parameters), so FHE schemes choose large enough keys to account for that. In short, FHE is generally thought safe against foreseeable quantum attacks, and in fact provides privacy even after such advances.

Who is building this?

We are moving from academic papers to real hardware. Major tech and crypto companies are developing FHE tools and services. For example:

• IBM has championed FHE for years. Their HElib (an open library) is widely used; IBM even released FHE toolkits for macOS/iOS (and later Linux/Android) based on HElib. IBM researchers worked with clients (like a Brazilian bank) to demonstrate encrypted predictions using FHE. They offer consulting and toolkits to help enterprises adopt FHE.
• Microsoft has released the open-source SEAL library for FHE. SEAL implements BFV and CKKS and is engineered for ease-of-use (MIT license). Microsoft’s research site highlights SEAL as enabling encrypted cloud computation where “the customer never needs to share their key”.
• Duality Technologies is a company (and co-founder of OpenFHE) providing FHE consulting and products. Their OpenFHE (openfhe.org) library supports all major schemes and is backed by industry and DARPA.
• Zama is an open-source crypto startup focusing on FHE. They’ve built Concrete, an FHE compiler and framework (based on TFHE) to make encrypted programming easier. Zama envisions using FHE to bring confidentiality to blockchains and finance, claiming high throughputs (tens of TPS now, aiming for thousands with hardware).
• Amazon/AWS offers FHE tooling in their cloud. In 2023 AWS published a guide on using FHE with SageMaker (ML) endpoints. They leverage libraries like SEAL (via wrappers like Pyfhel) to enable encrypted inference in the cloud. AWS also has the “Homomorphic Implementor’s Toolkit” for designing FHE circuits (e.g. for the CKKS scheme).
• Cornami: Building a “Sea of Cores” processor (Mx2) designed specifically to run FHE at speeds close to regular math.
• Niobium: Developing custom ASIC chips and PCIe cards to structurally eliminate data bottlenecks.

Other vendors and researchers active in FHE include Google (TensorFlow Privacy has FHE options), Intel (research on homomorphic encryption hardware), CryptoExperts and other cryptography startups, and various academic labs. The field is also getting attention in standards: for example, ISO/IEC is drafting a standard (WD 18033-8) for homomorphic encryption.

The Future : Privacy by Default

Fully homomorphic encryption is transitioning from theory to practice. Performance continues to improve rapidly with better algorithms, implementations, and hardware acceleration. Specialized hardware (GPUs, FPGAs, even dedicated ASICs) promise large speed-ups.

On the software side, efforts like FHE compilers (IBM, Zama, Microsoft, Google) and encrypted-programming frameworks are making FHE easier to use. We expect FHE to become common in privacy-sensitive domains: privacy-preserving AI (encrypted ML and analytics), secure multi-party collaborations, and confidential cloud services. Integration with other “confidential computing” tech (like enclaves and MPC) will yield hybrid solutions. Standardization and larger developer ecosystems will drive adoption.

Challenges remain—noise management, key-size overhead, and developer education—but the trajectory is clear. FHE is moving from “research curiosity” to “must-have infrastructure” for any organization that processes sensitive data in the cloud.

We are entering an era where privacy will be “implicit.” Soon, you won’t need to trust a cloud provider to keep your data safe because they simply won’t be able to see it. With the “Moore’s Law of FHE” driving performance up every year, we are quickly approaching a world where encrypted computation is just as fast as the “naked” math we do today.

The architecture of privacy is being built right now, dot by dot, on a multi-dimensional grid.

Is Your Privacy Ready for the Quantum Age? A Guide to Quantum Cryptography

The Quantum-Safe Architecture of IBM Power11