And the ciphertext modulus is log2(cryptoContext->GetCryptoParameters()->GetElementParams()->GetModulus().ConvertToDouble()) = 240.
May I know how the q is decided and can openfhe guarantee the security using this set of parameters? I’m also wondering how the security is guaranteed.
You are correct. 8192 should not be allowed for this parameters. If you do not set it manually, OpenFHE will use 16384. It looks like we are hitting an edge case where 8192 works at an earlier iteration but the extra check is not done for the updated log q. I’ve created an issue for this: Fix a bug with setting a lower ring dimension in BFV · Issue #382 · openfheorg/openfhe-development · GitHub This will be fixed in the next bugfix version (v1.0.4).
@ypolyakov I think I have figured out the root cause. Actually, the q is indeed 220-bit. However, if you convert q to double first and then compute the log, the result is incorrect. Converting to double will induce very large errors. I think this line should be modified:
Thank you @somnus No, the operations with doubles are not causing the issue. I looked at the parameters themselves. It is easy to see that q is 240 bits long (a product of small primes, each 60 bits long). We will fix this bug in the next bugfix version.