Security Notes for Homomorphic Encryption
==================================================

All homomorphic encryption schemes implemented in OpenFHE are IND-CPA secure, and hence are expected to be used under the honest-but-curios (a.k.a., semi-honest) model. In this model, the adversary cannot corrupt/tamper with ciphertexts (and perform related active attacks) but can only use the API of OpenFHE to perform valid operations.

Notes specific to the CKKS scheme
-----------------------------------

Li and Micciancio (https://eprint.iacr.org/2020/1533, EUROCRYPT '21) showed that the IND-CPA model may not be sufficient for the CKKS scheme in some scenarios because a decryption result can be used to perform a key recovery attack. This attack applies to the setting where decryption results need to be shared between multiple parties, e.g., in the the threshold FHE setting. To mitigate the Li-Micciancio attack, we extended the original CKKS to a stronger adversarial model where decryption results may still be shared between multiple parties. By default, OpenFHE chooses a configuration where a relatively large number of decryption queries of the same or related ciphertexts can be tolerated. The lower bound for the tolerated number of such decryption queries is N_d = 128 (but in practical computations, N_d is at least 10,000). We consider this default setting sufficient to prevent passive attacks (where a normal homomorphic encryption computation protocol is followed).

In scenarios where an even stronger adversarial model is needed, the user can increase the number of shared decryptions of the same or related ciphertexts to a higher number by increasing the `CKKS_M_FACTOR` CMake parameter (a compile-level flag). The minimum number of decryption results in this case becomes N_d x (`CKKS_M_FACTOR` + 1) / 2. Please note that increasing `CKKS_M_FACTOR` from the default value of 1 will decrease the precision of CKKS ciphertexts by 0.5 x (log2(`CKKS_M_FACTOR` + 1) - 1) bits. Hence increasing `CKKS_M_FACTOR` is only suggested when a stronger adversarial model is needed.

Both of the mitigations above do not achieve provable IND-CPA-D security (new model introduced by Li and Micciancio), as shown in https://eprint.iacr.org/2022/816 (CRYPTO '22). To achieve provable security, we added a two-phase approach described in the [CKKS noise flooding article](https://github.com/openfheorg/openfhe-development/blob/main/src/pke/examples/CKKS_NOISE_FLOODING.md). The reader is refered to the article for more details.

Notes specific to EvalSum and EvalInnerProduct calculations
-----------------------------------

`EvalSum` may expose extra information in other (non-result-designated) slots if decryption is done immediately after this, as illustrated in https://openfhe.discourse.group/t/evalsum-exposes-more-then-just-sum/2208. 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](https://openfhe.discourse.group/t/evalsum-exposes-more-then-just-sum/2208) (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.

Note that `EvalSum` is used as a subroutine in `EvalInnerProduct`. Hence, everything mentioned here equally applies to `EvalInnerProduct`.
