Homomorphic Encryption – Basics

Organizations storing data in cloud environments face a fundamental problem: to perform computation on encrypted data, Cloud Service Providers (CSPs) must first decrypt it, exposing plaintext to environments the organization does not fully control. Homomorphic encryption (HE) solves this by enabling computation directly on ciphertext, so the CSP never sees the underlying data. The recommended action: evaluate PHE (Partial HE) for use cases requiring only addition or multiplication; evaluate FHE (Fully HE) for arbitrary computation use cases while accounting for its current performance overhead (10^6 times slower than plaintext computation); and assess whether privacy-preserving alternatives like secure enclaves or differential privacy meet your needs at lower cost.

Quick Answer: What Is Homomorphic Encryption and Why Does It Matter?

Homomorphic encryption (HE) is a class of encryption scheme where computations performed on ciphertext produce an encrypted result that, when decrypted with the appropriate private key, equals the result of performing the same computations on the original plaintext. The algebraic property expressed formally: HE(a + b) = HE(a) + HE(b) and HE(a * b) = HE(a) * HE(b). This property means a cloud provider can run analytics, machine learning inference, or database queries on data that remains encrypted throughout the entire computation, and return the encrypted result to the data owner, who is the only party with the private key to decrypt it. It matters because it enables compliance with regulations like GDPR, PCI DSS, HIPAA, and FIPS even when sensitive data is processed by third-party infrastructure.

Why Standard Encryption Cannot Solve the Cloud Computation Problem

Standard encryption protects data at rest and in transit. When an organization sends encrypted data to a cloud provider and requests computation on that data, the provider must decrypt it to process it. This creates a structural confidentiality problem: the plaintext is exposed in the cloud provider’s environment during processing, where it may be visible to the provider’s systems, personnel, or an attacker who has compromised the provider’s infrastructure.

This constraint limits what organizations can delegate to cloud providers when the data involved is sensitive. Healthcare organizations cannot delegate analytics on patient records without exposing PHI. Financial institutions cannot use cloud-based machine learning on transaction data without exposing account and behavior data. Organizations subject to data residency or sovereignty requirements face restrictions on what computation can occur in cloud environments outside their jurisdiction.

Homomorphic encryption addresses this directly: the cloud provider receives only ciphertext, performs computation on it using the homomorphic properties of the scheme, and returns an encrypted result. At no point does the provider hold plaintext data. The organization decrypts the result using its private key, which never leaves its control.

What Is Homomorphic Encryption?

Homomorphic encryption makes it possible to perform computation while data remains encrypted. The term homomorphic comes from mathematics: an encryption function E is homomorphic with respect to an operation * if E(a) * E(b) = E(a * b), meaning the operation can be applied to the encrypted values and produce the same result as applying it to the plaintext values before encryption.

Like other asymmetric encryption schemes, HE encrypts data using a public key. The encrypted result (ciphertext) can only be decrypted by the corresponding private key. But uniquely, while the data is encrypted, defined mathematical operations can be performed on the ciphertext, and the result of decrypting the output matches the result of performing those operations on the original plaintext.

Addition and multiplication of plaintext values equals the corresponding operation on their ciphertexts. Any computable function can be expressed as a combination of addition and multiplication, which is the foundation of Fully Homomorphic Encryption’s claim to enable arbitrary computation on encrypted data.

Types of Homomorphic Encryption

Homomorphic encryption schemes are classified by which operations they support on ciphertext:

1. Partial Homomorphic Encryption (PHE): supports either addition or multiplication on ciphertext, but not both. PHE schemes are efficient and practical for specific use cases. The RSA cryptosystem is multiplicatively homomorphic: RSA(a) * RSA(b) = RSA(a * b) mod n. The Paillier cryptosystem is additively homomorphic. PHE is practical today and is deployed in applications like electronic voting (where vote tallying requires only addition) and certain privacy-preserving database queries.
2. Somewhat Homomorphic Encryption (SHE): supports both addition and multiplication, but only for a limited number of operations before the noise introduced by each operation accumulates to the point where decryption fails. SHE enables more expressive computation than PHE but imposes a cap on circuit depth. It is a precursor to FHE and is used in applications where the number of operations can be bounded in advance.
3. Fully Homomorphic Encryption (FHE): supports an unlimited number of additions and multiplications on ciphertext. Craig Gentry proposed the first plausible FHE scheme in 2009, based on lattice cryptography. FHE schemes use a bootstrapping operation to refresh ciphertext and eliminate accumulated noise, enabling unbounded computation. FHE is the most general and powerful form of HE, and active research is rapidly improving its practical performance.

Current FHE Schemes and Libraries

Several FHE schemes have been developed since Gentry’s 2009 paper, each optimized for different computation types:

Scheme	Best for	Operation type	Available in
BGV (Brakerski-Gentry-Vaikuntanathan)	Integer arithmetic; encrypted database operations	SIMD-style batched integer operations	HElib; OpenFHE
BFV (Brakerski-Fan-Vercauteren)	Exact integer arithmetic; vote tallying; encrypted search	Ring Learning With Errors (RLWE) based integer operations	Microsoft SEAL; OpenFHE
CKKS (Cheon-Kim-Kim-Song)	Approximate real-number arithmetic; machine learning inference	Approximate arithmetic (useful for neural network inference)	Microsoft SEAL; HElib; OpenFHE
TFHE (Fast FHE over the Torus)	Boolean circuit evaluation; comparison operations	Fast gate-by-gate bootstrapping; bitwise operations	OpenFHE; TFHE library

Applications of Homomorphic Encryption

1. Healthcare data analysis: a hospital can send encrypted patient records to a research institution or analytics provider. The provider runs statistical analysis or machine learning models on the ciphertext and returns the encrypted result. The hospital decrypts the result. The research institution never sees any patient’s PHI, satisfying HIPAA requirements even when the computation occurs outside the covered entity’s environment.
2. Encrypted databases: a database storing encrypted records can respond to queries without decrypting the database. Using PHE or FHE, the database system evaluates query predicates on encrypted values and returns encrypted matching records. This limits the exposure of the database in the event of a breach: stolen ciphertext cannot be queried without the client’s private key. Standard encryption on databases does not support queries on encrypted values without decrypting first.
3. Private information retrieval (PIR): a client can retrieve a record from a database without the database server learning which record was retrieved. The client sends an encrypted query; the server evaluates it homomorphically and returns an encrypted result. This is particularly valuable for privacy-sensitive lookups such as checking whether a password has been compromised against a known-breach database.
4. Cloud computation on sensitive data: organizations can delegate computation to cloud infrastructure without granting the cloud provider access to plaintext data. The data is encrypted with an HE scheme before upload; computation runs on ciphertext; the result is returned encrypted and decrypted by the organization. The cloud provider functions as an untrusted compute environment. This enables compliance with data sovereignty and confidentiality requirements even when using third-party cloud infrastructure.
5. Machine learning on private data: with CKKS (which supports approximate arithmetic), machine learning inference can be run on encrypted inputs. A medical diagnostic model, for example, can evaluate an encrypted patient symptom vector and return an encrypted classification, without the model operator seeing the patient’s data and without the patient seeing the model parameters. This is being actively deployed for privacy-preserving AI applications.

Performance and Interoperability Trade-offs

FHE’s primary practical limitation is computational overhead. Current FHE implementations are at least 10^6 times slower than equivalent plaintext computation for general-purpose computation. This means operations that take milliseconds in plaintext may take hundreds of seconds in FHE. Key factors that determine HE performance:

Factor	Impact on performance	Mitigation
HE scheme type	FHE (with bootstrapping) is slowest; PHE and SHE are faster but limited in operations supported	Choose the minimum HE power needed for the use case: use PHE if only addition or only multiplication is required
Polynomial modulus degree	Larger modulus enables more operations before noise limits but increases ciphertext size and operation time	Size parameters to the minimum required for the computation depth
SIMD batching	Many HE schemes support packing multiple plaintexts into a single ciphertext (batching), amortizing per-element cost	Design computation to use batched operations where possible
Hardware acceleration	GPU-accelerated HE libraries provide 10x to 100x speedup over CPU-only implementations for applicable schemes	Evaluate GPU-accelerated FHE libraries (Intel HEXL, cuFHE) for production deployments
Bootstrapping frequency	Bootstrapping (the FHE noise-reduction operation) is the most expensive operation in FHE	Minimize bootstrapping by structuring computation to use the minimum circuit depth

For most current production applications, PHE or SHE is more practical than FHE. Secure enclaves (Trusted Execution Environments such as Intel SGX) provide an alternative approach for cloud computation on sensitive data with significantly lower performance overhead, though with a different trust model (trusting the hardware manufacturer’s attestation rather than cryptographic computation). Differential privacy provides statistical privacy guarantees for aggregate analytics with minimal performance overhead but does not protect individual records. The choice among HE, secure enclaves, and differential privacy depends on the specific privacy threat model, the computation type, and the acceptable performance overhead.

Deployment Examples

Private financial risk computation: a financial institution wants a third-party risk analytics provider to compute credit risk scores on its customer portfolio without exposing account data. Using the Paillier cryptosystem (PHE, additively homomorphic), the institution encrypts each customer’s relevant financial metrics. The analytics provider computes weighted sums on the encrypted data (addition operations only) and returns the encrypted result. The institution decrypts the result to obtain the risk scores. The provider never sees individual account values. This use case is practical today because it requires only addition, which PHE supports efficiently.

Encrypted keyword search in a cloud database: an organization stores encrypted documents in a cloud database and needs to retrieve documents matching a keyword without revealing the keyword or the contents of non-matching documents to the cloud provider. Using a searchable encryption scheme (which combines PHE properties with structured indexing), the organization sends an encrypted query token for the keyword. The cloud database evaluates the query token against encrypted index entries and returns matching encrypted document references. The organization decrypts the references to retrieve the target documents. The cloud provider learns only which ciphertexts matched, not the keyword or document contents.

ML inference on encrypted healthcare data with CKKS: a healthcare AI provider offers a diagnostic model that classifies patient risk from a set of clinical features. Using CKKS FHE, the healthcare organization encrypts the patient feature vector and sends it to the AI provider. The provider evaluates the neural network inference computation on the encrypted vector using approximate arithmetic (CKKS’s native operation) and returns the encrypted classification. The organization decrypts the classification to obtain the diagnostic result. The AI provider never sees the patient’s clinical data, and the organization never sees the model weights. This type of deployment is being actively piloted in healthcare and financial services for high-value, privacy-sensitive inference use cases.

Limitations and Current Drawbacks

• Computational overhead: FHE computation is at least 10^6 times slower than plaintext computation for general-purpose operations. While hardware acceleration has improved this, FHE remains impractical for latency-sensitive applications and for computations on large datasets requiring many sequential operations.
• Circuit depth limits (SHE/FHE without bootstrapping): each homomorphic operation introduces noise into the ciphertext. Without bootstrapping, the number of operations that can be performed on a ciphertext before it becomes undecryptable is bounded. Bootstrapping extends this limit but is itself computationally expensive, adding significantly to overall processing time.
• Single-key limitation for shared databases: standard HE schemes encrypt data under one public key; only the holder of the corresponding private key can decrypt results. For a database accessed by multiple independent users who each hold different private keys, a separate encrypted copy of the data would be needed for each user, which becomes impractical at scale. Multi-key FHE schemes exist but add further complexity and overhead.
• Implementation complexity: choosing the right HE scheme, parameter sizes, and computation structure requires significant cryptographic expertise. Parameter misconfiguration (too small a modulus or polynomial degree) can cause noise to overwhelm the ciphertext or reduce security below required levels. Open-source libraries are improving in usability but remain more complex to deploy correctly than standard cryptographic libraries.
• CKKS approximate arithmetic limitations: CKKS supports real-number computation but produces approximate results, not exact ones. For applications requiring exact integer arithmetic (such as financial calculations where precise values are required), CKKS is inappropriate; BGV or BFV should be used instead.

How Encryption Consulting Can Help

• Encryption Advisory Services: our Encryption Advisory Services assess whether homomorphic encryption is the right approach for your specific use case, or whether alternatives such as secure enclaves, differential privacy, or tokenization better address your privacy and performance requirements. We design privacy-preserving computation architectures that are both cryptographically sound and operationally feasible.
• Compliance Advisory Services: our Compliance Advisory Services help organizations understand how HE and alternative privacy-preserving approaches address compliance requirements under GDPR, HIPAA, PCI DSS, and FIPS, including documentation requirements for regulators who may be unfamiliar with HE-based compliance architectures.
• CBOM Secure: CBOM Secure discovers existing cryptographic implementations in your environment, providing the inventory needed to assess whether current encryption approaches expose sensitive data to third-party environments and whether HE should be evaluated as a replacement or complement.
• HSM as a Service: HE schemes that use public-key encryption require secure management of the private decryption key. HSM as a Service provides FIPS 140-3 validated hardware storage for the private keys used in HE deployments, ensuring that the private key (and the ability to decrypt HE results) cannot be compromised even if cloud or application infrastructure is breached.

Conclusion

Homomorphic encryption addresses a problem that standard encryption cannot: how to allow a third party to perform meaningful computation on sensitive data without ever accessing the plaintext. PHE is practical today for use cases requiring a single operation type. FHE enables arbitrary computation on encrypted data and is being deployed in production for high-value, privacy-sensitive applications in healthcare, finance, and ML inference, despite its current performance overhead.

For most organizations evaluating HE, the decision framework is: if you need to delegate a specific, bounded computation to a third party without exposing plaintext, assess whether PHE or SHE supports that computation type; if arbitrary computation is required, evaluate FHE against the performance overhead and compare it to alternatives including secure enclaves and differential privacy. The right architecture depends on the specific threat model, the computation type, the sensitivity of the data, and the performance budget. If you want guidance on whether homomorphic encryption or another privacy-preserving approach fits your use case, contact Encryption Consulting. For related topics, see Format Preserving Encryption and our blog on Comparing Data Security and Data Privacy.

Frequently Asked Questions

What is homomorphic encryption?

Homomorphic encryption (HE) allows computations to be performed directly on ciphertext, with the decrypted result matching what would have been obtained by performing the same operations on the original plaintext. It enables a cloud provider to process encrypted data and return an encrypted result, without ever seeing the underlying plaintext.

What is the difference between PHE and FHE?

Partial Homomorphic Encryption (PHE) supports either addition or multiplication on ciphertext, but not both. It is practical and efficient for specific use cases. Fully Homomorphic Encryption (FHE) supports both operations in unlimited combination, enabling arbitrary computation on encrypted data, but is currently 10^6 times slower than plaintext computation for general use.

Why can’t standard encryption be used for cloud computation?

Standard encryption must be reversed (the data decrypted) before any computation can be performed on it. This exposes plaintext to the cloud provider’s environment during processing, creating compliance and confidentiality problems for sensitive data. HE eliminates the need to decrypt by enabling computation on ciphertext.

How slow is Fully Homomorphic Encryption compared to standard encryption?

FHE computation is at least 10^6 times slower than equivalent plaintext computation. An operation that takes 1 millisecond in plaintext may take up to 1,000 seconds in FHE. Hardware acceleration (GPU-based FHE) reduces this gap significantly for applicable schemes, and performance continues to improve through ongoing research.

What are the main real-world applications of homomorphic encryption?

PHE is deployed today in electronic voting, privacy-preserving database queries, and specific financial computations. FHE is being piloted for encrypted ML inference on healthcare data, private information retrieval, and cloud computation on regulated data. CKKS-based FHE is the most practical for ML inference because of its support for approximate real-number arithmetic.

What are the main HE schemes and libraries available today?

BGV and BFV are used for integer arithmetic; CKKS for approximate real-number computation (ML inference); TFHE for Boolean circuit evaluation. Libraries include Microsoft SEAL (BFV and CKKS), HElib (BGV and CKKS), and OpenFHE (BGV, BFV, CKKS, TFHE, and FHEW). All are open-source and vary in production maturity.