AI Privacy: Recent Cases Underscore Urgent Risks

As AI becomes embedded in everyday services, new incidents highlight how fragile privacy remains in the AI era. From chatbots leaking private conversations to browser assistants raising surveillance concerns and healthcare tools struggling with consent, these cases underline the critical need for stronger privacy safeguards.

Chatbot Data Leaks: Grok Under Scrutiny

Private conversations with xAI’s chatbot Grok were recently exposed online after its “share” button generated public URLs that were automatically indexed by search engines. This made sensitive exchanges accessible to anyone, including troubling content. Once indexed, those conversations became publicly searchable.

The flaw highlights a recurring problem with AI platforms. Features designed for convenience can create privacy nightmares if not implemented with safeguards. Similar indexing issues have affected other chatbots, including OpenAI’s ChatGPT. Developers across the industry need to adopt stronger privacy-by-design principles, but relying solely on developer safeguards has proven insufficient.

AI Web Browser Assistants: Convenience vs. Privacy

A new University College London study, presented at the latest USENIX Security Symposium, provided the first large-scale analysis of AI browser assistants. It uncovered widespread tracking, profiling, and data collection practices. Researchers found that popular extensions such as Merlin, ChatGPT for Google, and Microsoft Copilot can transmit entire webpage content, including sensitive form inputs like banking or health data, to their servers. Others shared identifiable user information with platforms like Google Analytics, enabling cross-site tracking and targeted advertising. Some assistants inferred personal traits such as age, gender, and income across browsing sessions.

A growing number of users rely on AI browser assistants for tasks like summarizing pages, automating browsing, and more. But researchers warn that these assistants operate with unprecedented access to users’ online behavior, often without transparency or consent. In some cases assistants may even breach privacy regulations such as HIPAA or FERPA. The authors argue that without stronger oversight and privacy-by-design safeguards, AI browser assistants risk becoming a surveillance layer embedded in everyday browsing.

Healthcare and Clinical Trials: Personalization at a Cost

In healthcare, AI is also being explored to personalize clinical trial consent forms, making them clearer and more engaging for participants, helping overcome a key barrier to recruitment. Yet experts warn of significant challenges. Beyond privacy and data security concerns, there are risks of AI-generated consent documents containing errors, biases, or even manipulative phrasing that could undermine true informed consent. Sensitive health data required to power these systems also heightens the risk of misuse, while regulators struggle to keep pace with technological change.

AI Privacy: The Path Forward 

Despite their differences, these cases reveal a common thread: AI systems not designed with privacy at the core are vulnerable to breaches and erosion of trust. As recent cases show, design safeguards and regulation alone cannot guarantee privacy.
One promising technology is Fully Homomorphic Encryption (FHE) which enables computation on encrypted data without ever exposing the underlying information. By keeping data secure throughout its lifecycle, FHE could mitigate chatbot leaks, reduce surveillance risks, and protect sensitive health records, while still enabling AI innovation. With hardware acceleration (such as 3PU™), FHE offers a way to embed privacy directly into AI infrastructure, safeguarding trust without delaying progress.

 

FHE Compilers: Bridging Theory and Real-World Applications

In our last blog post we reviewed how libraries serve as ready-made cryptographic building blocks. In this blog, we’ll review compilers (or transpilers) that help transform code into programs that can run securely on encrypted data. Libraries and compilers bridge the gap between theory and real-world application.

Writing efficient FHE programs by hand is complex. Developers must manage encryption parameters, ciphertext noise growth, and other cryptographic details that require specialized expertise. FHE compilers and transpilers bridge this gap by translating code or domain-specific descriptions into efficient FHE implementations.

These tools handle tasks like noise management, parameter selection, and insertion of encryption-specific operations, making FHE more accessible and practical for non-experts. This lowers the barrier to adopting FHE, enabling use cases where developers can write programs that run on encrypted inputs with minimal cryptographic know-how.

HEIR

HEIR (Homomorphic Encryption Intermediate Representation) is Google’s next-gen FHE compiler framework built on MLIR. It aims to unify established techniques in FHE, automating low-level cryptographic concerns, providing modular frontends and backends.

HEIR makes it easy for developers to get started with FHE by letting them write Python programs and simply mark secret data types. It offers hardware designers flexible integration points for targeting accelerators at different levels of abstraction. For researchers, HEIR provides a ready-made compiler infrastructure with standard optimizations, benchmarks and examples.

Key Features: HEIR compiles programs to encrypted equivalents, supports modern FHE schemes, and supports code generation for standard FHE libraries (Lattigo, OpenFHE) and hardware accelerators (GPU, TPU, FPGA and ASICs). HEIR supports frontends like Python and Torch.

HEIR was last updated in 2025, including Python Frontend, new schemes, improved noise modelling, parameter selection and more.

Concrete

Concrete is an open-source FHE compiler developed by Zama. It is built on TFHE technology and leverages LLVM, making FHE programming accessible to developers without deep cryptography expertise.

For example, a Python developer can write a function f(x,y) that operates on integers, and Concrete’s toolchain will produce a corresponding function that operates on encrypted integers (LWE ciphertexts) of specified bit-width, handling all cryptographic details in the background. This dramatically improves usability: it requires no knowledge of noise budgets or key switching.

Key Features: It includes a simple Python API for FHE operations, GPU acceleration support, automatic parameter selection, built-in performance analysis tools and integration with existing Python code.

Concrete is regularly updated by ZAMA and contributed to, with the latest release made in 2025, including added compatibility to TFHE-rs.

Key Innovations in FHE Compiler Development

Several early FHE compilers paved the way for today’s tools, each introducing key innovations at the time; here’s a quick look at who built them, when, and what impact they had.

Conclusion

FHE compilers and transpilers are steadily making homomorphic encryption more practical, bridging high-level programming with optimized cryptographic backends and lowering the barrier for developers to build privacy-preserving applications.

FHE Libraries: Established Cryptographic Building Blocks

In our last post, we placed Fully Homomorphic Encryption (FHE) alongside other Privacy-Enhancing Technologies (PETs). A dedicated processor is essential for scalable FHE, but it’s only one part of the puzzle.

This is where libraries and compilers come in. Think of them as the toolkits and translators of the FHE world. Libraries give developers ready-made cryptographic building blocks, sparing them from reinventing the math from scratch. Compilers (or in FHE’s case, often transpilers) help transform ordinary code into programs that can run securely on encrypted data. Together, they bridge the gap between cutting-edge theory and usable, real-world applications.

Researchers, organizations, and developers working with FHE face important decisions. The libraries and compilers they choose will influence everything from ease of development to performance and scalability. Each option has its own characteristics, so understanding the landscape is essential before starting. In the following post, we’ll cover FHE libraries part of this landscape.

FHE Libraries

Libraries are used by FHE developers as they provide established cryptographic building blocks for privacy-preserving data analysis implementations. Some of these libraries have been developed and shared by big tech companies like Microsoft and IBM, who offered the SEAL and HElib libraries, respectively. Current important libraries include OpenFHE, HEAAN, Lattigo and TFHE. Below is a quick review for each library, and a TL;DR summary table.

OpenFHE

Background & Developers: OpenFHE is a relatively new library (initial release in July 2022) that represents a unified, next-generation FHE project. It is the direct successor to the PALISADE library (see below) and was created by a consortium of FHE experts from multiple organizations, and is primarily led by Duality Technologies.

The design of OpenFHE intentionally incorporates the best ideas from prior libraries – it draws on the modular design of PALISADE and integrates selected concepts from HElib, HEAAN, and FHEW libraries. OpenFHE is maintained as a community-driven open-source project (affiliated with NumFocus) under a 2-clause BSD license.

Supported Schemes: A major strength of OpenFHE is its comprehensive scheme support. It implements all the major FHE schemes in a single library: BGV and BFV, CKKS, TFHE and FHEW.

Features & Innovations: OpenFHE’s design emphasizes extensibility, performance, and usability. Unlike its predecessors, OpenFHE was designed with bootstrapping in mind for all schemes from the very beginning. It provides built-in bootstrapping procedures so that users can optionally achieve fully homomorphic operation with BGV/BFV/CKKS, not just leveled computation.

Another key feature is its Hardware Abstraction Layer (HAL), which allows plugging in different hardware accelerators (GPUs, FPGAs, ASICs) to speed up FHE operations. This modular HAL enabled OpenFHE to be used in DARPA-funded hardware acceleration efforts and makes it future-proof as FHE moves toward specialized chips.

OpenFHE also supports multiple API modes: a high-level, user-friendly mode where the library automatically manages complex tasks like modulus switching and key rotation, and a lower-level “compiler-friendly” mode for integration with compilers or domain-specific languages that schedule those operations explicitly.

Use Cases: OpenFHE has become a widely used library for new FHE applications. Notably, Google selected OpenFHE as the backend for its FHE Transpiler – a tool that compiles high-level programs into FHE circuit operations.

In summary, OpenFHE’s distinguishing features are its unification of schemes, community-driven development, and forward-looking design that accommodates bootstrapping and hardware acceleration – making it a robust foundation for the next wave of FHE applications.

While OpenFHE unifies multiple approaches, other libraries specialize in specific schemes, for example HEAAN for arithmetic for approximate numbers.

HEAAN

Background & Developers: HEAAN stands for Homomorphic Encryption for Arithmetic of Approximate Numbers. This open-source library was developed by the Cryptography Lab at Seoul National University (SNU) under Prof. Jung Hee Cheon, et al., the inventors of the CKKS scheme. The first version of HEAAN was released on GitHub in May 2016, shortly after the publication of the CKKS paper (AsiaCrypt 2017). Today, HEAAN is maintained and further developed by CryptoLab, Inc., a Korean startup founded by Cheon, which has continued to improve the library’s performance and features.

Supported Schemes: HEAAN’s core (and original) focus is the CKKS scheme. It natively implements CKKS with all its major capabilities (encoding/decoding of vectors of real numbers, homomorphic addition, multiplication, rescaling, etc.). Over time, the developers also incorporated a bootstrapping procedure for CKKS into HEAAN, meaning the library can refresh CKKS ciphertexts and allow an unlimited number of operations on encrypted data.  (important for long or iterative computations). Recent versions from CryptoLab have added support for BFV as well.

Notable Features: HEAAN’s distinguishing feature is its expertise in approximate arithmetic. Because it was developed by the scheme’s creators, it often serves as a testbed for state-of-the-art CKKS techniques (e.g. improved encoding methods, error management, and bootstrapping algorithms). The library achieves high performance and precision in numerical homomorphic computations.

Importantly, HEAAN also natively supports GPU acceleration, with architecture-aware optimizations that can speed up core polynomial multiplications by more than 100× compared to single-threaded CPU execution.

HEAAN’s bootstrapping implementation was among the first for approximate arithmetic and continues to be optimized. The library also provides flexible APIs for adjusting parameters to balance precision, security, and performance for a given application.

Deployments & Applications: HEAAN has seen uptake in both research and industry, especially for data science applications. A notable real-world integration is IBM’s HElayers software (an SDK for homomorphic encryption in AI workflows), which incorporated CryptoLab’s HEAAN library. Another example is Samsung Electronics, which partnered with CryptoLab to develop a SmartSSD prototype that can perform homomorphic encryption operations (using HEAAN) directly on an SSD storage device.

In summary, HEAAN’s advantage lies in fast approximate computations: it is a go-to library for CKKS, offering world-class speed for encrypted linear algebra and has proven its mettle in commercial collaborations for privacy-preserving AI.

Another modern library, Lattigo, takes a different approach by focusing on Go-based implementations and multiparty FHE.

Lattigo

Background and developers: Lattigo is an open-source fully homomorphic encryption (FHE) library written in GO, initially developed in 2019 at EPFL’s Laboratory for Data Security and since 2021 maintained by Tune Insight. It implements full-RNS Ring-Learning-With-Errors-based homomorphic-encryption primitives and Multiparty-Homomorphic-Encryption-based secure protocols. It supports BFV, BGV and CKKS schemes and their multiparty versions. Notably, it offers a bootstrapping-capable CKKS, enabling iterative encrypted computations.

Its pure GO implementation makes it easy to integrate into concurrent microservices, supports cross-platform builds (including WebAssembly for browsers), and still delivers performance comparable to leading C++ libraries.

Lattigo is regarded as a state-of-the-art tool in the FHE community, broadly adopted for academic research due to its convenience, and acknowledged by industry and standards bodies, including the HomomorphicEncryption.org,  with C++ bindings available through AWS Labs.

Lattigo remains under active development (current major version 6) with frequent updates. It is backed by Tune Insight’s in-house team and guided by an expert advisory committee, ensuring continuous progress in multiparty homomorphic encryption while maintaining strong performance and usability.

TFHE

Background: TFHE stands for Torus Fully Homomorphic Encryption, and it is another library for Boolean circuit FHE that can be seen as the successor to FHEW. Developed by Ilaria Chillotti, Nicolas Gama, Mariya Georgieva, and Malika Izabachène (often referred to as the CGGI scheme, 2016), TFHE introduced a dramatically faster bootstrapping method.

The scheme was published in 2016 in a paper entitled “Faster Fully Homomorphic Encryption: Bootstrapping in less than 0.1 Seconds”. The first open-source release of the TFHE library was in 2017, and it has been updated with improved parameters (latest version 1.1 as of 2020). Unlike FHEW which used traditional polynomial rings, TFHE operates on the torus (real numbers modulo 1) representation of numbers, which enables certain optimizations in the bootstrapping procedure.

Scheme & Performance: The TFHE library implements a ring-variant of the GSW cryptosystem with numerous optimizations for speed. Its hallmark achievement is ultra-fast gate bootstrapping:  the library can evaluate a net-list of binary gates homomorphically at a rate of about 50 gates per second per core and has no restriction on the number of gates or on their composition. Essentially, TFHE improved the bootstrapping noise management to drastically reduce the time, and introduced an efficient technique for “gate-by-gate” bootstrapping on the fly. The supported functionality includes all binary gates and a fast encrypted multiplexer (MUX) operation as a primitive, which can be used to construct more complex circuits or programmable logic tables.

Features & Usage: The original TFHE library is written in C/C++ and released under Apache 2.0 license, making it easy to integrate in other projects. A notable aspect is that TFHE outputs are themselves libraries or services; for example, Zama built its “Concrete” library as a high-level framework on top of the TFHE scheme, which provides user friendly APIs for machine learning on encrypted data. Additionally, Google’s initial FHE transpiler releases (prior to OpenFHE integration) leveraged TFHE for Boolean circuits, given its speed.

More recently, the scheme has been reimplemented in Rust as TFHE-rs by Zama, offering the same underlying CGGI cryptosystem with added advantages of memory safety, modern APIs, and active long-term maintenance. TFHE-rs serves as the backend for Zama’s Concrete and Concrete-ML libraries, making the TFHE approach production-ready and easier to integrate into real-world applications.

TFHE’s distinguishing feature is its sheer speed for binary homomorphic operations. It made fully homomorphic evaluation of general-purpose logical circuits practical, bringing bootstrapping down to tens of milliseconds. With the Rust-based TFHE-rs now actively developed and deployed in modern frameworks, the TFHE family continues to be a cornerstone for Boolean FHE applications.

The following libraries have carried important influence in the development of the FHE ecosystem:

Microsoft SEAL

Microsoft SEAL (Simple Encrypted Arithmetic Library) was released by Microsoft Research in 2015 as an easy-to-use open-source FHE library. Developed by the Cryptography and Privacy Research group at Microsoft, SEAL was designed to make FHE accessible to software engineers without deep cryptography expertise. It is written in C++ with no external dependencies and provided under the MIT license. The last update for SEAL was version 3.7.3 on March 2021.

HElib

HElib was originally developed at IBM Research, making it one of the earliest functional FHE libraries (first released around 2013–2014). It emerged after Craig Gentry’s seminal 2009 FHE work, as an implementation of the BGV scheme. IBM’s goal with HElib was to explore and optimize lattice-based FHE in practice, and it was then maintained as a community project. It supported BGV, was the first library to support bootstrapping for BGV, and then added CKKS. The last update for HElib was version 2.3.0 on July 2023.

FHEW

FHEW was introduced by cryptographers Leo Ducas and Daniele Micciancio around 2014–2015. The name “FHEW” comes from their paper “FHE bootstrapping in less than a second“. FHEW’s contribution was foundational proving that gate-by-gate bootstrapping was feasible, which dramatically improved the speed of bootstrapping. FHEW was a proof-of-concept and was not heavily optimized beyond the authors’ initial efforts. The last major update to FHEW code was around 2017.

PALISADE

PALISADE is an open-source FHE library that preceded OpenFHE, developed by a team led by researchers from Raytheon BBN Technologies and NJIT, with contributions other organizations. Its development began under the DARPA PROCEED program (circa 2014) with the goal of creating a modular, open-source FHE toolkit for multiple schemes. PALISADE had its first public release in 2017, and as of 2025, PALISADE is still available but effectively succeeded by OpenFHE .

TL;DR Table

Library Schemes Supported Language Last Update Notable Features
OpenFHE BGV, BFV, CKKS, FHEW, TFHE C++ Active (2025, v1.x series) Unified support for all major schemes; built-in bootstrapping; Hardware Abstraction Layer (HAL) for GPU/FPGA/ASIC acceleration;
HEAAN CKKS, BFV C++ Active (2025, maintained by CryptoLab) Native CKKS reference library; native GPU acceleration; first to implement CKKS bootstrapping;
Lattigo BFV, BGV, CKKS GO Active (2025, v6) Pure Go implementation; multiparty FHE protocols; easy integration in microservices;
TFHE/
TFHE-rs		 Boolean circuits (binary gates, via CGGI scheme) Original: C/C++
Modern:
Rust (TFHE-R)		 TFHE – v1.1 (2020)
THFE-rs – Active (2025 by ZAMA)		 TFHE pioneered ultra-fast bootstrapping;
THFE-rs (RUST) offers memory safety, modern APIs and regular updates by ZAMA


Onwards to Compilers and Transpilers

If libraries are the toolkits of FHE, compilers and transpilers are the translators, in our next post, we’ll explore how they transform ordinary code into secure computations.

FHE Schemes – The Road to Practical Adoption

In our Fully Homomorphic Encryption (FHE) journey so far, we’ve looked at the history of FHE and introduced its immense potential for cloud computing and privacy. We subsequently touched on the key mathematical foundations of FHE, and most recently took a considered look at the computational toll  this technology currently demands. Now, it’s time to zoom in on the core cryptographic schemes that bring FHE to life: BGV, BFV, CKKS, and TFHE.

It may be helpful to think of each of these schemes as different ‘languages’ that FHE systems use and understand to compute on encrypted data. Each has its own vocabulary, grammar, and specialties — making them suitable for different applications. In this post, we’ll break them down in a friendly and intuitive way, and include a summary table for readers who prefer to jump straight to the conclusions.

Why Different FHE Schemes Exist

Before we dive into acronyms, let’s understand why we even have multiple FHE schemes. Imagine trying to design a tool that lets you perform computations without ever seeing the actual data. You’d quickly run into complex trade-offs between efficiency, precision, the types of data supported, and security.

No single FHE scheme can excel in every area, so different schemes have emerged, each optimizing for specific needs. Some are better for working with numbers, others for logic circuits, and some shine in machine learning tasks. Now, let’s explore schemes.

BGV: The Versatile Classic

BGV stands for Brakerski-Gentry-Vaikuntanathan, after the researchers who introduced it in 2011. We discussed Gentry’s particularly pivotal role in the origin story of FHE, and in BGV, in the introductory post. BGV was one of the first practical FHE schemes and remains widely studied and used today.

Key Characteristics:

When to Use It:

BGV is great for applications that need precise calculations on integers, like encrypted statistics, private database queries, or secure voting systems.

BFV: The Balanced Workhorse

BFV, short for Brakerski-Fan-Vercauteren, is similar to BGV but with some key differences under the hood. It’s designed for exact arithmetic over integers, just like BGV, but it handles ciphertext and noise in a slightly different way.

Key Characteristics:

When to Use It:

Similar to BGV, BFV is designed for applications that demand precise integer computations. Typical use cases range from financial analysis to private identity verification and secure government workflows.

CKKS: The Approximate Mathematician

Now we move into a different territory:  approximate arithmetic. The CKKS scheme (named after Cheon-Kim-Kim-Song) was built specifically for real numbers, allowing it to perform operations on decimal values, though with some loss in precision, liker rounding in everyday math.

Key Characteristics 

When to use it

CKKS is the go-to scheme for privacy-preserving AI, such as encrypted neural networks, homomorphic inference, and private data analytics. It’s also useful in healthcare or finance, where averages, trends, and predictions matter more than exact values.

Did You Know?

One of the strongest validations of CKKS is that the most advanced implementation of BFV bootstrapping converts to CKKS, performs bootstrapping using CKKS, and then converts back. This approach takes advantage of CKKS’s efficiency even when working with other schemes.

TFHE: The Speed Demon for Binary Logic

TFHE (short for “Fast Fully Homomorphic Encryption over the Torus”) is different from the previous three schemes. Instead of focusing on numbers, TFHE excels at bit-level operations. Think of it as a secure digital logic processor.

Key Characteristics:

When to use it

TFHE is best suited for applications involving simple logic circuits, such as blockchain, smart contracts, and private condition checking (like password verification or access control).

A Quick Comparison Table

Scheme Data Type Precision Strengths Common Uses
BGV Integers Exact Mature ecosystem Stats, Voting, Finance, ID verification
BFV Integers Exact Simpler noise handling
CKKS Reals / complex Approximate Scalable and high throughput ML, analytics
TFHE Bits Exact Fast bootstrapping Logic, access control

 

Wrapping Up

Each FHE scheme is like a different type of secret calculator. Some are better with exact values, others work faster when a bit of approximation is okay, and some thrive in logical decision-making.

The future of FHE isn’t about picking a single winner — it’s about choosing the right tool for the job. As this field evolves, we may even see hybrid models that combine the best features of each. However, newer generation FHE schemes can offer advancements in efficiency, scalability, and usability. Moreover, they are usually better suited to modern applications.

With a solid grasp of FHE schemes and bootstrapping, you’re ready for the next step: exploring FHE tools. In the upcoming posts, we’ll dive into libraries and compilers. Stay tuned!

Privacy Enhancing Technologies: An Overview

So far, we’ve covered the basics of FHE: its mathematical foundation, the concept of homomorphism, and how bootstrapping comes in. It’s easy to see why FHE is often called the holy grail of cryptography. Still, that doesn’t mean other Privacy-Enhancing Technologies (PETs) aren’t important.

In this post, we look at the most advanced and widely used PETs, their core benefits, limitations, and where they shine. We focus on Multi-Party Computation (MPC), Zero-Knowledge Proofs (ZKP), Trusted Execution Environments (TEE), and Differential Privacy (DP).
TL;DR? We’ve got you: Below you have a a quick comparison table.

Multi-Party Computation (MPC)

MPC is a cryptographic technique that lets multiple parties compute a shared result without revealing their individual data to one another. No single party ever sees the full dataset: each performs computations on their private input and shares encrypted outputs. The result is visible to all participants, but original inputs remain private throughout. MPC has some drawbacks, including high communication overhead and reliance on active participation from all parties.

MPC was first used in the Danish Sugar Beet Auction (2008), where the new market clearing price of sugar beets was done by a computer program implementing Secure MPC between the farmers and Danisco, one of the biggest sugar producers in Europe at the time. Since then, MPC has been used in financial systems, key management and more.

Zero-Knowledge Proofs (ZKP)

ZKPs use cryptographic algorithms to generate a proof that can be verified without revealing the underlying data. They let one party (the prover) convince another (the verifier) that they know a fact or possess certain information, without disclosing the actual information.
In short, it’s a way to prove something is true without revealing why.

ZKPs are ideal for identity verification but face scalability challenges with large datasets and rollouts, where they can encounter performance bottlenecks. First introduced in 1985, ZKPs began seeing widespread practical use when cryptocurrency systems like Zcash applied them to create shielded, private transactions.
Since then, they have been used in identity systems, private financial transactions, blockchain security, and other privacy-preserving technologies.

Trusted Execution Environments (TEE)

A Trusted Execution Environment (TEE) is an isolated, hardware-backed enclave within a processor that ensures the confidentiality and integrity of code and data during execution. It prevents access or tampering by the main operating system, hypervisor, or any unauthorized application, even if those layers are compromised.

It’s like a “safe room” inside a processor where only authorized code can enter and nobody else on the system can peek at the memory.

TEEs emerged in mobile devices in the early 2000s, with Texas Instruments’ M-Shield and Arm’s TrustZone providing secure on-chip environments. Today, technologies like Intel’s SGX and AMD’s SEV are widely used for secure computing. Along with other platforms, they support confidential infrastructure-as-a-service, with deployments in digital advertising, secure payments, IoT safety, digital rights enforcement, and more.

Although hardware-based, TEEs are not immune to vulnerabilities and have made headlines due to security flaws and hacking incidents.

Differential Privacy (DP)

Differential Privacy is a privacy-preserving technique that protects sensitive information by ensuring that results reflect population-level trends without revealing information about specific individuals. . It works by adding carefully calibrated noise to statistical outputs, so the presence or absence of any single individual’s data does not significantly affect the result. This allows useful patterns to be observed while minimizing the risk of identifying personal information.

The mathematical foundations of differential privacy were formalized in 2006, in the first formal privacy analysis of a data anonymization process was made in 2008 using commute data collected by the US Census Bureau. Since then, DP has been deployed by major tech companies including Apple in MacOS, Google via its RAPPOR Technology, and Facebook.

However, it is worth noting DP is not without its limitations: The added noise reduces accuracy, making it difficult to balance privacy and accuracy challenging, especially when multiple queries are involved. Each analysis performed using DP must be verified by a cryptographer or statistician to ensure it meets privacy guarantees, making the technology reliant on expert human oversight. Moreover, because data is not encrypted in all stages, it remains vulnerable to side-channel attacks.

Privacy Enhancing Technologies – TL;DR Table

MPC ZKP TEE DP FHE
Based on Cryptography Cryptography Hardware Statistics Cryptography
Short Description Allows multiple parties to jointly compute a result without revealing their private inputs. Proves that a statement is true without revealing the underlying data. A secure area inside a processor that runs code and stores data in isolation. Adds statistical noise to outputs to protect individual privacy in datasets. Enables computation directly on encrypted data without ever decrypting it.
Analogy Solving a puzzle together while keeping your piece hidden. Showing you solved a Sudoku without revealing the solution. A safe room in a building that only authorized code can access. Blurring a photo just enough that individuals can’t be recognized. Solving a math problem without knowing what the numbers are
Strengths Strong privacy, no need for a trusted third party, works on encrypted data. Strong data privacy, fast verification, ideal for trust-minimized environments. Hardware-enforced protection, efficient runtime Provable privacy guarantees, works well on large datasets, good for analytics. Maximum data privacy, computation on encrypted data, strong security guarantees.
Weaknesses High communication overhead, requires online parties participation, partial encryption. Computationally expensive, limited to specific use cases, some need trusted setup. Vulnerable to hardware attacks, limited memory, vendor trust required. Reduced accuracy, hard to tune, privacy loss across multiple queries. Computationally intensive, slow compared to other PETs.
Great For Collaborative analytics, secure voting, private machine learning. Identity proofs, blockchain privacy, private authentication. Secure payments, DRM enforcement, IoT safety. Sharing aggregate data, public statistics, large-scale analytics. Secure cloud computation, privacy-preserving AI, encrypted search and analytics.

Privacy Enhancing Technologies – Comparison conclusion

By now, you’ve gained a basic understanding of the leading privacy-enhancing technologies (PETs), where they shine, and what their limitations are. It’s worth noting that computational and communication overhead often prevents even the strongest cryptographic PETs from achieving widespread adoption.

This challenge is exactly what motivates Chain Reaction’s 3PU™, a purpose-built processor designed to accelerate FHE by orders of magnitude compared to general-purpose CPUs.

Next, we’ll explore the FHE ecosystem and how emerging libraries and compilers are making FHE implementations more accessible and practical.

 

 

 

 

 

Bootstrapping in FHE

Bootstrapping has been a cornerstone of Fully Homomorphic Encryption (FHE) since its earliest implementations. In simple terms, bootstrapping refreshes a ciphertext by resetting the noise that builds up during homomorphic computations. Without this step, the growing noise quickly makes accurate decryption impossible. Bootstrapping is what makes it possible to perform an unlimited number of operations on encrypted.

In earlier posts, we introduced the core concepts of FHE, explored its mathematical foundations and explained how homomorphic operations preserve algebraic structure while introducing computational cost, partly due to noise growth. In this post, we turn our attention to bootstrapping: the mechanism that keeps noise in check and makes deep encrypted computations possible.

We’ll cover: What is the role of noise in FHE?

What Is the Role of Noise in FHE?

To understand bootstrapping, one must first appreciate the role of noise in homomorphic encryption. When a message (or plaintext) is encrypted under a lattice-based FHE scheme like BFV, BGV, or CKKS, the resulting ciphertext includes a certain amount of mathematical noise: usually modeled as a small random polynomial or Gaussian-distributed error term. This noise is deliberately introduced to ensure semantic security: without it, an attacker could extract plaintexts from ciphertexts. Think of this noise as protective fuzziness: static that masks the signal. Without it, encrypted data would be easier to reverse engineer.

However, this noise becomes problematic under homomorphic evaluation. Each time a ciphertext is added or multiplied with another ciphertext (or plaintext), the underlying noise grows. While addition grows the noise linearly, multiplication can cause a quasi-exponential jump, depending on the scheme’s structure. Eventually, the noise may reach a threshold beyond which the decryption function fails to recover the correct plaintext: this is known as the decryption failure bound. This means that while you can do a few encrypted operations safely, doing too many, without a way of reducing the noise will eventually cause errors.

From a mathematical perspective, decryption in lattice-based schemes involves computing an inner product or rounding operation in a polynomial ring (such as Rq=Zq[X]/⟨Xn+1⟩), where q is a large modulus and n is the ring dimension. If the accumulated noise pushes the result beyond a decoding radius (e.g., past q/2), the rounding step will no longer correctly extract the original message. Therefore, maintaining control over noise growth is essential for any practical use of FHE. In practice, this means there’s a tight budget for noise, once it’s spent, the data is no longer usable. Bootstrapping gives us a way to reset that budget.

Why Is Bootstrapping Computationally Intensive?

Bootstrapping is a critical operation that allows a ciphertext to be “refreshed” when it is close to its noise limit. In FHE, each computation on encrypted data adds a bit of noise, and if the noise grows too large, the ciphertext becomes undecipherable.

Bootstrapping solves this by homomorphically decrypting the noisy ciphertext, using an encrypted version of the secret key, and then re-encrypting the result, yielding a new ciphertext with reduced noise.

In other words, it’s like decrypting a message while being blindfolded: the system decrypts and re-encrypts the data without ever seeing it in plaintext.

This process involves a clever circular trick: the system evaluates the decryption function on encrypted data using only encrypted components, computing something like:

\text{Enc}\left(\text{Dec}_{\text{sk}}(c)\right) using Enc(sk) and c.

Think of it as putting a locked safe inside another locked safe and somehow being able to open the inner one without ever opening the outer one. Everything stays locked, but the job gets done.

To pull this off, the FHE scheme must be powerful enough to evaluate its own decryption circuit, which is far from trivial. These circuits require arithmetic operations such as modular reduction, polynomial multiplication, rounding, and bit decomposition: all under encryption. Supporting this level of computation is what makes bootstrapping both essential and technically challenging.

The computational burden arises because decryption circuits must be expressed in a form suitable for homomorphic evaluation. This often means converting arithmetic to logic gates (e.g., using NAND gates, which are simple circuits that help represent all kinds of logic in binary) or re-encoding modulus reduction as a sequence of approximations. As a result, bootstrapping typically requires:

These factors contribute to the high computational cost of bootstrapping. In fact, it is often the slowest and most resource-intensive part of using FHE in practice. Because of this, bootstrapping frequently becomes the main performance bottleneck, directly increasing latency.

To address this challenge, tech companies are turning to custom hardware solutions, such as FPGAs and ASICs. These chips are purpose-built to accelerate the mathematical operations required by FHE, much like GPUs are optimized for graphics, ASICs can be optimized specifically for bootstrapping.

Do FHE Schemes Have an Associated Bootstrapping Method?

While early FHE schemes, such as Gentry’s original 2009 construction, introduced bootstrapping as an optional and challenging feature, modern schemes are increasingly designed with bootstrapping in mind. Many lattice-based schemes include or support customized bootstrapping procedures, each tailored to the scheme’s encoding, ring structure, and noise management strategy. This means that bootstrapping is no longer an afterthought, it’s being built directly into the core design of FHE.

Moreover, FHE libraries like Microsoft SEAL, PALISADE, and OpenFHE offer APIs for bootstrapping, but under the hood, these implementations involve significant mathematical engineering: building lookup tables, precomputing key-switching hints, and carefully tuning parameters to ensure correctness. While calling bootstrap () may look simple in code, it hides a lot behind-the-scenes complexity.

Note that various bootstrapping techniques can be compared, mainly, by the following parameters:

These trade-offs are important for practical applications. Some users need high speed, while others prioritize accuracy or depth for future computations.

What Is Being Done to Improve Bootstrapping?

Reducing the cost of bootstrapping has been a central challenge in FHE research over the past decade. Recent advances are promising, and many are grounded in deep mathematical innovation.

Together, these innovations aim to make bootstrapping not just faster, but viable for real-time and large-scale applications – from secure machine learning to encrypted search and analytics.

Summary

Without bootstrapping, which refreshes the ciphertext, FHE would be limited to shallow computations. Noise would accumulate to the point of rendering the ciphertext indecipherable. But with bootstrapping, ciphertexts can be refreshed indefinitely, making fully encrypted computation possible in theory and in practice.

From a mathematical standpoint, bootstrapping exemplifies the power, and challenge, of performing algebra on encrypted structures. It is a living example of how theoretical breakthroughs in lattice cryptography, ring theory, and algorithm design translate into real-world secure computing. While still computationally demanding, the pace of progress in bootstrapping signals a future where privacy-preserving computation becomes not only feasible but routine.

Now that we’ve explored how FHE works and how its core challenges are being addressed, our next post will compare it to other privacy-enhancing technologies and highlight where each one fits.

Disrupting Blockchain & Privacy | Chain Reaction
Powered by  GDPR Cookie Compliance
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.