Fully homomorphic encryption: computing without decrypting the data

Most encryption protects data while it is stored or moving across a network. Processing is the awkward part. A server normally has to decrypt the data before it can search, classify, compare, or calculate anything.

Fully homomorphic encryption, usually shortened to FHE, changes that model. It lets a system compute directly on ciphertext and produce an encrypted result. The system performing the work doesn’t need access to the underlying data.

The key holder decrypts the result afterward.

Key takeaways

• FHE allows general computations on encrypted data.

• The party performing the computation doesn’t need the decryption key.

• Most modern FHE schemes rely on lattice-based security assumptions.

• Privacy-preserving AI and confidential cloud workloads are leading use cases.

• FHE still carries substantial costs in compute time, memory, and ciphertext size.

What is fully homomorphic encryption?

FHE is an encryption method that supports arbitrary computations over encrypted values.

In simplified form, a user encrypts some data and sends the ciphertext to another system. That system evaluates a function without decrypting the input. It returns another ciphertext, which the user decrypts to obtain the result.

The relationship can be written as:

Decrypt(Evaluate(function, Encrypt(data))) = function(data)

The output should match the result of running the same function on the original plaintext, subject to the numeric behavior of the chosen scheme.

The word “homomorphic” refers to this preservation of mathematical structure. Operations performed on ciphertext correspond to operations on the values hidden inside it.

How FHE differs from conventional encryption

Conventional encryption usually protects two states:

• Data at rest, such as an encrypted database

• Data in transit, such as a message protected by TLS

The server still needs plaintext while processing the data. If that server is compromised, misconfigured, or operated by an untrusted party, the information may be exposed.

End-to-end encryption limits which endpoints can read a message, but an authorized endpoint eventually decrypts it. FHE allows an evaluator to work on the data without becoming an authorized reader.

That distinction matters for outsourced computing. A cloud provider could run a calculation without receiving the plaintext or the key needed to reveal it.

The idea predates the first working construction

The idea of computing over encrypted data dates to work by Ronald Rivest, Leonard Adleman, and Michael Dertouzos in 1978.

Craig Gentry provided the first plausible fully homomorphic construction in his 2009 Stanford dissertation. His work showed how a scheme supporting a limited amount of encrypted computation could be refreshed and extended into one capable of evaluating arbitrary circuits.

That breakthrough established that FHE was possible. It didn’t make it fast. Early constructions were far too expensive for most real workloads, and performance has remained the field’s central engineering problem.

How FHE works

An FHE system generally has four main operations.

Key generation

The user generates a public key for encryption and evaluation, along with a secret key for decryption. Some schemes use extra evaluation keys for specific homomorphic operations.

Encryption

The plaintext is encoded and encrypted. The resulting ciphertext is much larger and more complex than the original value.

Evaluation

A server applies an approved function to the ciphertext. At the lowest level, most computations are represented through additions and multiplications, or through Boolean gates.

These basic operations can be combined into larger circuits for comparisons, statistics, database queries, and machine-learning inference.

Decryption

The server returns an encrypted output. Only a party holding the appropriate secret key can decrypt it.

The server sees the ciphertext, the function it was asked to evaluate, and operational metadata. It doesn’t see the protected input or decrypted result.

Noise and bootstrapping

Many FHE schemes add mathematical noise during encryption. Homomorphic operations increase that noise.

If it grows beyond a scheme’s limit, the ciphertext can no longer be decrypted correctly. This restricts how much work can be done before the ciphertext needs to be refreshed.

Bootstrapping performs that refresh homomorphically. In effect, the system evaluates part of its own decryption process while the data remains encrypted. The refreshed ciphertext can then support more computation.

Bootstrapping is what makes computation depth effectively unbounded. It is also expensive, though modern schemes and hardware have reduced the cost substantially.

Not every workload requires it. Leveled homomorphic encryption can evaluate a circuit of known depth without bootstrapping, which may be faster when the calculation is limited in advance.

Lattice-based security and quantum resistance

Most practical FHE systems are built around lattice problems, often variants of Learning With Errors or Ring Learning With Errors.

These problems are believed to resist known attacks from both classical and quantum computers. That makes lattice-based FHE relevant to post-quantum cryptography.

“Quantum-safe” still needs qualification. Security depends on the exact scheme, parameter choices, implementation, and future cryptanalysis. FHE also isn’t interchangeable with standardized post-quantum key encapsulation or signature algorithms. They solve different problems.

Where FHE can be useful

Private AI inference

A user can encrypt input data before sending it to an externally hosted model. The service evaluates the model over ciphertext and returns an encrypted prediction.

The provider can run the model without reading the user’s raw input. This may be useful for medical records, financial information, biometric data, or proprietary business data.

Performance remains workload-dependent. Neural networks may need to be adapted to operations that the selected FHE scheme can evaluate efficiently.

Confidential cloud computing

A company can outsource a calculation without giving the cloud provider access to the underlying records.

Examples include searching an encrypted database, comparing private datasets, or calculating aggregate statistics. The cloud still provides the compute, but possession of the server doesn’t automatically grant access to the plaintext.

FHE can reduce trust in the service provider. It doesn’t eliminate the need to secure keys, applications, and outputs.

Finance and healthcare

Financial institutions could run risk, compliance, or fraud models against encrypted customer records. Healthcare organizations could analyze protected datasets without sharing raw patient information with an external processor.

These applications are promising, but deployment is not automatic. Data encoding, model design, output privacy, key ownership, and regulatory requirements still need separate treatment.

Encrypting the computation doesn’t make the surrounding system compliant by itself.

Private blockchain state

Public blockchains expose contract inputs and state to validators and observers. FHE could keep values such as balances, bids, votes, or trade parameters encrypted while allowing approved computations over them.

This can support confidential smart-contract designs, but the architecture is difficult. Someone still needs authority to decrypt permitted outputs. The system must also manage access control, malformed ciphertexts, consensus, and expensive computation.

Many designs therefore use an FHE coprocessor or specialized network instead of asking every validator to repeat heavy encrypted calculations.

FHE doesn’t prove the computation was correct

Privacy and integrity are different properties.

FHE can hide the input from the evaluator, but basic FHE doesn’t automatically prove that the evaluator ran the requested function correctly. A malicious server could return an invalid or incomplete ciphertext.

Verifiable FHE constructions, zero-knowledge proofs, trusted execution environments, or other authentication methods can address parts of this problem. They add more complexity and overhead.

This distinction is especially important in decentralized systems. A computation being encrypted doesn’t make it publicly verifiable.

Multi-party computation requires more than basic FHE

Standard FHE often assumes one encryption key and one party with decryption authority.

Joint analysis between organizations may require threshold decryption, multi-key FHE, or a separate secure multi-party computation protocol. These approaches can prevent any single participant from decrypting the shared result alone.

They also introduce coordination and key-management problems. FHE is a building block, not a complete governance model for collaborative data analysis.

The practical limits

FHE remains much slower than equivalent plaintext computation. The actual gap depends on the scheme, security parameters, circuit, data type, and hardware.

The main costs include:

• Large ciphertexts

• Higher memory use

• Expensive multiplication and bootstrapping

• Added latency

• Difficult conversion of existing software into FHE-friendly circuits

• Limited or approximate handling of some numeric operations

FHE also doesn’t hide everything. The evaluator may still observe ciphertext sizes, timing, request frequency, and the function being executed. Outputs can reveal sensitive information once decrypted, especially if users are allowed to submit many carefully chosen queries.

Privacy claims need to cover the entire system, not just its encryption layer.

Is FHE used today?

FHE has moved beyond pure theory. Optimized libraries, hardware acceleration, and better schemes now support research systems, pilots, and some narrow commercial workloads.

It still isn’t a drop-in replacement for ordinary computing. Teams usually choose it when the privacy requirement is strong enough to justify redesigning the workload around the performance cost.

FHE is most compelling when the party doing the computation should never see the data. If the operator can be trusted with plaintext, standard encryption and access controls will usually be simpler and cheaper.