Parameter selection
Before a CKKS deployment, a handful of parameters have to be fixed, such as the ring dimension, the number of levels, and the security level. This page lists the parameters and their defaults, states the constraints they must jointly satisfy, and explains what changing each one does to runtime, precision, and security.
If you are not a CKKS expert, you should use the default parameter set. It is a well-tested, balanced choice, and most of the parameters below won't make sense until you've read Part 3. An expert who tunes parameters carefully to a specific workload can usually win a factor of about $1.5$ in performance. The rest of this page is for readers who want to understand the tradeoffs before reaching for the knobs.
The default parameters
The table below lists every tunable parameter with its default value and a one-line description of what it controls. Many of these are explained in full in Part 3; here we describe them only by their effect on the computation.
| Parameter | Default | Controls |
|---|---|---|
| Ring dimension $N$ | $65536$ | Controls the number of slots, which is $N/2 = 32768$. Must be a power of two. |
| Levels $L$ | $17$ | Multiplicative depth available for computation between bootstraps. |
| Security level | $128$-bit | How much work an attacker must do to break the encryption. |
| Multiparty $(t, n)$ | $(1, 1)$ | Number of key-holders $n$ and the threshold $t$ needed to decrypt. The default $t = 1$, $n = 1$ is ordinary single-party FHE, with no noise flooding. |
| Small prime size | $\approx 2^{40}$ | Size of $q_1, \ldots, q_L$. Sets the precision of the computation (about $40$ bits after the binary point). |
| Big prime size | $\approx 2^{55}$ | Size of the base prime $q_0$ (and the bootstrap primes). |
| Key decomposition parameter $d$ | $3$ | Block size used in key-switching. Trades key-switching speed against noise and modulus budget. |
| Key-switching prime sizes | $\approx 2^{60}$ | Size of the $d$ auxiliary primes used during key-switching. |
| Error distribution $\sigma$ | $3.2$ | Standard deviation of the noise added during encryption and key generation. |
| Max plaintext magnitude | $2^{12}$ | Largest slot value a bootstrap can refresh; intermediate values must stay within this range. |
| Ephemeral key-switch Hamming weight | $32$ | Number of nonzero coefficients of the sparse secret used internally during bootstrapping. |
| Coefficients-to-slots depth | $3$ | Levels a bootstrap spends on its first linear transform. |
| Mod-eval degree | $127$ | Degree of the polynomial a bootstrap uses to strip the mod-raise term. |
| Slots-to-coefficients depth | $3$ | Levels a bootstrap spends on its last linear transform. |
Parameter constraints
The parameters are not independent: security imposes a ceiling that ties several of them together. One key quantity is the maximum modulus — the product of every prime that ever appears in the modulus chain, including the extra primes added during bootstrapping and the auxiliary primes used for key-switching:
$$ Q_{\max} \;=\; \underbrace{q_0}_{\text{base}} \cdot \underbrace{q_1 \cdots q_L}_{\text{computation}} \cdot \underbrace{q_{L+1} \cdots q_{L+D}}_{\text{bootstrap}} \cdot \underbrace{p_0 \cdots p_{d-1}}_{\text{key-switching}}. $$Measuring everything in bits, this is approximately
$$ \log_2 Q_{\max} \;\approx\; \underbrace{40\,L}_{\text{small primes}} \;+\; \underbrace{55\,(1 + D)}_{\text{big primes}} \;+\; \underbrace{60\,d}_{\text{KS primes}}, $$where $D$ is the bootstrapping depth, the number of extra primes a bootstrap consumes:
$$ \begin{aligned} D &= (\text{coeff-to-slots depth}) + \bigl\lceil \log_2(\text{mod-eval degree} + 1) \bigr\rceil + (\text{slots-to-coeff depth}) \\ &= 3 + 7 + 3 \\ &= 13. \end{aligned} $$At the defaults ($L = 17$, $d = 3$), this gives $\log_2 Q_{\max} \approx 40\cdot 17 + 55\cdot 14 + 60\cdot 3 = 1630$ bits.
The security ceiling
The Ring-LWE problem is only hard if the modulus is small relative to the ring dimension: for a fixed $N$ and security level, there is a hard cap on $\log_2 Q_{\max}$. The table below gives that cap at $128$-bit security; see Part 5 for where these numbers come from and how the security of a parameter set is estimated.
| $N$ | Max $\log_2 Q_{\max}$ (128-bit) |
|---|---|
| $2^{12} = 4096$ | $109$ |
| $2^{13} = 8192$ | $218$ |
| $2^{14} = 16384$ | $438$ |
| $2^{15} = 32768$ | $881$ |
| $2^{16} = 65536$ | $1721$ |
| $2^{17} = 131072$ | $\approx 3500$ |
Other security constraints
- The error $\sigma$ cannot be too small. Shrinking the noise weakens Ring-LWE: with too little noise it becomes vulnerable to the Arora–Ge algebraic attack, which solves the problem outright.
- The ephemeral Hamming weight cannot be too small. The sparse secret used during bootstrapping must still resist the sparse-secret variant of Ring-LWE.
- The key-switching primes must be large enough. Each one should exceed the big prime size.
Tuning each parameter
Unless noted, assume every other parameter is held at its default.
Ring dimension $N$
$N$ must be a power of two. It sets both the slot count ($N/2$) and the cap on the maximum modulus.
- Larger $N$: more slots, and a much higher modulus ceiling (so more levels are possible). The cost is runtime, which grows like $N \log N$, and memory, which grows like $N$.
- Smaller $N$: faster and smaller, but the modulus ceiling roughly halves with each halving of $N$, so the number of available levels collapses. In particular, bootstrapping alone needs about $950$ bits of modulus, so it effectively requires $N \ge 2^{16}$ at the default prime sizes.
Combining the modulus formula with the security ceiling gives a feel for how the available levels scale with $N$:
| $N$ | Max computation levels |
|---|---|
| $2^{16}$ | $\approx 19$ |
| $2^{17}$ | $\approx 63$ |
| $2^{18}$ | $\approx 150$ |
Levels $L$
More levels mean more multiplicative depth between bootstraps, so this is almost always a win. Make $L$ as large as the budget allows. The only limit is that the total modulus must stay under the security ceiling.
Security level
Raising the target above $128$ bits lowers the modulus ceiling for a given $N$, which means fewer levels — or, to keep the same depth, a larger $N$ and a corresponding slowdown. Reaching $256$-bit security with the default chain, for instance, forces $N$ up to $2^{17}$.
Multiparty $(t, n)$
Set $n$ and $t$ to whatever the application requires. Any setting in which decryption results are revealed back to the computing party (which includes most multiparty setups) additionally requires noise flooding, which adds overhead and reduces precision in every workload that needs it.
Small and big prime sizes
Together these set the dynamic range of a slot. The small prime size ($\approx 2^{40}$) is the scale factor, so it fixes the precision: values are represented to roughly $40$ bits after the binary point. The big prime size ($\approx 2^{55}$) sets the headroom for the integer part, and hence the maximum plaintext magnitude (about $2^{14}$ before raw overflow, and $2^{12}$ in practice once bootstrapping headroom is accounted for). Both feed directly into $Q_{\max}$, so larger primes buy precision and range at the cost of security budget.
Key decomposition parameter $d$
$d$ is the block size used in key-switching: a larger $d$ means fewer blocks, so key-switching (and therefore rotation and ciphertext multiplication) runs faster. The downside is that larger blocks introduce more key-switching noise, and they require a larger auxiliary modulus, which raises $Q_{\max}$ and so eats into the security budget.
Key-switching prime sizes
These should be as large as possible without overflowing a machine word or the security budget: larger auxiliary primes mean less key-switching noise (better precision).
Error distribution $\sigma$
A smaller $\sigma$ weakens the Ring-LWE security guarantee; a larger $\sigma$ adds more noise to every encryption and key-switching, eroding precision. There is rarely a reason to change $\sigma$.
Bootstrapping parameters
- Max plaintext magnitude ($2^{12}$): the largest slot value a bootstrap can refresh. Computations must keep their intermediate values inside this range before every bootstrap.
- Ephemeral Hamming weight ($32$): should be as small as possible without dropping the sparse-secret security below the security parameter. Smaller means a smaller interval for mod-eval, which means a lower-degree polynomial and thus a faster bootstrap.
- Coefficients-to-slots / slots-to-coefficients depth ($3$ each): spending more levels here makes each bootstrap faster but consumes more of the bootstrap budget, leaving fewer levels for computation.
- Mod-eval degree ($127$): a higher degree gives a more accurate (higher-precision) bootstrap, but costs more levels — $\lceil \log_2(\text{degree}+1)\rceil$ of them — and more time, leaving fewer levels for computation.