Hi！
I’m working on an encrypted database and want to store CKKS encrypted ciphertext in the database. But for a double type of data, the encrypted ciphertext has a size of 180,000 bits.
I’m wondering how to modify to reduce it. Regarding ckks encryption, I only require that the calculation of data less than 10,000 can be completed, the precision of floating point numbers is 4 digits after the decimal point, and the multiplication depth is less than 2.The calculations I perform are all real number calculations.
Can it be shortened to dozens of bytes?
Ciphertext expansion is a known cost with FHE.
There are various research level approaches to reduce ciphertext but I think you are talking about what you can do right now.
First, ciphertext size in CKKS are driven by three main things: native word size, ringsize, and multiplicative depth. these are ususally determined by the parameters selected when building the crypto context, and we recommend using one of the standard settings based on your security requirements.
You already fixed your depth to a good small number. ciphertext size increases ~linearly with depth.
as for wordsize, the default for OpenFHE is 64bits as it is most efficient for most CPUs.
the ringsize is a result of the parameters used. You can make a call to determine what it is.
Here is the big thing: You can store up to ringsize/2 data points in a vector in a single ciphertext. storing one value only does not save any space. All math is one element wise on this vector.
I do not know of much you can do to reduce the storage requirements. If your use case is allowed to determine the index in the clear, then you can encrypt many rows of the data into one vector and store it in a single ciphertext.
Sorry, it’s been a long time, reposting this question. The scenario I’m researching is on the public cloud, where the client’s data is encrypted into ciphertext and stored in the cloud. The calculation and query of ciphertext data need to be completed in the cloud.In this scenario, ciphertext inflation is a serious problem. Recently I’m learning about the Block Cipher FHE，like ccs’2022 Chaghri - A FHE-friendly Block Cipher.It seems to solve the problem of ciphertext inflation.
I wonder if there is an implementation about the block cipher FHE.
Hi
This is a very active area of research.
Dozens of bytes is not possible. Even if you forced the parameters to give you that, it translates into extremely small ring sizes, so there would be no security at all.
We do not have an implementation of this block cipher. There are a few examples of such FHE friendly ciphers for transciphering in the literature, i.e. Encrypt in cypher ->send msg-> encrypt in FHE → decrypt cipher within FHE-> FHE encryption of data. But, all these are all quite new, and have not been extensively vetted, so caveat emptor.
Alternatives solutions that have been used combine TEE with FHE, for situations where that security model is trusted/valid. See PALISADE / Graphene-PALISADE-SGX · GitLab for a PALISADE-based example.
Hello！
I don’t konw why to combine TEE with FHE.If we believe the security of TEE,we can achieve all query in TEE. And the performance cost in FHE is bigger than the performance in TEE.If we don’t believe the secure of TEE,the combination destroys the FHE security.So,I’m puzzled on why to combine them.
I also want to know how to reduce the size of ckks ciphertext, As you say that if your use case is allowed to determine the index in the clear, then you can encrypt many rows of the data into one vector and store it in a single ciphertext.Can you give an example？
If you use seeded encryption, leverage the complex domain (or use no batch encoding) and encrypt with one prime, you can get an amortized ciphertext expansion close to 1.
You will then need to use bootstrapping to bring the ciphertext to a higher level, and homomorphically encode it if batching is needed.