- Reference: TFHE Deep Dive - Part IV - Programmable Bootstrapping [10]
Continuing homomorphic additions of TFHE ciphertexts does not necessarily increase the noise , because is randomly generated over the Gaussian distribution, thus adding up many noises would give the mean value of 0. On the other hand, continuing homomorphic multiplications increases the noise, because the noise terms get multiplied, growing its magnitude. Thus, we need to somehow reset the noise before it trespasses on the higher bits where plaintext resides (i.e., preventing the red noise bits from overflowing to the blue plaintext bits as shown in Figure 8). The process of re-initializing the noise to a smaller value is called noise bootstrapping.
As explained in the beginning of this section, TFHE uses LWE (which is GLWE with ) to encrypt & decrypt a plaintext. That is, each plaintext is (a single number), encoded as a zero-degree polynomial. Further, the secret key S that encrypts each is a vector instead of a polynomial. On the other hand, TFHE’s noise bootstrapping uses homomorphic addition between GLWE ciphertexts and homomorphic multiplication between GLWE and GGSW ciphertexts.
Suppose we have a TFHE ciphertext as follows:
, where is a big noise accumulated over a series of many ciphertext (or plaintext) multiplications. The goal of noise bootstrapping is to convert into such that:
, where is a re-initialized noise.
To implement noise bootstrapping, we create a specially designed -degree polynomial called a Lookup Table (LUT). Before explaining , we will first motivate the idea based on a preliminary LUT polynomial . Imagine that the polynomial ’s each degree term has its exponent , a plaintext with some noise , and its corresponding coefficient , which is a noise-free plaintext. Therefore, the -degree polynomial is defined as follows:
# total terms
# total terms
# total terms
In the above formula, each and represent every possible plaintext message and error values (where and ).
We design to have the special property that each term represents the special mapping (exponent, coefficient) , where can be any value in . During the TFHE setup stage, we GLWE-encrypt by using our newly defined GLWE key , a bootstrapping key, which is different from the LWE secret key . is a list of -degree polynomials with binary coefficients. Later, during the noise bootstrapping stage, we will rotate the coefficients of by positions to the left by computing , by using the polynomial coefficient rotation method 1 technique (Summary A-5.2.1 in §A-5.2). Then, we will extract the polynomial’s constant term’s coefficient (i.e., the left-most 0-degree term’s coefficient in the rotated polynomial ) by using the coefficient extraction technique (§D-1.7). Further, we will encrypt as a GLWE ciphertext at the TFHE setup stage, and thus the rotated ’s extracted constant term’s coefficient is an LWE encryption of (i.e., ) with a re-initialized (i.e., completely reduced) noise.
To summarize, the noise bootstrapping procedure can be conceptually understood (at least for now) as follows:
The output encrypts the same plaintext message as the input ciphertext, but with completely reduced noise. Therefore, the output can be used for subsequent TFHE homomorphic operations (e.g., addition or multiplication). During this noise bootstrapping process, the polynomial is used as a dictionary that contains the mappings from the noisy plaintext (i.e., as where ) to the noise-free plaintext (i.e., as where ). Therefore, is called the Lookup Table (LUT).
Then, what should be the degree of ? In order for to encode all possible mappings from to , should be a -degree polynomial. However, is a very big number, and it is computationally infeasible to manage a -degree polynomial. Thus, in practice, we instead use a much smaller polynomial whose degree is only . Remember that according to our TFHE setup, . Therefore, we need a way to compress the big ciphertext space into a much smaller space and encode the compressed values as the exponents of in a proportionally correct way. For this proportional compression of , we will use the LWE modulus switching technique learned from §C-4.1.
To avoid using the giant -degree polynomial , we will compress possible ciphertext elements into distinct exponents of the -degree polynomial , where each term in represents a mapping from (i.e., noisy plaintext to noise-free plaintext). However, notice that when we rotate the coefficients of the -degree polynomial to the left, as rotates across the boundary between and degree terms, ’s sign flips to (as shown in the example of §A-5.2.1). Due to this coefficient sign flip, the -degree polynomial can theoretically encode total distinct coefficient states as follows: . To move each of these distinct coefficients to the constant term’s coefficient position in (i.e., shifting the coefficient to the leftmost term in ), the rotating computation of can use distinct values, which are , to move each of coefficients to the constant term’s position. This implies that the exponent in can use any of the distinct values to cover all possible (sign-flipped) coefficient states of . Also, remember that . Therefore, we will switch the modulo of from . Using the LWE modulus switching technique (§C-4.1), our original LWE ciphertext (i.e., the initial input to the noise bootstrapping procedure) will be converted into the following:
# the secret key stays the same, as each is binary
The degree of and Security: If our goal were to design the minimal-degree polynomial whose coefficients map all possible values of the plaintext , then it would be sufficient to design a -degree polynomial . Nonetheless, the reason why we choose the degree of to be instead of is to guarantee an enough security level– the higher the polynomial degree is, the safer our scheme is against attacks.
Problematically, the LUT polynomial rotates negacyclically, that is, (i.e., coefficients flip their signs with the rotation period of ). More generally:
, where denotes the constant term’s coefficient after rotating the polynomial by positions to the left. Problematically, flips its sign whenever its rotation crosses the boundary between and . Given the modulus-switched values , , and , we design the following LUT polynomial :
# total terms
# total terms
# total terms
Remember that by computing for , we can rotate ’s coefficients to the left by positions. For each -slot rotation of where , the rotated polynomial gets the following values as the constant-term’s coefficient:
In the above expression, is a noise that can range from . Note that all of exponents are designed to be mapped to the same coefficient value, , which aligns with the fact that their underlying plaintext is the same when decrypted (once their associated noise gets eliminated). This is why each is redundantly used times in a row as coefficients in . We can view this sequential repetition of coefficients as having a robustness of mapping each to against any noise .
So far, the above sequence of coefficients is what we expect (i.e., the rotated polynomial) to return as its constant term’s coefficient for each of rotations (where each ). However, the correctness of the coefficient mappings breaks when the rotation count is between , because their coefficients flip their signs when they cross the term’s boundary from to , due to the polynomial ring’s negacyclic nature. Specifically, the constant term’s coefficient values of the rotated polynomial are as follows for each rotation of positions:
As we can see above, the rotated ’s constant term’s coefficient shows a negacyclic pattern with the rotation period of , where the second -rotation group’s coefficients are exactly the negated values of the first -rotation group’s values. Let’s understand why this negacyclic behavior breaks the (exponent, coefficient) = mappings. Since TFHE’s plaintext and ciphertext values are defined in rings, as we rotate the LUT polynomial , we ideally want the rotated polynomial ’s constant term’s value (i.e., mapped plaintext value) to wrap around in a circular manner, representing a ring pattern (with sequential repetitions of each value to be resistant against up to a noise). However, the negacyclic nature of a polynomial ring makes the constant term’s value of the second-half rotation group problematic, because they are exact negations of those of the first-half rotation group, breaking the circular wrapping-around ring pattern between the first-group values and the second-group values.
To summarize the problem, has a limitation in becoming a perfect LUT, because it preserves the correct mappings of (exponent, coefficient) = only for one half of , not for the other half.
Solution: Good news is that we have observed that ’s mappings of (exponent, coefficient) = preserve their ring-pattern consistency if is rotated no more than positions (i.e., the first-half rotation group). Therefore, the easiest solution to avoid the negacyclic problem of the LUT polynomial rotation is that the application of TFHE restricts to be rotated no more than positions by design during the noise bootstrapping. To enforce this, when the TFHE application’s computation pipeline processes plaintext values (in its original plaintext computation logic before considering any homomorphic operations), the application should ensure to involve only some pre-defined continuous modulo values within as the possible inputs and outputs of each computation step. This constraint effectively ensures the possible values of to be continuous values within . Since the LUT polynomial gets rotated by computing , as the application restricts to be at most (out of ) by its application design, will be rotated at most positions during the noise bootstrapping. Thus, we can prevent the occurrences of the problematic rotations that flip the signs of coefficients.
To summarize, at the cost of halving the application’s usable plaintext values to some continuous values within , we can prevent ’s negacyclic rotation problem, and thereby preserve ’s correct mappings of (exponent, coefficient) = .
Considering all these, our final LUT polynomial is as follows:
Summary D-1.8.3 Structure of Lookup Table Polynomial
, where . The application should ensure that are some continuous modulo- values in . This constraint ensures ’s rotation positions (where ) to be most continuous possibilities, preventing from making more than 1 full-cycle rotation that triggers a negacyclic problem.
Blind rotation refers to rotating an encrypted polynomial’s coefficients so that it is not possible to know how many positions the polynomial’s coefficients are rotated, and after the rotation, it is not possible to see which coefficient has moved to which degree term. Blind rotation uses the basic polynomial rotation method 1 technique (Summary A-5.2 in §A-5.2), with the difference that the computation is done homomorphically.
Note that , so we can rotate by computing . In fact, we cannot directly compute the LWE decryption formula (or ) without the knowledge of the LWE secret key . Nevertheless, there is a mathematical work-around to compute without the knowledge of the secret key , provided we are given at the TFHE setup stage. Note that is a GGSW encryption of the LWE secret key , encrypted by the GLWE secret key (i.e., a bootstrapping key). We use to homomorphically compute (i.e., blindly rotate the coefficients of to the left by positions), according to the following procedure:
This means that the GLWE encryption of the final polynomial will have the coefficient in its constant term, as is designed to have the mapping ().
Note that while we restrict the application’s plaintext space usage to some continuous modulo values within (§D-1.8.3), this restriction does not exist in the ciphertext space. That is, it is okay for blind rotations to rotate more than positions during the intermediate steps, because their invalid positions can be brought back to valid ones by their subsequent steps. Therefore, what matters for the noise bootstrapping correctness is only the completed state . The rotation-completed must have been rotated positions to the left. Therefore, we only need to ensure that falls within our pre-defined continuous modulo range within the domain, which is equivalent to ensuring that the aggregate rotation count is at most positions to avoid coefficient extraction of any double-signed contradicting coefficients.
Homomorphic MUX Logic Gate: In step 3, the formula implements the MUX logic gate as shown in Figure 13, where in our case is the selection bit that chooses between the two inputs: and . If is 1, then the output is ; otherwise, the output is . In our design, the homomorphic computation of effectively implements a homomorphic MUX gate, where the two inputs are LWE-encrypted and the selection bit is GGSW-encrypted.
Finally, we use the coefficient extraction technique (§D-1.7) to extract the rotated polynomial ’s constant term’s coefficient as an encryption of : . At this point, the original ciphertext’s old noise has gone, and the bootstrapped new ciphertext has a newly generated small noise .
In fact, the homomorphic MUX logic in the blind rotation procedure (§D-1.8.4) involves lots of ciphertext multiplications and additions, which can accumulate additional noise until we reach the point of coefficient extraction. In order to limit the accumulating noise during the series of MUX logic, we can carefully adjust the security parameters. For example, we can design a narrower Gaussian distribution for sampling the noise , while designing a sufficiently large to compensate for the reduced noise. Meanwhile, increasing rather makes the system less secure, because it becomes more vulnerable to lattice reduction attacks.
TFHE’s noise bootstrapping procedure is summarized as follows:
Summary D-1.8.6 TFHE Noise Bootstrapping Procedure
Lookup Table Encryption: Encrypt the LUT polynomial as a GLWE ciphertext by using the bootstrapping key .
Each step of the actual blind rotation above is computed as the following TFHE ciphertext-to-ciphertext multiplication and addition:
Halving the Usable Plaintext Range: Problematically, the LUT polynomial V rotates negacyclically. To avoid this problem, we require the application to ensure that the plaintext uses only continuous modulo values within . This way, we avoid rotating more than positions that cause coefficient extraction of double-signed contradicting coefficients.
Suppose the GLWE security setup: , , ,
And suppose we have the following LWE ciphertext:
(should be the case that for correct decryption)
Now then, the TFHE noise bootstrapping procedure is as follows:
Note that
This small difference in comes from the aggregated noises of rounding during the modulus switch.
(in ) | () | () | () | () | () | () | () | () | ||
constant term’s | ||||||||||
coeff. of | ||||||||||
(plaintext) | ||||||||||
(in ) | () | () | () | () | () | () | () | () | ||
constant term’s | ||||||||||
coeff. of | ||||||||||
(plaintext) | ||||||||||
Note that ’s coefficients for the terms are instead of , so that if gets rotated by slots to the left, the constant term’s coefficient flips its sign to due to wrapping around the boundary of the exponent.
During the actual bootstrapping, we will do a blind rotation of Table 4’s (which is GLWE-encrypted) by positions to the left, which is computed as follows:
In Table 4, if the rotation count , the corresponding constant term’s coefficient is . As , we finally get .
The actual blind rotation is computed as follows:
The final output of blind rotation is the GLWE ciphertext of , , whose constant term’s coefficient is .
Each step of the actual blind rotation above is computed as the following TFHE ciphertext-to-ciphertext multiplication:
We will leave this computation for the reader’s exercise.
Now, we extract the constant term’s coefficient of the encrypted polynomial by using the coefficient extraction formula (Summary D-1.7). Specifically, we will extract the constant term’s coefficient, which corresponds to . We extract by computing the following:
Besides implementing the homomorphic MUX logic gate used during blind rotation (§D-1.8.4), it is possible to leverage the LUT polynomial to implement other homomorphic logic gates such as AND, NAND, OR, XOR, etc. When implementing these gates, each ciphertext is an encryption of a single-bit plaintext (or several bits can be bundled up in a linear combination formula and be processed simultaneously by using LUT). Suppose , , , , , and we encode the gate input into LWE plaintext as , and , and the maximum (accumulated) noise .
Decoded | Encoded |
|
| Bootstrapping |
|
|||||||||
0 | 0 | constant term’s coeff. is | 0 | |||||||||||
0 | 1 | constant term’s coeff. is | 0 | |||||||||||
1 | 0 | constant term’s coeff. is | 0 | |||||||||||
1 | 1 | constant term’s coeff. is | 1 | |||||||||||
Table 5 is a programmable bootstrapping design for an AND logic gate. For this application, we define the LUT polynomial as . The LUT polynomial maps one half of the plaintext domain to , while the other half to (as the terms wrap around the boundary of ). In this design setup, each bit is separately encrypted as independent TFHE ciphertext. Gate inputs 0 and 1 are encoded as and , respectively. The linear combination (i.e., homomorphic computation formula) for an AND gate is . Its output is positive if both inputs are positive (i.e. , in which case the blind rotation will rotate to the left by positions and the constant term’s coefficient will be . Thus, the output of blind rotation and coefficient extraction will be with a reduced noise, which is an encoding of . This design can tolerate the maximum noise of . To endure bigger noises, we should increase and .
Note that the AND gate’s LUT layout is negacyclic, which is a special case, thus we could use the entire coefficient states in for the AND gate mapping function’s outputs, by leveraging ’s innate property of negacyclic rotation. However, in many use cases, the LUT layout is not necessarily negacyclic like this AND gate example. Even our noise bootstrapping’s LUT layout (§D-1.8.1) was not negacyclic, but a unity function (as it simply removes the noise). Thus, for most use cases, we need to use only out of plaintext space to avoid more than rotations of (§D-1.8.3).
Besides the AND gate, other logic gates can be built in a similar manner, each of which is based on a different linear combination formula and LUT layout.
Division: TFHE does not support direct division of plaintext numbers of any size. This is because TFHE’s LWE vector elements are in the ring, where each element does not necessarily have a multiplicative inverse , which makes it hard to multiply to the target number to divide. Instead, division can be implemented as binary division based on the gates implemented by gate bootstrapping. To support binary division, each plaintext has to be a single bit and encrypted as an independent ciphertext. Or multiple bits can be bundled up and processed concurrently by designing a linear combination formula, similar to the linear combination that we designed for processing 2 input bits of an AND gate.
Homomorphic encryption can be applied to the neurons of deep neural networks, in which each neuron is generally comprised of two steps of computation:
TFHE can homomorphically compute the 1st step’s linear combination formula: as , which can be implemented as ciphertext addition (§C-1) and ciphertext-to-plaintext multiplication (§C-3).
However, the 2nd step’s non-linear functions cannot be expressed as addition and multiplication of ciphertexts. To address this issue, the activation function can be evaluated as a programmable bootstrapping, such that the output of the bootstrapping matches or (or is similar) to the output of the activation function. If we use bootstrapping at the 2nd step, noises can be refreshed at the end of every neuron, thus we can potentially handle neural networks of any depth without worrying about the noise growth.