Blog
 / 
TFHE-rs
Announcements

TFHE-rs v0.4.0: Signed Integers and Encrypted Conditionals

October 17, 2023
  -  
Jean-Baptiste Orfila
This is also a heading
This is a heading
This is also a heading

This new version of TFHE-rs introduces support for signed integers, conditional instructions and significant performance improvements.

New type: FheInt

The new version of TFHE-rs now supports signed integers. Similarly to what is proposed with the [.c-inline-code]FheUint[.c-inline-code] type, the API now includes the signed integer type [.c-inline-code]FheInt[.c-inline-code]. This mimics the behavior of the classical [.c-inline-code]int[.c-inline-code] from many programming languages. In general, an unsigned integer encoded over 32-bits, like a [.c-inline-code]uint32[.c-inline-code], allows representing values between 0 and 232-1. That is, it represents integers modulo 232. When working with 32-bit signed integers, the domain becomes [-231, 231-1].  All operations available in TFHE-rs for unsigned integers are now also available for signed integers, with similar timings. Note that this is also true for operations between a ciphertext and a cleartext. Finally, casting from an [.c-inline-code]FheUint[.c-inline-code] to an [.c-inline-code]FheInt[.c-inline-code] is supported (and vice versa). By default, all precisions up to 256-bits are available. In Table 1, timings of signed operations between two ciphertexts are given:

Table 1: Benchmarks of operations depending on the precision
Operation / Precision FheInt8 FheInt16 FheInt32 FheInt64
add 76 ms 99 ms 120 ms 169 ms
sub 85 ms 100 ms 125 ms 169 ms
mul 139 ms 192 ms 315 ms 744 ms
and/or/xor 19 ms 20 ms 21 ms 25 ms
left/right shift/rotate 99 ms 121 ms 175 ms 233 ms
eq/neq 27 ms 37 ms 56 ms 61 ms
lt/le/gt/ge 71 ms 90 ms 115 ms 145 ms
div/rem 935 ms 2.13 s 5.1 s 12.2 s

Below we outline a small code example on how to use signed integers in the latest version of TFHE-rs:

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

fn main() -> Result<(), Box> {
	// Basic configuration to use homomorphic integers
	let config = ConfigBuilder::all_disabled()
    	.enable_default_integers()
    	.build();

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

	let clear_a = 1344i32;
	let clear_b = -87825i32;
	let clear_c = 118038950i32;

	// Encrypting the input data using the (private) client_key
	// FheInt32: Encrypted equivalent to i32
	let encrypted_a = FheInt32::try_encrypt(clear_a, &client_key)?;
	let encrypted_b = FheInt32::try_encrypt(clear_b, &client_key)?;
	let encrypted_c = FheInt32::try_encrypt(clear_c, &client_key)?;

	// On the server side:
	set_server_key(server_keys);

	// Clear equivalent computation: '1344 * (-87825) = -118036800'
	let encrypted_mul = &encrypted_a * &encrypted_b;

	// Clear equivalent computation: '-118036800 + 118038950 = 2150'
	let encrypted_add = &encrypted_mul + &encrypted_c;

	// Clear equivalent computation: '-118036800 > 2150'
	let encrypted_comp = &encrypted_mul.gt(&encrypted_add);

	//Clear equivalent computation: 'as u32'
	let encrypted_cast: FheUint32 = encrypted_a.cast_into();

	// Client side
	// Decryption
	let clear_res: i32 = encrypted_comp.decrypt(&client_key);
	assert_eq!(
    	clear_res,
    	((clear_a * clear_b) > (clear_a * clear_b + clear_c)) as i32
	);

	let clear_res: u32 = encrypted_cast.decrypt(&client_key);
	assert_eq!(clear_res, clear_a as u32);

	Ok(())
}

Beyond the update of the default API (the one described in the previous example), all of the underlying APIs have been updated with this new type.

Support of conditional instructions

It is now possible to compute simple ternary homomorphic conditional instructions of the form [.c-inline-code]If...Then...Else[.c-inline-code]. The evaluated condition should be an encrypted boolean value represented as a classical [.c-inline-code]FheUint[.c-inline-code] or [.c-inline-code]FheInt[.c-inline-code]. This allows a ciphertext, or an expression, to be chosen depending on the value of the condition. The example below shows how to use this feature:

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

fn main() -> Result<(), Box> {
	// Basic configuration to use homomorphic integers
	let config = ConfigBuilder::all_disabled()
    	.enable_default_integers()
    	.build();

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

	let clear_a = 32i32;
	let clear_b = -45i32;

	// Encrypting the input data using the (private) client_key
	// FheInt32: Encrypted equivalent to i32
	let encrypted_a = FheInt32::try_encrypt(clear_a, &client_key)?;
	let encrypted_b = FheInt32::try_encrypt(clear_b, &client_key)?;

	// On the server side:
	set_server_key(server_keys);

	// Clear equivalent computations: 32 > -45
	let encrypted_comp = &encrypted_a.gt(&encrypted_b);
	let clear_res: i32 = encrypted_comp.decrypt(&client_key);
	assert_eq!(clear_res, (clear_a > clear_b) as i32);

	// `encrypted_comp` contains the result of the comparison, i.e.,
	// a boolean value. This acts as a condition on which the
	// `if_then_else` function can be applied on.
	// Clear equivalent computations:
	// if 32 > -45 {result = 32} else {result = -45}
let encrypted_res = &encrypted_comp.if_then_else(&encrypted_a, &encrypted_b);

	let clear_res: i32 = encrypted_res.decrypt(&client_key);
	assert_eq!(clear_res, clear_a);

	Ok(())
}

Performance Improvements

This latest release of TFHE-rs includes many performance improvements. On the low-level primitives, the programmable bootstrapping is now slightly faster. As a result, the latency of all integer operations has been reduced by approximately 8%. The practical gain depends on the operation and precision, ranging from 3 to 20%. 

Some specific operations have undergone significant optimizations, such as the multiplication between a clear value and a ciphertext, which is now 30 to 50% faster.

Additionally, the division between two ciphertexts is almost twice as fast in comparison to the previous version.

Additional links

Read more related posts

Dark Market with TFHE-rs

In this tutorial, we show how to implement a dark market with TFHE-rs

July 7, 2023
 - 
The Zama Team
, 
Tutorials
TFHE-rs

Boolean SHA256 with TFHE-rs

In this tutorial, we show how to implement a SHA256 function with booleans in TFHE-rs

July 9, 2023
 - 
The Zama Team
, 
Tutorials
TFHE-rs

Regular Expression Engine with TFHE-rs

In this tutorial, we show how to implement a FHE Regular Expression Engine on encrypted texts.

June 30, 2023
 - 
The Zama Team
, 
TFHE-rs
Tutorials
The Zama Team
July 7, 2023

Dark Market with TFHE-rs

In this tutorial, we show how to implement a dark market with TFHE-rs

Read Article
The Zama Team
July 9, 2023

Boolean SHA256 with TFHE-rs

In this tutorial, we show how to implement a SHA256 function with booleans in TFHE-rs

Read Article
The Zama Team
June 30, 2023

Regular Expression Engine with TFHE-rs

In this tutorial, we show how to implement a FHE Regular Expression Engine on encrypted texts.

Read Article
Back to Blog
TFHE-rs
Announcements
Libraries and Solutions
TFHE-rs Concrete Concrete ML FHEVM Confidential machine learningConfidential smart contracts
Developers
BlogDOCUMENTATION GITHUB FHE resources Research papers CommunityBounty and grant Program
Company
Aboutintroduction to fheEventsMediaCareers Newsletter LegalContact us
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.