Developer’s Checklist: How to Build an FHE Application

For most developers, fully homomorphic encryption (FHE) application development is uncharted territory. FHE allows you to compute on data without ever decrypting it, which means organizations can pool sensitive data to create smarter machine learning models or build cloud-based encrypted anomaly detection models without ever exposing data in the clear. In practice, building such applications asks you to deal with a host of parameters that aren’t relevant to traditional programming, including noise budgets, polynomial approximations, ciphertext packing, and parameter tradeoffs.

It’s all a lot to take in, but you can tackle FHE development just like an elephant sandwich: one bite at a time. Here is my checklist for how to approach FHE application development. By following this guide, you can take your first steps toward never exposing your sensitive data in the cloud again.

Step One: Design Your Architecture for a Clean Client-Server Handoff

FHE applications follow a strict client-server pattern. The client encrypts plaintext data and hands it to the server. The server performs computations on the encrypted data and hands it back. The keys never leave the client, and only the client can read the results.

Practically, that means no peeking. The server must be able to perform the required calculations without querying the client mid-computation. All data takes a single round trip: the server can never “decide what to do next” based on the results of a computation.

An FHE application can have multiple clients and a single server; that’s how federated learning works. In this case, you need to carefully consider who is allowed to decrypt the application results. FHE ensures no one can see the data during computation, but the output is a separate question entirely. It’s up to you to determine who holds the decryption keys.

Step Two: Build a Plaintext Version

Your application is going to be really hard to debug once it’s working with encrypted data. Instead, start with an application that just works. You’re going to iterate a lot as you go through the following design steps. Your original plaintext implementation will serve as a kind of control sample: every version and update of your application should be tested against the plaintext version using a robust set of test data.

Step Three: Strip the Branches

FHE applications can’t branch based on intermediate values. This is where FHE application development gets really tricky: you can’t use standard conditional branching to determine when to end a loop. Instead, FHE typically relies on branchless computation: The program evaluates both sides of a conditional and then uses an arithmetic selector to pick the result. You basically end up replacing branching logic with linear algebra. 

Step Four: Mind Your Noise Budget

As data makes its client-server round-trip in an FHE application, every multiplication step consumes a finite noise budget. If there are too many multiplications chained together, the noise will overwhelm the encrypted data, and the results will be unreadable. 

This leads us to one of the most important concepts in FHE: multiplicative depth. This is the longest single chain of dependent multiplications in an application. Shorter is better. Never use multiplication when you can use addition instead; favor tree-structured reductions over sequential accumulation; and, as always, seek the shortest critical path.

Sometimes even the best possible application design will consume the noise budget. In that case, you can use a technique called bootstrapping, which effectively allows the noise on your encrypted data to “refresh”, allowing for more computation. Bootstrapping doesn’t require decryption and can be performed multiple times, but it is extremely expensive. It’s preferable to reduce multiplicative depth instead of bootstrapping whenever possible. 

Step Five: Approximate Non-Linear Functions

Many mathematical functions, including division, comparison, root, and sigmoid operations, don’t have an FHE equivalent. You can either remove such functions, or replace them with a polynomial approximation (e.g., Chebyshev series).

Polynomial approximation adds multiplication, increasing multiplicative depth. The higher the accuracy of the approximation (i.e., higher-degree polynomials), the more it eats into your noise budget. When it comes to approximation, you always have to weigh tradeoffs between accuracy and computational cost. Also, polynomial approximations can usually only be applied to a specific, bounded input range, e.g., [-1, 1]. Your inputs must be normalized to the expected range, or your results may be nonsense.

Once you substitute polynomial approximations for any non-linear functions, check the results. You’re not just looking for similar outputs compared to the original plaintext “control” application; you’re looking for the accumulated approximation error. You need to make sure your application can handle this approximation noise.

Step Six: Convert to Integers and Constrain Precision

FHE only operates on integers. That means every variable in the application must be converted from floating-point to integer or fixed-point arithmetic. Computation precision must be constrained as well. Depending on the parameter choices in Step 7, available precision may be in the 16-32 bit range. 

Step Seven: Define Scheme, Parameters, and SIMD Strategy 

The FHE encryption scheme you choose defines what kind of math you can do. BFV and BGV are integer-only schemes, commonly used in image processing. CKKS is approximate, making it better for applications dealing with real values (by way of fixed-point representation), though in many cases it can still provide integer-precise results. 

Alongside the scheme, you need to define the degree of polynomials used in ciphertexts (usually 2¹⁵ or 2¹⁶), often called the ring dimension. This parameter, often in conjunction with decisions you’ve made above, determines security level, slot count (how many data items you can encode in a ciphertext), multiplicative depth, and memory footprint.

You also need to determine how your data will be organized for FHE processing. Modern FHE schemes leverage vector processing, allowing you to process data items in parallel by packing them into a single ciphertext. A machine learning application, for instance, can process thousands of data samples at once by packing them into the same ciphertext. You can thus compute inference over many features by striping them across several ciphertexts. Packaging data for efficient vector processing is critical to writing FHE applications that can operate at real-world speed.

Finally, a note on parameters: 128-bit security is the practical ceiling for most FHE applications. That said, 192-bit can work for shallower circuits. It all comes down, once again, to multiplicative depth.

Step Eight: Choose a Library

The BFV/BGV/CKKS schemes discussed above have actively maintained open-source options, including  OpenFHE (C++ with Python bindings) and Lattigo (Go). There are also commercial libraries, such as those from DeSilo, CryptoLab, and Lattica. For your first FHE application, I recommend OpenFHE. It’s well-supported, open-source, and road-tested.

Step Nine: Build the FHE Version

Every step so far has been an iteration on your original plaintext application. Now, it’s finally time to build the FHE version. Start by replacing each addition and multiplication with the corresponding FHE library call. Then check your work: compile again and make sure the syntax is correct.

Next up, you will need to generate keys, since you’re now ready to work with encrypted data. Using your FHE library, you will need to generate:

• The public (encryption) key
• The private (decryption) key
• Specialized FHE keys that allow the server to perform homomorphic computations.

The specialized FHE keys used by the server don’t decrypt anything. They instead enable the server to keep its computations well-formed.  

Now, it’s finally time to test your application.  Encrypt your test data, run the program, and compare your results to the output of the plaintext application. If they don’t match, comb through your code. You likely have a non-linear operation lurking somewhere, or too much multiplicative depth for your parameters. You may also have too little precision built into your approximation.

As I said above, debugging a program running on encrypted data is tricky. When you encounter a discrepancy between the FHE application and the plaintext control, I recommend outputting the intermediate variables one at a time from both versions. When you see where they diverge, you’ll know where to look for the problem.

Step Ten: Measure and Refine

Once your FHE application is up and running, check peak memory consumption and runtime. These numbers will likely be eye-popping, but that’s normal. FHE applications naturally have memory footprints in the gigabyte range and long runtimes to match. The question is, “Will this performance work for my application?” If the answer is “no,” return to the checklist. Look for ways to shorten multiplicative depth or pack data more efficiently.  Make your application as lean as possible while still baking in the precision you require. Once you’ve trimmed all the fat, FHE hardware acceleration may offer the performance gains you need to attain real-world performance speeds.

It’s Dangerous to Go Alone! Take This.

The FHE learning curve is admittedly steep. Niobium’s open-source FHE Application Design Skill can help accelerate your progress up the learning curve. Using the methodology described above, this Claude Code skill guides developers through designing and building FHE applications using OpenFHE. You don’t need FHE experience: just a basic understanding of what encryption does and facility writing C++ or Python.

I also recommend telling your AI partner to take advantage of the open-source Niobium Domain Specific Language (DSL). This DSL is designed to pair with the AI application design skill above, producing cleaner code that converts to OpenFHE. 

Both the FHE Application Design Skill and the Niobium DSL compile to Niobium’s fork of OpenFHE. This library is required when using the Fog, Niobium’s encrypted cloud platform, but also runs on a standard CPU. Like the other tools listed here, it’s open source and free to use. 

FHE is an immensely powerful tool that should be accessible to everyone. I hope this guide will inspire you to build your first FHE application. I cannot wait to see what this community will build once they never have to expose their data again.