Practical Homomorphic Encryption: Implementing Microsoft SEAL and OpenFHE for Secure Data Sharing

The scenario HE is built for is narrow and specific: a computing party needs to run a calculation on your data, and you need a mathematical guarantee, not a policy promise, that the computing party never has access to the plaintext. This is different from encryption at rest or in transit, which protects data while it is stored or moved but requires decryption before any computation can happen. It is also different from most access-control or contractual approaches to data sharing, which rely on the other party behaving correctly rather than on the data being unreadable to them in the first place.

Concretely, HE fits scenarios such as: a healthcare analytics vendor computing aggregate statistics across patient records it must never see in the clear; a third-party auditor summing encrypted financial values without gaining transaction-level visibility; or a cloud provider running a specific scored ML inference (for example, a linear model or a small neural network layer) over an encrypted input vector so the input and the intermediate values stay hidden from the provider's own infrastructure. In every one of these cases, the actual computation being outsourced is a small, well-defined set of arithmetic operations, not a general-purpose program.

That last point is the honest limit to state up front: fully homomorphic encryption (FHE) is computationally expensive enough that it is realistically used today for narrow, bounded computations, sums, weighted averages, dot products, and specific ML inference operations, not arbitrary general-purpose computation at production scale. If your use case needs comparisons, loops with data-dependent bounds, or complex branching logic, HE in its current form is a poor fit, and you should evaluate confidential computing (TEE-based approaches) or secure multi-party computation before committing engineering time to HE.

Choose a scheme based on your data type, not familiarity. BFV and BGV both operate on exact integer arithmetic and produce exact results, which makes them the right choice when correctness cannot tolerate any approximation, for example summing financial amounts. CKKS operates on approximate real-number (fixed-point) arithmetic and is the standard choice for machine learning workloads, since ML computations already tolerate numerical approximation and CKKS is substantially more efficient for real-valued vector operations than trying to force BFV/BGV to emulate fractional values.

Understand multiplicative depth before you design the computation. Every HE ciphertext carries a noise budget that shrinks with each homomorphic operation, and multiplication consumes noise budget far faster than addition. The multiplicative depth of your computation, the longest chain of sequential multiplications the data passes through, directly determines how large your encryption parameters need to be. A computation with a multiplicative depth of 2 (for example, one round of squaring followed by a weighted sum) needs much smaller, faster parameters than a depth-10 computation. Map out the arithmetic circuit of your computation and count multiplicative depth before choosing parameters, because undersized parameters are the single most common reason a working HE prototype produces garbage on real data.

Decide between SEAL and OpenFHE deliberately. Microsoft SEAL is a C++ library (with a well-known community-maintained .NET wrapper and Node.js bindings via node-seal) implementing BFV, BGV, and CKKS, distributed under the MIT license from Microsoft's Cryptography and Privacy Research group. OpenFHE is a community-governed successor to the PALISADE library, implementing a broader scheme set (BFV, BGV, CKKS, plus the DM/CGGI schemes used for boolean-circuit FHE) with an explicit focus on usability, cross-platform support, and hardware accelerator integration. Neither is a turnkey platform: both are cryptographic libraries that expect you to handle parameter selection, key management, and serialization yourself, and both require a working knowledge of the underlying math to avoid footguns like insufficient noise budget or mismatched encryption parameters between client and server.

1. Install the library. Microsoft SEAL builds from source via CMake on Linux, macOS, and Windows, or installs as a vcpkg/NuGet package for .NET integration; OpenFHE builds from source via CMake as well, with binary packages available for common Linux distributions. Pin a specific release rather than tracking the development branch, since parameter defaults and API surfaces have changed across major versions of both libraries.
2. Select your scheme and encryption parameters. Choose BFV/BGV for exact integer workloads or CKKS for approximate real-number workloads based on the prerequisites above. Set the polynomial modulus degree (commonly a power of two such as 4096, 8192, or 16384) and the coefficient modulus chain based on your required multiplicative depth: both libraries expose helper functions (SEAL's CoeffModulus::BFVDefault or CoeffModulus::Create, OpenFHE's CCParams builder) that suggest a modulus chain for a target depth, and both will reject or warn on obviously insecure parameter combinations, but neither will tell you if your depth estimate was wrong until you run the actual computation.
3. Generate the key set. Generate a secret key (held only by the data owner), the corresponding public key (used to encrypt), relinearization keys (used after every ciphertext-ciphertext multiplication to control ciphertext size growth), and, if your computation needs vector rotations, Galois keys. Relinearization and Galois keys can be large; generate only the ones your computation actually needs.
4. Encrypt client-side. Encode your plaintext values into the library's plaintext format (SEAL's Plaintext/OpenFHE's Plaintext wrap the encoding step, batching multiple values into SIMD slots where the scheme supports it) and encrypt using the public key. Only the resulting ciphertext, never the secret key, leaves the client.
5. Perform the homomorphic operations server-side. Run the actual computation, additions, scalar multiplications, ciphertext-ciphertext multiplications, on the received ciphertext using only the public key and evaluation keys. Call relinearization immediately after each ciphertext-ciphertext multiplication to keep ciphertext size from growing unboundedly across subsequent operations. For CKKS specifically, track the scale factor after each multiplication and rescale as needed to keep values in range.
6. Return the encrypted result and decrypt client-side. Send the resulting ciphertext back to the data owner, who decrypts it with the secret key that never left their control. The server at no point holds, generates, or has access to the secret key.

Test correctness against the equivalent plaintext computation first. Before trusting any HE pipeline, run the identical computation in plaintext on the same test inputs and diff the results (accounting for CKKS's expected approximation error, typically on the order of the scale factor's precision). A mismatch almost always traces back to an encoding error, a scale mismatch in CKKS, or a relinearization step that was skipped or ordered incorrectly.

Monitor noise budget consumption, not just final output. Both SEAL and OpenFHE expose noise budget inspection (SEAL's Decryptor::invariant_noise_budget) that lets you check remaining noise budget mid-computation during development. Run your actual production computation against this and confirm noise budget stays positive through the last operation with margin to spare, not just barely above zero, since real-world input variance can push a marginal computation over the edge in production even when your test vectors passed.

Benchmark latency and ciphertext size against plaintext computation on your actual hardware. This is usually the deciding factor in whether HE is viable for a given use case. Measure end-to-end latency (encryption, homomorphic computation, decryption) and ciphertext size overhead against the equivalent plaintext computation, using your actual target parameters and target hardware, not a scheme's best-case published benchmark. A computation that takes microseconds in plaintext can take hundreds of milliseconds to seconds under HE, and ciphertexts are routinely tens to hundreds of times larger than the plaintext they encrypt. If that overhead makes the use case impractical at your required throughput or latency, that is a valid outcome of this validation step, not a sign you implemented it wrong.

Noise budget exhaustion. If the computation's actual multiplicative depth exceeds what your chosen parameters support, the noise budget hits zero before decryption and the decrypted output is garbage, not an error message. This is the most common HE implementation failure and the reason multiplicative depth has to be mapped out before parameter selection, not discovered afterward.

Undersized parameters for the wrong reason. Teams sometimes size parameters for the computation as originally scoped, then extend the computation (adding another aggregation step, another model layer) without revisiting the parameter choice. Any change to the computation's arithmetic circuit requires re-checking multiplicative depth against your coefficient modulus chain.

Use cases that need operations HE does not support efficiently. Comparisons (greater-than, sorting, conditional branching on encrypted data) are not natively efficient in BFV/BGV/CKKS; they require workarounds (polynomial approximations of comparison functions, or switching to the DM/CGGI boolean-circuit schemes OpenFHE also implements) that add significant overhead and complexity. Discovering mid-project that your computation needs a comparison step is a sign the use case should be re-scoped, split between HE and a different approach, or reconsidered for a TEE-based confidential computing model instead.

HE protects the confidentiality of data from the party performing the computation. It does not, by itself, provide integrity or authenticity guarantees: a malicious or compromised server can still perform the wrong computation on the ciphertext, or substitute a different ciphertext entirely, and the client has no built-in way to detect this from the ciphertext alone (this is the distinction between HE's standard security model and additional verifiable-computation techniques, which are a separate and generally heavier-weight problem). Treat HE as solving confidentiality-from-the-computing-party specifically, and pair it with the same input validation, access control, and result verification you would apply to any computation whose provider you do not fully trust.

The performance cost is real and scheme-dependent: expect roughly 100x to 10,000x overhead versus the equivalent plaintext computation depending on the operation mix and chosen parameters, which is why HE stays confined to narrow, bounded computations rather than replacing general application logic.

HE is not a drop-in replacement for TLS or at-rest encryption, and treating it as a general privacy upgrade for a whole system rather than a targeted tool for one specific compute-on-encrypted-data problem is the most common way HE projects get over-scoped. Choosing between SEAL, OpenFHE, a dedicated confidential-computing or TEE-based approach, or a purpose-built privacy-preserving analytics platform is a real architecture decision, and the right answer depends on your computation's shape, your latency and throughput budget, and whether you need protection against a malicious-server model or only an honest-but-curious one. Neither SEAL nor OpenFHE will make that decision for you.