Large Serailized Objects in Threshold Key Generation

FHE Use Cases
1

I set up a 2 party Threshold FHE system and in the key generation step, I noticed that the data that needs to be sent from one party to the other is very large. In my case using security level HEStd_256_classic results in a ~160,000,000 length binary string when serializing the EvalSumKeyMap. Is that expected, or is there something I could be doing incorrectly that’s resulting in this large serialization? I tried to follow the Palisade Example as reference.

Thanks

2

The EvalSumKeyMap contains a set of rotation keys, one for every power of two rotation (in order to do the summation using a binary tree approach. up to the entire ring size for BGV/BFV or 1/2 the ring size for CKKS. I believe you can specify a batch size that restricts this down to a a smaller power of two in the EvalSum call, but not sure if that can be specified when you generate the EvalSumKeyMap. Are you required to use EvalSum in your computations, and are you using all the slots in the ciphertexts?

3

Thanks for the reply! One of the main function of the system is to provide a total sum of all the encrypted data, so I’m using EvalSum to sum up all of the data points. There can be thousands of data points and I had just put them in one batch, using all the slots. So a lower batch size help with the EvalSumKeyMap size then? I could probably re-work the caclulations to do a sum of sums on smaller batches of Ciphertexts. I’ll give that a try and post back with the results.