Shared key
This document explains how to set up a shared secret key between Concrete and TFHE-rs to perform computations.
In this scenario, a shared secret key will be used, while different keysets will be held for Concrete and TFHE-rs. There are two ways to generate keys, outlined with the following steps
From Concrete (1.1)
Perform a classical key generation in Concrete, which generates a set of secret and public keys.
Use this secret key to perform a partial key generation in TFHE-rs, starting from the shared secret key and generating the rest of the necessary keys.
From TFHE-rs (1.2)
Perform a classical key generation in TFHE-rs, generating a single secret key and corresponding public keys.
Use the secret key from TFHE-rs to perform a partial keygen in Concrete.
While TFHE-rs does use a single secret key, Concrete may generate more than one, but only one of these should be corresponding to the TFHE-rs key. The API does hide this detail, but will often ask you to provide the position of a given input/output. This will be used to infer which secret key should be used.
After the key generation is complete and we have both keysets, we can perform computations, encryption, and decryption on both ends.
Setup and configuration
The first step is to define the TFHE-rs ciphertext type that will be used in the computation (see Overview). This includes specifying both cryptographic and encoding parameters. TFHE-rs provides a pre-computed list of recommended parameters, which we will use to avoid manual selection. You can find the parameters used in this guide here.
In short, we first determine a suitable set of parameters from TFHE-rs and then apply them in Concrete. This ensures that the ciphertexts generated in both systems will be compatible by using the same cryptographic parameters.
Defining the circuit and compiling
We will now define a simple modular addition function. This function takes TFHE-rs inputs, converts them to Concrete format (to_native
), runs a computation, and then converts them back to TFHE-rs. The circuit below is a common example that takes and produces TFHE-rs ciphertexts. However, there are other scenarios where you might not convert back to TFHE-rs, or you might convert to a different type than the input. Another possibility is to take one native ciphertext and one TFHE-rs ciphertext.
We can compile the circuit as usual.
You could optionally try the full execution in Concrete
Connecting Concrete and TFHE-rs
We are going to create a TFHE-rs bridge that facilitates the seamless transfer of ciphertexts and keys between Concrete and TFHE-rs.
Key generation
In order to establish a shared secret key between Concrete and TFHE-rs, there are two possible methods for key generation. The first method (use case 1.1) involves generating the Concrete keyset first and then using the shared secret key in TFHE-rs to partially generate the TFHE-rs keyset. The second method (use case 1.2) involves doing the opposite. You should only run one of the two following methods.
Remember that one key generation need to be a partial keygen, to be sure that there is a unique and common secret key.
Parameters used in TFHE-rs must be the same as the ones used in Concrete.
KeyGen starts in Concrete (use case 1.1)
First, we generate the Concrete keyset and then serialize the shared secret key that will be used to encrypt the inputs. In our case, this shared secret key is the same for all inputs and outputs.
Next, we generate client and server keys in TFHE-rs using the shared secret key from Concrete. We will cover serialization in a later section, so there's no need to worry about how we loaded the secret key. For now, we will consider having 4 functions (save_lwe_sk
, save_fheuint8
, load_lwe_sk
, load_fheuint8
) which respectively save/load an LWE secret key and an FheUint8 to/from a given path.
KeyGen starts in TFHE-rs (use case 1.2)
First, we generate the TFHE-rs keyset and then serialize the shared secret key that will be used to encrypt the inputs
Next, we generate a Concrete keyset using the shared secret key from TFHE-rs.
Using ciphertexts
At this point, we have everything necessary to encrypt, compute, and decrypt on both Concrete and TFHE-rs. Whether you began key generation in Concrete or in TFHE-rs, the keysets on both sides are compatible.
Now, we'll walk through an encryption and computation process in TFHE-rs, transition to Concrete to run the circuit, and then return to TFHE-rs for decryption.
First, we do encryption and a simple addition in TFHE-rs. For more information on how to save ciphertexts, refer to Serialization.
Next, we can load these ciphertexts in Concrete and then run our compiled circuit as usual.
Finally, we can decrypt and decode in Concrete
... or export it to TFHE-rs for computation/decryption
Full working example can be found here.
Last updated