Bug in security level?

Library Questions
1

Hello, I am trying to setup a cryptocontext for CKKS but I am struggling with security levels.
In particular, this is the context I am creating:

CCParams<CryptoContextCKKSRNS> parameters;

SecurityLevel securityLevel = lbcrypto::HEStd_128_classic;

parameters.SetSecretKeyDist(UNIFORM_TERNARY);
parameters.SetSecurityLevel(securityLevel);
parameters.SetBatchSize(1 << 14);

ScalingTechnique rescaleTech = FLEXIBLEAUTO;
usint dcrtBits               = 58;
usint firstMod               = 42;


parameters.SetScalingModSize(dcrtBits);
parameters.SetScalingTechnique(rescaleTech);
parameters.SetFirstModSize(firstMod);

usint depth =
            levelsUsedBeforeBootstrap + FHECKKSRNS::GetBootstrapDepth(8, {3, 3}, UNIFORM_TERNARY);

cout << endl << "Ciphertexts depth: " << depth << endl;

parameters.SetMultiplicativeDepth(depth);

context = GenCryptoContext(parameters);

cout << "Ring size " << log2(context->GetRingDimension());

The problem is that I obtain these ring dimensions:

HESTD_128_classic -> ring: 2^17
HESTD_192_classic -> ring: 2^17
HESTD_256_classic -> ring: 2^17

HESTD_128_quantum -> ring: 2^16
HESTD_192_quantum -> ring: 2^17
HESTD_256_quantum -> ring: 2^16

These values seem weird to me, especially the HESTD_192_quantum one (or the other two quantum!). Plus, in previous versions with the same context I used to get 2^16 when using HESTD_128_classic.

Thank you

2

Hi @marc-alonso ,

We recently updated the security tables to include thresholds for the ring dimension of 2^{16} for Gaussian and uniform ternary secrets (for the classical computer setting) - see Updated standard security tables by sararv22 · Pull Request #439 · openfheorg/openfhe-development · GitHub for more details. The HomomorphicEncryption.org security standard only includes thresholds up to 2^{16} (so we extended them to 2^{17} using the lattice estimator).

This is why you now see 2^{17} for the classical setting (when the the threshold for 2^{16} is exceeded, 2^{17} is used).

For the quantum setting, the maximum is 2^{16} (as thresholds only up to 2^{15} are currently included). The 192-bit quantum case appear to be caused by a typo in the program (it should be 2^{16}).

We will extend other parameter sets in future versions of OpenFHE. The main challenge is that lattice estimator is slow for high ring dimensions (see Lattice estimator is very slow for larger lattice dimensions (2^14 or higher) · Issue #75 · malb/lattice-estimator · GitHub).and Lattice estimator fails to run (with all attacks) for lattice dimension 2^15 or higher, i.e., larger q · Issue #74 · malb/lattice-estimator · GitHub for more details)