Reducing size of ciphertext in PRE application

Hi !

I am currently developing a Java application requiring PRE capabilities.
The data that needs to be encrypted and re-encrypted between the users is a lightweight JSON String.
For the first question, I’m trying out BGV and BFV schemes for the moment and the size of the output strings seems to be around 2 Mb on average, Is it possible to reduce the size of the ciphertext and if yes which parameters could influence the size on both schemes ?
For the second question, which schemes of PRE works better for encrypting and re-encrypting small lightweight JSON strings ?

Thanks for your attention!

My first question is what is the maximum “payload” size you need? That will be significant
In general both of the B*V schemes let you encrypt a vector of integers, modulo the plaintext size p.
the length of the vector is the ringsize and the #bits per integer that are useful is log2(p) rounded down
so for example, if the security settings give you ringsize of 32k, you have 32k pts
p = 2 give you 32k bits or 4k bytes of storage
p = 2^16+1 gives you 32k shorts or 64k bytes of storage
the former is faster to re-encrypt, the latter stores 16x more information for the same ring size.
both will give the same general serialization size of CT.

My second question is what security you need? selecting lower security generally gives smaller CT.
Whatever you do though, if you manipulate the various parameters yourself, rather than use one of the homomorphic_encryption.org standard settings, you may be running with a reduced security.

My third question is do you need any HE computation? if not then you will generally get a minimized size ciphertext in BGV

Basically json is highly inefficient for data transfer – we use it exclusively for when humans need to read the data. think about it, you are converting a 64bit integer into a stream of ascii characters, then adding other bytes for things like “,” “{}” etc. However,
if the residue moduli that are being generated are relatively small then the number of decimal digits will be reflected in this and your json size is smaller.

I know this is a lot of things to consider , and some conflict. we are in the process of publishing some current research in PRE that we recently did, and we will be publishing the code in the openFHE repo group, hopefully in the next two or three months.

Dave Cousins

Thank you for the detailed explanation.
I tried to play on the Plaintext Modulus p for various settings but the only accepted value for string encoding is 256. I also tried to select lower security levels (HEStd_128_classic, Ringsize 1024, 2048) while choosing the values from the standard but the choice is limited since it kept asking me to increase the Ringsize to meet security requirements.
the only success I got encrypting JSON strings was using the BFV scheme with 128-bit securtiy level and a Ringsize of 4096 (the size was shrunk down by almost half).
I need to encrypt a string of max size 300 (that is why I tried to reduce the Ringsize to 1024 since the largest possible plaintext for string encoding is the size of the Ring).

I dont need any HE computation on the ciphertext except the re encryption.

What do you think is the right approach to select the parameters since the plaintext modulus is fixed to 256 (to be able to encrypt strings) and the Ringsize to a minimum of 4069 for BFV scheme at 128-bit security level ?
or is there other schemes you would recommend for encrypting light weight strings ?

Hi @omarsomey

If you want to use a custom plaintext modulus (instead of the hard-coded 256 for the string encoding), you can use the coefficient packed encoding. In this encoding, you can select any plaintext modulus p between 2 and 2^{32}-1 and encode characters or bits of the corresponding numerical representation mod p. To see examples, just search for MakeCoefPackedPlaintext in the OpenFHE code base (there are several examples). You can also check PKE Encoding documentation — OpenFHE documentation for additional information. I also suggest watching the correspond PALISADE/OpenFHE webinar to learn more about the encoding: Homomorphic Encryption for OpenFHE Users – OpenFHE.org

Note that in this case, you would encode all characters using their numerical representation, which should be done in your application.