This subsection will explain how the RNS primitives we have learned so far are used to handle FHE operations for RNS-based ciphertexts in BFV, CKKS, and BGV.
In BFV, CKKS, and BGV, ciphertext-to-plaintext addition, ciphertext-to-ciphertext addition, and ciphertext-to-plaintext multiplication are performed by only involving modulo additions and multiplications among polynomial coefficients. Therefore, we can represent each polynomial coefficient as an RNS residue vector and compute coefficient-wise additions and multiplications by using RNS-based addition and multiplication of residues as explained in Summary A-13.1 (§A-13.1). For example, suppose we have the following two polynomials and :
In the RNS-variant FHE schemes, we express each polynomial’s each coefficient as an RNS residue vector as follows:
# for
# for
Given the above RNS setup, when we add or multiply two polynomials, each coefficient-to-coefficient addition is computed as element-wise additions of two RNS residue vectors as follows:
# where ,
Similarly, each coefficient-to-coefficient multiplication is computed as element-wise multiplications of two RNS residue vectors as follows:
Using the above isomorphism, we can efficiently compute ciphertext-to-plaintext addition, ciphertext-to-ciphertext addition, and ciphertext-to-plaintext multiplication of big polynomial coefficients (e.g., 1000 bits big) based on small RNS residues (e.g., 30 bits each).
In BFV or CKKS, an RNS-based ciphertext’s key-switching operation from is performed by computing the following formula in RNS vectors:
In the above formula, the computation of can be performed by using (Summary D-5.9 in §D-5.9), after which can be added to it by using regular RNS-based addition.
Similarly, in the case of the BGV, an RNS-based key-switching operation on a ciphertext from is performed by computing the following in RNS vectors:
In BFV or CKKS, an RNS-based ciphertext’s input slot rotation is performed by computing the following formulas in RNS vectors:
Step 1 is equivalent to re-positioning the coefficients within each polynomial and flipping their signs whenever they cross the boundary of the -th degree term. This step can be done with RNS-based coefficients by moving around each set of RNS residue vectors as a whole whenever the coefficient they represent is re-positioned to a new degree term, and flipping the signs of the residues in the same RNS vector altogether whenever their representing coefficient’s sign is to be flipped. Step 2’s RNS-based key switching can be done in the same way as explained in the previous subsection (§D-5.10.2).
Similarly, in BGV, an RNS-based ciphertext’s input slot rotation is performed by computing the following formulas in RNS vectors:
We can compute the above formulas in RNS by using the same strategy explained for BFV or CKKS.
BFV’s ciphertext-to-ciphertext multiplication (Summary D-2.7.5 in §D-2.7.5) comprises ModRaise polynomial multiplication relinearization rescaling, where the order of relinearization and rescaling can be swapped. In RNS-based ciphertext-to-ciphertext multiplication, we will swap the order of these two steps. The procedure is as follows: (1) ModRaiseRNS from ; (2) polynomial multiplication; (3) constant multiplication by ; (4) ModSwitch from ; (5) FastBConvEx from ; and (6) relinearization. Among these, step corresponds to the rescaling operation. We will explain how each of these steps works.
Let be a new RNS base where so that is large enough to prevent a multiplied scaled plaintext in ciphertexts (i.e., ) from exceeding its allowed limit (Summary D-2.3 in §D-2.3) during ciphertext-to-ciphertext multiplication. is also added for exact fast base conversion to be performed later. Specifically, we mod-raise the modulus of each polynomial coefficient of ciphertexts and as follows:
, where each coefficient of is either . Decrypting these two (noisy) ciphertexts with the private key would give the following outputs:
# where is the -overflows of the decryption process
Compute , whose decryption relation is as follows:
Step are equivalent to rescaling the plaintext’s scaling factor from as well as switching the ciphertext’s modulus from to . In this step, we multiply to each coefficient of the resulting polynomials from the previous step as follows:
, which is equivalent to a ciphertext encrypting the following plaintext:
We switch the modulus of the ciphertext from to by using ModSwitchRNS as follows:
, which is (almost, considering the rounding error) equivalent to a ciphertext encrypting the following plaintext:
# where is a rounding error caused by treating
We exactly convert the base of the ciphertext from as follows:
, which is equivalent to a ciphertext encrypting the following plaintext:
# all other terms are relatively much smaller than in modulo
Once we have derived the rescaled polynomial triple , the final relinearization step is equivalent to deriving the synthetic ciphertexts and and then computing . is simply , and we can derive by using the DecompMultRNS operation (Summary D-5.9 in §D-5.9). The final ciphertext-to-ciphertext addition of can be performed by using regular RNS addition.
CKKS’s ciphertext-to-ciphertext multiplication (Summary D-3.5.6 in §D-3.5.6) is almost the same as BFV’s, except that CKKS does not need the ModRaise operation in the beginning (because each multiplicative level’s modulus is large enough to hold a multiplied scaled plaintext ). Therefore, CKKS’s RNS-based multiplication is the same as BFV’s except that it does not require step 1 (ModRaise), step 3 (constant multiplication by ), and step 5 (exact fast base conversion). Since a CKKS ciphertext’s scaling factor is approximately the same as the prime modulus factor of each multiplicative level, each ciphertext-to-ciphertext multiplication only needs to perform a modulus switch to a lower level.
BGV’s ciphertext-to-ciphertext multiplication (Summary D-4.8 in §D-4.8) is almost the same as CKKS’s, except that BGV uses its own modulus switch ( as described in Summary D-4.7 in §D-4.7) during the rescaling step. Therefore, BGV’s RNS-based ciphertext-to-ciphertext multiplication is the same as CKKS’s, except that ModSwitchRNS is replaced by .
BFV’s original bootstrapping procedure (Summary D-2.11.7 in §D-2.11.7) is as follows: (1) modulus switch from ; (2) homomorphic decryption; (3) CoeffToSlot; (4) EvalExp; (5) SlotToCoeff; and (6) re-interpretation.
However, in RNS, we cannot mod-switch to because RNS’s base moduli have to be co-prime to each other, whereas the factors of are not. To avoid this issue, RNS-based BFV’s bootstrapping instead performs the following: (1) ModRaiseRNS from , where is an auxiliary base; (2) coefficient multiplication by ; (3) ModSwitchRNS from ; (4) FastBConvEx from ; (5) homomorphic decryption to adjust the scaling factor of the plaintext; (6) CoeffToSlot; (7) EvalExp; (8) SlotToCoeff; and (9) re-interpretation. The detailed procedure is described as follows:
Input: The input BFV ciphertext to bootstrap is , which would decrypt to:
# where
Mod-raise ciphertext to , which would decrypt to:
# where is the FastBConv + SmallMont error, and ’s coefficients are either
Multiply the coefficients of by to update the ciphertext to , which would decrypt to:
Mod-switch the ciphertext to , which would decrypt to:
# is a small rounding error
Exact fast base conversion of to , which would decrypt to:
Now, we have the ciphertext . We do homomorphic decryption by using the encrypted private key , where . The output is .
Theoretically re-interpret the ciphertext without any additional mathematical computation. The ciphertext is mathematically the same as:
# since , and
.
CKKS’s original bootstrapping procedure (Summary D-3.13.7 in §D-3.13.7) is as follows: (1) Modraise; (2) homomorphic decryption; (3) CoeffToSlot; (4) EvalExp; (5) CoeffToSlot; (6) Re-interpretation. In the RNS-based CKKS bootstrapping, we perform ModRaiseRNS at step 1, and all other steps are computed by using regular RNS-based addition and multiplication operations. Step 1’s ModRaiseRNS operation generates a noise (where using SmallMont) for each polynomial coefficient during FastBConv. Therefore, step 2’s homomorphic decryption outputs , where represents the aggregation of all coefficient noise terms which are multiplied with the -overflow noises generated by FastBConv and SmallMont. The term gets eliminated by step 4’s EvalExp which performs approximated modulo reduction based on a sine-graph evaluation whose period is .
BGV’s original bootstrapping procedure (§D-4.11) is as follows: (1) modulus switch from ; (2) ciphertext coefficient multiplication by ; (3) ModRaise; (4) CoeffToSlot; (5) EvalExp; (6) homomorphic multiplication by ; (7) SlottToCoeff; (8) noise term re-interpretation. Given this procedure, the RNS-based bootstrapping steps are as follows:
Suppose the target BGV ciphertext to bootstrap is , where the plaintext modulus (i.e., noise scaling factor) is .
# since
After the above steps, the remaining steps (i.e., CoeffToSlot, EvalExp, homomorphic multiplication by , SlotToCoeff, and re-interpretation) can be performed by regular RNS-based addition and multiplication operations.
When RNS techniques are used in FHE operations, the noise generated by FastBConvExRNS, ModRaiseRNS, and ModSwitchRNS is directly added to each coefficient of the ciphertext polynomials and . Since the decryption relation is , even the noise added to the coefficients of the polynomial gets multiplied by a large factor due to the polynomial multiplication with . Therefore, it is important to always ensure to reduce the generated noise of each FastBConvExRNS by using it with SmallMont.
We provide a Python script implementing the following exemplary RNS primitives: FastBConv, ModRaiseRNS, ModDropRNS, ModSwitchRNS, SmallMont, and BaseBConvEx.