Hello,
I have a question about CKKS ciphertext-plaintext multiplication. Can I set different scale factors for ciphertext and plaintext? Here the plaintext is encoded by a vector with N/2 slots. If it can work, does the plaintext scale factor have limits? For example, the scale factor must be bigger than a value.
I tried scale 2^30 for ciphertext, and scale 2^0 (No scale) for plaintext in SEAL, after decrypting and decoding, the result became a zero vector. Then I test scale 2^8 for plaintext, it was still zero vector, and then scale 2^10, the result was right. How did this happen?
In theory there is no restriction on the scale of the plaintext. You should be able to encode it with the scale you want and multiplying with the ciphertext should update the ciphertext scale accordingly.
But that’s in theory. In practice encoded vectors are discrete.
The canonical embedding has a norm that is on average slightly smaller than the norm of the encoded vector (for a vector uniformly distributed in an interval). This is something I had observed when parameterizing the bootstrapping and it is due to the distribution and norm of the roots.
Meaning that if you encode a vector with zero mean and small variance, it is very likely that its norm is smaller than your small scaling factors. So when you scale it by 2^8 (or 2^0), and then discretize it, you will get a too small or zero vector and lose most or all information about the original one.
@jasmine It is best to think of the scaling factor as a measure of precision. For the plaintext (I will initially ignore the CKKS SIMD encoding), you take a float, scale it by the 2^{pt} (where pt corresponds to plaintext scaling), and then round it. The fractional part after the decimal point gets lost (rounded to next integer). For example, if you have 0.12345 and apply a scaling factor of 2^8, you get something like round(0.12345 * 2^8) = 32. If you convert it back to float, you will get 1/8 = 0.125. So 0.12345 became 0.125 just because you used low precision.
CKKS encoding adds extra error on top of this that needs to be accounted for (as mentioned by @Pro7ech ). So you want to reserve about extra \log \sqrt{n} bits.
In the case of ciphertexts, you need to use a larger precision to offset the approximation error introduced by CKKS encryption noise, which is higher than the CKKS encoding error. So when we scale ciphertexts by 2^{ct}, we have to use ct > pt (but ct and pt can be the same in practice for simplicity and set to the larger value, i.e., ct).
@ypolyakov@Pro7ech I’m trying to get deep in FHE in particular CKKS, and all this of errors, the use of norms to compare encoded vectors in this context, reserve bits to keep precision are topics that I can’t understand well. Can you give me some key words or recommendations to understand the concepts in a cryptographic general way so then I can understand it in CKKS?