# Bug in security level?

**URL:** <https://openfhe.discourse.group/t/bug-in-security-level/835>\
**Category:** Library Questions\
**Tags:** bugs\
**Created:** [October 5, 2023, 9:33am UTC](https://openfhe.discourse.group/t/bug-in-security-level/835 "2023-10-05T09:33:01Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![marc-alonso](https://avatars.discourse-cdn.com/v4/letter/m/6f9a4e/32.png) [@marc-alonso](https://openfhe.discourse.group/u/marc-alonso)\
**Post date:** [October 5, 2023, 9:33am UTC](https://openfhe.discourse.group/t/bug-in-security-level/835/1 "2023-10-05T09:33:01Z")

</div>

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:

```auto
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:

```auto
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

---

<div class="post-metadata">

**Author:** ![ypolyakov](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/ypolyakov/32/47_2.png) [@ypolyakov](https://openfhe.discourse.group/u/ypolyakov)\
**Post date:** [October 13, 2023, 11:20pm UTC](https://openfhe.discourse.group/t/bug-in-security-level/835/2 "2023-10-13T23:20:34Z")

</div>

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](https://github.com/openfheorg/openfhe-development/pull/439) for more details. The [HomomorphicEncryption.org security standard](https://homomorphicencryption.org/wp-content/uploads/2018/11/HomomorphicEncryptionStandardv1.1.pdf) only includes thresholds up to 2^{16} (so we extended them to 2^{17} using the [lattice estimator](https://github.com/malb/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](https://github.com/malb/lattice-estimator/issues/75)).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](https://github.com/malb/lattice-estimator/issues/74) for more details)