# CKKS scaleModSize \<= 60

**URL:** https://openfhe.discourse.group/t/ckks-scalemodsize-60/1625
**Category:** Library Questions
**Created:** [October 8, 2024, 6:03pm UTC](https://openfhe.discourse.group/t/ckks-scalemodsize-60/1625 "2024-10-08T18:03:21Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![seyda](https://yyz1.discourse-cdn.com/flex031/user_avatar/openfhe.discourse.group/seyda/32/397_2.png) [@seyda](https://openfhe.discourse.group/u/seyda)
#### Post date: [October 8, 2024, 6:03pm UTC](https://openfhe.discourse.group/t/ckks-scalemodsize-60/1625/1 "2024-10-08T18:03:21Z")

</div>

When setting the CKKS parameters, the following lines:

```auto
uint32_t scaleModSize = 61;
CCParams<CryptoContextCKKSRNS> parameters;
parameters.SetScalingModSize(scaleModSize);

```

Gives the following error message:  
`.../src/core/include/math/nbtheory-impl.h:l.333:FirstPrime(): FirstPrime: Requested bit length 61 exceeds maximum allowed length 60`

I know that the moduli chain we use is approximately the scale size we requested, and we need to be careful not to cause overflows (assuming 64-bit precision). However, 60-bit upper bound seemed like an overkill. Why can’t we use, say, scaleModSize = 62?

---

<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 10, 2024, 4:51pm UTC](https://openfhe.discourse.group/t/ckks-scalemodsize-60/1625/2 "2024-10-10T16:51:49Z")

</div>

One of the underlying modular multiplication algorithms (modified Barrett modular multiplication) supports only moduli up to 2^{60}-1. This is why moduli are restricted to 60 bits. OpenFHE does not impose any restrictions on the selection of moduli, i.e., any modulus that is congruent to 1 \bmod 2 N is supported.

It is theoretically possible to support 62-bit moduli on 64-bit architectures, but the complexity of modular multiplication algorithms becomes higher (search for “62-bit” in [A Tour of NTL: Summary of Changes](https://libntl.org/doc/tour-changes.html) or look at [https://www.shoup.net/papers/akl-chapter.pdf](https://www.shoup.net/papers/akl-chapter.pdf) for Victor Shoup’s discussion of this topic), or special (invariant) primes have to be used to achieve lower complexity (as in NFLlib: [https://core.ac.uk/download/pdf/50531552.pdf](https://core.ac.uk/download/pdf/50531552.pdf)). We decided not to support 62-bit primes in OpenFHE to maintain the flexibility of using an arbitrary prime (especially in RNS settings, when many moduli are needed and generated on the fly).