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.
Hello, I would like to know if there has been any update on reducing the size of the CKKS ciphertext.
Thank you.
Could you clarify your question? What specifically are you asking? At a high level, a CKKS ciphertext can be encrypted using one prime and then expanded using CKKS bootstrapping, as described by @Pro7ech Also, the complex domain encoding could be used to achieve additional 2x speed-up. In total, this would get close to the factor of 1x (the remaining expansion is the ratio in bits between the scaling factor and actually achieved precision as the CKKS approximation errors erase information in 10 or so least significant bits).
I am encrypting a single value (5.1), no multiplication is needed, no further encoding is needed and the scaling factor was reduced to 3. Here is my output
CKKS scheme is using ring dimension 8192
Public Key: 0x2…3f2…d440
Private Key: 0x2…3f2…c460
Input x1: (5.1, … ); Estimated precision: 3 bits
However, the ciphertext is so large and would take up the entire memory of the device. How can I make the ciphertext smaller? Is there a way to edit the security parameter to 32-bit or 64-bit ( if that would help) or probably avoid encoding altogether since it is not required for this instance?
If I may add, values from multiple devices can be aggregated and amortized later on an external computation server if needed.
You have to encode data to encrypt it under CKKS and be able to compute on it homomorphically. Note that in OpenFHE, you can also perform mixed-type operations like ciphertext-plaintext operations where the plaintext constants do not need to be encoded or encrypted if they are scalars (that is, not vectors).
You can reduce the ring dimension manually to reduce the ciphertext size but this will reduce the security level (<128-bit default security level in OpenFHE). I highly discourage doing so if you are going to deploy your solution. Use the following at your own risk!
parameters.SetSecurityLevel(HEStd_NotSet);
parameters.SetRingDim(4096); // you can even set this to lower power of 2 values
Thank you. Will do just that.