CKKS’s ciphertext-to-ciphertext multiplication is partially different from that of BFV. In the case of BFV, its ciphertext modulus stays the same after each multiplication. On the other hand, CKKS reduces its ciphertext modulus size by 1 after each multiplication (which is equivalent to reducing its multiplicative level by 1). When the level reaches 0, no more multiplication can be further done (unless we bootstrap the modulus). This difference happens because the two schemes use different strategies in handling their plaintext scaling factors– BFV’s , whereas CKKS’s can be any value such that where is the lowest multiplicative level’s ciphertext modulus. However, both schemes use the similar relinearization technique.
To make it easy to understand, we will explain CKKS’s ciphertext-to-ciphertext multiplication based on this alternate version of RLWE (Theorem B-4.4 in §B-4.4), where the sign of the term is flipped in the encryption and decryption formulas.
Suppose we have the following two (CKKS) RLWE ciphertexts:
, where
, where
RLWE ciphertext-to-ciphertext multiplication is comprised of the following 2 steps:
We will explain each of these steps.
The 1st step of RLWE ciphertext-ciphertext multiplication is to find a way to express the following congruence relation:
in terms of our following known values: . First, notice that the following is true:
, because encrypting and decrypting the multiplication of two plaintexts should give the same result as decrypting two encrypted plaintexts and then multiplying them. As the encryption and decryption functions cancel out, we get the following:
# where , where is small enough to be eliminated upon decryption, and and will be scaled down to and upon modulus switch later, becoming small enough to be enough to be eliminated during decryption
Remember from §B-4.4 the following:
Thus, the above congruence relation can be rewritten as follows:
# since
In the final step above, we converted into , where is the synthetic RLWE ciphertext encrypted by . Similarly, our next task is to derive a synthetic RLWE ciphertext such that . The reason why we want this synthetic ciphertext is that we do not want the square of (i.e., ), because if we continue to keep , then over more consequent ciphertext-to-ciphertext multiplications, this term will aggregate exponentially growing bigger exponents such as , which would exponentially increase the computational overhead of decryption. In the next subsection, we will explain how to derive the synthetic RLWE ciphertext such that .
As explained in BFV’s ciphertext-to-ciphertext multiplication (§D-2.7.3), relinearization is a process of converting the polynomial triplet , which can be decrypted into using and as keys, into the polynomial pairs , which can be decrypted into the same by using as key. In the previous subsection, we explained that we can convert and into simply by viewing and as . The process of converting into is exactly the same as the technique explained in §D-2.7.3, which applies the gadget decomposition (§A-6.4) on and computes an inner product with the RLev encryption (§B-5) of . Specifically, we compute the following:
# the scaling factors of are all 1
# where
# because (where is the noise embedded in
Finally, we get the following relation:
, where
In the next subsection, we introduce another (older) relinearization technique.
At the setup stage of the RLWE scheme, we craft a special pair of polynomials modulo as follows:
is called an evaluation key, which is essentially a RLWE ciphertext of encrypted by the secret key without any scaling factor . Remember that our goal is to find a synthetic RLWE ciphertext such that decrypting it gives us , that is: . Let’s suppose that . Then, decrypting gives us the following:
But unfortunately, , because (as is not necessarily a small number).This is because , can be any arbitrary value between .
To solve the above problem, we modify the evaluation key as a set of polynomials in big modulo as follows:
# where is some large integer power of 2, is the largest modulo before any relinearization
is essentially an RLWE ciphertext of encrypted by . We can derive the following:
(for some integers )
Note that
(for some integer )
Now, let’s multiply to each component of as follows:
Now, we switch the modulus of this RLWE ciphertext from based on the technique in §C-4.5:
Now, we finally got which is in the form of RLWE ciphertext modulo . Remember that our goal is to express as a decryption of RLWE ciphertext. If we treat as a synthetic RLWE ciphertext and decrypt it, we get the following:
# where is treated as a synthetic RLWE ciphertext
#
# ,
As shown in the above, decrypting gives us . Therefore, we reach the following conclusion:
, where
Therefore, we finally get the following congruence relation:
, where
Our last step of ciphertext-to-ciphertext multiplication is to convert into , because if the result of ciphertext-to-ciphertext multiplication is , then for consistency purposes, the resulting RLWE ciphertext is supposed to be:
We will explain this process in the next subsection.
To convert into , we cannot simply divide the ciphertext by , because as explained in §A-1.2.2, modulo arithmetic does not support direct division. Multiplying the RLWE ciphertext by (i.e., an inverse of ) does not work either, because the only useful property we can use for inverse multiplication is: . If an inverse is multiplied to any other values other than its counterpart, the result is an arbitrary value. For example, if is multiplied to a noise (i.e., ), then the result can be a very huge value. Thus, multiplying the RLWE ciphertext by does not help due to the unpredictable result of the noise term.
The safest way to convert into is modulus switch (§C-4.5), which is essentially modulo rescaling (§A-12). For this to work, the RLWE setup stage should design the ciphertext domain as , where is denoted as the level of multiplication, and (which is important for the accuracy of homomorphic modulo reduction during bootstrapping in §D-3.13). Upon each ciphertext-to-ciphertext multiplication, we switch the modulus of the RLWE ciphertext from , which effectively converts the plaintext’s squared scaling factor (in ) into (in ). Once the RLWE ciphertext’s level reaches 0 (i.e., ciphertext modulus ), we cannot do any more ciphertext-to-ciphertext multiplication, in which case we need a special process called bootstrapping to re-initialize the modulus level to .
However, one problem with this setup is that will be a huge number. Performing homomorphic addition or multiplication over modulo is computationally expensive. To reduce the overhead of ciphertext size, we use the Chinese remainder theorem (§A-13): given an integer where is a multiplication of co-primes such that , the following congruence relationships hold:
, where , and
In other words, can be isomorphically mapped to a vector of smaller numbers each in modulo , addition/multiplication with big elements in modulo can be done by using their encoded smaller-magnitude CRT vectors element-wise, and later decode the intended big-number result. By leveraging this property, we design the CKKS scheme’s maximal ciphertext modulus as , where is the maximum multiplicative level, , and all other . Then, whenever reaching from the -th to the next lower -th multiplicative level, we switch its modulus from to as follows:
, # where all are prime numbers, to ensure the scaled plaintext during homomorphic operations never overflows the ciphertext modulus even at the lowest multiplicative level, and all other
, where each
, where each
The above update of to effectively changes to as follows:
, where each
# If we treat as , the rounding error slightly increases the noise to , while the decryption of outputs the same
Note that after the rescaling, the plaintext scaling factor of is also updated to . Meanwhile, and stay the same as before.
After we switch the modulus of the ciphertext from by multiplying to and , the encrypted original plaintext term will become , where , because as explained before, we chose such that . Therefore, , where , which becomes part of the noise term of the modulus-switched (i.e., rescaled) new ciphertext .
The benefit of this design of the CRT (Chinese remainder problem)-based ciphertext modulus and rescaling is that we can isomorphically decompose the huge coefficients (bigger than 64 bits) of polynomials in ciphertexts into -dimensional Chinese remainder vectors (Theorem A-13.2 in §A-13) and perform element-wise addition or multiplication for computing coefficients over the small vector elements. This promotes computational efficiency for homomorphic addition and multiplication over a large ciphertext modulus (although the number of addition/multiplication operations increases). This technique is called Residue Number System (RNS). When CRT is used in ciphertexts, the security regarding the ciphertext modulus depends on the smallest and the largest CRT elements.
Initial Scaling Factor Upon Encryption: To support multi-level multiplicative levels (using CRT), we need to modify the generic scaling factor setup presented in Summary B-4.2 (§B-4.2) from to .
Noise Growth: Upon each step of rescaling during ciphertext-ciphertext multiplication, the noise also gets scaled down by (or by at multiplicative level in the case of using CRT). Therefore, if the accumulated noise is smaller than ( in the case of using CRT), running a single ciphertext-ciphertext multiplication operation effectively reduces the noise against growing. However, during each ciphertext-to-ciphertext multiplication, the encrypted (noisy) plaintext is , and rescaling roughly has the effect of dividing this by , which approximately gives us . Because of the term, the noise actually grows compared to before ciphertext-to-ciphertext multiplication. Therefore, ciphertext-to-ciphertext multiplication inevitably increases the noise.
CKKS bootstrapping shares several common aspects with BFV bootstrapping. CKKS’s ModRaise and Homomorphic Decryption steps are equivalent to BFV’s Homomorphic Decryption (without modulo- reduction) step. BFV homomorphically multiplies polynomial and whose coefficients are in with the encrypted secret key whose ciphertext modulus is , which generates the modulo wrap-around coefficient values . Similarly, CKKS coefficients are in with the encrypted secret key whose ciphertext modulus is , which generates the modulo wrap-around coefficient values . However, they use different strategies to handle their modulo wrap-around values. CKKS uses evaluation of the sine function having a period of to approximately eliminate (i.e., EvalExp). On the other hand, BFV uses digit extraction to scale down by and then treats the remaining small as part of the modulo wrap-around value of the plaintext. The requirement of the digit extraction algorithm is that the plaintext inputs should be represented as base- values, and because of this, BFV bootstrapping includes the initial step of modulus switch from , where is used as the plaintext modulus after homomorphic decryption.
Both BFV and CKKS use the same strategy for their CoeffToSlot, SlotToCoeff, and Scaling Factor Re-interpretation steps.
Multiplicative Level: A critical difference between BFV and CKKS is that in BFV, the ciphertext modulus stays the same after ciphertext-ciphertext multiplication, and there is no restriction on the number of ciphertext-ciphertext multiplications. On the other hand, in CKKS, the ciphertext modulus changes from after each multiplication, and when it reaches , no more multiplication can be done, unless we reset the ciphertext modulus to by using the modulus bootstrapping technique (§D-3.13).
Limitation of Noise Handling: Although CKKS’s rescaling during ciphertext-to-ciphertext multiplication reduces the magnitude of noise by , it also reduces the ciphertext modulus by the same amount, and thus the relative noise-to-ciphertext-modulus ratio does not get decreased by rescaling. In order to reduce (or reset) the noise-to-modulus ratio, we need to do bootstrapping (§D-3.13), which will be explained at the end of this section.
To put all things together, CKKS’s ciphertext-to-ciphertext multiplication is summarized as follows:
Summary D-3.5.6 CKKS’s Ciphertext-to-Ciphertext Multiplication
Suppose we have the following two RLWE ciphertexts:
, where
, where
Multiplication between these two ciphertexts is performed as follows:
Compute the following:
, where
,
Switch the relinearlized ciphertext’s modulus from by updating to as follows:
, # where all are prime numbers, to ensure the plaintext during homomorphic operations never overflows the ciphertext modulus even at the lowest multiplicative level, and all other
, where each
, where each
The above update of to effectively changes to as follows:
, where each
# This rounding error slightly increases the noise to , while the decryption of outputs the same plaintext
Note that after the rescaling, the ciphertext modulus changes from , and the plaintext scaling factor of is also updated to . Meanwhile, the plaintext and the secret key stay the same as before.
Swapping the Order of Relinearization and Rescaling: The order of relinearization and rescaling is interchangeable. Running rescaling before relinearization reduces the size of the ciphertext modulus, and therefore the subsequent relinearization can be executed faster.