Crashes when firstModSize and scalingModSize are equal in CKKS

Library Questions
1

Hello,

I found that the examples in CKKS producing crash, floating point exception (core dump) , on the latest version (v1.1.4).

Here’s the minimum code snippet of the crash example:

int main(void)
{
  CCParams<CryptoContextCKKSRNS> parameters;
  parameters.SetRingDim(32768);
  parameters.SetMultiplicativeDepth(2);
  parameters.SetFirstModSize(49);
  parameters.SetScalingModSize(49);

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

  return 0;
}

In this case, {firstModSize, scalingModSize} is {49, 49}.
Also I’ve found that when {firstModSize, scalingModSize} is {36, 36}, {32, 32}, or {30, 30} terminates with crash.

  • Note: These mod sizes are above 30. I’m aware that from the comment in #1252, mod sizes under 30 are very small and don’t offer good precision.

However, when I increase firstModSize larger than scalingModSize (in all cases), for example {firstModSize, scalingModSize} = {31, 30}, then it just terminates normally. So I guess this crash happens due to the equality between firstModSize and scalingModsize.

I want to ask:

  1. Is it invalid case to have equal firstModSize and scalingModsize? If so, can you give me some reference related with?
  2. Anyway, I believe this is not the case can be expected… Could you please check out this unexpected behavior?

Thank you for your attention!

2

In general, it is recommended to set FirstModSize larger than ScalingModSize, see other posts on the forum for the meaning of these moduli: Setting security parameters according to 128 bit security (very small CKKS scaling factor) - #5 by ypolyakov, What is the differences among firstModSize, scalingModSize and scalingFactor? - #2 by Caesar, EvalAdd does not add in some cases - #7 by ypolyakov.

This is the same issue as in Crashes with specific parameter setting in CKKS, since there is currently a missing check for equality of the different moduli. We are aware of it and an issue has been created.