FHE Bootstrapping: What It Is, How It Works, and Which Scheme to Use

Anyone who has read any introductory material on FHE knows that bootstrapping is central to making fully homomorphic encryption practical. It is the most compute-intensive operation in any FHE scheme, and how a scheme implements it determines its performance profile, precision, and which workloads are realistic. 

This guide explains how FHE bootstrapping works, compares the major approaches used in CKKS, CGGI/TFHE, and BGV/BFV, and provides practical recommendations to help you choose the right scheme for your application. 

What Is Bootstrapping in Fully Homomorphic Encryption?

The term comes from the phrase “pulling yourself up by your own bootstraps.” In FHE, a scheme is considered bootstrappable when it can homomorphically evaluate its own decryption procedure, plus at least one additional operation, without exposing the secret key or the plaintext.

In traditional encryption, decryption uses a secret key to convert a ciphertext back into its original plaintext. Bootstrapping works differently. 

It uses a ciphertext together with an encrypted version of the secret key, known as a bootstrapping key or refreshing key, to create a new ciphertext that contains the same encrypted message but with much lower noise.

The secret key is never decrypted or revealed during this process. It remains encrypted throughout the operation under what cryptographers call the circular security assumption, allowing FHE computations to continue while keeping the underlying data protected.

Why Is Bootstrapping Necessary for FHE to Work?

Every practical FHE scheme relies on noisy encryption. The noise is an essential part of the encryption process because it helps protect the ciphertext, but it also creates a limitation: every homomorphic operation adds more noise.

As ciphertexts go through additions, multiplications, comparisons, and other computations, the accumulated noise eventually becomes too large. At that point, the ciphertext can no longer be decrypted correctly and cannot safely support additional operations.

Bootstrapping solves this problem by refreshing the ciphertext and reducing its accumulated noise. It produces a new ciphertext that contains the same encrypted information but has enough computational capacity for further homomorphic operations. 

This process, known as ciphertext noise reduction, is what allows FHE schemes to support computations of unlimited depth.

Bootstrapping can also do more than refresh ciphertexts. During the same operation, it can evaluate a function on the encrypted data, meaning the output ciphertext contains the result of applying that function rather than the original value. 

This capability is known as functional or programmable bootstrapping and is especially important for applications that require encrypted comparisons, lookups, or non-linear operations.

How Does FHE Bootstrapping Actually Work?

Every common bootstrapping method follows the blueprint Gentry introduced: homomorphically evaluate the scheme’s own decryption function. What differs between schemes is how that decryption function gets evaluated under the hood.

Classical decryption in lattice based schemes generally comes down to two steps, a linear computation involving the ciphertext and the encrypted secret key, followed by a rounding or modular reduction step.

Bootstrapping performs both of these steps homomorphically. The linear step is fairly similar across schemes. The rounding step is where CKKS, CGGI, and BGV diverge, and that divergence is what drives the very different performance profiles below.

CKKS vs CGGI vs BGV: What Is the Real Difference in Bootstrapping?

Each scheme was designed around a different kind of data and a different rounding strategy, and that shows up directly in bootstrapping performance. 

CGGI (also called TFHE), and its close relative DM (FHEW), encrypt one value per ciphertext, typically a bit or a small integer. Bootstrapping happens through a technique called blind rotation and can run in well under a tenth of a second.

Because it is so fast and operates natively on lookup tables, CGGI is the natural fit for evaluating arbitrary functions over small integers, Boolean circuits, comparisons, and similar logic. 

CKKS encrypts a vector of real numbers into a single ciphertext, often tens of thousands of values at once, using an approach that behaves like SIMD parallelism.

Its bootstrapping step is slower per operation but gives it the highest bootstrapping throughput of the mainstream schemes for large, real-valued workloads. . 

CKKS is approximate by design, meaning bootstrapping introduces a small, well understood error rather than reducing noise to exactly zero.

BGV and BFV work with exact integers rather than approximations and use a digit extraction technique during bootstrapping. Their bootstrapping throughput lands between CGGI and CKKS for most workloads, and unlike CKKS, they preserve the plaintext exactly rather than approximately. 

The table below summarizes real, published benchmark results for each scheme, run on comparable hardware at the 128 bit security level.

These figures come from Duality’s own peer reviewed benchmarking of the OpenFHE library, published in Demystifying Bootstrapping in Fully Homomorphic Encryption.

A newer bootstrapping method for the CGGI family, known as LMKCDEY, has since been added to OpenFHE and now matches or beats CGGI’s speed while using a smaller memory footprint, which matters most for threshold and multiparty FHE deployments.

How Fast Is FHE Bootstrapping in 2026?

Bootstrapping speed has moved fast over the last two years, mostly because of hardware, not just algorithms.

A few figures worth knowing if you are scoping a project this year: CKKS bootstrapping on GPUs is now measured in tens of milliseconds rather than tens of seconds. Recent open source GPU libraries built on top of OpenFHE have reported speedups of 70 times or more over the AVX optimized CPU implementation for full CKKS bootstrapping.

TFHE style bootstrapping has crossed the sub millisecond mark on modern data center GPUs such as the NVIDIA H100, a threshold researchers had been chasing for years and that opens the door to near real time encrypted logic evaluation.

OpenFHE itself has kept shipping. The library reached version 1.5 in 2026 and continues to add native support for newer, faster bootstrapping variants like LMKCDEY, alongside its existing CKKS, CGGI, DM, and BGV implementations.

Hardware focused programs, most notably DARPA’s DPRIVE initiative, have funded dedicated FHE accelerator chips aimed at closing the remaining gap between encrypted and plaintext computation, with early designs targeting order of magnitude improvements over GPU acceleration alone.

For a broader view of where FHE performance stands across libraries and hardware platforms in 2026, see our detailed breakdown of homomorphic encryption performance benchmarks.

What Is Programmable (Functional) Bootstrapping?

Programmable bootstrapping, sometimes called functional bootstrapping, is what happens when you combine noise reduction with function evaluation in a single bootstrapping call. 

Instead of just refreshing a ciphertext, the operation also applies a lookup table to the encrypted value, so the output ciphertext encrypts a chosen function of the input rather than the input itself.

This is where CGGI and DM have a real structural advantage. Because they already bootstrap one small value at a time using an accumulator and a lookup table, evaluating an arbitrary function over that value during bootstrapping costs essentially nothing extra.

CGGI and DM are the only families where arbitrary function evaluation is free during bootstrapping. CKKS reaches similar functionality two ways: polynomial approximation, and OpenFHE’s functional-bootstrapping and CKKS-to-FHEW switching paths for functions that polynomials approximate badly.

CKKS gets similar functionality by evaluating a polynomial approximation of the target function, which works well for smooth, continuous functions but cannot represent arbitrary lookup tables the way CGGI can. 

BGV and BFV support a narrower set of built in operations, mainly scaling and sign evaluation, during their bootstrapping step.

How Does Hardware Acceleration Improve FHE Bootstrapping Performance?

Hardware acceleration applies to every bootstrapping method described above, and the gains are large enough that they now shape which scheme teams choose, not just how fast it runs. GPUs remain the most widely deployed accelerator.

Memory centric optimizations have delivered reported speedups above 100 times for CKKS bootstrapping compared to naive CPU implementations, and similar multiples for CGGI through massively parallel gate evaluation. FPGAs offer a middle ground between GPU flexibility and custom silicon efficiency.

FPGA based bootstrapping accelerators have demonstrated significant latency reductions by optimizing memory bandwidth and arithmetic intensity, the two biggest bottlenecks in bootstrapping. ASICs are the newest frontier.

Government backed research programs are funding dedicated FHE processors specifically to remove the bootstrapping bottleneck at the hardware level, with published designs already showing bootstrapping latency in the tens of milliseconds for BGV style schemes.

The practical takeaway is that the relative ranking of CKKS, CGGI, and BGV bootstrapping performance holds steady across hardware platforms. Acceleration speeds all of them up by a similar order of magnitude, so the scheme choice guidance in this article stays valid whether you are running on a laptop CPU or a GPU cluster.

Our own platform applies this same principle in production, matching batching strategy and hardware selection to each workload rather than accelerating blindly. You can see how this applies to emerging encrypted AI workflows in our piece on agentic AI with FHE. 

What is the biggest mistake companies make when choosing an FHE scheme for a real-world application?

Picking the scheme before defining the workload and the trust model. Teams compare published per-operation bootstrapping latency and choose whichever number looks fastest, when what actually matters in production is end-to-end throughput at their own data shape and precision requirement.

A scheme with far worse per-call latency can be cheaper overall if each call carries tens of thousands of values.

Benchmark results should always be evaluated in context. Factors such as library version, hardware, security level, ring dimension, precision, and workload design can significantly affect reported performance, making raw bootstrapping latency alone an unreliable basis for choosing an FHE scheme.

The second version of this mistake is treating scheme choice as the whole architecture. Circuit depth and how well a computation packs into slots usually drive cost more than which scheme or accelerator is used, so reducing depth or improving packing often buys more than switching either one.

The third is assuming FHE has to handle an entire pipeline end to end. Most production deployments are hybrids: private set intersection under FHE feeding a computation that runs inside an attested TEE, or federated learning with encrypted aggregation rather than pure FHE inference. And with scheme switching now supported between CKKS and CGGI, the scheme question itself is no longer strictly either/or.

The mistake that surfaces last, and matters most once a system reaches production, is deferring key management: who holds the secret key, whether it is shared across parties under a threshold scheme, and who can authorize a decryption. That decides whether a deployment clears a regulated environment far more than bootstrapping speed does.

Which FHE Scheme Should You Use for Your Application?

Once you understand how each scheme bootstraps, choosing between them comes down to matching the shape of your data and your computation to the scheme’s strengths.

Choose CKKS if your application works with real numbers, typically represented as floating point values. This covers most practical machine learning workloads, logistic regression training, neural network inference, and general statistical computation, where you need to process large batches of numbers efficiently and can tolerate a small, bounded approximation error.

Choose CGGI or DM (TFHE or FHEW) if your application needs to evaluate arbitrary functions over small integers or Booleans. Encrypted comparisons, branching logic, Boolean circuits, and small scale machine learning inference all fit naturally here, especially when programmable bootstrapping lets you fold a whole function into a single fast operation.

Choose BGV or BFV if your application needs exact, not approximate, computation over vectors of small integers. Private information retrieval, private set intersection, and secure database queries are the classic use cases, since exactness matters more than raw throughput for these workloads. 

Many real applications need both large batch processing and arbitrary function evaluation, decision tree training is a good example.

For these cases, OpenFHE now supports scheme switching, moving a ciphertext from CKKS to CGGI and back within the same computation, so you get CKKS style throughput for the bulk of the workload and CGGI style function evaluation exactly where you need it, without redesigning your entire pipeline around a single scheme. 

If your project is still at the stage of deciding whether FHE fits at all, our guide to real world FHE applications walks through where teams typically start.

Bootstrapping is what makes fully homomorphic encryption fully homomorphic. It is also the single biggest lever for performance, cost, and which computations are even practical to run encrypted.

Duality helped build OpenFHE, the open source library behind most of the benchmarks in this article, and continues to publish updated bootstrapping research as new schemes and hardware become available. 

For the full technical treatment, including the complete benchmark methodology, read our whitepaper, Demystifying Bootstrapping in Fully Homomorphic Encryption.