TFHE-rs: programmable bootstrapping as a library, with three front ends over one Rust core

One cryptographic core behind three APIs

TFHE-rs is a pure Rust implementation of TFHE, the fast fully homomorphic encryption scheme whose practical appeal is bootstrapping: a computation on ciphertexts that refreshes them so further operations can follow. The library ships three ways to reach the same functionality.

There is a Rust API for native callers. There is a C API, described in the README as bindings to the Rust high-level API, so an existing C or C++ service can link against the library without a rewrite. And there is a client-side WASM API, so browser code can hold the private key and perform encryption on the client while a server evaluates encrypted operations and never sees a plaintext.

That third option is the one that shapes the library's feature list. Compressed ciphertexts and compressed server keys are listed as main features, and for a WASM client they are not a nicety but the difference between a payload that transfers and one that does not. The README also lists size-efficient public key encryption, which attacks the same problem from the other direction by shrinking what the client has to send.

The stated goal is a library that gives developers and researchers full control over TFHE without requiring them to own the low-level implementation, and that framing is consistent with the release history. The first stable version, v1.0.0, landed in February 2025 and stabilized the high-level API for the x86 CPU backend.

Programmable bootstrapping and what it changes

Programmable bootstrapping is the feature that separates TFHE from leveled homomorphic encryption, and the README names it first among the main features. In a leveled scheme, each operation consumes a level, and the computation has a fixed depth budget decided before it starts. In TFHE, the ciphertext is refreshed to its initial noise level after every multiplication, so depth is not the binding constraint the same way.

Making bootstrapping programmable means the refresh function is something the caller can influence rather than a fixed internal step. That is what allows circuits beyond the standard depth budget to be evaluated, at the cost of running an expensive operation more often. For anyone designing a custom circuit rather than calling a library function, that trade is the central design decision, and it belongs to the application, not to the crypto library.

The rest of the feature list covers the layers a real deployment needs: an implementation of the original TFHE boolean API usable as a drop-in replacement for other TFHE libraries, so existing boolean circuits port without restructuring, and a short integer API for exact, unbounded integer arithmetic with up to 8 bits of message space.

Zama publishes a companion handbook document with scientific and technical detail on the algorithms, plus a four-part TFHE deep dive covering ciphertext types, encodings and linear leveled operations, key switching and leveled multiplications, and programmable bootstrapping. That is the reference to consult when a question goes past the API surface.

Adding the crate and the toolchain requirements

The dependency line is short, and the feature names are what select the API layers you need:

tfhe = { version = "*", features = ["boolean", "shortint", "integer"] }

All three features are in the README's example, which tells you the recommended setup enables the original boolean API, the short integer API and the integer API together. Pulling in only what you use is reasonable, but the boolean feature is the compatibility layer, so treat dropping it as a decision rather than an optimization.

The toolchain requirement is stated plainly: Rust 1.91.1 or newer, checked with `rustc --version`. A second note covers a platform hole. AArch64-based machines running Windows are not supported, because the CSPRNGs used inside TFHE-rs have no entropy source available on that combination. That is a security-relevant exclusion rather than a performance one, and it means Windows users on ARM hardware have no path today.

The repository pins its own toolchain through `rust-toolchain.toml` and carries a `nightly-toolchain.txt`, and the Makefile builds against the nightly toolchain. The Cargo manifest lists workspace members for the backends, including `tfhe-cuda-backend`, `tfhe-hpu-backend` and `zk-cuda-backend`, alongside `tfhe-csprng`, `tfhe-fft`, `tfhe-ntt`, `tfhe-zk-pok`, `utils/`, `tests/`, `tasks/`, `apps/test-vectors` and `tfhe-benchmark`. If you are targeting an accelerator, the backends are where that work lives.

A worked example that shows the shortint ergonomics

The README's full example is short enough to read end to end, and it shows the API style better than any description. The header imports the prelude plus the specific types used, and the body runs through multiplication, a right shift, a cast, a minimum and an operation against a clear value:

use tfhe::prelude::*;
use tfhe::{generate_keys, set_server_key, ConfigBuilder, FheUint32, FheUint8};

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let config = ConfigBuilder::default().build();

    let (client_key, server_keys) = generate_keys(config);

    let clear_a = 1344u32;
    let clear_b = 5u32;
    let clear_c = 7u8;

    let mut encrypted_a = FheUint32::try_encrypt(clear_a, &client_key)?;
    let encrypted_b = FheUint32::try_encrypt(clear_b, &client_key)?;

    let encrypted_c = FheUint8::try_encrypt(clear_c, &client_key)?;

    set_server_key(server_keys);

    let encrypted_res_mul = &encrypted_a * &encrypted_b;

    encrypted_a = &encrypted_res_mul >> &encrypted_b;

    let casted_a: FheUint8 = encrypted_a.cast_into();

    let encrypted_res_min = &casted_a.min(&encrypted_c);

    let encrypted_res = encrypted_res_min & 1_u8;

    let clear_res: u8 = encrypted_res.decrypt(&client_key);
    assert_eq!(clear_res, 1_u8);

    Ok(())
}

The type names carry the information. `FheUint32` is the encrypted counterpart of `u32` and `FheUint8` the counterpart of `u8`, so the ciphertext width is visible at every point where it matters. Operators are overloaded so that arithmetic reads the way the cleartext version does, and operations mixing ciphertext and cleartext work, as the `& 1_u8` line shows.

Two details are worth copying into your own code. `set_server_key(server_keys)` is called once on the server side before any computation, which is how the evaluation context is installed. And decryption happens on the client with `decrypt(&client_key)`, which is the boundary a real deployment is built around: the server evaluates, the client decrypts.

Run it with:

cargo run --release

The README calls release mode close to a requirement, warning that it is highly recommended to use `--release` for the best performance possible. It also points out that transparent huge pages give a noticeable additional speedup on Linux with many threads.

What changed in the 1.7 and 1.8 release lines

The release notes describe features, which is unusual for a crypto library and tells you the project is shipping capability rather than only patches.

The 1.8.0 release, published 2026-09-17, is the substantive one. It adds transciphering as a new server input, selective decompression, a boolean dot product, and key size tuning for shuffle. Transciphering as a server input matters architecturally: it means the server can take an input it did not produce under the same key, which is what a multi-key or multi-owner setup needs. Selective decompression keeps ciphertexts compressed except where a computation requires expansion, which is the natural companion to the compression features on the client side. The boolean dot product is a primitive that shows up in a lot of real circuits, and the shuffle key size tuning cuts transfer cost for a pattern common in sorting and comparison networks.

Version 1.8.1, published the same day, is a single fix, adding a missing `has_transciphering_key` on `CompressedXofKeySet`. That is a one-day follow-up to a feature added the same day, so treat 1.8.0 as the baseline and 1.8.1 as its correction.

The 1.7.0 release, from 2026-07-21, brought array shuffle implemented via bitonic sort, `KVStore` contains, low-level transciphering and Kreyvium. Bitonic sort for shuffle is a deliberate choice: it is network-friendly, so the sequence of comparisons can run in parallel on accelerator hardware.

Licensing, supply chain and what to verify first

The README carries a license badge reading BSD-3-Clause-Clear, a LICENSE file is present in the tree, and the repository metadata classifies the license as NOASSERTION, which is what GitHub reports when it cannot detect a standard license. A permissive three-clause license is unusually good news for a cryptography library you might link into a product, and the mismatch between the badge and the metadata field is a packaging detail rather than a contradiction in terms. Read the LICENSE file to see the exact wording.

Supply chain work is visible rather than implied. There is a SLSA Level 3 badge, a SECURITY.md, a CODE_OF_CONDUCT.md, a CODEOWNERS file, and separate CONTRIBUTING.md and CONTRIBUTION_GUIDELINES.md documents. `codecov.yml` and a `ci/` directory suggest test coverage is enforced in CI, and `apps/test-vectors` exists as a workspace member, which is a sign that known-answer tests for the crypto operations are part of the build rather than an afterthought.

Documentation is broader than a typical repository README. There is a `.gitbook.yaml` and a `SECURITY.md`, plus linked tutorials, and the README asks contributors to read the contribution guidelines before opening a pull request. The last push was on 2026-09-20, three days after the 1.8.1 release, so the release line is current rather than abandoned.

Before adopting it, two checks are worth doing first. Confirm your target platform is supported, particularly if you are on Windows on ARM. Then look at how your circuit maps onto the shortint API versus the boolean API, because the two have very different performance profiles and the README does not publish a comparison.

Editorial conclusion

TFHE-rs is the right choice if you need TFHE with programmable bootstrapping and you want to write your circuit in Rust rather than assemble it from a lower level library. The boolean drop-in API, the shortint layer and the compression options are the practical reasons to pick it over a generic FHE framework, and the C and WASM front ends mean a Rust core can serve a C server and a browser client. Before you commit, check two things: that your target platform is on the supported list, since Windows on AArch64 is excluded for a CSPRNG reason, and that release mode is a requirement rather than a preference, because the README is explicit about `--release`. The most recent release, tfhe-rs-1.8.1, came out on 2026-09-17 and the repository was pushed on 2026-09-20.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. zama-ai/tfhe-rs on GitHub