Parameter Settings and Efficient Computation for Homomorphic Encryption in CKKS

Abstract

This paper investigates the impact of modular reduction backends on the security–performance trade-offs of the CKKS approximate homomorphic encryption scheme. Specifically, we compare a standard Residue Number System–Chinese Remainder Theorem (RNS-CRT) implementation with a Barrett reduction–based backend across representative parameter sets $(N,logq)$, spanning approximately 80–256-bit security levels as recommended by the Homomorphic Encryption Standard. We evaluate typical CKKS workloads—including encoding, encryption, homomorphic multiplication with the Number Theoretic Transform (NTT), rescaling, relinearization, and decryption—by measuring execution time and peak memory usage on a uniform experimental platform. Our results indicate that the parameter pair $(N,logq)$ primarily determines both security level and computational cost, while the choice of backend significantly influences the trade-offs between performance and memory efficiency. In particular, the Barrett-based backend is competitive and slightly more memory-efficient at lower security levels, whereas the CRT-based approach achieves lower latency at higher security levels. However, Barrett reduction provides notable memory savings at the cost of a 2–4× increase in runtime. Based on these findings, we derive practical guidelines for selecting CKKS parameters and modular reduction backends under varying constraints on security, latency, and memory.

1. Introduction

Modern cryptography provides mathematically grounded tools to ensure data confidentiality, integrity, and authenticity in adversarial environments [1]. As digital health systems and connected medical devices proliferate, healthcare providers increasingly rely on cryptography to protect sensitive clinical records, diagnostic data, and treatment histories while still enabling data-driven decision making [2]. Lattice-based, post-quantum cryptography offers strong security guarantees against both classical and quantum adversaries and forms the foundation for advanced primitives such as homomorphic encryption (HE) [3].

HE enables computation directly on encrypted data and is therefore well suited to privacy-preserving health management, where raw medical data (e.g., lab results, imaging features, or wearable sensor streams) cannot be exposed to cloud or third-party analytics systems. In this context, HE supports tasks such as secure risk scoring, encrypted model inference, and collaborative analysis across institutions without revealing individual patient records. Among existing schemes, the Cheon–Kim–Kim–Song (CKKS) scheme for approximate arithmetic is particularly attractive for healthcare workloads because many clinical and predictive models operate on real-valued vectors and can tolerate small numerical approximation errors [4]. CKKS encodes real or complex-valued health features into ring elements and performs approximate fixed-point arithmetic over ciphertexts, enabling deeper encrypted computations than exact-integer schemes at comparable parameter sizes [4].

The practical deployment of CKKS in health management systems depends critically on parameter settings and implementation choices. In particular, the ring degree N and ciphertext modulus q largely determine security level, numerical precision, and circuit depth, while the choice of arithmetic backend, i.e., modular reduction method, directly impacts runtime and memory usage [5,6].

CRT-based residue number systems and Barrett-based techniques are probably the two most widely used modular reduction methods in cryptographic implementations, like in CKKS [7,8]. To the best of our knowledge, there is still no comprehensive evaluation of these two backends within a unified homomorphic encryption environment. Most prior studies analyze modular reduction approaches independently or across different software frameworks and parameter settings, making direct and fair comparisons challenging.

In this work, we bridge this gap by evaluating CRT and Barrett backends within the same HE framework, focusing on how different $(N,q)$ configurations and CRT versus Barrett implementations affect performance by measuring their effects on computational overhead, memory utilization, and ciphertext-level performance under standard security levels. The goal is to provide experimentally grounded guidelines for designing CKKS-based health management pipelines that respect strict privacy requirements while remaining practical on real-world computing platforms [9,10,11].

The main contributions of this work include (1) A systematic study of CKKS parameters, highlighting the impact of ring degree N and ciphertext modulus size $logq$ on security, depth, runtime, and memory usage. (2) A comparison of two CKKS modular reduction backends: conventional RNS–CRT and Barrett-based modular reduction. (3) Practical guidelines for parameter and backend selection under different security and application requirements for CPU-based privacy-preserving analytics and machine-learning workloads.

To enhance readability, a list of acronyms and abbreviations is provided at the end of the paper.

2. Math Preliminaries

2.1. Cyclotomic Polynomial Ring

CKKS and many RLWE-based schemes work over a cyclotomic polynomial ring

$$\mathcal{R}=\mathbb{Z}\left[X\right]/\left({\Phi }_{2N}\left(X\right)\right),$$

where N is a power of two and ${\Phi }_{2N}\left(X\right)=X^N+1$ is the $\left(2N\right)\mathrm{th}$ cyclotomic polynomial [3,12]. For a modulus q, coefficients are reduced to obtain

$${\mathcal{R}}_q={\mathbb{Z}}_q\left[X\right]/(X^N+1).$$

(1)

An element of ${\mathcal{R}}_q$ is a polynomial

$$a\left(X\right)=a_0+a_{1}X+\cdots +a_{N-1}{X}^{N-1},a_i\in {\mathbb{Z}}_q,$$

with addition and multiplication performed modulo $X^N+1$ and q. The choice ${\Phi }_{2N}\left(X\right)=X^N+1$ in  Equation (1), where N is a power of two, ensures Cooley–Tukey FFT-style efficient computation for Number Theoretic Transform (NTT) and supports packing of complex or real vectors via the canonical embedding, which is essential for CKKS throughput [3,4].

2.2. Ring Learning with Errors (RLWE)

The security of CKKS relies on the Ring Learning With Errors problem, which lifts the LWE hardness assumption from vectors over ${\mathbb{Z}}_q$ to polynomials in ${\mathcal{R}}_q$.

A typical RLWE cryptosystem can be briefly outlined as follows. For the uniformly sampled polynomial $a\left(X\right)\in {\mathcal{R}}_q$ and the sampled small polynomial $s\left(x\right)$, compute $b\left(X\right)$ from

$$b\left(X\right)=a\left(X\right)s\left(X\right)+e\left(X\right)modq,$$

(2)

where $e\left(X\right)$ is a small “error” polynomial. Then the public key is the pair $\left(a\right(X),b(X\left)\right)$, and the secret key is $s\left(X\right)$. Given many such noisy equations, recovering $s\left(X\right)$ is believed to be as hard as solving certain worst-case problems on ideal lattices in the underlying cyclotomic field [13].

For the plaintext message $m\left(X\right)$, encode it into a polynomial in ${\mathcal{R}}_q$. Obtain the small polynomials $r\left(X\right),e_1\left(X\right),e_2\left(X\right)$ through sampling and compute

$$\begin{array}{ccc}\hfill c_1\left(X\right)& =& a\left(X\right)r\left(X\right)+e_1\left(X\right)modq,\hfill \\ \hfill c_2\left(X\right)& =& b\left(X\right)r\left(X\right)+e_2\left(X\right)+\mathrm{Encode}\left(m\left(X\right)\right)modq,\hfill \end{array}$$

(3)

Then, the ciphertext can be given as $c=(c_1\left(X\right),c_2\left(X\right)).$

The decryption requires the computation of

$$v\left(X\right)=c_2\left(X\right)-c_1\left(X\right)s\left(X\right)modq.$$

(4)

So that $m\left(X\right)$ can be recovered from $v\left(X\right)=\mathrm{Encode}\left(m\right(X\left)\right)+\left(\mathrm{small}\mathrm{noise}\right)$.

When instantiated as an encryption scheme, RLWE yields compact public keys and ciphertexts: the public key encodes one noisy relation of the form (2), and encryption masks the plaintext polynomial $m\left(X\right)$ with additional small noise polynomials (3). Decryption subtracts the secret-dependent part and recovers $m\left(X\right)$ as long as the accumulated noise remains below a modulus-dependent threshold (4). This structure is inherited directly by CKKS, which augments RLWE encryption with approximate fixed-point encoding and rescaling operations [4,14].

2.3. Residue Number System and CRT in ${\mathcal{R}}_q$

To support large ciphertext moduli efficiently, CKKS uses a residue number system based on CRT. A large integer modulus

$$q=q_0{q}_1\cdots q_{\ell },$$

with pairwise coprime primes $q_i$, is represented by its residues

$$amodq⟷(a_0,\dots ,a_{\ell }),a_i=amod{q}_i.$$

(5)

CRT implies the ring isomorphism

$${\mathbb{Z}}_q\cong {\mathbb{Z}}_{q_0}\times \cdots \times {\mathbb{Z}}_{q_{\ell }},$$

so additions and multiplications modulo q can be performed independently in each limb.

This idea extends naturally to the polynomial ring ${\mathcal{R}}_q$, yielding the so-called “double-CRT” representation

$${\mathcal{R}}_q\cong {\mathcal{R}}_{q_0}\times \cdots \times {\mathcal{R}}_{q_{\ell }},{\mathcal{R}}_{q_i}={\mathbb{Z}}_{q_i}\left[X\right]/(X^N+1).$$

A ciphertext polynomial in ${\mathcal{R}}_q$ is stored as its components in each ${\mathcal{R}}_{q_i}$, and all homomorphic operations are carried out limb-wise. Full-RNS CKKS variants operate entirely in this representation and are now standard in efficient implementations [5,6,9].

2.4. Barrett Modular Reduction

Modular reduction by the small primes $q_i$ is a core operation in NTT butterflies, pointwise multiplications, and rescaling steps. Direct division by $q_i$ is expensive, so CKKS implementations typically employ Barrett modular reduction, which replaces division by precomputed constants and multiplications [15,16].

For a fixed modulus q and an integer k with $2^k>q^2$, Barrett’s method precomputes

$$\mu =⌊{\displaystyle \frac{2^k}{q}}⌋.$$

Given an input x with $0\le x<q^2$, an approximate quotient is obtained by

$$\widehat{q}=⌊{\displaystyle \frac{x·\mu }{2^k}}⌋,$$

and the intermediate remainder is

$$r=x-\widehat{q}·q.$$

One can show that $0\le r<2q$, so a final conditional subtraction yields $xmodq$. In the RNS setting, the same idea is applied independently to each limb $q_i$, using precomputed $(k_i,{\mu }_i)$ for each modulus. Compared to division-based reduction, Barrett’s method significantly reduces latency and is competitive with Montgomery-style techniques in HE workloads [16,17,18].

3. Homomorphic Encryption Schemes and CKKS

Since its introduction, HE has evolved from supporting a single operation on ciphertexts to enabling practical evaluation of complex functions over encrypted data. Early schemes were either additively or multiplicatively homomorphic, while later constructions combined both operations and ultimately achieved fully homomorphic encryption (FHE) with support for arbitrary circuits [19]. This evolution has been driven by lattice-based cryptography and noise-management techniques, which improved efficiency enough for HE to be applied in privacy-sensitive domains such as healthcare analytics and clinical decision support [20].

3.1. From PHE and SHE to FHE

Let $\mathrm{Enc}\left(m\right)$ and $\mathrm{Dec}\left(c\right)$ denote encryption and decryption of a message m and ciphertext c, and let ⊕ and ⊗ denote homomorphic addition and multiplication. A partially homomorphic encryption (PHE) scheme supports only one operation, for example

$$\mathrm{Enc}\left(m_1\right)\oplus \mathrm{Enc}\left(m_2\right)=\mathrm{Enc}(m_1+m_2),$$

(6)

for additively homomorphic schemes such as Paillier, or 

$$\mathrm{Enc}\left(m_1\right)\otimes \mathrm{Enc}\left(m_2\right)=\mathrm{Enc}(m_1·m_2),$$

(7)

for multiplicatively homomorphic constructions such as textbook RSA without padding.

Somewhat homomorphic encryption (SHE) schemes support both addition (6) and multiplication (7) but only up to a bounded depth because each operation increases ciphertext noise, and decryption fails once the noise exceeds a threshold [21]. Fully homomorphic encryption (FHE) removes this depth limitation by periodically refreshing ciphertexts via bootstrapping, allowing the evaluation of arbitrary polynomial-size circuits

$$\mathrm{Eval}\left(C,\mathrm{Enc}\left(m_1\right),\dots ,\mathrm{Enc}\left(m_t\right)\right)=\mathrm{Enc}\left(C(m_1,\dots ,m_t)\right),$$

for any circuit C [19].

3.2. Generations of HE Schemes

First-generation FHE schemes, starting from Gentry’s original ideal-lattice construction, established feasibility but were orders of magnitude too slow for practice [19]. Second-generation schemes such as BGV and BFV moved to RLWE-based polynomial rings and introduced techniques such as modulus switching, key switching, and SIMD batching, enabling leveled FHE without frequent bootstrapping [14,22]. Third-generation schemes (GSW, FHEW, TFHE) optimized binary gate evaluation and made bootstrapping fast enough for real-time logic on encrypted bits [23,24,25]. A fourth generation focuses on approximate arithmetic, where many applications—including health management—operate on real-valued features and tolerate small numerical errors. In this space, the CKKS scheme is now a de facto standard, enabling efficient encrypted computation over vectors of real or complex numbers with floating-point-like semantics [4].

3.3. CKKS Scheme

CKKS is an RLWE-based homomorphic encryption scheme tailored to approximate arithmetic on real and complex vectors [4]. It operates over the cyclotomic ring

$${\mathcal{R}}_q={\mathbb{Z}}_q\left[X\right]/(X^N+1),$$

where N is a power of two, and q is the ciphertext modulus, often factored into smaller RNS primes. Plaintexts encode vectors in ${\mathbb{C}}^{N/2}$ using a packing technique based on the canonical embedding, and each ciphertext carries a scale parameter that tracks fixed-point precision [4,26].

3.3.1. Encoding and Approximate Arithmetic

CKKS assumes that user data are a vector of complex numbers $\mathbf{z}\in {\mathbb{C}}^n$. The encoding maps the vector into the values of a polynomial at special points (roots of unity), then reconstructs the polynomial $m\left(X\right)$ via an inverse transform.

Let $\xi$ be a primitive $\left(2N\right)$-th root of unity, $\xi \in \mathbb{C}$. So we construct $m\left(X\right)$ such that $m\left({\xi }^{k_i}\right)=z_i$ through

$$\mathbf{z}\stackrel{InverseFFT}{\to }\mathrm{coefficients}\mathrm{of}m.$$

after embeds m into the cyclotomic field via the canonical embedding, then CKKS applies a scaling factor $\Delta$:

$$w=\Delta ·{\pi }^{-1}\left(m\right),$$

where ${\pi }^{-1}$ reconstructs a Hermitian-symmetric vector from the slots [26]. The coordinates of w in a fixed lattice basis are rounded to integers and used as coefficients of the plaintext polynomial

$$m\left(X\right)={\displaystyle \sum _{i=0}^{N-1}}{\tilde{z}}_i{X}^i\in {\mathcal{R}}_q.$$

Decoding inverts this process: after decryption, the polynomial is mapped back through the canonical embedding and divided by $\Delta$, yielding an approximation of the original slot vector. The choice of $\Delta$, modulus chain, and N determines the achievable precision and depth for a given health-management workload.

3.3.2. Encryption and Decryption

The secret key is a small polynomial

$$s\left(X\right)\leftarrow {\chi }_{\mathrm{key}}\subset {\mathcal{R}}_q,$$

and the public key $(p_0\left(X\right),p_1\left(X\right))\in {\mathcal{R}}_q^2$ is constructed as a noisy RLWE sample encrypting zero [4]. Given an encoded plaintext $m\left(X\right)\in R_q$, encryption samples fresh small polynomials $u\left(X\right),e_0\left(X\right),e_1\left(X\right)$ and outputs the ciphertext

$$\begin{array}{cc}\hfill c_0\left(X\right)& =p_0\left(X\right)u\left(X\right)+e_0\left(X\right)+m\left(X\right)\left(\mathrm{mod}q\right),\hfill \end{array}$$

(8)

$$\begin{array}{cc}\hfill c_1\left(X\right)& =p_1\left(X\right)u\left(X\right)+e_1\left(X\right)\left(\mathrm{mod}q\right),\hfill \end{array}$$

(9)

so that $c=(c_0,c_1)\in {\mathcal{R}}_q^2$.

Decryption uses the linear form in the secret key

$$\tilde{m}\left(X\right)=c_0\left(X\right)+c_1\left(X\right)s\left(X\right)\left(\mathrm{mod}q\right),$$

which equals $m\left(X\right)$ plus a bounded noise polynomial. After decoding and division by $\Delta$, the slots approximate the original real or complex inputs [27].

3.3.3. Homomorphic Addition and Multiplication

Let ciphertexts $c=(c_0,c_1)$ from (8) and (9), and $c^{\prime }=(c_0^{\prime },c_1^{\prime })$ encrypt plaintexts $\mu$ and ${\mu }^{\prime }$ at the same level. Homomorphic addition is defined component-wise:

$$c_{\mathrm{add}}=(c_0+c_0^{\prime },c_1+c_1^{\prime }),$$

and decryption yields

$${\mathrm{Dec}}_s\left(c_{\mathrm{add}}\right)=(c_0+c_0^{\prime })+(c_1+c_1^{\prime })s\approx \mu +{\mu }^{\prime }.$$

Plaintext–ciphertext multiplication by a plaintext polynomial ${\mu }^{\prime }\left(X\right)$ is given by

$$c_{\mathrm{ptmult}}=({\mu }^{\prime }{c}_0,{\mu }^{\prime }{c}_1),$$

with

$${\mathrm{Dec}}_s\left(c_{\mathrm{ptmult}}\right)={\mu }^{\prime }(c_0+c_{1}s)\approx {\mu }^{\prime }·\mu .$$

Ciphertext–ciphertext multiplication takes two ciphertexts $c=(c_0,c_1)$ and $c^{\prime }=(c_0^{\prime },c_1^{\prime })$ and forms a 3-component ciphertext

$$\begin{array}{cc}\hfill d_0& =c_0{c}_0^{\prime },\hfill \end{array}$$

(10)

$$\begin{array}{cc}\hfill d_1& =c_0{c}_1^{\prime }+c_1{c}_0^{\prime },\hfill \end{array}$$

(11)

$$\begin{array}{cc}\hfill d_2& =c_1{c}_1^{\prime },\hfill \end{array}$$

(12)

so that

$$d_0+d_{1}s+d_2{s}^2\approx \mu ·{\mu }^{\prime }.$$

3.3.4. Relinearization

Relinearization maps the 3-component product $(d_0,d_1,d_2)$ back to a standard 2-component ciphertext under the same secret key [28]. Using an evaluation key that encrypts $s^2$ under s, relinearization computes

$$(c_0^{*},c_1^{*})=(d_0,d_1)+\mathrm{RelinMap}(d_2,\mathrm{evk}),$$

and the resulting ciphertext

$$c_{\mathrm{relin}}=(c_0^{*},c_1^{*})$$

again decrypts with the standard rule ${\mathrm{Dec}}_s\left(c_{\mathrm{relin}}\right)=c_0^{*}+c_1^{*}s\approx \mu ·{\mu }^{\prime }$.

3.3.5. Rescaling and Multiplication Pipeline

After multiplication, both the scale and modulus grow. CKKS controls this growth with a rescaling step that simultaneously reduces the modulus and divides the ciphertext by the scale [6,29]. If c lives at level ℓ with modulus $q_{\ell }$, rescaling to level $\ell -1$ is defined as

$${\mathrm{Rescale}}_{\ell \to \ell -1}\left(c\right)=⌊{\displaystyle \frac{q_{\ell -1}}{q_{\ell }}}·c⌉mod{q}_{\ell -1},$$

which approximately divides both the message and noise by the scale and drops one modulus from the chain.

Combining these steps, the CKKS multiplication pipeline is

$$c_{\mathrm{mult}}=\mathrm{CMult}(c,c^{\prime })\stackrel{\mathrm{Relin}}{\to }{c}_{\mathrm{relin}}\stackrel{\mathrm{Rescale}}{\to }{c}_{\mathrm{rs}},$$

where $c_{\mathrm{rs}}$ is a 2-component ciphertext at the next lower level with restored scale and controlled noise, ready for further homomorphic operations.

4. Parameter Selection, Simulation and Recommendations

4.1. CKKS Parameters Used in This Work

In the proposed implementation, the CKKS scheme is instantiated with a tuple of parameters $(N,q,\Delta ,\sigma )$ that jointly determine security, precision, and performance. All experiments use the same parameter sets for both the CRT-based baseline and the Barrett-based variant, so that any performance differences arise purely from the modular arithmetic backend and not from changes in cryptographic strength.

4.1.1. Ring Degree N

The ring degree N is chosen as a power of two (in the range $2^{10}$–$2^{14}$ in this work). It defines the polynomial ring $\mathbb{Z}\left[X\right]/(X^N+1)$, the RLWE lattice dimension, and the number of SIMD slots ($N/2$) [4,6]. Larger N improves security and packing capacity but increases ciphertext and key sizes, and raises the cost of NTT-based operations roughly as $O(NlogN)$.

4.1.2. Ciphertext Modulus q

The ciphertext modulus q is represented in RNS form as

$$q={\displaystyle \prod _{i=0}^{\ell }}{q}_i,$$

where each $q_i$ is a 30–60-bit prime so that arithmetic in each limb fits in an 80-bit word. This modulus chain is consumed by homomorphic multiplication and rescaling: every multiplication increases noise and effective scale, and each rescale step drops one $q_i$ and divides by the scaling factor $\Delta$ [4,5]. The total size $logq$ must be large enough to sustain the required multiplicative depth and precision; too small a $logq$ causes decryption failures, whereas too large a $logq$ adds limbs and slows all operations without increasing security [6,30].

4.1.3. Scaling Factor $\Delta$

The scaling factor $\Delta$ is chosen as a power of two (e.g., $\Delta =2^{30}$–$2^{40}$). It is applied during encoding to map real or complex health features into fixed-point integers by multiplying by $\Delta$ and rounding [30]. A larger $\Delta$ improves numerical precision but consumes more modulus bits per multiplication and may require a longer modulus chain; a smaller $\Delta$ saves modulus but may reduce application-level accuracy for clinical workloads.

4.1.4. Noise Distribution Parameter $\sigma$

The parameter $\sigma$ controls the discrete Gaussian (or similar) distribution used for RLWE noise in encryption and key-dependent operations [6]. Typical choices (e.g., $\sigma \approx 3$) provide sufficient initial noise for security while keeping it small enough to be tracked within the available modulus. In this work, $(N,q,\Delta ,\sigma )$ are selected according to standard CKKS guidelines [6,30] and then fixed across all implementations.

4.2. Parameters $(N,logq)$ Versus CKKS Security Levels L

The pair $(N,logq)$ is the dominant driver of both security and performance in CKKS. Security is based on the hardness of Ring-LWE in the cyclotomic ring ${\mathcal{R}}_q={\mathbb{Z}}_q\left[X\right]/(X^N+1)$, so N and $logq$ define the underlying lattice dimension and modulus [6]. In practice, the security level (L, in bits) is estimated via the cost of the best known lattice attacks (typically BKZ-based), which depends primarily on the ring dimension N and the modulus-to-noise ratio (captured through $logq$ and the error distribution) [31,32,33].

4.2.1. Dependence of Security Level L on N

For RLWE instances with fixed modulus and noise parameters, increasing the polynomial modulus degree N (equivalent to the lattice dimension) increases hardness.

The complexity of the best known attacks (e.g., BKZ with block size $\beta$) scales as:

$$\mathrm{Cost}\approx 2^{c·\beta }$$

where $\beta$ itself depends on N and the ratio $q/\sigma$ (the standard noise deviation is usually set as $\sigma =3.2$).

Heuristically, for fixed $logq$, increasing N increases the required block size $\beta$, and hence the attack cost.

The implication is that security increases with N, but sublinearly in terms of security bits. For example, doubling N does not double L; instead, it typically yields a moderate increase depending on the modulus size. This behavior is consistent with modern lattice cost models and empirical estimates from tools such as the LWE Estimator.

4.2.2. Dependence of Security Level L on $logq$

The modulus q directly affects the distinguishability of RLWE samples.

Increasing q (for fixed noise standard deviation $\sigma$) increases the ratio $q/\sigma$, making the problem easier. A common heuristic from LWE/RLWE analysis relates the root-Hermite factor to:

$${\delta }_0^n\approx {\displaystyle \frac{q}{\sigma }}$$

which implies that larger q leads to smaller required ${\delta }_0$, hence easier lattice reduction.

Since attack cost depends exponentially on lattice reduction quality, one may write:

$$log\left(\mathrm{Cost}\right)\propto {\displaystyle \frac{n}{log(q/\sigma )}}$$

As a result, security decreases as $logq$ increases. However, the dependence is not linear; rather, it appears inside a logarithm within an exponential model. Thus, increasing $logq$ reduces security in a nonlinear and attenuated manner.

4.2.3. Combined Dependence and Practical CKKS Parameter Selection

Combining the above effects yields a commonly used first-order heuristic:

$$L\propto {\displaystyle \frac{N}{log(q/\sigma )}}$$

This expression captures the fundamental trade-off:

• Increasing N improves security;
• Increasing q degrades security;
• The relationship is ratio-based and nonlinear.

However, this is only an approximation. In CKKS, the modulus q grows with multiplicative depth, so parameter selection must respect a security budget constraint:

• N and $logq$ cannot be scaled independently;
• For a fixed target security level (e.g., 128 bits), increasing $logq$ requires increasing N.

This explains the structure of parameter tables in implementations such as Microsoft SEAL [34], where larger N permits larger total modulus $logq$, but the scaling is sublinear rather than proportional.

For fixed $logq$, increasing N raises the cost of lattice reduction; for fixed N, increasing $logq$ generally weakens the instance and may require a larger N to restore the same security level [6]. The Homomorphic Encryption Standard therefore provides recommended $(N,logq)$ curves for 80–128-bit security, which we follow when selecting parameter sets [6].

From a performance perspective, nearly all CKKS operations (NTT/INTT, ciphertext multiplication, key switching, and rotations) scale with N and with the number of RNS primes in q [9,11,35]. Larger N increases latency and memory but also provides more slots ($N/2$), improving amortized cost per health record or feature vector. Adding primes to q increases depth and precision but enlarges ciphertexts and evaluation keys and raises time and memory. Consequently, both N and $logq$ are kept as small as possible while meeting target security and accuracy for the health-management workloads considered.

4.3. Algorithmic Choices: RNS–CRT and Barrett Reduction

Efficient polynomial arithmetic in ${\mathcal{R}}_q$ is essential to make these parameter choices meaningful. All implementations in this work use the same RNS/CRT representation: the large modulus q is split into pairwise coprime primes $q_i$, and each polynomial coefficient is stored as its residues $(amod{q}_i)$ [5]. This “double-CRT” representation enables limb-wise parallelism and efficient rescaling in Full-RNS CKKS [5,36].

The only algorithmic difference between the two backends lies in how modular reduction is performed at each limb. The baseline uses a conventional CRT-centric modular reduction, while the proposed variant replaces division by Barrett reduction, using precomputed reciprocals ${\mu }_i$ for each modulus $q_i$ [16,37]. In both cases, the RNS structure and CKKS parameters are identical; the experiments therefore isolate how the choice between RNS-CRT (or CRT in short form) and Barrett affects runtime and peak memory across $(N,logq)$ and security levels, for representative health-management workloads.

4.4. Simulation Settings

The experiments are run on an AMD Ryzen 7 7700X (8 cores, 16 threads, 4.49 GHz, fabricated by TSMC in Taiwan), 64 GB DDR5-5200 RAM (manufactured by SK Hynix in South Korea), Ubuntu 22.04, and Python 3.12. The CRT baseline is a forked py-fhe implementation; the Barrett backend is our CKKS-Barrette code. Both use the same CKKS parameters and RNS structure, so that differences reflect only the modular reduction backend. For each parameter set $(N,logq)$, we measure end-to-end execution time (seconds) and peak memory (MB) for a representative CKKS workload that includes at least one ciphertext–ciphertext multiplication with rescaling and relinearization.

4.5. Simulation Results and Recommendations

Simulations were conducted for selected parameter pairs $(N,logq)$ at security levels of 80, 100, 110, 128, 192, and 256 bits. The corresponding results are summarized in

Table 1. Experimental results for 80-bit security level.

N	$log\mathit{q}$	Time (s)		Space (MB)
		CRT	Barrett	CRT	Barrett
1024	80	1.45	1.61	231.88	187.67
2048	200	5.01	7.57	353.68	324.37
4096	300	15.53	33.64	901.37	885.30

,

Table 2. Experimental results for 100-bit security level.

N	$log\mathit{q}$	Time (s)		Space (MB)
		CRT	Barrett	CRT	Barrett
2048	100	4.01	6.56	335.21	328.81
4096	200	13.42	29.10	924.36	884.01
8192	300	47.34	133.57	3167.18	3116.49

,

Table 3. Experimental results for 110-bit security level.

N	$log\mathit{q}$	Time (s)		Space (MB)
		CRT	Barrett	CRT	Barrett
2048	80	3.71	6.46	337.81	328.39
4096	150	13.12	30.34	905.58	887.46
8192	250	45.04	125.23	3159.32	3114.66
16,384	550	180.49	800.44	12,183.48	12,020.21

,

Table 4. Experimental results for 128-bit security level.

N	$log\mathit{q}$	Time (s)		Space (MB)
		CRT	Barrett	CRT	Barrett
2048	60	3.68	6.25	336.86	327.88
4096	120	13.06	27.62	903.83	887.44
8192	200	43.15	117.00	3175.11	3114.03
16,384	450	166.36	666.78	12,174.28	12,030.07

,

Table 5. Experimental results for 192-bit security level.

N	$log\mathit{q}$	Time (s)		Space (MB)
		CRT	Barrett	CRT	Barrett
2048	40	3.92	6.16	334.63	327.53
4096	80	12.09	26.26	903.63	887.39
8192	150	41.25	121.39	3152.82	3116.62
16,384	300	149.71	539.89	12,124.83	11,873.28

and

Table 6. Experimental results for 256-bit security level.

N	$log\mathit{q}$	Time (s)		Space (MB)
		CRT	Barrett	CRT	Barrett
4096	60	11.48	25.76	902.64	886.82
8192	120	39.75	109.07	3150.76	3116.81
16,384	250	155.70	533.87	12,108.49	11,323.03

, respectively. The parameter sets chosen for the 128-, 192-, and 256-bit security levels follow the recommendations of the Homomorphic Encryption Standard [6].

4.5.1. The 80-Bit Security

An 80-bit security level, commonly regarded as ultra-lightweight security, corresponds to legacy cryptographic systems such as 1024-bit RSA and Triple DES. It remains relevant in legacy communication infrastructures and resource-constrained embedded devices where lightweight security is sufficient.

For $(N,logq)=(1024,80)$, CRT is slightly faster than Barrett, whereas Barrett achieves significantly lower memory usage. For the remaining parameter sets, CRT substantially outperforms Barrett in execution time, while Barrett consistently requires less memory.

With a fixed security level, e.g., 80 bits, the selection of $(N,logq)$ depends on the requirements of the target application. Further discussion is provided at the end of this section.

4.5.2. The 100 and 110-Bit Security Levels

Security levels of 100 and 110 bits are generally considered lightweight and are suitable for IoT devices, RFID systems, sensor networks, edge computing platforms, and embedded applications.

Even when higher security levels are desired, lower-security configurations are often explored for latency-sensitive applications and intermediate deployment scenarios.

At 100-bit security with $(N,logq)=(2048,100)$, CRT achieves lower execution time but requires more memory. For $(4096,200)$, CRT is more than twice as fast as Barrett, whereas Barrett reduces memory usage to approximately 95% of that required by CRT. For $(8192,300)$, CRT is nearly three times faster, while Barrett reduces memory consumption by about 2%.

At 110-bit security, CRT is approximately twice as fast as Barrett for $(2048,80)$ and $(4096,150)$, although it requires slightly more memory. For $(8192,250)$, CRT is nearly three times faster, while Barrett reduces memory usage by approximately 1.5%. For (16,384, 550), CRT is about 4.5 times faster, whereas Barrett provides only a marginal memory reduction of roughly 1%.

4.5.3. The 128-Bit Security

A 128-bit security level is widely regarded as the standard baseline for modern cryptographic applications, offering a practical balance between efficiency and long-term protection against classical adversaries.

In CKKS-based homomorphic encryption, 128-bit security is commonly adopted for privacy-preserving machine learning, encrypted database queries, and secure outsourced computation. It is also the default recommendation in standards such as NIST SP 800-57 for protecting sensitive personal, commercial, and institutional data over medium- to long-term periods.

For high-security settings (128 bits or above), large parameter sets such as N = 16,384 with large moduli are generally required. Although both backends incur substantial runtime and memory overhead, CRT consistently achieves lower execution time, whereas Barrett provides slightly lower memory consumption.

4.5.4. The 192-Bit Security

A 192-bit security level is less commonly deployed but is suitable for applications requiring stronger protection against highly capable adversaries or longer data retention periods. Typical use cases include government, defense, and high-assurance-secure communication systems.

In homomorphic encryption and secure multi-party computation, 192-bit security may be preferred when 256-bit security is considered excessively costly, while additional assurance beyond 128-bit security is still desired.

At the 192-bit security level, CRT consistently achieves lower execution time, whereas Barrett provides slightly lower memory usage. For large ring degrees, such as $N=2^{13}$ or $2^{14}$, the memory advantage of Barrett becomes marginal compared to the substantial runtime advantage of CRT.

4.5.5. The 256-Bit Security

A 256-bit security level targets applications requiring maximum resilience against future threats, including large-scale quantum adversaries and long-term archival attacks. Typical applications include national security systems, critical infrastructure, and highly sensitive financial systems.

In post-quantum and high-assurance cloud-computing applications, 256-bit security provides a conservative security margin for data requiring decades of confidentiality. Although it significantly increases parameter sizes and computational cost in homomorphic encryption systems, such overhead may be justified for highly sensitive long-term data.

At the 256-bit security level, CRT is approximately 2.2–3.4 times faster than Barrett, while Barrett reduces memory usage by roughly 1–2% compared to CRT.

In summary, we acknowledge that the superior performance of the CRT-based method over the Barrett-based method arises primarily from the use of reduced-size moduli obtained via the factorization of q. This decomposition enables computations to be carried out over smaller integers, significantly lowering arithmetic complexity. In addition, the inherent parallelism of the CRT approach—where operations across different moduli are independent—aligns well with modern multi-core architectures, further enhancing performance. This advantage becomes more pronounced for larger values of q, or equivalently, for larger polynomial degrees N that support a larger modulus.

In terms of memory usage, however, the CRT-based method typically incurs higher overhead, as it must maintain multiple residues corresponding to the factorization of q, leading to increased storage and data movement compared to the Barrett-based approach.

4.6. Application Considerations on Selection of $(N,logq)$

In CKKS, once the target security level is fixed, the polynomial modulus degree N and the total modulus size $logq$ are primarily driven by circuit depth D, required numerical precision, and the SIMD vector size.

The circuit depth determines the length of the modulus chain: each multiplication (followed by rescaling) consumes one level, so a deeper circuit requires a larger total $logq$ to accommodate the cumulative modulus drops.

The required precision dictates the size of the scaling factor and the tolerance to noise growth; higher precision necessitates larger intermediate moduli and therefore increases $logq$ as well.

The vector size (i.e., the number of packed slots) is bounded by $N/2$, so larger batch sizes require larger N. However, increasing $logq$ at a fixed security level typically forces an increase in N to maintain hardness of the underlying RLWE instance.

Consequently, D and precision directly inflate $logq$, while vector size directly sets a lower bound on N; together they interact so that more demanding depth or precision indirectly pushes N upward to preserve the desired security level. Two practical workload patterns require special attention:

• Large batches of input data:

Increasing N increases the number of CKKS slots and thus the batch size. For throughput-oriented workloads (e.g., batched inference), larger N (8192 or 16,384) is recommended even at lower security levels. CRT is preferable when minimizing latency per batch is critical; Barrett becomes attractive when many batches run concurrently, and aggregate memory usage limits the number of parallel sessions.

• High-resolution input data:

Increasing $logq$ allows larger scaling factors and higher fixed-point precision, but increases runtime and memory. For high-precision workloads (e.g., finance or scientific computing), medium-to-large moduli (220–260 at $N=8192$, or 300–350 at N = 16,384) are recommended. In these cases, CRT should be chosen when speed is paramount, while Barrett offers a memory-optimized alternative when infrastructure cost or device RAM is the bottleneck.

• Suggested practical guidelines:

Our results suggest the following criteria for choosing between CRT and Barrett for practical users:

• For memory-constrained IoT devices with limited RAM and moderate security requirements (e.g., 80-bit security), Barrett is preferable due to its lower memory usage, even though it may be slower.
• For cloud servers or high-performance environments requiring high security (e.g., 128-bit or above), CRT is preferable because it provides significantly better time efficiency at these security levels, and memory is less constrained.
• For applications where both memory and time are critical, the choice depends on the target security level: Barrett is competitive at low-to-moderate security, while CRT becomes more advantageous as security level increases.

The above guidelines can also be summarized into a table as shown in

Table 7. Practical guidelines for choosing CRT and Barrett.

Applications	Backend Choice	Main Reason
Memory-constrained IoT/low security	Barrett	Lower memory at 80–100 bit
High security, server/cloud	CRT	Better time efficiency at ⩾128 bit
Implementation simplicity	CRT	Uniform scaling with security

.

5. Conclusions

5.1. Summary of Contributions

The proposed research work investigated parameter selection and modular arithmetic design choices for the CKKS homomorphic encryption scheme, with a particular focus on how these choices shape the security–performance trade-off in practice. The core contributions are:

• A systematic experimental study of CKKS parameters, emphasizing the dominant role of the ring degree N and the ciphertext modulus size $logq$ in determining security, depth, runtime, and memory usage [6,9].
• A controlled comparison of two modular reduction backends within CKKS: a conventional RNS–CRT-centric implementation and an alternative implementation that integrates Barrett modular reduction into performance-critical arithmetic routines [16].
• Practical recommendations for parameter and backend selection under different security and application scenarios, targeting CPU-based deployments of privacy-preserving analytics and machine-learning workloads.

5.2. Significance and Limitations of the Research

The significance of the results lies in their systems-level implications for homomorphic encryption. CKKS is increasingly used in applications such as privacy-preserving machine learning and secure data analytics, where performance and memory usage often determine feasibility [9,38]. In such settings, asymptotic complexity alone is insufficient to guide design choices.

The experiments show that even when two implementations share the same cryptographic foundations, low-level arithmetic decisions can meaningfully alter practical behavior. In particular, they indicate that Barrett reduction, while typically slower than CRT-based arithmetic in terms of raw execution time at higher security levels, can reduce peak memory usage in several important regimes. This trade-off is especially relevant for cloud and multi-tenant environments, where memory constraints often limit the number of concurrent encrypted workloads more severely than compute throughput [39,40]. The results also reinforce that there is no universally optimal CKKS configuration: parameter and backend choices must be aligned with application requirements such as acceptable latency, available memory, and target security level [38].

• Discussion relating to SEAL/Palisade:

These findings have direct implications for widely used homomorphic encryption libraries such as Microsoft SEAL and Palisade. In SEAL, modular reduction is implemented as part of the core arithmetic, and the choice of backend can significantly affect performance for CKKS-based workloads. Our results suggest that, for SEAL deployments targeting low-security, memory-constrained scenarios, a Barrett-based modular reduction backend could reduce memory pressure and enable operation on devices with limited RAM. Conversely, for high-security server-side deployments, a CRT-based backend is likely to provide better throughput and lower latency. Similarly, in Palisade, where multiple modular reduction strategies can be configured, our results indicate that CRT should be preferred for high-security parameter sets, while Barrett may be advantageous for lower-security configurations where memory is the primary bottleneck. Practitioners using these libraries can use our decision table and examples to guide parameter and backend selection based on their target deployment environment.

• Limitations of this work:

Several limitations should be acknowledged. First, the experimental evaluation is based on Python implementations, which do not fully exploit low-level optimizations available in production-grade C/C++ libraries such as SEAL or OpenFHE [9]. In this sense, the results are intended to guide backend selection and parameter tuning within CKKS, while a native C/C++ re-implementation is left to future work. Second, the study evaluates performance only on a CPU platform and does not consider GPU or FPGA accelerators, where the relative behavior of CRT and Barrett might differ [39]. Finally, the analysis focuses on execution time and peak memory; other important metrics, such as energy consumption and end-to-end numerical accuracy in concrete applications, are outside the scope of the presented work in this paper [9].

5.3. Directions for Possible Future Work

The findings suggest several avenues for future research.

An immediate direction is to extend the evaluation to optimized C/C++ CKKS libraries, integrating Barrett-based modular reduction into mature frameworks such as SEAL or OpenFHE. This would clarify whether the memory advantages observed here persist when aggressive compiler optimizations, vectorization, and hand-tuned arithmetic are applied [6].

Another direction is to explore hardware-accelerated implementations on GPUs and FPGAs, where multiplication-heavy algorithms such as Barrett reduction may benefit disproportionately from parallelism [39,40]. A comparative study across CPU, GPU, and hybrid architectures could yield new insights into backend selection for large-scale deployments.

Finally, the methodology developed in this work could be generalized to other homomorphic encryption schemes, such as BFV or TFHE, to assess whether similar trade-offs between modular arithmetic backends arise beyond CKKS [6,38].