Efficient TFHE Bootstrapping in the Multiparty Setting

TFHE is a practical fully homomorphic encryption scheme (FHE) capable of computing any boolean gate or non-linear function. The scheme was originally designed to work for the single key setting. To implement realistic application scenarios, it is necessary to extend it to handle multiple users. In this paper, we introduce a new approach to generate TFHE bootstrapping keys for (predefined) multiple users. Hence, a fixed number of users can enjoy the same level of efficiency as in the single key setting, keeping their individual input privacy. Our construction relies on a novel algorithm called homomorphic indicator, which can be of independent interest. We provide a detailed analysis of the noise growth and a set of secure parameters suitable to be used in practice. Moreover, we compare the complexity of our technique with other state-of-the-art constructions and show which method performs better depending on the parameter sets. We also provide a prototype implementation of our technique. To the best of our knowledge, this is the first implementation of TFHE in the multiparty setting.


I. INTRODUCTION
Many privacy-preserving protocols are efficiently designed in a non-interactive way with practical implementation results thanks to recent improvements on FHE.However, some problems arise when it comes to handling multiple users.The easiest way to handle multiple users is to share the same secret key among them and then ask a third party (a server in general) to compute a function of the given encrypted data of each user under the same key.However, in this case, some dishonest parties can easily intercept others' encrypted inputs through the public channel and decrypt them.Therefore, this naive approach does not guarantee input privacy [1], [2].
If numerous users want to compute a common function keeping their input privacy, multi-key homomorphic encryption (MKHE) [3] and multiparty homomorphic encryption (MPHE) (a.k.a.threshold-multikey FHE) [4] are the best The associate editor coordinating the review of this manuscript and approving it for publication was Barbara Masucci .solutions for non-interactive protocols. 1That is, both designs allow users to keep partial information of the master secret key without the need to involve a third trusted party during key distribution.In other words, no one knows the master secret key, so decrypting other's ciphertexts becomes impossible.Decryption is possible only when all the participants (users) agree to do so by the definition of MKHE/MPHE.Despite providing user privacy, MKHE has a serious practical problem when the number of users is large, since the ciphertext size increases depending on the number of users.On the other hand, MPHE does not have such ciphertext expansion, so it can achieve (asymptotically) the same computational complexity as single key FHE.However, it requires a setup phase where users must interact at least once to generate their common public key, which is not necessary in MKHE.Therefore, both approaches have distinct advantages and there are different applications where each can have better performance than the other, as analyzed in [5].For example, if there are already predefined inputs for a function which a server is going to compute, such as the training of a machine learning model, MPHE outperforms MKHE.
The main technical difficulty of designing MPHE is to create the common bootstrapping key.Mouchet et al. [4], introduce a MPHE construction requiring two rounds between participants.In [5], the author improved upon [4] by designing a non-interactive algorithm, once the public keys are already known.The setup phase (generation of the common keys) of the above works has practical computation time and memory consumption.Once the common public keys (including bootstrapping keys) are generated during the setup phase, most of the algorithms that the server runs have the same performance as those of the underlying single key scheme.Indeed, the asymptotic complexity of previously designed MPHE is the same as their single key FHE versions (BGV [6], FV [7], and CKKS [8]).
MPHE designs based on TFHE have not been well studied even though TFHE is widely used in privacy-preserving protocols [9], [10], [11]. 2 TFHE enables to compute a gate operation over bits homomorphically, whereas the other schemes aim for (approximate or exact) arithmetic operations.After each gate operation (which only consists of a few additions), TFHE needs to run a bootstrapping algorithm to refresh the noise level to allow further operation without decryption failure.Therefore, constructing TFHE in the multiparty setting boils down to designing an efficient TFHE bootstrapping algorithm handling multiple keys.
Recently, Lee et al. [12] briefly introduced (a theoretical version of) an MPHE protocol based on TFHE.They first design the protocol for single key TFHE with larger coefficients for the secret key and then, they naturally extend it to the MPHE version, introducing a simple (global) bootstrapping key generation algorithm which requires all parties' local bootstrapping keys.This makes sense because the common secret key of MPHE corresponds to the sum s := s 1 + • • • + s k , where s i 's is the binary secret key of the i-th user, which is viewed as a secret key of a single user, corresponding to a secret s with large entries.However, a direct extension without implementation might hide the actual computation overhead caused by the noise contained in the global bootstrapping keys.The main difference between single key FHE with larger secret entries and its MPHE version is the noise contained in the same types of keys.Since the global keys are made of all parties' keys, the noise contained in the keys grows proportional to the total number of parties (which we denote by k).Therefore, in practice, we cannot directly use the same parameters which are recommended for the single key setting.In other words, we must consider the noise contained in the global keys, when it comes to choosing parameters.
A concurrent paper [13] gives a protocol for TFHE with larger key sizes with a different technique.We observe that their technique requires only k multiplications in the FFT domain among bootstrapping keys in the main loop of the boostrapping algorithm.Whereas Lee et al. [12] makes use of key switching including two FFT conversions and an external product, which is more expensive than the k FFT multiplications in every loop.However, a detailed comparison of both techniques, even in the single key setting, has not appeared in the literature just yet.

A. OUR CONTRIBUTIONS
In this work, we extend [13]'s scheme to a version of MPHE, introducing an efficient bootstrapping key generation algorithm.To do this, we introduce an algorithm called homomorphic indicator, which homomorphically computes a unit vector of a suitable dimension.That is, the algorithm takes as input a bit string and outputs a unit vector with an encryption of 1 in the position corresponding to the Hamming weight of the input string.This algorithm is the main building block of our bootstrapping key generation to indicate which key is selected during bootstrapping.The server can therefore run the bootstrapping algorithm of [13] with the indicated bootstrapping key, without revealing the corresponding secret value because the the algorithm's output is the same as their bootstrapping key.We believe that our technique for constructing the bootstrapping key can be of independent interest.
Furthermore, we compare the complexity of the bootstrapping technique of [12] with our extension of [13] and we show which scheme performs better in what parameter sets, based on our noise analysis.We provide a prototype implementation of our key generation algorithm using the Concrete library [14] with exact parameters yielding at least 110 bits security.With a number of parties of up to 16, we are able to perform bootstrapping in less than a second.To the best of our knowledge, this is the first implementation of TFHE in the multiparty setting.Since we also analyze the practicality of both our approach and [12] based on different metrics including noise analysis and complexity, this work can serve as a guide for readers to choose the right one for their use cases.

B. A BRIEF NOTE ON APPLICATIONS
A direct application of MPHE is privacy preserving machine learning [10], [11], [15] where a model provider holding its private machine learning model encrypts the model under the common public key, and the client encrypts its private input data under the common public key, then both party sends ciphertexts to the server (which is the (semi-honest) third party) for a computation (see Fig. 1).At the end of the server's computation and partial decryption [16] interacting with the model provider, the client only gets the inference/predicted value from the server.The whole protocol is non-interactive thanks to homomorphic encryption on the client's side, therefore the client can go offline after the query phase until the computation is over.More applications are discussed in Section IX-A.

C. PAPER ORGANIZATION
In Section II we establish notation and give background on FHE.In Section III, we detail the bootstrapping process of single-key TFHE.In Section IV, we detail the blind rotation algorithms of [12] and [13].In Section V we explain the homomorphic indicator algorithm and we detail how to use it to construct suitable bootstrapping keys to be used with the blind rotation of [13].In Section VI, we explain how MPHE TFHE based on [13] works using the keys constructed in the previous section.In Section VII we study the noise growth of our construction.In Section VIII we provide a comparison between the MPHE approach of [12] and our approach, we also provide the implementation details and our parameter recommendations.Finally, in Section IX we conclude the paper, providing a few extra comments on applications.

II. PRELIMINARIES
In this section, we fix notation for the rest of the paper and provide the necessary background on FHE and multiparty FHE to understand our contributions.The interested reader can find more background in [17].

A. NOTATIONS
We denote the security parameter of the FHE scheme by λ.The dot product of two vectors v, w is denoted by ⟨v, w⟩.For a vector x, both x i and x[i] denote either the i-th scalar component or the i-th element of an ordered finite set.The i-th element of an array A is denoted by A[i].We denote the logarithm function in base two by log(•).Let R and R q denote the rings of polynomials Z[X ]/(X N + 1) and Z q [X ]/(X N + 1), respectively, for positive integers q and N .Let θ , θ ′ denote the standard deviation of the noise contained in a fresh RLWE ciphertext and a fresh LWE ciphertext, respectively.All the noise is sampled from a distribution denoted by χ according to a suitable standard deviation.Let ℓ = O(log q) be the parameters of the TFHE scheme [18].We denote the number of users by k.The LWE (resp.RLWE) secret key of each user is denoted by s i = (s i,0 , . . ., s i,n−1 ), where s i,j ∈ {0, 1} and n ≥ 1 (resp.s i ∈ R).The (master) secret key corresponding to the common public key for an LWE ciphertext is denoted by S = (S 0 , S 1 , . . ., S n−1 ), where S j = k i=1 s i,j ≤ k for all j ∈ {0, . . ., n − 1}.Similarly, s := s 1 + s 2 + • • • + s k is the master secret key for an RLWE/RGSW ciphertext.Given a base g and ℓ = O(log q), we define a gadget vector g = (1, g, . . ., Let G be a gadget matrix defined as G := I 2 ⊗ g.Let G −1 (•) be the gadget decomposition function, which satisfies G −1 (a) • G ≈ a mod q for any a ∈ R 2 q .We define G −1 (c) := (G −1 (c 1 ), . . ., G −1 (c δ )), for a vector c = (c 1 , . . ., c δ ) ∈ R δ×2 q .In this paper, we use the terms parties and users interchangeably to refer to the entities who join the homomorphic computation.

B. BASIC BACKGROUND ON FHE
Informally, a public key Fully Homomorphic Encryption (FHE) scheme is an encryption scheme which allows us to perform arbitrary computations over encrypted inputs without decrypting them first.That is, given a ciphertext ct encrypting a plaintext m and an arbitrary function f , we can obtain a new ciphertext ct ′ encrypting f (m) without decrypting ct.
Definition 1 (Public Key Homomorphic Encryption Scheme): A public key homomorphic encryption scheme E consists of a set of probabilistic polynomial-time algorithms (KeyGen, Enc, Dec, Eval) such that: • KeyGen(1 λ ): outputs the secret key sk, the public key pk and the evaluation key evk given the security parameter λ.The evaluation key is also public, and it is used to perform the homomorphic operations over ciphertexts.
• Enc(pk, m): Outputs a ciphertext ct encrypting m under the public key pk.
• Dec(sk, ct): Outputs a message m.If the algorithm cannot recover m from ct, the output is ⊥.

1) BOOTSTRAPPING
If a homomorphic encryption (HE) scheme has an additional algorithm called bootstrapping, we say that it is a fully HE scheme.
Bootstrapping is a technique which reduces the error within a ciphertext, which enables the computation of arbitrary functions.In Section III-D, we will describe in detail the bootstrapping procedure of TFHE, now we give a highlevel overview of the general template of this technique.
To bootstrap ct, we first need to encrypt sk 1 under pk 2 , obtaining sk ′ 1 ← Enc(pk 2 , sk 1 ).Then we encrypt ct under pk 2 , obtaining ct ′ ← Enc(pk 2 , ct).Finally, the crucial step is to decrypt homomorphically ct ′ using sk ′ 1 via the Eval procedure.That is: ct ′′ ← Eval(evk, Dec, ct ′ , sk ′ 1 ).By construction, we have that m ← Dec(sk 2 , ct ′′ ).The error within ct ′′ consists of the error of a freshly encrypted ciphertext plus the error introduced by homomorphically evaluating the decryption circuit.If the error of ct corresponds to an evaluation of a circuit of less depth than the decryption circuit, then the error of ct ′′ will be less than the one contained in ct.

2) SECURITY ASSUMPTIONS
The security of the most well-known FHE schemes currently in use is based on the learning with errors (LWE) or the  2) After the computation is over, the server sends the output (Enc(f (m), pk)) to the model provider so that (3) he can run partial decryption with his own secret key sk _2 and (4) sends the output which is an encryption of Enc(f (m), sk _1)) to the server.(5) The server sends the given value from the model provider to the client, so that he can obtain f (m) by decrypting the ciphertext with its own secret key sk _1.
ring learning with errors (RLWE) problems.We describe the decisional version of both problems below.
Definition 2 (Decisional Learning with Errors (LWE)): Let n be a power of 2, let q ≥ 3 be an odd integer and let χ be a distribution over Z n q .The LWE n,q,χ problem is to distinguish the following two distributions over {(a i , b i )} i ⊂ Z n q × Z q : In the first distribution one samples (a i , b i ) uniformly at random from Z n q × Z q and, in the second distribution, one secretly samples s ← Z n q uniformly and then defines (a i , b i = ⟨a i , s⟩+ e i ) ∈ Z n q × Z q by sampling a i ← Z n q uniformly and e i ← χ.Definition 3 (Decisional Ring Learning with Errors (RLWE)): Let f (x) = x n + 1 where n is a power of 2. Let q ≥ 3 be an odd integer.Let χ be a distribution over R. The RLWE n,q,χ problem is to distinguish the following two distributions over {(a i , b i )} i ⊂ R 2 q defined as follows: In the first distribution one samples (a i , b i ) uniformly at random from R 2 q and, in the second distribution, one secretly samples s ← R q uniformly and then defines (a i , b i = a i s + e i ) ∈ R 2 q by sampling a i ← R q uniformly and e i ← χ.
We use the fact that the TFHE scheme is IND-CPA secure under the assumption that (R)LWE (defined above) is hard.

C. MULTIPARTY FHE
In this paper, we are concerned with a generalization of FHE to a setting where we have multiple parties.Let P = {P 1 , . . ., P k } be a set of k parties.Informally, a multiparty homomorphic encryption scheme (MPHE) over P is a homomorphic encryption scheme where the secret key is a function of the k individual secret keys of each party s 1 , . . ., s k .In this paper, we are interested in the case where the secret key s of the MPHE is computed as s = s 1 +• • •+s k .Notice that obtaining this secret key structure from existing lattice-based HE schemes is already well-known and simple in a common random string (CRS) model [4], [5], [19].For example, following the same notation as in subsection III-A, the ciphertext LWE s 1 (0) + • • • + LWE s k (0) can be decrypted using the secret key s provided that the same mask a was used for all parties as the masks of these k LWE ciphertexts. 3We follow the most communication efficient MPHE protocol [5], which can be described as follows: 1) Each party generates its own (local) public key using a common random string and distributes the keys to all the predefined users P i 's. 2) All parties locally generate (public) bootstrapping keys and ciphertexts by aggregating the given k different keys, obtained in 1).Then, they send them to a computing party (server).
3) The computing party generates the global evaluation key to perform the necessary operations over a set of given ciphertexts.4) The computing party can now perform homomorphic operations over ciphertexts given by the k parties using the global keys computed in step 3).We note that step 1) is a (one-round) setup for k parties, and step 3) is a (non-interactive) setup for the computing party.Therefore, for the same party set P, the outcomes of steps 1) and 2) are reused over and over.The difficulty of building practically efficient MPHE schemes stems from the fact that more complex types of keys also need to be condensed to a global key from the individual keys produced from the parties in P (step 3).

III. BACKGROUND ON TFHE
The goal of this section is to provide the reader with a basic understanding of TFHE and its bootstrapping procedure.We refer the interested reader to [14], [17], [18], and [20] for further details on the topics exposed in this section.

A. TFHE CIPHERTEXTS
We denote the ciphertext modulus as q and encode a message m ∈ {0, 1} as m, where = ⌊q/8⌉.In our design, we only focus on binary messages and binary secret keys for each party.
• An LWE ciphertext is defined as LWE s (m) := (a, b) ∈ Z n+1 q , where a is a random vector, b = ⟨a, s⟩+ m+e for a message m ∈ {0, 1}, a secret key s ∈ Z n , and a noise term e ← χ θ ′ .We call a the mask and b the body of an LWE ciphertext.To decrypt, we compute b − ⟨a, s⟩ = m + e and then apply a rounding operation to obtain the message m.
, where b = as + m + e ′ for a random polynomial a ∈ R q , a message polynomial m ∈ R 2 , a secret key s ∈ R, and e ′ ← χ θ .Similarly, a and b are called the mask and the body of an RLWE ciphertext, respectively.To decrypt, we compute b−as = m+e ′ and then apply a rounding operation to obtain the message m.
• Fix a base B g and ℓ = O(log q), and the gadget vector , where R q = and b = H + mG, each row of H is a RLWE s (0) and G is a gadget matrix defined as G := I 2 ⊗ g.The decryption process of a RGSW is not relevant to this work and we omit it.
• TrivialNoiseless(tag, µ) : it takes as input a tag tag ∈ {LWE, RLWE, RGSW} which indicates the ciphertext form, and a message µ, and outputs a ciphertext with the form according to tag with a noiseless mask.

B. EXTERNAL AND INTERNAL PRODUCTS
Given C 1 = RGSW s (m) and c 2 = RLWE s (µ), the external product produces the ciphertext RLWE s (mµ).It is defined as follows: The internal product of two RGSW ciphertexts C 1 and C 2 is equivalent to computing the external product of C 1 with all 2ℓ RLWE rows (c 1 , . . ., c 2ℓ ) t of C 2 .It is defined as follows: The main use of external products in TFHE is in the instantiation of the controlled multiplexer (CMUX) gate.Given two RLWE ciphertexts c 0 and c 1 encrypting messages m 1 and m 2 respectively and a RGSW ciphertext C encrypting a (controller) bit b, the CMUX gate returns a RLWE ciphertext encrypting m b .That is, the CMUX essentially selects either c 0 or c 1 depending on the controller bit encrypted in C. The CMUX gate is instantiated as follows: It can also be instantiated with internal products, producing a RGSW ciphertext encrypting m b , as we use in our bootstrapping key generation.In this case, it is computed as follows:

D. TFHE BOOTSTRAPPING
The bootstrapping of TFHE consists of four algorithms: modulus switching, blind rotation, sample extraction and key switching.In what follows, we describe how these algorithms work and their role in TFHE bootstrapping.

1) MODULUS SWITCHING
Modulus switching is the first step of the bootstrapping algorithm and compresses the information of the input LWE ciphertext to a smaller space.Consider a ciphertext ct = LWE s = (a, b) ∈ Z n+1 q .The goal of modulus switching is to change the modulus of ct from q to another modulus h.This is done by changing the modulus of all components of ct (let us say that a n := b) as follows ãi = In TFHE bootstrapping, the key switching is done from q to the modulus 2N , where N corresponds to the polynomial degree defining R q .Notice that 2N is much smaller than q, for example N = 2 10 and q = 2 32 .

2) BLIND ROTATION
The core and most computationally expensive procedure of TFHE bootstrapping is called blind rotation.This algorithm takes a trivial RLWE encryption of a vector v and rotates it by q , where m is a rounded approximation of b − ⟨a, s⟩.In more detail, notice that we can write where b and a j are rounded approximations of b and a j respectively.The algorithm starts by generating a trivial RLWE encryption of X b v (referred to as accumulator in the literature).The goal now is to obtain an RLWE encryption of X m v. Notice that we only need to multiply the trivial encryption by X −a j for all j if s j = 1.This conditional is instantiated using a CMUX gate and the bootstrapping keys (or bootstrapping keys), which are RGSW encryptions of the secret key components.That is, bsk acc ← acc + bsk[j] ((X −a j − 1) • acc) 4: end for 5: return acc This blind rotation procedure only works when the secret keys are binary.In Section IV, we will see two approaches to perform a blind rotation where the secret keys are sampled from an arbitrary distribution.

3) SAMPLE EXTRACTION
The output of the bootstrapping procedure should be an LWE ciphertext, however, the output of the blind rotation procedure is an RLWE ciphertext.For this reason, after running the blind rotation, it is necessary to extract a LWE ciphertext from the output RLWE.Assume that the output RLWE ciphertext encrypts a plaintext polynomial with constant term µ 0 .The extraction process consists in carefully selecting some of the coefficients of the RLWE ciphertext and then building the output LWE ciphertext corresponding to µ 0 .How this selection is done is not relevant to this work, and we refer the reader to the literature provided at the beginning of the section for further details.

4) KEY SWITCHING
At this point, we have a ciphertext under the secret key s ′ but we need a ciphertext under s.To obtain the desired ciphertext, we can apply key switching, which is a common technique used in homomorphic encryption.Consider a LWE ciphertext c ′ = (a, b) encrypting a plaintext m under s ′ .The basic idea of key switching is to compute b − ⟨a, s ′ ⟩ homomorphically providing s ′ as an encryption under s.This will cancel out s ′ and allow us to decrypt the resulting ciphertext with s.The encryptions of the bits of s under s ′ correspond to the key switching keys, which are constructed as follows.Let B ks < q 2 be the key switching basis and let l ks be such that log B (l ks ) = q.For every bit s ′ i of s ′ , the corresponding key switching key will be We can now compute where Decomp(a i ) = (a i,0 , . . ., a i,l ks −1 ) is the decomposition of a i in base B ks .It is easy to see that c is a correct LWE ciphertext encrypting m under the secret key s.

IV. TFHE BLIND ROTATION WITH ARBITRARY SECRET KEY DISTRIBUTION
In the following subsections, we explain the two most efficient state-of-the-art approaches of TFHE blind rotation which can work with an arbitrary secret key distribution.

A. BLIND ROTATION OF LEE ET AL
The work of Lee et al. [12] introduces a new efficient blind rotation algorithm that works with arbitrary secret key distributions and requires small bootstrapping keys.Very briefly and omitting a lot of technicalities, each loop of their blind rotation algorithm consists of a number of external products followed by one automorphism (key switching).That is, starting with an accumulator acc = RLWE s (f ′ (X )) and a collection of bootstrapping keys bsk j := RGSW s (X s j ) for j ∈ J , for some indexing set J , their blind rotation algorithm proceeds by multiplying acc by all bsk j , obtaining acc = RLWE s (f ′ (X )X j∈J s j ).Then, applying an automorphism they obtain for a suitable integer g depending on the polynomial degree N .After repeating this process with other indexing sets they finally obtain acc = RLWE s (f (X )X β+⟨α,s⟩ ).This blind rotation technique requires a total of at least 1.5n external products, where n is the dimension of the input LWE ciphertext.
To use this blind rotation algorithm in the MPHE setting, they require the construction of a common blind rotation key (bsk) and a common automorphism key (ak).We only give a short summary of how a computing party can obtain bsk and refer the interested reader to the original paper for the construction of ak.Let s 1 , . . ., s k be the secret keys of a set of k parties.Each party j computes bsk j,i = RGSW s (X s j,i ) where s j,i is the i-th component of s j and sends this to the computing party.Then, the computing party obtains bsk i = ⊠ j∈J bsk j,i = RGSW s (X s * ,i ).

B. BLIND ROTATION OF JOYE AND PAILLIER
As mentioned in the introduction, each loop of the blind rotation in the work of Joye and Paillier [13] consists of k RGSW ciphertext additions followed by an external product.Their bootstrapping key is a set of RGSW ciphertexts which encrypt either 0 or 1. Basically, a client generates k RGSW ciphertexts, denoted by {key j,i } i∈[k] , per secret key component S j (j ∈ {0, . . ., n}) such that all of them are encryptions of 0 or only one of them encrypts 1 and the rest encrypt 0.Then, the computing party runs a selection algorithm to choose the corresponding X a j S j , as follows: 1 + (X a j − 1) key j,1 +(X 2a j − 1) key j,2 For example, if S j = 3, then key j,3 is an encryption of 1 and the rest are encryptions of 0. Here, we note that the X ia j 's for i ∈ [k] are precomputed and the product with key i is a multiplication in the FFT domain which is the most expensive part in this selection algorithm.
For the interested reader, we now provide a more detailed description of how the bootstrapping keys are constructed and how to use them during the blind rotation step.For 118630 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
simplicity, we will assume that we sample keys from the set S = {0, . . ., k}.Let I be the indicator function, that is, I{t = S j } = 1 when t = S j and I{t = S j } = 0 otherwise.Notice that we can write Therefore, we can compute acc by setting key j,i ← RGSW(I{i = s j }), and iterating acc ← acc + k i=1 (X ia j − 1) key j,i acc.

C. CHOOSING A BLIND ROTATION ALGORITHM FOR MPHE TFHE
As we have mentioned in the introduction, the goal of this work is to extend [13] to the MPHE setting by constructing suitable bootstrapping keys and see under which conditions this approach is better than that of [12].This analysis is done in Section VIII-A.

V. BOOTSTRAPPING KEY GENERATION FOR MPHE TFHE
Since we wish to use Joye and Paillier's approach for TFHE bootstrapping, our main goal in this section is to create on the fly a common bootstrapping key compatible with their blind rotation algorithm.This new key will be created from the locally generated keys sent by all users.To do this, we introduce our novel algorithm called homomorphic indicator and we explain how to use it to build the MPHE bootstrapping keys.

A. HOMOMORPHIC INDICATOR
Given an array A of encryptions of 0's and 1's, the goal of the homomorphic indicator algorithm is to homomorphically produce a new array with an encryption of 1 in the position corresponding to the Hamming weight (W H ) of A, that is, the output array will have an encryption of 1 in the W H (A)-th position and encryptions of 0 everywhere else.Let us start by explaining how a plaintext version of the homomorphic indicator works.The algorithm takes as input an array A of k slots4 filled with 0's and another array C with also k slots but filled with 0's and 1's, which we will call controller bits.The algorithm proceeds by iterating over C as follows.If the first controller bit is 1, the first slot of A becomes 1, and the rest of A is untouched.If the second controller bit is also 1, A remains the same except the first and second slots, where the first slot becomes 0, and the second slot becomes 1.After repeating this k times, the array A will have a 1 at the position corresponding to the number of 1's in C.
In the ciphertext case, we start with two arrays of k+1 slots, denoted by A old and A new , where the 0-th slot of A old contains an encryption of 1 and the rest are set to encryptions of 0. Additionally, we need k controller bits {C i } i∈ [k] , each of which encrypts a bit.We note that the last k slots of A old are what we have at the beginning in the cleartext case.We store the desired value (which is 1) at the 0-th slot.In each loop, A new is updated based on the corresponding controller bit and the values in the slots of A old , as follows.For each j ∈ . This can be instantiated as In order to update the first slot, we need to deal with the 0th slot as well since it influences on the first slot of A new .The 0-th slot should also be updated to 0 or remain 1.That is, A new [0] is updated to A old [0] if C i is an encryption of 0, otherwise, A new [0] becomes an encryption of 0. This is instantiated as After all the slots of A new are updated, A old is set as A new and we repeat the protocol until all k controller bits are used.At the end of the protocol, we will take the last k slots of A new as the desired result.
Algorithm 2 Homomorphic Indicator (Hom.Indicator) Note that we use the internal product to instantiate the CMUX gate and the multiplication between two ciphertexts.However, one can use the internal product or any type of homomorphic multiplication.Since the multiplicative depth of the homomorphic indicator algorithm is linear in the size of the output (unit vector), the use of internal/external product is highly recommended if the size of the output is large, in order to manage the noise growth.

B. INSTANTIATION OF BOOTSTRAPPING KEY GENERATION
In this subsection, we explain how to use the homomorphic indicator to construct suitable bootstrapping keys for the blind rotation algorithm of [13].We start by explaining how the users need to prepare their local keys, and then we detail how the server can build the bootstrapping keys from the local keys.

1) LOCAL BOOTSTRAPPING KEY GENERATION
We generate the local bootstrapping key similarly to [5], however, the instantiation is a bit different in order to minimize the noise.We adapt the typical technique, which transforms a private-key ciphertext into a public-key ciphertext.Our goal is to turn single key ciphertexts encrypted under a user's public key into a ciphertext encrypted under the global public key via one interaction.We specifically follow the way of [20] which is designed for TFHE ciphertexts.Each user does the following: 1) Generates a vector consisting of size m = O(n log q) LWE/RLWE/RGSW encryptions of 0 under its own key, and distributes the vector of the ciphertexts to the other predefined k − 1 users.In other words, each component of the vector looks like (a, b i ), where b i = as i + e i , with a being a common random string (CRS) which has already been provided to all the users.Once this step is done, the rest can be run multiple times without interactions among users.2) Generates k random bit vectors of dimension m.
3) Computes k dot products between the bit vectors and the given k ciphertext vectors, including its own vector, and adds up the results.The outcome is an LWE/RLWE/RGSW encryption of 0 under the master secret key, which is s := (s 1 + s 2 + • • • + s k ).Every time all k users generate ciphertexts/local bootstrapping keys, each user does the second and the third step described above and add the message term on the desired spot at the end.We give an algorithm for this procedure below.In practice, we set m = ⌈3 log q⌉ as [6] analyzed.The main goal of this algorithm is to create the global bootstrapping key of [13] on the fly using all clients' keys which have already been given at the beginning of the protocol.As we explained in Section II, the global bootstrapping key is an array of k RGSW ciphertexts per coefficient.We denote this key as bsk := [ bsk 0 , . . ., bsk To generate bsk, the following actions are required by each user and by the server (or a computing party).

Server.
• Initialization: The server creates two arrays of k +1 slots per coefficient, denoted by A old and A new , respectively, where the first slot of A old is 1 and the rest are zeros.
• As soon as it receives the (local) bootstrapping keys bsk 1 , . . ., bsk k from the predefined k users, it executes algorithm 4, running Hom.Indicator as a subroutine.

Algorithm 4 Global Bootstrapping Key Generation
Input: Assume that we have four users (k = 4), and each has a secret key s i for i ∈ [4].For ease of exposition, we only focus on the constant term of each s i , the process is the same for the rest of the coefficients.Let us say that s 1,0 = 1, s 2,0 = 1, s 3,0 = 1, and s 4,0 = 0, hence the constant term of the master secret key is 3 (S 0 = 3).The server creates two arrays of k + 1 = 5 elements, as we explained in the above section, called A old , A new .The array A old has an RGSW encryption of 1 at the first position and an RGSW encryption of 0 in the rest while A new consists of RGSW encryptions of 0.
In the first iteration, since s 1,0 = 1, we will set A new [1] = RGSW(1) and A new [j] = RGSW(0) for all j ̸ = 1.We then have an encryption of 1 in position 1.The same would happen in the next two iterations until we reach s 4,0 .In this case, since s 4,0 = 0, the algorithm does not change the plaintexts of all elements in the output array (but the noise is increased).At the end, we get an array with an RGSW encryption of 1 in position 3, and a RGSW encryption of 0 in the rest.The last 4 elements of the final array correspond to the bootstrapping keys needed for 4 parties in the blind rotation protocol of [13].This example is depicted in Figure 2.

VI. TFHE BOOTSTRAPPING IN THE MULTIPARTY SETTING
Once the predefined k users (parties) generate their own local bootstrapping key as discussed in Section V-B and upload them to server, the server runs Algorithm 4 to create the common/global bootstrapping key.The global bootstrapping key is stored, and the server can reuse it as long as the computation is for the same set of users.
After running the blind rotation algorithm of Joye and Paillier with the global bootstrapping key, the output is an 118632 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.RLWE ciphertext under the k ''RLWE keys'' defined over a polynomial ring of degree N .However, the result of a TFHE bootstrapping should be an LWE ciphertext encrypted under the k ''LWE keys'' to enable further computations.
As explained in Section III-D, in single key TFHE, we switch the ciphertext format from an RLWE to an LWE ciphertext by running an algorithm called sample extraction.However, the outcome has still dimension N which is larger than the original input dimension n.Therefore, TFHE introduced a key-switching algorithm to switch an LWE from dimension N to dimension n.We can adapt the single key version of this algorithm to the multiparty setting as follows.

A. KEY SWITCHING IN THE MULTIPARTY SETTING
The key switching algorithm for the MPHE case is the same as in the single key TFHE setting, the only change is in the key switching keys.Assume that we want to switch from with s i and s ′ i being the secrets of the i-th party.Each user only needs to produce ksk i := LWE s (s ′ i ) as their key switching key by running the function Local.Enc.To obtain the global key switching key, the server only needs to add up all ksk i .

B. OVERALL DESCRIPTION OF OUR BOOTSTRAPPING
We now have all the ingredients to perform MPHE bootstrapping using the blind rotation of [13].We describe the process below.
Users.Each i-th user does the following: • Local public keys: generates its own local public key; a vector of ciphertexts of dimension m(= O(log q)) per ciphertext format (LWE,RLWE,RGSW), where all the masks of the ciphertexts are set to a which is a common random string (CRS).We denote the vectors by V LWE , V RLWE , V RGSW .
• Local bootstrapping keys: generates local bootstrapping key bsk i by running Local.Enc(V RGSW , RGSW, s i,j ) for all j ∈ [n].
Similarly, generates local key switching key ksk i by running Local.Enc(V LWE , LWE, s i ).
• Setup: runs Algorithm 4 to generate a global bootstrapping key bsk.Generates a global key switching key denoted by ksk by summing up all given ksk i given by k users.
• After a gate operation: run Joye and Paillier's bootstrapping with bsk and ksk.

C. SECURITY
We rely on the fact that TFHE is IND-CPA secure (due to the (R)LWE assumption (see Section II) for one key) and the security of ciphertexts under multiple keys discussed in [2] and [5].
• Local Public key: each local key is encrypted under the owner's key, therefore the other users cannot decrypt the secret key from the public key (due to IND-CPA of TFHE).
• Common public keys: common public keys (including bootstrapping keys and key-switching keys) are encrypted under are compromised, the ciphertext is still encrypted under one valid and uncompromised key, hence the IND-CPA of TFHE guarantees the security of the common public keys.
• Security model: We present our construction under the assumption that both the users and the server are semi-honest.Lattice-based commitment schemes and zero-knowledge proofs can be used to transform a semihonest MPHE protocol into a maliciously secure one, see for example [21].

VII. NOISE ANALYSIS
In this section, we analyze the noise growth of the setup phase and the final noise after bootstrapping.We start by briefly recalling the noise growth of TFHE ciphertexts [18].Let C 1 and C 2 be two RGSW ciphertexts encrypting m 1 and an m 2 , respectively.After one internal product between C 1 and C 2 , denoted by C ′ := C 1 ⊠ C 2 , the variance of the noise contained in the output is Let e be the initial noise in each user's (local) public key, that is, Var(e) = θ 2 as we defined in Section II.After receiving all the public keys from the predefined users, the noise contained in each user's bootstrapping key becomes k •ι•e due to additions, where ι = ⌈3 log q⌉ to guarantee LWE security [6] (as we mentioned in Section V-B).Therefore, The noise becomes larger during the generation of the global bootstrapping key.Each element in the initial array is a plaintext which has no noise.We can upper-bound the variance of the i-th output array A i of one homomorphic indicator operation as • Var(Err(bsk i )) + k(1 + N ), from Equation (1).Each element of bsk is a vector of RGSW ciphertexts (denoted by [A 0 , . . ., A n−1 ]).Each component of such vectors is created via homomorphic indicator which consists of k consecutive CMUX gates (internal products).We define the variance of bsk to be the maximum variance of A i 's.Hence, the noise contained in bsk can be bounded as follows: • Var(Err(bsk i )) . Now, we run bootstrapping as specified in [13] with the constructed bsk.In the blind rotation algorithm of [13], there are k additions among the corresponding bsk components in every loop.After the additions, the output, say C add , contains the noise of which the variance is In terms of noise growth, the blind rotation of [13] is viewed as TFHE bootstrapping with C add as the bootstrapping key.After blind rotation, the output RLWE ciphertext c has a noise that can be bounded as follows: Performing a key switching to convert c to an LWE ciphertext, denoted by c, only adds a small noise N •ℓ•g 2 •Var(Err(evk i )) which is not a dominant term compared to the noise in c.Therefore, the variance of the final noise in our case has complexity ).Under the central limit heuristic, the noise contained in the output LWE ciphertext c has the following bound with overwhelming probability: As a result, we can find the relation among parameters (mainly q, N , n and k) from the following bound in order to guarantee the correctness, ∥ Err(c)∥ ∞ ≤ q/16.Overall, our bootstrapping key generation algorithm gives the same noise propagation as Lee et al.'s approach, however, our choice of bootstrapping adds more noise depending on the number of users during blind rotation.Therefore, the final noise contained in the output of bootstrapping using our technique has a bigger factor (k 1.5 ) than the approach of Lee et al., where the noise grows linear in k.

TABLE 1.
Comparison in terms of the number of expensive operations such as external products denoted by T mult and a point-wise multiplication between two polynomials of degree N in FFT domain, denoted by T PM used in blind rotation.w is a small constant.

VIII. PERFORMANCE EVALUATION
In this section, we detail our implementation choices and provide the best parameter sets together with their benchmarks with respect to the actual running time of the main homomorphic operation and noise growth.We came across some difficulties when comparing our implementation numbers with the existing design of [12] since they did not implement their multi-key extension.Therefore, for a fair comparison, we analyze the noise growth of both designs in terms of crucial parameters such as k, N , n, ℓ, and provide benchmarks with respect to the running time of the dominant operation of both cases on the same machine.

A. COMPLEXITY COMPARISON 1) BOOTSTRAPPING RUNNING TIME
In Table 1 we provide the computational cost of the blind rotation algorithms of [12] and [13] in terms of the cost of one point-wise multiplication in the FFT domain (denoted by T PM ) and one external product (denoted by T mult ).An external product consists of 4ℓ point-wise multiplications in the FFT domain and 2ℓ + 2 FFT conversions of a polynomial (denoted by T FFT ) (from the standard domain to FFT domain and vice versa).Since the dominant part of one external product is (2ℓ+2) FFT conversions, we can consider T FFT as the dominant factor.The actual computational cost of blind rotation will, of course, depend on the chosen parameters for the schemes.
We want to know up to which k our MPHE approach based on [13] outperforms that of [12].For this, we can use Table 1 and upper bound k as follows: Theoretically, the ratio between T FFT and T PM (denoted by r) is O(log N ), however, the hidden constant in the complexity varies depending on machines and FFT libraries the server runs.Moreover, with the bound on the noise after blind rotation derived in Section VII, we obtain the following relation among parameters (3) to guarantee correctness in the multiparty setting with our global bootstrapping key.
With the parameters that we used in our implementation (see Table 2), we can handle up to k ≤ 2 13.3 parties according to (3).However, the practical bound for k depends on r and ℓ, as described by (2).For example, let us fix ℓ = 3.If r < 4, it is better to use single-key TFHE directly, if 5 ≤ r ≤ 7 then the optimal approach is to use our technique for k ≤ 2 and the approach of [12] for k ≥ 3. Similarly, for 8 ≤ r ≤ 10 the optimal is to use our technique when k ≤ 3 and the approach of [12] for k ≥ 4. When r ≈ 64 in our implementation, we can expect the upper bound of k which guarantees that our approach is better up to 21 parties for N = 2 11 , ℓ = 3.Therefore, our approach is better the higher the ratio r is.This is the case when we want to handle larger message spaces in TFHE.That is, in order to handle message spaces larger than bits, TFHE offers functional bootstrapping, which uses N up to 2 14 [22].In this case, our approach provides faster bootstrapping than that of [12] since r increases significantly compared to the case N = 2 11 .

2) SETUP PHASE
Once the global keys are generated, the server can reuse the keys multiple times.Therefore, in the MPHE case, the global key generation is considered to be part of the setup phase.The setup phase of Lee et al. consists of nk internal products with multiplicative depth k.Similarly, our homomorphic indicator consists of k CMUX instantiated with internal products per secret key element.Therefore, our approach also requires kn internal products, in total, with multiplicative depth k.As a result, both approaches have the same computation complexity and the same noise propagation during this phase.

3) MEMORY BLOWUP
The main downside of our approach is linear memory blowup as the number of parties grows, whereas the other existing approach has constant memory overhead.Therefore, one can enjoy our approach up to reasonably many parties in the computing environment where the memory blow-up is not a big issue.With a normal laptop, we show our implementation results for up to 16 parties in the next section.

B. IMPLEMENTATION
We provide a prototype implementation of our multikey bootstrapping key generation algorithm.We have also implemented the blind rotation algorithm of [13] instantiated with our bootsrapping keys.The prototype was done in Rust using the Concrete library (concrete-core version 1.0.0-beta)[14] and can be found at this GitHub repository.We include the Cargo.lockfile of our project and the generated files from our benchmarking to ensure reproducibility.

C. RESULTS AND RECOMMENDED PARAMETER SETS
To test our new key generation algorithm, we have computed a NAND gate using the blind rotation algorithm of [13] and our bootstrapping keys.We want to remark that the noise after bootstrapping is independent of the noise of the LWE ciphertext being bootstrapped.As long as the noise after bootstrapping is smaller than q/16 it is possible to compute a new gate.Therefore, our approach can be used for a more complex circuit than just a single NAND gate.
We have performed a search over a set of 26 possible parameter sets for decomposition base g and level ℓ of the RGSW ciphertexts composing the keys, and we have selected the best parameters in terms of bootstrapping time and noise growth.This selection was done after computing 500 NAND gates per parameter set.Our experiments were done using a machine with an Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz with 8GB of RAM and the results can be found in Table 2.
We use parameter N = 2048, log Q = 64, θ = 1.85 • 2 4 for the local public key (generated during the parties' setup phase) to achieve 110 bit security.The keys are used to generate ciphertexts and global keys which have higher security due to k aggregation.
We can see the trade-off between running time and the noise contained in the ciphertexts and keys, depending on the choice of B = log 2 g and ℓ, where g ℓ ≤ Q in Table 2. Since ℓ influences on the size of the bootstrapping key, it also affects the running time.Moreover, as we can see from Section VII, both ℓ and g are important factors for noise growth.However, the noise grows in poly(g).Therefore, our small choice of B increases bootstrapping running time but decreases the noise contained in the bootstrapping key and the final ciphertext after bootstrapping, significantly, which guarantees a much lower decryption failure probability.In Table 2, we give two versions of noise in logarithmic form, in the second column from the right.The first is the noise in R Q and the second in the parentheses is the noise after modulus switching from Q to q.Since our message m ∈ {0, 1} is encoded as q/8 • m, the final noise should be smaller than q/16 to guarantee the correctness.Blind rotation with the global bootstrapping key works over R Q , therefore, the correctness holds if the noise contained in the output of blind rotation is less than Q/16.Our result shows that we still have enough noise room to handle more operations before decryption failure occurs.Moreover, our bootstrapping key noise grows linearly in k as our analysis expected (for fixed parameters Q, θ, N and similar choice of ℓ and B).
In Table 3, we show how much memory the server requires to store the bootstrapping keys, which increases linearly in k.We also show the time to generate the keys.We want to remind the reader that this key generation happens only once and can be done by the server alone.Therefore, the parties can produce their individual keys, send them to the server and go offline until the server generates the bootstrapping keys.For the single-key case, the original TFHE key generation takes around 1.5 seconds, while ours takes 6 seconds.Since bootstrapping keys are forms of RGSW ciphertext and the number of keys depends on the size of the secret key, the keys are the main factor of the server's memory overhead of FHE in general.
As we mentioned above (Section VII), Lee et al. [12]'s bootstrapping key generation would be very similar since the number of the dominant operation (internal product) of their  [23] for different number parties k.We indicate by log q and log Q the LWE and RLWE modulus, respectively.The noise in a fresh RLWE ciphertext is indicated as σ rlwe .The noise in a fresh LWE ciphertext is indicated as σ lwe .B corresponds to log(g).The last column details the noise contained in the bootstrapping keys after running the homomorphic indicator algorithm.The values in the last three columns correspond to the average of 500 NAND operations, each performed with a freshly encrypted LWE ciphertext.

TABLE 3.
Size in GB and time of generation (in seconds) of the bootstrapping keys produced by our approach with respect to the best parameters for time/noise error.We also provide the time of generation (in seconds) of the rests of the keys generated during setup.That is, the generation of all the users public and secret keys, the global public and secret key and the global key switching key.The values in the last two columns correspond to the average of 500 NAND operations, each performed with a freshly encrypted LWE ciphertext.
algorithm is the same as our case.Since they don't provide experimental results, our results can be used as a reference for their case.

IX. DISCUSSION AND CONCLUSION A. APPLICATIONS OF TFHE-BASED MULTIPARTY FHE
Determining whether a MKHE or a MPHE approach is better for a given application will come down to understanding two things.First, the character of the parties involved.If the application needs to provide parties with the capability of joining and leaving during the life cycle of the application, then multikey is the only choice.On the other hand, if the application has a static number of users from start to finish, then both approaches can be considered.The deciding factor in this case will be the bandwidth of the network and the storage capabilities of the parties.That is, the ciphertexts produced by a multikey scheme grow linearly in size with respect to the number of parties.The ciphertexts considered in a multiparty scheme have constant size.In fact, they have the same size as the single-party equivalent of the scheme.Another detail that needs to be considered in this discussion is the setup time.A multiparty-based application requires an expensive setup phase since the generation of the global bootstrapping key is computationally expensive.If the application only needs to run once, the multiparty approach might not be the best approach and the user should favor some other alternative.On the other hand, if the application is executed a good amount of times, the amortized cost compensates for the initial requirement of the setup phase.
In what follows, we give examples of applications that could benefit from the multiparty variant of TFHE that we present in this paper.We will try to provide the best explanation as of why we think that these applications would indeed need to use a multiparty variant of TFHE and not some other FHE-based solutions such as multikey or the use of some other scheme instead of TFHE.
• k-NN learning.k-NN is a well-known Machine Learning algorithm that given a distance δ, a collection of vectors D (model vectors) and a source vector v returns the k vectors in D closest to v with respect to distance δ.Using our new technique for generating bootstrapping keys for TFHE, it is possible to run k-NN homomorphically in the following scenario, as discussed in Fig. 1.The data owner sends its data to a server (the computing party), by encrypting D with the global public key.The client encrypts its source vector v using the same global public key and sends it to the server, which runs the k-NN algorithm homomorphically using the bootstrapping procedure of [10], together with our bootstrapping keys to evaluate the sign function as described in this work.The server sends back to the client the set of model vectors M closest to v together with the partial decryption interacting with the data owner.This allows the client to decrypt M .If another party wants to do the same, it simply interacts with the server to generate a new collection of global public key, bootstrapping keys and secret keys.
• Privacy-Preserving Analysis on Medical Data.A recent work [24] on privacy-preserving analysis of 118636 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
medical data was done via multiparty homomorphic encryption.They are using a collaborative (interactive) version of bootstrapping as the original MPHE [4] proposed.It can use our protocol built upon [5] (noninteractive design) when the data analysis requires a non-linear function, or gate operation, which is more attractive in a cloud service scenario.

B. DISCUSSION
Our homomorphic indicator can be of independent interest to homomorphically indicate where the desired position is in an array/vector.There is a similar technique which achieves the same functionality as ours, introduced in [11].Their algorithm is called homomorphic traversal and outputs a unit vector where the desired component is set to 1, and 0 elsewhere.Their algorithm gives less noise in the output than the homomorphic indicator procedure since the multiplication depth is log k instead of k, where k is the dimension of the output vector.However, they need a bit representation form of i for inputs, which is an implementation bottleneck in our case.That is, we would need a bit representation of each S j ≤ k which is a master secret element to run their algorithm for all j ∈ {0, . . ., n − 1}.Since S j 's are not known to every user, the only way to do this is to homomorphically compute the binary addition of all the bit representations of s i,j 's which were sent by all k users.
Moreover, handling a carry bit homomorphically is not well studied and not practical enough for now.This is the reason why we have designed a new way to output the same unit vector with only simple homomorphic operations.Therefore, each approach can be used in different applications, depending on the required input form.

C. CONCLUSION AND FUTURE WORK
We propose a novel approach to construct bootstrapping keys for the TFHE scheme in the multiparty setting given a predefined set of parties.We compare two different TFHE bootstrapping designs which can handle multi-digit secret keys in the single-user setting and that can be extended to deal with multiple users.From our comparison, we have determined which of the two approaches provides a faster bootstrapping algorithm, and we have built an efficient global bootstrapping key compatible with it.
To this end, we introduce a novel algorithm called homomorphic indicator to obliviously compute an (encrypted) unit vector where the encryption of one is placed according to the input parameters.We believe that this construction can be of independent interest.
We have implemented our design as a proof-of-concept.Given a suitable set of parameters, we have been able to compute TFHE gate bootstrapping in less than a second for up to 16 parties.
As detailed in the paper, our method induces a memory blow-up in the bootstrapping keys when the number of parties grows.As future work, we will address this issue and provide optimal parameters for as many parties as possible.We also leave as future work the instantiation and performance evaluation of a real-use case using our technique.

FIGURE 1 .
FIGURE 1. Illustration of an application scenario of MPHE (two-party case).(1) Once a client and a service provider generate a common key (pk) during the setup phase, both can send their item (m : client's data, f : machine learning model) encrypted under the key to the server.(2) After the computation is over, the server sends the output (Enc(f (m), pk)) to the model provider so that (3) he can run partial decryption with his own secret key sk _2 and (4) sends the output which is an encryption of Enc(f (m), sk _1)) to the server.(5)The server sends the given value from the model provider to the client, so that he can obtain f (m) by decrypting the ciphertext with its own secret key sk _1.

FIGURE 2 .
FIGURE 2. Example for k = 4 of our bootstarpping key generation.The blue arrow shows the direction of moving the first slot.The black arrows show that the elements in the new array come from the previous slots in the old array when the corresponding secret key component is 1.The red arrow shows that the elements in the new array come from the same slots of the old array when the corresponding secret key component is 0.

TABLE 2 .
Parameter sets recommended achieving at least 110-bit security based on LWE estimator