Is it possible to have batching enabled with BFV with N=1024 and Security of 128 bits

Hello,

I am trying to configure the parameters for BFV such that I have a security of 128 bits, a ring dimension of 1024 and have batching enabled, I intend to do only additions thus I set the multiplicativeDepth to 0. I know the plaintext modulus “t” must be a prime such that t = 1 mod 2N.
I’ve tried many plaintext modulus and it still doesn’t work.

These are my current parameters (which don’t work):
params = fhe.CCParamsBFVRNS()
params.SetMultiplicativeDepth(0)
params.SetSecurityLevel(fhe.SecurityLevel.HEStd_128_classic)

params.SetKeySwitchTechnique(fhe.KeySwitchTechnique.BV)
params.SetPlaintextModulus(65537)
params.SetRingDim(1024)
params.SetScalingModSize(24)
params.SetBatchSize(1024)

Thanks a lot for your help!

Please check Automaticly find a good Plaintext Modulus At a high level, the procedure for finding a plaintext modulus that is compatible with batching is explained on Slide 15 of the FHE integer arithmetic webinar at Homomorphic Encryption for OpenFHE Users – OpenFHE.org

But this is needed only if you want to support component-wise multiplications (what batched encoding typically refers to). In the case of additions only, a different encoding can be used that does not have the constraint you mentioned. For example, p=2 would be allowed. In this case, you would use MakeCoefPackedPlaintext instead of MakePackedPlaintext when encoding the input vectors. See Template Class CryptoContextImpl — OpenFHE documentation for more details (or search for code examples/unit tests in the library).

Thank you for your advices.

So for N=2048 I made it work.

So for N=2048 with plaintext modulus = 2 (coefficient encoding) I have:

  • params = fhe.CCParamsBFVRNS()

    params.SetMultiplicativeDepth(0)

    params.SetSecurityLevel(fhe.SecurityLevel.HEStd_128_classic)

    params.SetPlaintextModulus(2)

    params.SetRingDim(2048)

    params.SetScalingModSize(51)

And for N=2048 with batching, I set plaintext modulus to 40691:

  • params = fhe.CCParamsBFVRNS()

    params.SetMultiplicativeDepth(0)

    params.SetSecurityLevel(fhe.SecurityLevel.HEStd_128_classic)

    params.SetPlaintextModulus(40961)

    params.SetRingDim(2048)

    params.SetScalingModSize(51)

    params.SetBatchSize(2048)

Even though I use no multiplications, I wanna use batch encoding as I noticed that additions are faster when using batch encoding than when using coefficient encoding. Is this behavior normal?

Also I made it work for N=1024 with plaintext modulus 2 (coefficient encoding):

  • params = fhe.CCParamsBFVRNS()

    params.SetMultiplicativeDepth(0)

    params.SetSecurityLevel(fhe.SecurityLevel.HEStd_128_classic)

    params.SetPlaintextModulus(2)

    params.SetRingDim(1024)

    params.SetScalingModSize(25)

But I’ve still not found the right parameters for batching with N=1024, is this even possible?

Based on the “Homomorphic encryption standard” shouldn’t I be able to get at least 128 bit security?

I tried to change the plaintext modulus, but it doesn’t work either, is it a matter of the SetScalingModSize()?

Here is my preliminary code:

params = fhe.CCParamsBFVRNS()
params.SetMultiplicativeDepth(0)
params.SetSecurityLevel(fhe.SecurityLevel.HEStd_128_classic)
params.SetKeySwitchTechnique(fhe.KeySwitchTechnique.BV)
params.SetPlaintextModulus(12289)
params.SetRingDim(1024)
params.SetScalingModSize(25)
params.SetBatchSize(1024)

It should not be the case. Maybe a certain subroutine is used that is not as optimized as in the packed case. It could also be related to how the measurement was done. Make sure this is measured in the single-threaded mode or when OMP is disabled.

The logic for finding the smallest plaintext modulus that supports batching for a given N is not related to LWE security. The constraint is that the plaintext modulus should be a prime congruent to 1 \bmod 2N. For instance, 40961 satisfies both constraints for N=1024. The smallest number satisfying these constraints for N=1024 is 12289.

If it’s not related to LWE security, params.SetPlaintextModulus(12289) should work. Then why when I do:

params = fhe.CCParamsBFVRNS()
params.SetMultiplicativeDepth(0)
params.SetSecurityLevel(fhe.SecurityLevel.HEStd_128_classic)
params.SetKeySwitchTechnique(fhe.KeySwitchTechnique.BV)
params.SetPlaintextModulus(12289)
params.SetRingDim(1024)
params.SetScalingModSize(25)
params.SetBatchSize(1024)

I get an error:
”Ring dimension 1024 specified by the user does not meet the security requirement. Please increase it to 2048.”

While for the same ring dimension, I manage to make it work using coefficient encoding:

params = fhe.CCParamsBFVRNS()
params.SetMultiplicativeDepth(0)
params.SetSecurityLevel(fhe.SecurityLevel.HEStd_128_classic)
params.SetPlaintextModulus(2)
params.SetRingDim(1024)
params.SetScalingModSize(25)

So in the end is the reason that a ring dimension of 1024 can’t have batching?

As Yuriy mentioned, ring dimension 1024 can have batching. The behavior you observe is linked to an error returned by OpenFHE because your parameters do not meet the specified 128 bit of security. You can temporarily disable this security check by replacing params.SetSecurityLevel(HEStd_128_classic); with params.SetSecurityLevel(HEStd_NotSet);.

But does it exist a set of parameters that enable batching with ring dimension 1024 and security of 128 bits which would pass OpenFHE requirements ?

The main issue is that the ciphertext modulus needed to support one multiplication (which is the whole purpose of batching) with plaintext modulus t = 12289 is higher than 27 bits. At a high level, to support one multiplication, the noise bound should be a factor of t^2 (multiplied by regular encryption and polynomial multiplication noise bounds). Even without multiplication, this is still higher than 27 bits.

In summary, the are two (distinct) things here. First, the plaintext modulus of 12289 is compatible with N=1024, but the ciphertext modulus needed to support one multiplication is much higher than 27 bits. As a result, you cannot use batching for N=1024 (even in principle, based on noise estimates) and still achieve 128 bit of security.

Ah I see, thank you very much for your help!