Somewhat Homomorphic Encryption (SWHE) is a cryptographic scheme that supports a bounded number of both addition and multiplication operations on ciphertexts, representing a middle ground between Partially Homomorphic Encryption (PHE) and Fully Homomorphic Encryption (FHE). Unlike PHE, which is restricted to a single operation type, SWHE can evaluate low-degree polynomials, making it suitable for specific privacy-preserving computations like evaluating shallow neural network layers or statistical functions directly on encrypted data.
Glossary
Somewhat Homomorphic Encryption (SWHE)

What is Somewhat Homomorphic Encryption (SWHE)?
A cryptographic scheme capable of evaluating a limited number of both addition and multiplication operations on encrypted data before the inherent noise corrupts the ciphertext and prevents correct decryption.
The primary limitation of SWHE is its finite noise budget, which grows with each successive multiplication until the ciphertext becomes undecryptable. This constraint means the scheme can only evaluate circuits up to a predetermined multiplicative depth without employing bootstrapping. SWHE often serves as a foundational building block for Leveled Fully Homomorphic Encryption, where the circuit depth is known in advance, and is typically constructed using lattice-based cryptography assumptions such as Ring Learning With Errors (RLWE).
Key Characteristics of SWHE
Somewhat Homomorphic Encryption occupies a critical middle ground between limited single-operation schemes and the heavy computational burden of fully homomorphic encryption. It supports a bounded number of both additions and multiplications, making it practical for specific machine learning inference tasks where the circuit depth is known in advance.
Bounded Circuit Depth
SWHE schemes can evaluate arithmetic circuits up to a predefined multiplicative depth L. Each multiplication increases the noise in the ciphertext, and once the noise exceeds a threshold, decryption fails. The depth L is chosen at key generation time and determines the size of the parameters. This is in contrast to Fully Homomorphic Encryption (FHE), which uses bootstrapping to support unlimited depth. For ML inference, a fixed-depth network like a ResNet-20 can often be evaluated entirely within an SWHE budget without the overhead of bootstrapping.
Noise-Based Security
The security of SWHE relies on the hardness of the Ring Learning With Errors (RLWE) problem. Each plaintext is encrypted with a small, random error term. Homomorphic additions add these errors together, while multiplications cause the errors to grow multiplicatively. The scheme remains secure as long as the noise does not overwhelm the modulus q. This noise growth is the fundamental constraint that limits the number of operations and defines the 'somewhat' nature of the scheme. The noise budget is consumed predictably with each gate evaluation.
Leveled vs. Fully Homomorphic
SWHE is often referred to as Leveled Fully Homomorphic Encryption when the circuit depth L is known before encryption. The key distinction from true FHE is the absence of bootstrapping. Bootstrapping homomorphically evaluates the decryption circuit to refresh the noise, enabling unbounded computation. SWHE avoids this expensive procedure entirely. For applications like encrypted inference on a fixed neural network architecture, the depth is known at compile time, making SWHE a more efficient choice than bootstrapped FHE.
Parameter Selection Trade-off
Selecting parameters for an SWHE scheme involves a three-way trade-off between security level, circuit depth, and computational efficiency. Larger modulus q and ring dimension n support deeper circuits but increase ciphertext size and operation latency. The security parameter λ (typically 128 bits) dictates the minimum ring dimension. For a fixed security level, the maximum multiplicative depth L is determined by the ratio of the modulus to the initial noise. This parameter selection is often automated by libraries like Microsoft SEAL or PALISADE.
SIMD Packing for Throughput
SWHE schemes based on RLWE natively support Single Instruction Multiple Data (SIMD) packing via the Chinese Remainder Theorem. A single ciphertext can encode a vector of up to n plaintext values, where n is the ring dimension (often 2^15 or more). Homomorphic operations then act component-wise on all slots simultaneously. This is critical for ML workloads: a single ciphertext can represent an entire feature vector or a batch of inputs, amortizing the computational cost across thousands of data points in parallel.
Polynomial Approximation Requirement
SWHE natively supports only addition and multiplication over rings. Non-linear activation functions like ReLU, Sigmoid, or MaxPooling must be replaced with low-degree polynomial approximations. The degree of the approximation directly consumes the multiplicative depth budget. For example, approximating ReLU with a degree-3 polynomial consumes 2 multiplicative levels. This constraint drives research into polynomial-friendly neural architectures and influences the choice between the CKKS scheme (for approximate real arithmetic) and the BFV scheme (for exact integer arithmetic).
SWHE vs. PHE vs. FHE
A comparison of the computational capabilities, noise management, and practical trade-offs between Partially, Somewhat, and Fully Homomorphic Encryption schemes.
| Feature | PHE | SWHE | FHE |
|---|---|---|---|
Supported Operations | Addition OR Multiplication | Addition AND Multiplication | Addition AND Multiplication |
Circuit Depth | Unlimited (single op type) | Limited (predefined) | Unlimited (arbitrary) |
Bootstrapping Required | |||
Noise Management | Not applicable | Modulus switching | Bootstrapping |
Computational Overhead | 10x–100x | 100x–1,000x | 10,000x–1,000,000x |
Ciphertext Expansion | 2x–10x | 100x–1,000x | 1,000x–10,000x |
ML Inference Suitability | Linear models only | Low-depth neural networks | Arbitrary deep networks |
Scheme Examples | Paillier, ElGamal | BFV, CKKS (leveled) | TFHE, CKKS (bootstrapped) |
Frequently Asked Questions
Clear answers to common questions about the mechanics, limitations, and practical use cases of Somewhat Homomorphic Encryption in privacy-preserving machine learning.
Somewhat Homomorphic Encryption (SWHE) is a cryptographic scheme that enables a limited number of both addition and multiplication operations directly on encrypted data, but only up to a specific computational depth before the inherent noise corrupts the ciphertext. Unlike Fully Homomorphic Encryption (FHE), which can evaluate circuits of arbitrary depth through the use of a computationally expensive procedure called bootstrapping, SWHE lacks this self-refreshing capability. This means an SWHE scheme is parameterized to support a pre-defined multiplicative depth; once that limit is reached, decryption fails. In practice, SWHE is often a practical stepping stone—many FHE schemes start as an SWHE construction that is then made fully capable by adding a bootstrapping step. For machine learning engineers, SWHE can be sufficient for evaluating fixed-depth neural networks where the architecture is known in advance, avoiding the heavy performance penalty of bootstrapping.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Understanding Somewhat Homomorphic Encryption (SWHE) requires familiarity with the broader homomorphic encryption landscape and the noise management techniques that define its operational boundaries.
Fully Homomorphic Encryption (FHE)
The theoretical ideal that SWHE approaches. FHE supports arbitrary computation on encrypted data without any depth limits. While SWHE can only evaluate circuits up to a fixed multiplicative depth before noise corrupts the result, FHE uses bootstrapping to refresh the noise budget, enabling unlimited operations. Most practical FHE schemes are built by extending SWHE constructions with this self-referencing capability.
Partially Homomorphic Encryption (PHE)
A simpler, more restricted cousin of SWHE. PHE schemes support only one operation type—either addition (e.g., Paillier) or multiplication (e.g., ElGamal)—but can perform that single operation an unlimited number of times. SWHE advances beyond PHE by supporting both addition and multiplication, which is the minimal requirement for evaluating arbitrary arithmetic circuits, albeit with a strict depth constraint.
Noise Budget
The critical resource that defines SWHE's limitations. Every ciphertext contains a small amount of cryptographic noise to ensure security. Each homomorphic operation—especially multiplication—causes this noise to grow. The noise budget is the total tolerable noise before decryption fails. SWHE schemes are parameterized to support a specific number of operations; exceeding this depth causes the noise to overflow, rendering the ciphertext undecryptable.
Leveled Fully Homomorphic Encryption
A practical refinement of SWHE that makes the depth constraint explicit and configurable. In leveled FHE, the scheme's parameters are chosen to support a pre-determined circuit depth known at setup time. This eliminates the need for expensive bootstrapping while still enabling the evaluation of complex, bounded functions. Leveled FHE is the dominant paradigm for privacy-preserving machine learning inference, where the neural network's depth is fixed in advance.
Bootstrapping
The mechanism that bridges SWHE to full FHE. Bootstrapping homomorphically evaluates the decryption circuit on a noisy ciphertext, producing a fresh encryption of the same plaintext with a reset noise budget. This operation is computationally intensive—often dominating runtime—but it is the only way to transcend SWHE's inherent depth limitation. SWHE schemes deliberately omit bootstrapping to maintain practical performance for bounded computations.
Lattice-Based Cryptography
The mathematical foundation underlying virtually all modern SWHE constructions. These schemes base their security on the hardness of lattice problems like Learning With Errors (LWE) and its ring variant (RLWE). The noise that accumulates during homomorphic operations is directly tied to the error term in these hard problems. Lattice-based schemes are also believed to be post-quantum secure, making SWHE a candidate for long-term cryptographic resilience.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us