Microsoft SEAL: a C++ homomorphic encryption library for encrypted addition and multiplication

The problem Microsoft SEAL solves, and who it is actually for

Ordinary public-key encryption protects data at rest and in transit, but the moment a cloud service needs to compute on that data, the encryption layer has to come off. The README puts it plainly: outsourced computation traditionally forces the service to hold secret keys and to enforce access policies so that employees cannot reach them. Microsoft SEAL removes that requirement for a narrow class of operations. Data is encrypted with a public key, the server computes on the ciphertext, and only the holder of the secret key can decrypt the result. The secret key never leaves the data owner.

The intended user is not a data scientist looking for a drop-in privacy switch. The README is explicit that homomorphic encryption cannot be used to circumvent GDPR, and that there is no way for a cloud service to use it to draw insights from encrypted customer data. The realistic adopter is an engineer who already controls both sides of a protocol: a client that encrypts a small vector of numbers, and a server that runs a fixed arithmetic circuit over them. Budgets, aggregates, scoring functions and similar lightweight pipelines fit. Exploratory analytics do not.

How the scheme works: keys, ciphertexts and a bounded arithmetic circuit

SEAL implements homomorphic encryption schemes in which additions and multiplications can be performed on encrypted integers or real numbers. The README describes the standard three-part structure underneath: key generation, encryption, decryption. Most schemes in this family are public-key, so anyone with the public key can encrypt, while only the secret key holder can decrypt. Data encrypted this way is many times larger than the plaintext, which is why the README warns against encrypting something like an entire large database.

The practical consequence is that a program has to be rewritten as a circuit. The README states that operations such as encrypted comparison, sorting, or regular expressions are in most cases not feasible, and that it is not possible to branch on encrypted data. Multiplication consumes a finite budget of noise, so the difference between an efficient and an inefficient implementation is large. The README also notes that multiple private data owners engaging in collaborative computation is probably not a reasonable fit, because the scheme typically has a single secret key held by one owner.

The repository is split into a native/ directory for the C++ core and a dotnet/ directory for the .NET wrapper, with android/, cmake/, pkgconfig/, pipelines/ and tools/ alongside them. Optional dependencies named in the README are Intel HEXL for acceleration, Microsoft GSL, and ZLIB with Zstandard for serialization.

Installing Microsoft SEAL and running a first encrypted computation

There are three documented routes in. On Windows, Linux, macOS, Android and iOS the README points to a NuGet package; vcpkg is the second; building manually with CMake is the third. The README does not print the exact install commands, so the concrete steps live in the repository rather than in the README text.

The manual build uses the top-level CMakeLists.txt together with CMakePresets.json, and the README documents basic and advanced CMake options, so anything beyond the default configuration is set at configure time. The repository layout shows a cmake/ directory and a pkgconfig/ directory, which is where the build and packaging support lives.

Once the library is linked, the repository's examples directory is the place to start: the README lists examples, tests and benchmarks as buildable targets, and it separately points to EVA for CKKS programming. A first real use is to take one of those examples, build it, and watch a vector of numbers get encrypted, multiplied, and decrypted back to the expected result. That single loop is the whole mental model. If your computation cannot be expressed as additions and multiplications over that vector, no amount of tuning will make SEAL fit.

Where Microsoft SEAL is the wrong tool

The README is unusually direct about the boundaries, and they are worth taking at face value. Homomorphic encryption is not a generic technology. Only some computations are possible, and the performance overhead is substantial, so anything already expensive on plaintext is likely infeasible on ciphertext. There is no branching on encrypted data, and encrypted comparison, sorting and regular expressions are mostly out of reach. A workflow that needs an if-statement on a secret value is not a SEAL workflow.

The multi-owner case is the second boundary. Because the schemes typically have one secret key held by the data owner, several mutually distrusting parties cannot simply pool encrypted inputs and share a result. The README says homomorphic encryption is probably not a reasonable solution there. The third is scale: ciphertexts are many times larger than plaintext, so encrypting a large database is a poor use of the technology even when it is technically possible.

Finally, the security model itself. The README states that most homomorphic encryption schemes provide weaker security guarantees than traditional encryption schemes, and that anyone considering production software must read SECURITY.md. That file is in the repository root, and it is the correct first stop, not an afterthought.

How Microsoft SEAL differs from a general-purpose FHE framework

The closest alternative in practice is a compiler-oriented FHE stack, such as the EVA toolchain that the README itself links for CKKS programming. The difference is one of layer. SEAL gives you the primitives: key generation, encoding, encryption, evaluation, decryption, plus the parameter selection that decides how much multiplication depth you can afford. A compiler layer takes a higher-level program and tries to schedule it onto those primitives, which shifts effort from hand-tuning noise budgets to writing something the compiler can lower.

That trade is real in both directions. Working directly against SEAL means you choose the scheme and parameters and you see exactly where the noise goes, which matters when a circuit is small and fixed. A compiler layer can make a larger program tractable, but you inherit its lowering decisions and whatever subset of the language it supports. The README positions EVA as an addition to SEAL rather than a replacement, which is consistent with SEAL being the substrate. If your circuit is a handful of additions and multiplications, the extra layer buys little. If it is a program, start by reading what the compiler can actually express.

A second practical difference is packaging. SEAL ships a NuGet package for Windows, Linux, macOS, Android and iOS, plus vcpkg and a CMake build, and the repository carries a dotnet/ tree for the managed bindings. Projects that need to call FHE from a managed service will find that path shorter than binding a research C++ codebase themselves.

Upgrade cost, version 4.4 and the MIT licence

The README opens with an important notice: Microsoft SEAL 4.4 is a critical security update, and all users should upgrade to version 4.4.0 or later as soon as possible. The listed fixes cover untrusted-input handling, native memory safety, and managed/native interoperability. The repository shows releases v4.4.3, v4.4.4 and v4.4.5 in the weeks before the last push on 2026-09-14, so the 4.4 line is receiving patch releases. Anyone pinned below 4.4.0 is carrying the issues that notice describes.

The README directs users of previous versions to CHANGES.md, which is the file to read before moving a production service across a major version. Because SEAL is a compiled C++ library with a managed wrapper, an upgrade touches both the native artifact and the .NET package, and the 4.4 notice specifically names managed/native interoperability among the fixed areas, which is a hint about where version skew between the two halves can bite.

On licensing, the repository carries an MIT licence and a separate NOTICE file, and the README links the MIT text directly. MIT is permissive, but this article gives no legal advice: read LICENSE and NOTICE in the repository before shipping, particularly if you redistribute the native binaries.

Editorial conclusion

Adopt Microsoft SEAL when the computation is small, the inputs are integers or real numbers, and policy forbids the cloud from ever seeing plaintext. Do not adopt it for multi-owner collaborative computation, for branching or comparison on encrypted data, or for large databases: the README states homomorphic encryption is not a generic technology and that encrypted data is many times larger. Before writing code, read SECURITY.md, since the README says most homomorphic encryption schemes provide weaker security guarantees than traditional encryption, and confirm the version you pull is 4.4.0 or later.

Frequently asked questions

Official sources

1. License: MIT
2. microsoft/SEAL on GitHub
3. Project website
4. README
5. Releases