TFHE-rs v0.3.0: Faster Operations, Wider API, Shorter Keys

July 25, 2023

Jean-Baptiste Orfila

TFHE-rs 0.3 introduces quicker homomorphic operations, incorporates parallel processing for programmable bootstrapping, and implements a novel method that reduces the size of public keys.

New and Faster Homomorphic Operations

This new version of TFHE-rs supports more homomorphic operations. The list of newly available operations over encrypted data is:

Bitwise not: [.c-inline-code]![.c-inline-code]
Not equal: [.c-inline-code]ne[.c-inline-code]
Left/Right rotation: [.c-inline-code]rotate_left[.c-inline-code], [.c-inline-code]rotate_right[.c-inline-code]
Shift Left/Right: [.c-inline-code]<<[.c-inline-code], [.c-inline-code]>>[.c-inline-code]
Integer division: [.c-inline-code]/[.c-inline-code]
Remainder: [.c-inline-code]%[.c-inline-code]
Casting: [.c-inline-code]cast_into[.c-inline-code], [.c-inline-code]cast_from[.c-inline-code]

New operations between a ciphertext and a clear value:

Division: [.c-inline-code]/[.c-inline-code]
Remainder: [.c-inline-code]%[.c-inline-code]
Bitwise operations: [.c-inline-code]&[.c-inline-code], [.c-inline-code]|[.c-inline-code], [.c-inline-code]^[.c-inline-code]
Comparisons: [.c-inline-code]eq[.c-inline-code], [.c-inline-code]ne[.c-inline-code], [.c-inline-code]lt[.c-inline-code], [.c-inline-code]gt[.c-inline-code], [.c-inline-code]le[.c-inline-code], [.c-inline-code]ge[.c-inline-code]
Rotations: [.c-inline-code]rotate_left[.c-inline-code], [.c-inline-code]rotate_right[.c-inline-code]

Many existing operations have been updated, to reach a performance gain between 10 and 90% depending on the operation. In the following table, benchmarks for operations between two ciphertexts are given. Main improvements come from using the carry lookahead approach instead of the classical one. The former gives better performance for operations slowed down by the carry propagation (like the multiplication, which requires many additions and thus carry propagations). Note that operations between an [.c-inline-code]FheUint[.c-inline-code] and a clear value have also been reworked to be more efficient depending on the input scalar size.

Table 1. Timings for homomorphic operations between two ciphertexts depending on input sizes.

Below, a short code example illustrating the use of a right shift, a casting and a division:

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

fn main() -> Result<(), Box<dyn std::error::Error>> {
	// Configuration with integers
	let config = ConfigBuilder::all_disabled()
    	.enable_default_integers()
    	.build();

	// Key generation
	let (keys, server_keys) = generate_keys(config);
	set_server_key(server_keys);

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

	let mut a = FheUint32::try_encrypt(clear_a, &keys)?;
	let b = FheUint32::try_encrypt(clear_b, &keys)?;
	let c = FheUint8::try_encrypt(clear_c, &keys)?;

	// Clear equivalent computations: 1344 >> 5 = 42
	a = a >> &b;

	// Clear equivalent computations: let mut a = a as u8;
	let mut a: FheUint8 = a.cast_into();

	// Clear equivalent computations: 42/7 = 6
	a = &a / &c;

	let dec_a: u8 = a.decrypt(&keys);
	assert_eq!(dec_a, (clear_a >> clear_b) as u8 / clear_c);

	Ok(())
}

Multithreaded Bootstrapping

The programmable bootstrapping (PBS) is an homomorphic operation which reduces the noise of a ciphertext and, and at the same time, computes homomorphically an univariate function over the encrypted message. By construction, this operation is sequential. However, TFHE-rs now proposes a multithreaded version of the PBS, called the multibit PBS. This approach offers a new trade-off between increasing the size of the bootstrapping key and improving the latency of the PBS. Without getting into details, the idea is to extend the bitwise homomorphic decryption of the PBS to a group of bits. The size of the group is a variable parameter that can be adapted depending on the machine constraints (e.g., available memory and number of CPU threads). In the following table, a summary of the new timings and sizes is given.

Table 2. Size (MB) and timing (ms) comparisons between sequential and multithreaded PBS

The following code example is similar to the previous one, but uses the multithreaded PBS instead. The only difference lies in the ConfigBuilder, which relies on a different parameter set than the default one.

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

fn main() -> Result<(), Box<dyn std::error::Error>> {
	// Configuration to use the multithreaded PBS
	let config = ConfigBuilder::all_disabled()  	
           .enable_custom_integers(
                tfhe::shortint::parameters::DEFAULT_MULTI_BIT_GROUP_2,
                None
           )
    	     .build();

	// Key generation
	let (keys, server_keys) = generate_keys(config);
	set_server_key(server_keys);

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

	let mut a = FheUint32::try_encrypt(clear_a, &keys)?;
	let b = FheUint32::try_encrypt(clear_b, &keys)?;
	let c = FheUint8::try_encrypt(clear_c, &keys)?;

	// Clear equivalent computations: 1344 >> 5 = 42
	a = a >> &b;

	// Clear equivalent computations: let mut a = a as u8;
	let mut a: FheUint8 = a.cast_into();

	// Clear equivalent computations: 42/7 = 6
	a = &a / &c;

	let dec_a: u8 = a.decrypt(&keys);
	assert_eq!(dec_a, (clear_a >> clear_b) as u8 / clear_c);

	Ok(())
}

Compressed and Compact Public Keys

Similarly, the public encryption method has been updated. Public key sizes have been drastically reduced. The table below compares the key sizes using the classical encryption method and the new compact method depending on the input precision for one ciphertext block.

In what follows, the same code snippet which has been updated to use compact public keys. To do so, specific parameters are given, the public key has to be generated and the encryption key is changed to use the public one.

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

fn main() -> Result<(), Box<dyn std::error::Error>> {
	// Configuration to use compact public keys
	let config = ConfigBuilder::all_disabled()
    	.enable_custom_integers(
        	tfhe::shortint::parameters::DEFAULT_COMPACT_PK,
        	None,
    	)
    	.build();

	// Key generation
	let (keys, server_keys) = generate_keys(config);
	let public_key = CompactPublicKey::new(&keys);

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

	let mut a = FheUint32::try_encrypt(clear_a, &public_key)?;
	let b = FheUint32::try_encrypt(clear_b, &public_key)?;
	let c = FheUint8::try_encrypt(clear_c, &public_key)?;

	set_server_key(server_keys);

	// Clear equivalent computations: 1344 >> 5 = 42
	a = a >> &b;

	// Clear equivalent computations: let mut a = a as u8;
	let mut a: FheUint8 = a.cast_into();

	// Clear equivalent computations: 42/7 = 6
	a = &a / &c;

	let dec_a: u8 = a.decrypt(&keys);
	assert_eq!(dec_a, (clear_a >> clear_b) as u8 / clear_c);

	Ok(())
}

of a ciphertext, and at the same time,

Additional features

Some other features have been updated:

C API: all the functions available in the default API of TFHE-rs can be called from a C program;
WASM API: functions related to the client can be called from a web browser or a JS program; parallelism for key generation is available in Web browsers;‍
Transciphering: an example of transciphering between TFHE and the Trivium (or Kreyvium) cryptosystems has been added. This offers the possibility to encrypt ciphertexts using a symmetric cryptosystem, and then to convert them into TFHE-compatible ciphertexts. An application of transciphering is homomorphic random bit generation. More details will be provided in a future blog post.

What’s next?

The focus in the next release will be on continuing the performance enhancement of homomorphic operations. Furthermore, TFHE-rs will include a new homomorphic type: the FheInt for homomorphic signed integers. Finally, more control will be given to users, for example allowing them to change the ciphertext modulus.

Additional links

Star the TFHE-rs Github repository to endorse our work.
Review the TFHE-rs documentation.
Get support on our community channels.
Help advance the FHE space with the Zama Bounty Program.

Read more related posts

Zama Product Releases - July 2023

With these releases, Zama continues to build its suite of products to make homomorphic encryption accessible, easy, and fast.

July 26, 2023

The Zama Team

Announcements

Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn't want the whole world to know, but a secret matter is something one doesn't want anybody to know. Privacy is the power to selectively reveal oneself to the world.If two parties have some sort of dealings, then each has a memory of their interaction. Each party can speak about their own memory of this; how could anyone prevent it? One could pass laws against it, but the freedom of speech, even more than privacy, is fundamental to an open society; we seek not to restrict any speech at all. If many parties speak together in the same forum, each can speak to all the others and aggregate together knowledge about individuals and other parties. The power of electronic communications has enabled such group speech, and it will not go away merely because we might want it to.Since we desire privacy, we must ensure that each party to a transaction have knowledge only of that which is directly necessary for that transaction. Since any information can be spoken of, we must ensure that we reveal as little as possible. In most cases personal identity is not salient. When I purchase a magazine at a store and hand cash to the clerk, there is no need to know who I am. When I ask my electronic mail provider to send and receive messages, my provider need not know to whom I am speaking or what I am saying or what others are saying to me; my provider only need know how to get the message there and how much I owe them in fees. When my identity is revealed by the underlying mechanism of the transaction, I have no privacy. I cannot here selectively reveal myself; I must always reveal myself.Therefore, privacy in an open society requires anonymous transaction systems. Until now, cash has been the primary such system. An anonymous transaction system is not a secret transaction system. An anonymous system empowers individuals to reveal their identity when desired and only when desired; this is the essence of privacy.Privacy in an open society also requires cryptography. If I say something, I want it heard only by those for whom I intend it. If the content of my speech is available to the world, I have no privacy. To encrypt is to indicate the desire for privacy, and to encrypt with weak cryptography is to indicate not too much desire for privacy. Furthermore, to reveal one's identity with assurance when the default is anonymity requires the cryptographic signature.We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence. It is to their advantage to speak of us, and we should expect that they will speak. To try to prevent their speech is to fight against the realities of information. Information does not just want to be free, it longs to be free. Information expands to fill the available storage space. Information is Rumor's younger, stronger cousin; Information is fleeter of foot, has more eyes, knows more, and understands less than Rumor.We must defend our own privacy if we expect to have any. We must come together and create systems which allow anonymous transactions to take place. People have been defending their own privacy for centuries with whispers, darkness, envelopes, closed doors, secret handshakes, and couriers. The technologies of the past did not allow for strong privacy, but electronic technologies do.We the Cypherpunks are dedicated to building anonymous systems. We are defending our privacy with cryptography, with anonymous mail forwarding systems, with digital signatures, and with electronic money.Cypherpunks write code. We know that someone has to write software to defend privacy, and since we can't get privacy unless we all do, we're going to write it. We publish our code so that our fellow Cypherpunks may practice and play with it. Our code is free for all to use, worldwide. We don't much care if you don't approve of the software we write. We know that software can't be destroyed and that a widely dispersed system can't be shut down.Cypherpunks deplore regulations on cryptography, for encryption is fundamentally a private act. The act of encryption, in fact, removes information from the public realm. Even laws against cryptography reach only so far as a nation's border and the arm of its violence. Cryptography will ineluctably spread over the whole globe, and with it the anonymous transactions systems that it makes possible.For privacy to be widespread it must be part of a social contract. People must come and together deploy these systems for the common good. Privacy only extends so far as the cooperation of one's fellows in society. We the Cypherpunks seek your questions and your concerns and hope we may engage you so that we do not deceive ourselves. We will not, however, be moved out of our course because some may disagree with our goals.The Cypherpunks are actively engaged in making the networks safer for privacy. Let us proceed together apace.Onward. By Eric Hughes. 9 March 1993.