Homomorphic Encryption
1. Overview
A. Definition
A cryptographic technique in which computing directly on ciphertext without decrypting it yields a result identical to encrypting the outcome of the same computation performed on the plaintext. Because data can be processed while it stays encrypted (processing on encrypted data), it can be analyzed and used without ever exposing the original to the party doing the processing.
The name comes from the algebraic notion of a homomorphism. A homomorphism is a map between two algebraic structures that preserves their operational structure; here it means the encryption function Enc "carries over and preserves" the additive and multiplicative structure of the plaintext space into the ciphertext space. Because addition and multiplication on plaintexts correspond directly to matching operations on ciphertexts, computation holds on the ciphertext without any need to return to the original.
What fundamentally sets homomorphic encryption apart from other cryptographic techniques is that it achieves protection and utility at the same time. With conventional cryptography, once data is locked it cannot be used, and to use it you must unlock it. Homomorphic encryption breaks this all-or-nothing logic and offers a third state in which data is "computed on while still locked." This property becomes an especially powerful weapon in an era when data is entrusted to someone else's infrastructure for processing, as with cloud and AI.
The main characteristics of homomorphic encryption can be summarized as follows. First, computation without exposing the original, so the processing party learns neither the data nor the result. Second, lattice-based security, which is expected to be strong even against quantum computers. Third, generality, in that FHE can in theory compute any function. Fourth, the price paid for all these strengths is a high computational cost. Finding the balance point among these four traits is the essence of designing with homomorphic encryption.
B. Background and Necessity
Traditional cryptography protects data only at rest and in transit; because you must decrypt to compute, the original is laid bare in memory at the point of use (in use). Of the three phases of data protection (at rest, in transit, in use), this last "protection during processing" long remained a gap.
This gap turns into a risk the moment computation is outsourced. To upload data to the cloud and hand off the analysis, the data owner must trust the cloud provider unconditionally; for sensitive information such as medical diagnostic data or financial transaction records, this very assumption of trust becomes the seed of regulatory violations and privacy breaches. For example, for a hospital to send a patient's genomic data to an external AI for analysis, it must hand over the original, and at that moment liability arises under the Personal Information Protection Act and medical laws.
Homomorphic encryption confronts this dilemma of "giving up protection in order to gain utility" head-on and resolves it. If you upload data to the cloud in encrypted form, let the cloud handle the computation, then bring back only the result and decrypt it, the processing party performs the computation on your behalf without ever learning either the input or the output. For this reason homomorphic encryption draws attention as a foundational technology for Privacy-Preserving Data Analysis and for PET (Privacy Enhancing Technology), and in an environment of tightening data regulation such as Korea's Data 3 Acts and the GDPR, it is regarded as an alternative that "protects the original without anonymization."
2. How It Works
A. Overall Processing Flow
flowchart LR
D["Plaintexts m1, m2"] -->|"Encrypt Enc"| E["Ciphertexts c1, c2"]
E -->|"Compute f on ciphertext"| R["Computed ciphertext f(c1,c2)"]
R -->|"Decrypt Dec"| O["Plaintext result f(m1,m2)"]
K["Secret key sk"] -.-> D
K -.-> O
The core is the homomorphic property Dec(f(Enc(m1), Enc(m2))) = f(m1, m2). When the data owner encrypts plaintexts m1, m2 with the public key and sends them to the server, the server, without knowing the plaintext at all, performs the function f (essentially a combination of additions and multiplications) on the ciphertexts, and only the owner holding the secret key decrypts the resulting ciphertext to obtain f(m1, m2). The power of this structure lies in the fact that all the server sees is ciphertext that looks like random noise, and it can learn neither the inputs nor the computed result.
Tracing the trust boundary in this flow makes the security value of homomorphic encryption plain. The secret key rests solely with the data owner, and the server receives only the public key and the evaluation key needed for computation. Therefore, even if the server behaves maliciously or is compromised, all that leaks is ciphertext that cannot be decrypted. This property — "you can entrust computation to a server without trusting it" — is precisely the decisive differentiator of homomorphic encryption in outsourced cloud computation.
Since any computation can ultimately be expressed as a combination of additions and multiplications (an arithmetic circuit) or a combination of AND and XOR (a Boolean circuit), supporting both operations homomorphically makes it possible in theory to compute any function on ciphertext. For example, mean, variance, inner product, and matrix multiplication consist solely of addition and multiplication, and most of deep learning inference (convolution and fully connected layers), once expressed as polynomial approximations, can also be performed homomorphically.
B. Lattice-Based Structure and the Noise Problem
flowchart TD
P["Plaintext m"] --> ADD["Add small noise e to plaintext<br/>(LWE/RLWE based)"]
ADD --> C0["Ciphertext c (small noise)"]
C0 --> OP1["1 operation (add/multiply)"]
OP1 --> C1["Noise grows"]
C1 --> OP2["Repeat operations"]
OP2 --> LIMIT{"Noise > limit?"}
LIMIT -->|"No"| C1
LIMIT -->|"Yes"| FAIL["Decryption impossible"]
C1 -->|"Bootstrapping"| RESET["Noise reset<br/>(re-encrypt without decrypting)"]
RESET --> C0
Most modern fully homomorphic encryption schemes base their security on lattice-based cryptography, specifically on the hardness of the LWE (Learning With Errors) problem and its ring version RLWE. In this approach, for the sake of security a small amount of noise (error) is deliberately mixed into the plaintext during encryption; this very noise is the basis of the lattice problem that is hard to solve even with a quantum computer, and the reason homomorphic encryption is counted among the Post-Quantum candidates.
The problem is that this noise accumulates and amplifies as operations are repeated. Multiplication in particular grows the noise sharply, so if operations continue with no countermeasure, the moment a certain limit is exceeded the plaintext is buried in noise and decryption becomes impossible. Thus "how to control the noise while securing computational depth (circuit depth)" is the central challenge of implementing homomorphic encryption, and the bootstrapping examined below is the fundamental solution to this problem.
Several supporting techniques for handling noise have also developed. Modulus switching reduces the coefficient size of the ciphertext to slow the rate of noise growth, and relinearization returns the ciphertext degree, which grows after multiplication, back to its original so that further operations remain possible. Thanks to such techniques, computations of considerable depth became possible even without bootstrapping, greatly improving practical performance. This shows how important algorithmic optimization is in the process of homomorphic encryption moving from "theoretical possibility" to "practical tool."
C. Bootstrapping
Bootstrapping is a concept presented by Gentry in 2009, a technique that "resets" the noise inside a ciphertext by re-encryption without decrypting it. Intuitively, it runs the decryption function itself as a homomorphic operation on the ciphertext, swapping it out for a "new ciphertext with little noise." Through this, the noise can be lowered periodically before reaching its limit, enabling computation of unlimited depth. However, because bootstrapping itself is a very heavy operation, in practice it is used together with leveled FHE, which computes only up to a predetermined depth without bootstrapping, trading off performance against functionality.
Bootstrapping becomes clear through the analogy of a "noise budget." A ciphertext is granted a certain noise budget when it is first created; addition consumes the budget a little at a time, while multiplication consumes it heavily. If you finish the computation before the budget runs out you are fine, but if deeper computation is needed you must recharge the budget through bootstrapping. Therefore the circuit designer strikes a balance between the optimization of "reducing multiplicative depth so the computation can finish without bootstrapping" and the choice of "accepting heavy bootstrapping to secure generality."
D. A Simple Conceptual Example
You can gain intuition from Paillier, which has additive homomorphism. Encrypt two salary values m1=300 and m2=200 separately to obtain c1, c2, then have the server compute c1 × c2 (ciphertext multiplication); decrypting the result yields m1 + m2 = 500. The server performed only the "computation of summing" on your behalf, without knowing 300, 200, or 500. Real-world scenarios like salary statistics and survey aggregation, where only the total is obtained without exposing individual responses, are realized on this principle. FHE extends this by adding unlimited multiplication as well, so that beyond a sum it can perform complex analyses such as regression and classification while data stays encrypted.
3. Types
Homomorphic encryption is divided into three stages according to the kind and number of operations it supports, and this history of development is precisely the history of "how far the noise can be controlled." Each stage is not merely a performance improvement but a process of broadening the very range of expressible functions.
| Type | Supported operations | Representative schemes |
|---|---|---|
| Partially Homomorphic (PHE) | Addition or multiplication, only one kind, unlimited | RSA (multiplication), Paillier (addition), ElGamal (multiplication) |
| Somewhat Homomorphic (SWHE) | Both addition and multiplication, but a limited number of times | BGN (unlimited addition + one multiplication) |
| Fully Homomorphic (FHE) | Arbitrary operations, arbitrary number of times | Gentry (2009), BGV·BFV, CKKS, TFHE |
Partially Homomorphic Encryption (PHE) supports only one kind of operation, without limit. Paillier has additive homomorphism, so multiplying ciphertexts yields the sum of the plaintexts, and it is used practically in electronic voting (summing encrypted votes without decryption) and privacy statistics. RSA and ElGamal have multiplicative homomorphism. PHE is fast and its implementations are mature, but it has the limitation that the computations it can express are extremely restricted. What is interesting is that textbook RSA (c = m^e mod n) already had multiplicative homomorphism; this shows that the homomorphic property itself was no special invention, and that "supporting both addition and multiplication simultaneously and without limit" was the unsolved challenge of the past three decades or so. Herein lies the reason the arrival of FHE was such a momentous event.
Somewhat Homomorphic Encryption (SWHE) supports both addition and multiplication but, because of the noise limit, allows only computations of shallow circuit depth. Representatively, BGN (Boneh-Goh-Nissim) permits unlimited addition and exactly one multiplication. SWHE can be used on its own for shallow statistics and classification, but it did not secure true generality.
Fully Homomorphic Encryption (FHE) was the "holy grail" that can perform arbitrary operations an arbitrary number of times. In 2009 Craig Gentry first realized it by introducing bootstrapping based on ideal lattices (1st generation), after which it developed into the LWE/RLWE-based BGV·BFV (2nd generation, strong at integer arithmetic), TFHE (strong at Boolean circuits and comparison operations) supporting fast bootstrapping, and CKKS (4th generation), specialized for approximate arithmetic over reals and complex numbers. CKKS in particular is a scheme proposed in 2017 by a Korean research team (Professor Jung Hee Cheon's group at Seoul National University); because it is approximate arithmetic that allows error, it has effectively become the standard in fields such as machine learning that require large-scale floating-point computation.
An important practical point is that scheme choice depends on "what you compute." Integer statistics and counting favor BGV·BFV; machine learning inference dominated by real-valued vector and matrix operations favors CKKS; and logic heavy with comparisons, branching, and bit operations favors TFHE with its fast bootstrapping. Since no single scheme is optimal for every workload, the key to securing performance is for the architect to first analyze the character of the target computation and then decide on the scheme and parameters.
4. Pros and Cons, and Comparison with Related Technologies
A. Pros and Cons
Homomorphic encryption's powerful privacy is traded for an enormous computational cost. Understanding this trade-off is the starting point for practical adoption.
| Advantages | Disadvantages |
|---|---|
| Analysis while encrypted → original not exposed, strong privacy | Computation and performance burden is very large (FHE is thousands to millions of times that of plaintext) |
| Safe execution of cloud and outsourced computation | Capacity surges due to ciphertext expansion |
| Compliance with data regulation (protecting the original without anonymization) | Implementation difficulty is high, e.g., noise management and circuit design |
| Lattice-based → quantum resistance expected | Standardization is in progress, so interoperability and validation are immature |
The performance burden is the greatest practical barrier. A single simple addition can require thousands of times the time of a plaintext operation, and the gap widens further once bootstrapping is included. Ciphertext expansion is also a problem: an integer of a few bytes swells into a ciphertext of several KB to tens of KB, driving up storage and transmission costs. Therefore the principle for homomorphic encryption is not "everything in ciphertext" but selective application at points of high sensitivity and low computational frequency.
Another point to note is that homomorphic encryption is fundamentally weak at control operations such as comparison and branching. While encrypted, you cannot judge "is this value greater than 0?" and branch on it (the judgment itself requires plaintext information), so algorithms with many conditionals must be worked around with polynomial approximation or masking, and this incurs losses in accuracy and performance. For this reason, redesigning algorithms to be "HE-friendly" is a hidden cost of adoption, and a representative example is using a polynomial activation function instead of ReLU in deep learning.
B. Relationship with MPC, Federated Learning, and Differential Privacy
Homomorphic encryption is not in competition with other PETs but in a complementary relationship with them, because each technology protects a different target under a different trust model.
| Technology | Core idea | Relationship with homomorphic encryption |
|---|---|---|
| MPC (Multi-Party Computation) | Multiple parties jointly compute a function while each hides its input | Favorable for reducing communication and distributing computation; HE is favorable for outsourced computation without communication → combine them (HE+MPC) |
| Federated Learning (FL) | Share only model updates without gathering the originals | Encrypt the update values themselves with HE to prevent the server from inferring them |
| Differential Privacy (DP) | Add noise to the result to prevent individual identification | HE protects the computation process, DP protects the output result → layered combination |
MPC divides the computation with communication among several institutions, so its communication cost is high while its computation is relatively light, whereas homomorphic encryption, once data is handed over, lets the server compute alone without communication, making it suitable for outsourcing scenarios. In federated learning, the originals can be back-inferred from just the gradients each participant sends, so these are encrypted with homomorphic encryption (Secure Aggregation) to keep the server from seeing individual values. Differential privacy adds noise to the "result" of a computation to hide individuals, while homomorphic encryption hides the "process" of computation; using the two together in a layered way protects both the process and the result.
Meanwhile, confidential computing based on hardware trusted execution environments (TEE, e.g., Intel SGX) processes plaintext inside an isolated region within the CPU, so it is far faster than homomorphic encryption, but it differs in its trust assumption: you must trust the hardware manufacturer and it can be exposed to side-channel attacks. Homomorphic encryption bases its security solely on a mathematical hard problem, so it needs no hardware trust but is slow. Therefore the crux of design is to position the two technologies from the perspective of "what to place trust in," not "how fast it is."
5. Deep Dive: Latest Trends and Practical Application
Homomorphic encryption was long judged to be "theoretically beautiful but too slow to use," but in recent years practical adoption has been advancing rapidly along the three axes of hardware acceleration, library maturity, and standardization. Gentry's first FHE took tens of minutes for a single simple operation, but algorithmic improvements and SIMD packing made it thousands of times faster or more within a few years — a fact that symbolizes this trend.
First, the maturation of the library ecosystem. Microsoft's SEAL, IBM's HElib, OpenFHE (of the PALISADE lineage) into which several projects were integrated, the Go-based Lattigo, and the CKKS reference HEAAN have been released as open source, so that even non-cryptography-experts can pick and use BGV·BFV·CKKS·TFHE. These support SIMD packing (batching), which places a vector into a single ciphertext for parallel processing, greatly boosting the effective performance of large-scale computation.
Second, dedicated hardware acceleration. The bottleneck of FHE lies mostly in polynomial multiplication (NTT operations) and bootstrapping, and attempts to accelerate these with GPU, FPGA, and ASIC continue. The U.S. DARPA DPRIVE program aims to greatly accelerate computation with an FHE-dedicated processor, and companies such as Intel and Samsung are researching related hardware. As such acceleration matures, the gap that was thousands of times that of plaintext is expected to narrow to a practical level.
Third, standardization. The HomomorphicEncryption.org consortium has organized standards for parameters and security levels, and FHE standardization (such as ISO/IEC 28033) is also underway at the ISO/IEC level. Standardization enables interoperability between different libraries and organizations and safe parameter selection, and thus becomes a prerequisite for industrial diffusion. For example, even with the same CKKS, parameter notation and defaults differed by library, making mutual validation difficult; once a standard parameter set is established, a consensus emerges that "this parameter satisfies 128-bit security," making auditing and certification easier. Standardization is thus as much a core axis for securing industrial trust as performance is.
As practical application cases, a representative one is research at iDASH, a genomic analysis competition for medical data, that performed statistics and disease prediction on homomorphically encrypted genomic data, and in the financial sector several institutions are attempting to apply it to privacy-preserving credit scoring and fraud detection without exposing their respective data. In Korea too, encrypted-state machine learning inference services using CKKS are entering the commercialization stage.
To make the scenario concrete: when a hospital encrypts a patient's test values with CKKS and uploads them to the cloud, the cloud's diagnostic-assistance model runs a neural network approximated by polynomials on the ciphertext and produces only an "abnormal-finding probability" ciphertext. The hospital decrypts this and checks only the result, while the cloud provider learns neither the original test values nor the diagnostic result. Such a structure is notable as a rare solution that satisfies both "data sovereignty" and "AI utilization" in regulation-sensitive industries that must send data to overseas clouds. However, accounting for the accuracy loss and latency from polynomial approximation, a realistic approach is to apply it first to non-real-time uses such as screening (first-line triage).
The likely direction of exam questions is also worth noting. In the professional engineer exam, homomorphic encryption tends to appear entangled with other topics rather than as a standalone definition question — such as "comparison of privacy-preserving technologies (HE, MPC, DP, federated learning)," "data protection measures in cloud environments," or "relationship with post-quantum cryptography." Therefore, in your answer, rather than stopping at definition and principle, developing the argument along the three axes of "why it is needed now (the gap in protection during processing)," "what it is combined with (the PET stack)," and "what the obstacles are (performance and standardization)" raises the completeness of the answer as a deep-dive response.
6. Considerations and Implications
From a professional engineer's perspective, homomorphic encryption should be treated not as a cure-all but as an option in architectural design.
- Selective application strategy: Given FHE's performance cost, apply it first to batch-type computations that are insensitive to latency and highly sensitive (e.g., nightly statistics, ciphertext inference), and do not force it onto real-time, high-frequency transactions. Not "encrypting the entire path" but "encrypting only the sensitive segment" is realistic.
- Parameter and security-level management: For lattice-based cryptography, parameter selection determines both security level and performance. Secure 128-bit or higher security in line with standards (the HomomorphicEncryption.org recommendation), while requiring the expertise to tune parameters to the demands of circuit depth and precision.
- Combined architecture: Rather than homomorphic encryption alone, design the trust model by layering combinations with MPC, federated learning, differential privacy, and confidential computing (TEE). For example, protect federated learning gradients with HE and add DP noise to the final output.
- Alignment with the quantum-resistance roadmap: Since LWE/RLWE-based homomorphic encryption shares its mathematical foundation with post-quantum candidates, reviewing it together with the organization's PQC (post-quantum cryptography) migration roadmap can improve the efficiency of investment in future readiness.
- Linkage with regulation and governance: From the standpoint of compliance with the Personal Information Protection Act and the GDPR, position homomorphic encryption as "an alternative or complement to pseudonymization and anonymization," and, at adoption, establish a governance framework that jointly assesses performance, cost, and verifiability (auditability).
- Key management and integrity: Homomorphic encryption guarantees the confidentiality of computation but does not automatically guarantee even that "the server honestly performed the promised computation" (integrity). Therefore you must jointly design a combination with verifiable computation or zero-knowledge proofs, along with a policy for the secure storage and rotation of the secret key, in order to respond to a real threat model.
- Gradual adoption roadmap: Adopt in stages of pilot (non-real-time statistics and screening) → partial commercial (sensitive batch computation) → expansion, and a realistic path that reduces risk is to broaden the scope of application while watching the maturity of hardware acceleration and standards.
References
- Gentry, C. "A Fully Homomorphic Encryption Scheme" (PhD thesis, Stanford, 2009): https://crypto.stanford.edu/craig/craig-thesis.pdf
- Cheon, Kim, Kim, Song. "Homomorphic Encryption for Arithmetic of Approximate Numbers (CKKS)": https://eprint.iacr.org/2016/421
- Microsoft SEAL: https://github.com/microsoft/SEAL
- OpenFHE: https://www.openfhe.org/
- HomomorphicEncryption.org standardization consortium: https://homomorphicencryption.org/
In one line: Homomorphic encryption is a lattice-based technique that enables computation on ciphertext without decryption, having developed through PHE, SWHE, and FHE (FHE realized via Gentry's bootstrapping in 2009, and real-number arithmetic made practical with CKKS); despite its heavy performance burden, it is being made practical through hardware acceleration and standardization, and it is a core PET technology that enables privacy-preserving data utilization in the cloud and AI era.