Unexpected Behavior with SetScalingModSize and FLEXIBLEAUTOEXT in BGV Scheme

Library Questions
,
1

Hello OpenFHE Team,

I’ve encountered a unexpected behavior in the library and wanted to report it.
Here is a minimal snippet of the code that reproduces the issue:

#include "openfhe.h"

using namespace lbcrypto;
using namespace std;

int main(void)
{
  CCParams<CryptoContextBGVRNS> parameters;
  parameters.SetRingDim(32768);
  parameters.SetMultiplicativeDepth(2);
  parameters.SetPlaintextModulus(65537);
  parameters.SetFirstModSize(52);
  parameters.SetScalingModSize(50);
  parameters.SetSecurityLevel(HEStd_256_classic);
  parameters.SetScalingTechnique(FLEXIBLEAUTOEXT);

  CryptoContext<DCRTPoly> cc = GenCryptoContext(parameters);
  cc->Enable(PKE);
  cc->Enable(KEYSWITCH);
  cc->Enable(LEVELEDSHE);
  return 0;
}

When executed on OpenFHE version 1.0.4, this code results in a crash with the following output:

floating point exception (core dumped)

And when I change it to the latest version (OpenFHE v1.1.3), it throws the following exception:

terminate called after throwing an instance of 'lbcrypto::OpenFHEException'
  what():  NativeIntegerT ComputeMu: Divide by zero

The program terminates normally if the ScalingTechnique is changed to something else, the scheme is switched to BFV/CKKS, or if SetScalingModSize is not called.

Could you please clarify if using SetScalingTechnique with the BGV scheme is incorrect or if there might be another issue at play?

Thank you for your attention to this matter.

2

Thank you. FLEXIBLEAUTOEXT automatically selects all parameters. So these parameters should not be allowed to be configured for this mode. We will create an issue and fix this in the next release (v1.1.5).

1 Like
3

Thank you for your response. I have one more related question. Are these parameters also prohibited from being configured in FIXEDAUTO and FLEXIBLEAUTO modes? I found that the two codes below also cause a floating point exception (core dumped) crash in the latest version (v1.1.4), and I’m curious if it’s for the same reason.

int main(void)
{
    CCParams<CryptoContextCKKSRNS> parameters;
    parameters.SetRingDim(32768);
    parameters.SetMultiplicativeDepth(2);
    parameters.SetPlaintextModulus(65537);
    parameters.SetFirstModSize(20);
    parameters.SetScalingModSize(19);
    parameters.SetSecurityLevel(HEStd_256_classic);
    parameters.SetScalingTechnique(FIXEDAUTO);

    CryptoContext<DCRTPoly> cc = GenCryptoContext(parameters);
    cc->Enable(PKE);
    cc->Enable(KEYSWITCH);
    cc->Enable(LEVELEDSHE);
    return 0;
}

int main(void)
{
    CCParams<CryptoContextCKKSRNS> parameters;
    parameters.SetRingDim(32768);
    parameters.SetMultiplicativeDepth(2);
    parameters.SetPlaintextModulus(65537);
    parameters.SetFirstModSize(17);
    parameters.SetScalingModSize(17);
    parameters.SetSecurityLevel(HEStd_256_classic);
    parameters.SetScalingTechnique(FLEXIBLEAUTO);

    CryptoContext<DCRTPoly> cc = GenCryptoContext(parameters);
    cc->Enable(PKE);
    cc->Enable(KEYSWITCH);
    cc->Enable(LEVELEDSHE);
    return 0;
}
4

All BGV modes compute all moduli using the MultiplicativeDepth, EvalAddCount, and EvalKeyswitchCount supplied by the user. So we should also throw an exception for the examples you added. Will will do this as part of the same issue.

1 Like
5

Thank you for your response.

I just have a quick question

Does this hold in CKKS? I’m asking because the crashes I mentioned for the two pieces of code are occurring within CKKS. (Please ignore the line with parameters.SetPlaintextModulus(65537);)

6

It is a similar issue: the plaintext modulus is not used by CKKS. The high-level idea is that we will add scheme-specific validation of input parameters to handle all these situations.

1 Like