EvalSum exposes more then just sum

Library Questions
1

Action:

Running example file threshold-fhe.py, (openfhe-python/examples/pke/threshold-fhe.py at main · openfheorg/openfhe-python · GitHub)

Actual result:

Output of EvalSum on plaintext3 (2, 2, 3, 4, 5, 6, 7, 8, 9, 10, … ) and batch size 16 is(56, 54, 52, 49, 45, 40, 34, 27, 19, 10, … ). For the case of BFV.

Expected result:

I would expect the result to have the correct value on the batch indexes (meaning index 0, 16, etc. - this is as expected), and to have no or random value on non batch index (that is 1,2,3,4…,15,17…).

My reason why it is not good:

This seems like a bug/issue because of which the final/last decrypting party can know about all the values before the sum. Such as in the example above the sum is 56, but on the next index there is value 54, which means before the sum there was value 2 at that index. Which expose the entire plaintext before the EvalSum.

Suggested solution:

Make use of random number generator module to automatically add random noise to the value after the sum is calculated (except of the indexes of batch)

Let me know if you need help with reproducing it or if I am missing something. I am using the python wrapper, so I guess not all C methods are available to use as workaround for me.

2

It is correct that EvalSum may expose extra information in other (non-result-designated) slots if decryption is done immediately after this. There are different ways to clear this noise (which at this time is the responsibility of the application developer rather than the library), depending on whether more computations are performed.

For BFV, random noise can be added as suggested in the question (there is a method AddRandomNoise in OpenFHE that can be used for this purpose) as long as no computations that may change the main results are applied after this. Note that for CKKS, a much larger mask would need to be used to make this secure (which would not be efficient).

In more general cases, one can multiply the result by a binary vector with 0’s and 1’s (where 0’s correspond to the slots that need to be cleared). This consumes a level but works for any case, e.g., when the results need to be prepared for a subsequent matrix multiplication (where ``good’’ values also need to be replicated) or when we deal with CKKS.

Overall, this is a good example where FHE applications should be written with care. Of course, the library could always multiply by a binary mask of 0’s and 1’s (after every application of EvalSum), but this performance penalty could be excessive in many cases.

We will add an article to the next version of OpenFHE (v1.5) providing some guidelines on how such inadvertent leakage can be avoided by adding a random mask or multiplying by a binary mask. I’ve created an issue for this: Add an article on the leakage risks of operations like EvalSum · Issue #1085 · openfheorg/openfhe-development · GitHub

1 Like