You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fully homomorphic encryption (FHE) allows you to run computations on encrypted data without decrypting it first. As a developer, this means you’re able to write code that doesn’t jeopardize the privacy of your users.
Benefits of using FHE in your applications as a developer can include:
Demonstrating a commitment to data privacy and security to your users, and enhancing user trust in your application.
Improving security by performing computations on cloud data without exposing to potential threats or unauthorized access.
Ensuring that sensitive data remains protected even when third-party sharing is a required property of your application
Complying with privacy regulations and standards by default
Ideal Use Cases
Homomorphic encryption is ideal for some use cases more than others.
Cloud / Distributed Computing
FHE enables secure computations on encrypted data stored in the cloud without the need to decrypt it. This preserves the confidentiality of sensitive data even when processed by third-party cloud service providers.
FHE allows for analysis and performing actions on encrypted data without revealing the actual content analysts. For instance, healthcare providers can conduct statistical analysis on confidential patient information without decrypting it, thus maintaining patient privacy.
FHE enables machine learning models to be trained on encrypted data. This is beneficial when data owners are hesitant to share their data for privacy reasons. With FHE, data remains encrypted during the model training process, and only the encrypted model is shared.
FHE allows financial institutions to analyze encrypted financial transactions for fraud detection while maintaining client confidentiality.
Working Examples
More Reading
Blind and Private Databases
FHE allows encrypted search and querying of databases without exposing search criteria or database contents, thus ensuring privacy for data owners who want to allow others to search and access information.
Homomorphic encryption is not a silver bullet for all use cases. As with all cryptography, how practical or safe it is to use is ultimately dependent on the use case, implementation, library, and underlying scheme.
Encryption Strength
The security of homomorphic encryption relies on the strength of the underlying encryption scheme. If the encryption scheme is compromised or broken, the encrypted data and computations could be exposed.
Implementation Flaws
Like any cryptographic system, the implementation of homomorphic encryption algorithms and protocols may introduce vulnerabilities. Implementation flaws, such as programming errors or side-channel attacks, could potentially compromise the security of the encrypted data. It's important to have your code audited, use libraries that are audited, and also schemes that have been publicly tested and accepted by the community as safe.
Metadata Leakage
While homomorphic encryption protects the content of the data, it does not hide the metadata associated with the encrypted computations. Metadata leakage could enable attackers to infer information about the encrypted data, such as its size, access patterns, or the type of computations being performed.
Key Management
Homomorphic encryption schemes typically require the management of encryption keys. Adequate key management practices, including key generation, distribution, storage, and revocation, are crucial to maintaining the security of the encrypted data.
There are several constraints regarding the implementation of homomorphic encryption-based solutions. Each of these constraints needs to be considered carefully when implementing an FHE-based solution.
Choosing Parameters
The target homomorphic encryption scheme needs to be initialized with parameters which are used throughout the computation. These parameters determine everything performance related: the security level, the efficiency of homomorphic operations, the size of key material, the input (and output) precision, how noise grows throughout the computation, and when a special operation called bootstrapping needs to be performed. We consider each of these issues below, one-by-one.
FHE schemes can be categorised in many ways. One of the most important distinctions is whether an FHE scheme is exact or approximate. In the first case computations are typically considered over the integers and correctness of output is guaranteed. In the latter case, a small error is incurred during computation, so that the output of a homomorphic function evaluation, such as computing `f(x)`, contains a small error: `f(x) + e`.
Input Precision
FHE schemes typically work over restricted input domains (for example: the integers modulo `p`). This means that when implementing an algorithm in FHE, it is important to consider whether the algorithm needs to be adapted to work over this domain. As an example, consider the `max()` function on real numbers: suppose that we want to compute the max of 0.001 and 8.764. Certain FHE schemes work modulo `p` (as mentioned above), so the first step is to figure out how to map our inputs, and the respective max algorithm, into this modular domain.
For approximate schemes, such as CKKS, the homomorphic encryption scheme carries an implicit error which impacts the message. The parameters can be adapted to guarantee a specific output precision, but this is important to note when considering implementing solutions in CKKS.
Introduction to CKKS (Approximate Homomorphic Encryption) video by Yongsoo Song (SNU) in 2020.
Speed
The speed of FHE-based operations is constantly improving. However, there is still a large slow-down compared to plaintext operations, and it is important to consider this when getting started. There are a variety of open-source implementations of various algorithms implemented in FHE, and looking at benchmarks for these applications can give a good indication of where FHE is at.
When data is encrypted using an FHE scheme, there is an expansion factor which needs to be considered. As an example, in the TFHE scheme, to encrypt somewhere in the order of 1-8 bits, a ciphertext will be of size 5 kilobytes. Evaluation keys, which are required for the server to carry out homomorphic operations over ciphertexts, can be very large. In particular, all evaluation keys stored on the server are just collections of ciphertexts, and can be in the order of tens of megabytes (or even over a gigabyte, in certain cases). This means that there is a high bandwidth requirement on FHE-based solutions.
Noise and Bootstrapping
As homomorphic operations are being computed, the level of noise contained in the utilised ciphertext grows. The noise level must not be allowed to overflow a specific bound, or errors can be introduced into computations. The process used to clear this noise is called bootstrapping, and, depending on the scheme, has a varying level of efficiency.
Further Reading
A blogpost on bootstrapping by Nigel Smart (Zama) in 2023.
A blogpost on bootstrapping by Yuriy Polyakov and Ahmad Al Badawi (Duality) in 2023.
Security
It is important that the homomorphic encryption scheme is parameterised correctly to ensure a sufficient level of security. The security is related a problem called Learning with Errors, and we need to choose cryptographic parameters such that this problem is hard to solve. Luckily, there are many FHE-based tools which take the problem of parameter selection away from the user. Moreover, most FHE libraries typically have default parameter sets for which the security level has already been determined.
Further Reading
Wikipedia page on the Learning with Errors problem.
Stackexchange answer to: What is a security parameter?
A blogpost on estimating the security of FHE schemes by Zama in 2021.
Schemes are the mathematical algorithms that are used for the underlying FHE operations on data. There are several major schemes implemented in modern libraries, each taking a different approach that has their own benefits and drawbacks on what types of operations can be done, the depth of calculations, and the resulting latency.
TFHE by Ilaria Chillotti; Nicolas Gama; Mariya Georgieva; Malika Izabachene
Libraries
Libraries are the software developers use to perform FHE operations easily, similarly to how one might use the libsodium library for basic cryptographic operations. Each library is designed for working with different schemes, some with multiple schemes and the ability to switch between them as needed.
Concrete - TFHE Compiler that converts python programs into FHE equivalent by Zama
Concrete ML - Privacy Preserving ML framework built on top of Concrete by Zama
HEaaN - C++ FHE library implementing CKKS scheme that supports bootstrapping and GPU-acceleration by Crypto Lab
HElib - BGV scheme with bootstrapping and the Approximate Number CKKS scheme by IBM
Lattigo - Lattice-based multiparty homomorphic encryption library in Go by Tune Insight
OpenFHE - Production-ready implementations of all major FHE schemes by Duality Tech
SEAL - C++ FHE library implementing BFV and CKKS schemes by Microsoft
TFHE-rs - A pure Rust implementation of the TFHE scheme for boolean and integer arithmetics over encrypted data by Zama
Choosing the right scheme/library
Choosing which library/scheme is right for you can be confusing at first, but here are some considerations that help in the decision making process:
What data types will you working with? (Large integers? Small integers / Booleans? Real / Complex values?)
How parralelizable is your workflow?
How deep are your typical calculations?
What performance requirements do you have?
How easy do you need implementation to be?
How much existing code / support will you need?
In the following section, you'll have a chance to use existing sample code and write your own code. If at that point you're still unsure which library is right for you or have deeper questions about it the libraries and schemes, consider joining the FHE.org community on Discord and asking the community directly. We're here to help!
The best way to get started in FHE is to look at Tutorials. In particular: trying to read them, understand the code, and then extend the examples with your own code.
Below is a list of all resources from Tutorials and Examples found on various libraries repositories and some diagram to let you pick
one library to start with. Note that every libraries have their own capabilities that are not covered here.
Select an FHE library
By Language
stateDiagram
Prog_lang: Where to start
Prog_lang: by language
Prog_lang --> C++
Prog_lang --> Rust
Prog_lang --> Go
Prog_lang --> Python
C++ --> OpenFHE
C++ --> SEAL
C++ --> HEAAN
C++ --> HELIB
Go --> LattiGo
TFHErs: TFHE-rs
Rust --> TFHErs
Python --> pyFHEL
Python --> Concrete
Loading
By Scheme
stateDiagram
Scheme: Where to start
Scheme: by FHE scheme
Scheme --> BFV
Scheme --> BGV
Scheme --> CKKS
Scheme --> TFHE
BFV --> OpenFHE
BGV --> OpenFHE
CKKS --> OpenFHE
TFHE --> OpenFHE
BFV --> SEAL
BGV --> SEAL
CKKS --> SEAL
TFHE --> Concrete
TFHErs: TFHE-rs
TFHE --> TFHErs
Loading
Tutorials
Here is a list of examples and tutorials from each libraries, with some keywords (prefixed with a #) to highlight the language, library, scheme and category they belong to.
