OpenFHE: one C++ library for BFV, BGV, CKKS and lookup-table schemes

Four scheme families cover most homomorphic workloads

The README's opening claim is that OpenFHE includes efficient implementations of all common FHE schemes, and the list is specific. The Brakerski and Fan-Vercauteren scheme, BFV, and the Brakerski-Gentry-Vaikuntanathan scheme, BGV, handle integer arithmetic. The Cheon-Kim-Kim-Song scheme, CKKS, handles real-number arithmetic and includes approximate bootstrapping. Then there are the schemes for evaluating Boolean circuits and arbitrary functions over larger plaintext spaces using lookup tables: Ducas-Micciancio, which is FHEW, Chillotti-Gama-Georgieva-Izabachene, which is TFHE, and the Lee-Micciancio-Kim-Choi-Deryabin-Eom-Yoo scheme. The practical split is that integer and approximate real work goes through the PKE side of the library, and arbitrary function evaluation goes through the binfhe side, and the two are not interchangeable.

Scheme switching is the feature that makes non-smooth functions reachable

The part of the README that is hardest to summarise is the hybrid vectorized support, and it is the reason to look at OpenFHE rather than a single-scheme implementation. The stated goal is enabling FHEW and TFHE-like functional bootstrapping capability for schemes such as CKKS and BFV. In practice the library supports switching between CKKS and FHEW or TFHE to evaluate non-smooth functions, with comparison given as the example, and switching between RLWE, which the README notes is equivalent to the coefficient-encoded additive BFV scheme, and CKKS to evaluate arbitrary lookup tables over vectors of integers, with modular reduction, comparison and S-box given as the cases. The library also offers partial schemes called schemelets, and RLWE is described as the starting point for the vectorized functional bootstrapping capability.

Multiparty extensions are included, not left to a separate project

The README lists the multiparty extensions as part of the library rather than as an add-on. Threshold FHE is supported for BGV, BFV and CKKS, so a key can be split across parties. Interactive bootstrapping is supported for Threshold CKKS, which is the operation that is awkward to do with a single party's key. Proxy re-encryption is supported for BGV, BFV and CKKS, which is what you need when a third party has to transform a ciphertext without learning anything about the plaintext. The example list backs this up with threshold-fhe.cpp for BGV, BFV and CKKS, interactive-bootstrapping.cpp for the two-party case, and tckks-interactive-mp-bootstrapping.cpp for the simple n-party case. For a library that has been around long enough to have a design paper at eprint.iacr.org/2022/915, having these in the tree rather than in a fork matters.

The examples are organised by scheme, which is how you should learn it

The code examples section is effectively the API documentation, and its structure is the clearest guide to the library. For BFV and BGV there are simple examples plus serialization variants, simple-integers.cpp and simple-integers-serial.cpp for BFV, and the bgvrns and serial-bgvrns equivalents for BGV. CKKS has the widest set, with simple and advanced real number examples, an advanced example for high-precision CKKS, a function evaluation example, simple and advanced bootstrapping examples, a double-precision iterative bootstrapping example, a composite scaling example, and a Fourier-extension functional bootstrapping example. For the binfhe side there is boolean.cpp with symmetric encryption, a public key variant, multi-input gate evaluation, JSON and binary serialization examples, a large-precision comparison example and a small-precision arbitrary function evaluation. Scheme switching and functional bootstrapping over integers have their own files, and threshold FHE has its own.

The build is CMake, and the old Makefile only prints instructions

The root Makefile is a short signpost that says the project has converted to CMake and tells you what to do instead.

all:
	@echo "OpenFHE has converted to CMake"
	@echo "Try this:"
	@echo mkdir build
	@echo cd build
	@echo cmake ..
	@echo make
	@echo make install \(to install in 'installed'\)

The real build files are CMakeLists.txt with a CMakeLists.User.txt for local overrides, OpenFHEConfig.cmake.in and OpenFHEConfigVersion.cmake.in for the installed package config, and PreLoad.cmake. The repository also has configure/ for a separate configuration path, a third-party/ directory with git submodules given the.gitmodules file, a cicd/ directory, a docker/ directory, benchmark/, demoData/, test/, scripts/ and a docs/ tree that produces the published documentation. A.clang-format file and a CPPLINT.cfg at the root are the sign of a project that expects contributions to be formatted a particular way, and a.pre-commit-config.yaml enforces it.

Compiler floors and a best-performance guide, but no build recipe here

The compiler support is stated precisely. OpenFHE supports any GNU C++ compiler version 9 or above, and clang C++ compiler version 10 or above, and the README points at a document for building OpenFHE for best runtime performance, which is the right way to phrase it for a library where the parameter set and the polynomial degree dominate the timing. The README does not give a build command inline, it defers to the installation documentation with per-OS pages for Linux, MacOS and Windows, and separately points at a Quickstart in the same documentation set. That is a deliberate choice, since the number of CMake options for an FHE library is large enough that a one-line recipe in a README would be misleading. If you are evaluating quickly, the documentation is where the time goes, not the repository.

Version 1.6.1, a governance page and a security contact

The repository description states the current version is 1.6.1, released on October 9, 2026, and the release list matches with v1.6.1 on 2026-10-09, v1.6.0 on 2026-09-28 and v1.5.1 on 2026-04-10, so there was a substantial gap between 1.5.1 and 1.6.0 and then a quick follow-up patch. The last push was on 2026-10-11 and the repository is not archived, though the README notes that it is the development repository, which is the detail to keep in mind. The project also publishes a governance page and a contributing guide in the documentation, and for security issues the README asks you to email [email protected] rather than filing a public issue.

Editorial conclusion

OpenFHE fits a team that needs to experiment with homomorphic encryption across several schemes, since the same library covers integer and approximate real arithmetic, bootstrapping, lookup-table evaluation and multiparty extensions, and the example set is organised so you can start from the scheme closest to your problem. It is a poor fit for a production system with a hard audit requirement, because the repository is explicitly the development tree, the default branch is main and there is no stability promise in the documentation. Verify first which scheme your workload actually needs, since bootstrapping cost and precision limits differ sharply between BFV, CKKS and TFHE, and check the release notes and governance page before building on a specific tag.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. openfheorg/openfhe-development on GitHub
4. README
5. Releases