GPU Acceleration for KLSS Key Switching in Fully Homomorphic Encryption

Abstract

Fully Homomorphic Encryption (FHE) enables privacy-preserving computation but is hindered by high computational overhead, with the key-switching operation being a primary performance bottleneck. This paper introduces the first CUDA-optimized GPU implementation of the Kim, Lee, Seo, and Son (KLSS) key-switching algorithm for three leading FHE schemes: BGV, BFV, and CKKS. Our solution achieves significant performance gains, delivering speedups of up to 181× against the original CPU implementation. Furthermore, we analyze the critical trade-off between the key-switching techniques on GPUs, providing insights for the choice between single- and double-decomposition methods. Our work provides a high-performance tool and offers clear guidelines on the trade-off between latency and hardware memory constraints.

1. Introduction

Fully Homomorphic Encryption (FHE) represents a paradigm shift in cryptography by enabling computation directly on encrypted data without prior decryption. This capability allows for the processing of sensitive information by untrusted third parties, such as cloud service providers, while guaranteeing data confidentiality. Consequently, FHE is an immensely attractive technology for a wide range of privacy-preserving applications, including secure cloud computing, private machine learning inference, and federated learning [1,2,3,4,5].

Despite this promise, the practical deployment of FHE has been hindered by significant performance challenges. The substantial computational overhead associated with current FHE schemes remains a critical barrier to their widespread adoption in real-world systems. Among the various homomorphic operations, key switching is a particularly demanding primitive. It is a fundamental building block for other essential operations, such as ciphertext relinearization after multiplication and automorphisms. Given its frequent invocation and resource-intensive nature, the efficiency of the key-switching procedure has a profound impact on the overall performance of an FHE system.

This bottleneck has drawn considerable attention from the research community, leading to continuous efforts on developing more efficient key-switching algorithms. Among these, the technique by Kim, Lee, Seo, and Son (KLSS) [6] is particularly noteworthy. It reduces the complexity, measured in the number of Number Theoretic Transform (NTT) operations, from $\mathcal{O}\left({\mathsf{\ell }}^2\right)$ to $\mathcal{O}\left(\mathsf{\ell }\right)$ with respect to the ciphertext level ℓ.

While the theoretical advantages of the KLSS algorithm are clear, its practical benefits depend heavily on an optimized implementation that can fully exploit modern hardware architectures. To date, however, implementations have often been scheme-specific or tailored to CPU environments.

In this work, we bridge this gap by presenting the first unified, GPU-accelerated implementation of the KLSS key-switching algorithm for three of the most prominent FHE schemes: BGV [7], BFV [8,9,10], and CKKS [11]. Our contributions are threefold:

• A CUDA-optimized GPU implementation of KLSS key switching for the BGV, BFV, and CKKS schemes.
• A comprehensive benchmark against CPU and prior state-of-the-art GPU implementations, demonstrating significant speedups.
• An in-depth analysis of the trade-off between single- and double-decomposition for key switching, specifically within the context of GPU-accelerated homomorphic encryption.

The remainder of this paper is organized as follows. Section 2 reviews the necessary background on FHE and GPU acceleration. Section 3 looks into the specifics of the FHE schemes and the key-switching procedure relevant to our work. Section 4 details the architecture of our unified GPU implementation. Section 5 presents our experimental setup and performance results. Section 6 provides a detailed discussion of our findings. Finally, Section 7 concludes the paper and discusses potential directions for future work.

2. Related Works

2.1. Fully Homomorphic Encryption

Since Gentry’s blueprint in 2009 [12], the field of FHE has largely been built on lattice-based cryptography. The security of these systems is rooted in the computational hardness of the Learning with Errors (LWE) and Ring-LWE (RLWE) problems [7,9,10,12,13,14,15,16]. The schemes based on the RLWE problem, such as BGV [7], BFV [8,9,10], and CKKS [11], have gained prominence due to their high computational efficiency. This efficiency stems from their ability to pack multiple data values into a single ciphertext, enabling parallel processing via Single Instruction, Multiple Data (SIMD) operations. The BGV and BFV schemes are designed for exact computations over finite fields, while the CKKS scheme is tailored for approximate arithmetic on real and complex values. This makes CKKS particularly well-suited for applications in privacy-preserving machine learning [2,11,17,18,19,20,21]. The practical implementation and academic study of these schemes are supported by many open-source libraries, including SEAL [22], HElib [23], and OpenFHE [24].

2.2. Research in Key Switching

Previous research on key switching [25] produced two primary techniques with distinct trade-offs. The Gentry, Halevi, and Smart (GHS) method is highly efficient, requiring only a linear number of NTTs [16]. However, this efficiency comes at the cost of either halving the modulus size or doubling the polynomial dimension to preserve security. In contrast, the Brakerski and Vaikuntanathan (BV) technique is more direct to implement but incurs a higher computational cost, involving a quadratic number of NTTs [10].

Hybrid key switching was developed to combine the digit decomposition technique from BV with the larger modulus strategy from GHS to strike a better balance [26]. More recent research [27] has continued to build upon the hybrid approach to further minimize the computational overhead. For instance, some work focuses on optimizing the selection of decomposition parameters for different ciphertext levels [28]. A more recent advancement, now considered the state-of-the-art, is the KLSS technique, which significantly reduces the computational workload by further optimizing the use of NTTs [6].

2.3. GPU-Accelerated FHE

To mitigate the substantial computational demands of FHE, researchers have turned to Graphics Processing Units (GPUs) for acceleration. The inherent parallelism of FHE, especially the SIMD batching, makes GPUs a natural fit for this task, and numerous studies have confirmed their effectiveness in accelerating homomorphic operations [29,30,31,32,33,34,35].

The research landscape for GPU acceleration can be divided based on the type of FHE scheme. For bit-wise schemes, the open-source library cuFHE was one of the first to provide a CUDA-based implementation for TFHE [36]. Subsequent work on FHEW and TFHE has introduced advanced parallelization strategies and memory-aware optimizations tailored to their unique computational patterns [37,38,39].

Simultaneously, a significant body of research has focused on accelerating word-type schemes like CKKS, BFV, and BGV, which are critical for arithmetic-heavy applications. The central aim is to reduce the computational overhead that impedes practical FHE deployment. To achieve this, researchers have developed optimizations at multiple levels, from algorithmic enhancements in key switching to software strategies like kernel fusion that reduce memory latency [40,41,42]. Other efforts have targeted hardware-specific features, such as leveraging Tensor Cores for further acceleration [43,44]. Most recently, the Cheddar library was introduced, demonstrating state-of-the-art performance by integrating these multi-level optimization techniques [45].

Most open-source library, like HEonGPU [42], provide implementations for previous variants of key-switching techniques (BV [10], GHS [16], Hybrid [26]). To the best of our knowledge, no existing GPU acceleration library offers an implementation for KLSS key switching or other double-decomposition based methods, a gap that directly motivated this work.

3. Preliminaries

The security of the Learning With Errors (LWE) problem stems from the computational hardness of recovering a secret vector from a system of linear equations that contains a small amount of noise. Formally, for a given modulus q and dimension n, an LWE instance is a pair $(\mathbf{a},b)\in {\mathbb{Z}}_q^{n+1}$. Here, $\mathbf{a}$ is a vector chosen uniformly at random, and b is derived as the inner product of $\mathbf{a}$ and a secret vector $\mathbf{s}\in {\mathbb{Z}}_q^n$, perturbed by a small error term $\mathbf{e}$:

$$b=\langle \mathbf{a},\mathbf{s}\rangle +\mathbf{e}(modq).$$

The error $\mathbf{e}$ is typically drawn from a discrete Gaussian distribution.

The Ring Learning With Errors (RLWE) problem is the ring-based analogue of LWE, offering improved efficiency by operating over polynomial rings. Within a ring ${\mathcal{R}}_q={\mathbb{Z}}_q\left[x\right]/\left(f\left(x\right)\right)$, the challenge is to find a secret polynomial $\mathbf{s}\in {\mathcal{R}}_q$. This is done using samples $(\mathbf{a},\mathbf{b})\in {\mathcal{R}}_q^2$, where $\mathbf{a}$ is a uniformly random polynomial and $\mathbf{b}$ is computed as

$$\mathbf{b}=\mathbf{a}·\mathbf{s}+\mathbf{e}(modq),$$

with $\mathbf{e}$ being an error polynomial with small coefficients.

In this work, we operate within the polynomial ring $\mathcal{R}=\mathbb{Z}\left[X\right]/(X^N+1)$, where N is a power of two. A ciphertext, denoted as $\mathbf{ct}$, is a pair of polynomials $({\mathbf{c}}_{\mathbf{0}},{\mathbf{c}}_{\mathbf{1}})$. The correctness of decryption relies on the relationship

$${\mathbf{c}}_{\mathbf{0}}+{\mathbf{c}}_{\mathbf{1}}·\mathbf{s}=\mathbf{m}+\mathbf{e},$$

where $\mathbf{s}$ is the secret key, $\mathbf{m}$ is the encoding of the plaintext $\mu$, and $\mathbf{e}$ is a small error term.

3.1. BGV, BFV, CKKS

We now summarize the core functionalities of three RLWE-based FHE schemes: BGV [7], BFV [8,9,10], and CKKS [11].

• Setup: The process begins by establishing the cryptographic environment based on a security parameter $\lambda$. This involves selecting public parameters $pp=(N,t,Q,P,{\chi }_{\mathrm{key}},{\chi }_{\mathrm{err}})$, which define the polynomial ring dimension N, plaintext modulus t, ciphertext modulus Q, and the distributions for key and error sampling (${\chi }_{\mathrm{key}}$ and ${\chi }_{\mathrm{err}}$).
• Key Generation: A secret key $\mathbf{sk}$ is created by sampling a polynomial $\mathbf{s}$ from the key distribution ${\chi }_{\mathrm{key}}$. The corresponding public key $\mathbf{pk}$ is a pair $(\mathbf{a},-\mathbf{as}+\mathbf{e})$, where $\mathbf{a}$ is a uniformly random polynomial in $R_Q$ and $\mathbf{e}$ is a small error from ${\chi }_{\mathrm{err}}$. Additionally, evaluation keys, such as relinearization keys ${\mathbf{ksk}}_{\mathbf{relin}}$ and automorphism keys ${\mathbf{ksk}}_{\mathbf{auto}}$, are generated for homomorphic operations.
• Encryption: To encrypt a plaintext $\mathbf{m}$, it is first encoded into a polynomial ${\mathbf{m}}^{*}$. The specific encoding method depends on the scheme:

  – 

  BFV: The message is scaled to the most significant bits: ${\mathbf{m}}^{*}=\lfloor {\displaystyle \frac{Q}{t}}\rceil ·{\left[\mathbf{m}\right]}_t$.

  – 

  BGV: A correction factor $\mu$ is applied: ${\mathbf{m}}^{*}={\left[\mu \mathbf{m}\right]}_t$.

  – 

  CKKS: The message is directly encoded as a polynomial: ${\mathbf{m}}^{*}=\mathbf{m}$.

  The final ciphertext $\mathbf{ct}=({\mathbf{c}}_{\mathbf{0}},{\mathbf{c}}_{\mathbf{1}})$ is then formed by adding this encoded message to a fresh encryption of zero, which is calculated as ${\mathit{Enc}}_{pk}\left(0\right)={[\mathbf{r}·(\mathbf{a},\mathbf{b})+\mathbf{t}·({\mathbf{e}}_{\mathbf{0}},{\mathbf{e}}_{\mathbf{1}})]}_Q$.

• Decryption: The original message is recovered from a ciphertext using the secret key $\mathbf{s}$.

  – 

  BFV:$\mathbf{m}=\lfloor {\displaystyle \frac{t}{Q}}·{[{\mathbf{c}}_{\mathbf{0}}+{\mathbf{c}}_{\mathbf{1}}·s]}_Q\rfloor$

  – 

  BGV:$\mathbf{m}=\left[{\mu }^{-1}{[{\mathbf{c}}_{\mathbf{0}}+{\mathbf{c}}_{\mathbf{1}}·s]}_Q\right]$.

  – 

  CKKS:$\mathbf{m}={[{\mathbf{c}}_{\mathbf{0}}+{\mathbf{c}}_{\mathbf{1}}·s]}_Q$

• Homomorphic Operations: These schemes support computations directly on encrypted data.

  – 

  Addition: The sum of two ciphertexts, $\mathbf{ct}$ and $\mathbf{ct}\prime$, is simply their component-wise sum: ${\mathbf{ct}}_{\mathrm{add}}=\mathbf{ct}+\mathbf{ct}\prime$.

  – 

  Multiplication: The product of two ciphertexts is computed, followed by a relinearization step using ${\mathbf{ksk}}_{\mathrm{relin}}$ to produce ${\mathbf{ct}}_{\mathrm{mult}}$.

  – 

  Automorphism: An automorphism (e.g., rotation) is applied to a ciphertext $\mathbf{ct}$ using a corresponding key ${\mathbf{ksk}}_{\mathbf{auto}}$ to yield the transformed ciphertext ${\mathbf{ct}}_{\mathrm{auto}}$.

3.2. Key Switching

Key switching is a generic technique for changing the secret key under which a ciphertext is encrypted, from an initial key ${\mathbf{s}}_{\mathbf{A}}$ to a target key ${\mathbf{s}}_{\mathbf{B}}$, without altering the underlying plaintext. A switching key, ${\mathbf{ksk}}_{s_A\to s_B}$, is defined as:

$${\mathbf{ksk}}_{s_A\to s_B}=({[{\mathbf{s}}_{\mathbf{A}}+\mathbf{a}·{\mathbf{s}}_{\mathbf{B}}+t\mathbf{e}]}_Q,-\mathbf{a})\in {\mathcal{R}}_Q^2$$

where $\mathbf{a}$ is a uniformly random polynomial in ${\mathcal{R}}_Q^2$ and $\mathbf{e}$ is a small error sampled from ${\chi }_{\mathrm{err}}$.

3.2.1. Relinearization

Relinearization is a specific application of key switching used after a homomorphic multiplication. The multiplication of two linear ciphertexts results in a quadratic ciphertext of degree 2, effectively encrypted under $(\mathbf{1},\mathbf{s},{\mathbf{s}}^{\mathbf{2}})$. Relinearization uses a key-switching key ${\mathbf{ksk}}_{\mathrm{relin}}$ to convert this quadratic ciphertext back into a linear one under the original basis $(\mathbf{1},\mathbf{s})$. Our implementation unifies the key-switching module for both relinearization and other operations (like automorphisms). For non-relinearization inputs, we structure the input as $[{\mathbf{c}}_{\mathbf{0}}^{*},\mathbf{0},{\mathbf{c}}_{\mathbf{1}}^{*}]$, where the term to be switched, ${\mathbf{c}}_{\mathbf{1}}^{*}$, is treated as the third component (${\mathbf{c}}_{\mathbf{2}}$) to maintain a consistent interface.

3.2.2. Modulus Switching

Modulus Switching is a technique for managing noise growth. It reduces the modulus of a ciphertext from a larger value Q to a smaller one $Q^{\prime }$ while preserving the plaintext. This is done by scaling the ciphertext coefficients by the ratio $Q^{\prime }/Q$ and rounding to the nearest integer:

$${\mathbf{ct}}^{\prime }=⌊{\displaystyle \frac{Q^{\prime }}{Q}}·\mathbf{ct}⌉(mod{Q}^{\prime })$$

4. GPU Acceleration for KLSS

4.1. The Double-Decomposition Approach

The KLSS key-switching technique [6] builds upon the prior state-of-the-art methods such as hybrid key switching, by introducing a double-decomposition strategy. As illustrated in Figure 1, after being raised to $Q_{\mathsf{\ell }}P$, both the input ciphertext ${\mathbf{ct}}_{\mathbf{A}}$ and the key-switching key $\mathbf{ksk}$ are additionally converted to an external base T for external product. In Section 4.2, we restructure the original Algorithm 1 to align with the massively parallel architecture of GPUs, thereby maximizing its computational throughput.

4.2. GPU Acceleration

To better leverage the massively parallel architecture of modern GPUs, we restructured the original algorithm into a two-stage process. The first stage is an offline preprocessing step, where all necessary data is precomputed and loaded into GPU global memory. The second stage performs the online calculation of the key-switching ciphertext based on a given input. These two stages are detailed in Algorithms 2 and 3, respectively.

4.2.1. Stage 1: Key Generation (Offline)

This module is executed once. All intermediate and final key data are generated and stored in the GPU’s global memory (Device memory) to avoid costly data transfers during the online phase.

4.2.2. Stage 2: GPU-Accelerated Key Switching (Online)

This module leverages the pre-computed key ${\mathbf{ksk}}_{double}$ from the GPU memory. The input ${\mathbf{c}}_i$ is first transferred to the GPU, all computations are performed on the device, and only the final result is transferred back.

Algorithm 1 KLSS Key Switching
Input: Context parameters: Bases $q,P,E$; Decompositions $d,d_{double}$. Input: Offline: Secret keys ${\mathbf{s}}_{\mathbf{A}},{\mathbf{s}}_{\mathbf{B}}$. Input: Online: Ciphertext component ${\mathbf{c}}_i\in {\mathcal{R}}_q$. Output: Switched ciphertext parts $({\tilde{\mathbf{c}}}_0,{\tilde{\mathbf{c}}}_1)\in {\mathcal{R}}_{Q_{\mathsf{\ell }}}$.
STAGE 1. Generates ${\mathbf{ksk}}_{double}$ and store.   1:  for$l\leftarrow 0$ to d do   2:        Sample ${\mathbf{a}}_l,{\mathbf{e}}_l$. Compute raw parts:   3:        ${\mathbf{ksk}}_{0,l}\leftarrow {[{\mathbf{a}}_l{\mathbf{s}}_{\mathbf{B}}+t{\mathbf{e}}_l+P·\mathcal{B}{\left({\mathbf{s}}_{\mathbf{A}}\right)}_l]}_{Q_{\mathsf{\ell }}P}$   4:        ${\mathbf{ksk}}_{1,l}\leftarrow {[-{\mathbf{a}}_l]}_{Q_{\mathsf{\ell }}P}$        // BaseConvert (Map from $Q_{\mathsf{\ell }}P\to T$)   5:  for$j\in \{0,1\},l\in [0,d],m\in [0,d_{double}-1]$do
6:        $\mathbf{poly}\leftarrow \tilde{\mathcal{D}}{\left({\mathbf{ksk}}_{j,l}\right)}_m$	▹ Extract digit
7:        ${\mathbf{ksk}}_{double,j,l,m}\leftarrow {\mathrm{NTT}}_{\mathrm{fwd}}\left(\mathrm{BaseExt}(\mathbf{poly},Q_{\tilde{m}},T)\right)$
▹ Store in NTT form in Ring ${\mathcal{R}}_T$ for fast online dot products.
STAGE 2. Transforms ${\mathbf{c}}_i$ using ${\mathbf{ksk}}_{double}$.        1. Input Preparation (Decompose & BaseConvert)   8:  for$l\leftarrow 0$ to d do
9:        $\mathbf{poly}\leftarrow \mathcal{D}{\left({\mathbf{c}}_i\right)}_l$	▹ Decompose input ${\mathbf{c}}_i$
10:       ${\mathbf{c}}_{\mathrm{ext},l}\leftarrow {\mathrm{NTT}}_{\mathrm{fwd}}\left(\mathrm{BaseExt}(\mathbf{poly},q_{\tilde{l}},T)\right)$
▹ Move input parts to Ring ${\mathcal{R}}_T$ and transform to NTT.
2. Inner Product  11:  for$j\in \{0,1\}$do  12:        Initialize accumulator ${\mathbf{acc}}_j\leftarrow 0\in {\mathcal{R}}_T$.  13:        for $m\leftarrow 0$ to $d_{double}-1$ do  14:              $\mathbf{temp}\leftarrow 0$  15:              for $l\leftarrow 0$ to d do
16:                    $\mathbf{temp}\leftarrow \mathbf{temp}+{\mathbf{c}}_{\mathrm{ext},l}·{\mathbf{ksk}}_{double,j,l,m}$	▹ Pointwise Mult-Add
17:               ${\mathbf{acc}}_j\leftarrow {\mathbf{acc}}_j+\mathbf{temp}·{\mathrm{NTT}}_{\mathrm{fwd}}\left({\tilde{\mathcal{B}}}_m\right)$	▹ Reconstruct in ${\mathcal{R}}_T$
18:        ${\mathbf{c}}_j^{\prime \prime }\leftarrow {\mathrm{NTT}}_{\mathrm{inv}}\left({\mathbf{acc}}_j\right)$	▹ Inverse NTT in Ring ${\mathcal{R}}_T$
3. Post-Processing (BaseConvert & ModDown)  19:  for$j\in \{0,1\}$do
20:        ${\mathbf{c}}_j^{\prime }\leftarrow \mathrm{BaseExt}({\mathbf{c}}_j^{\prime \prime },T,Q_{\mathsf{\ell }}P)$	▹ Convert back to large modulus
21:        ${\mathbf{ffi}}_j\leftarrow -t·\mathrm{BaseExt}({\left[{\mathrm{NTT}}_{\mathrm{inv}}\left(t^{-1}{\mathbf{c}}_j^{\prime }\right)\right]}_P,P,Q_{\mathsf{\ell }})$	▹ Correction factor
22:        ${\tilde{\mathbf{c}}}_j\leftarrow {\left[P^{-1}({\mathrm{NTT}}_{\mathrm{inv}}\left({\mathbf{c}}_j^{\prime }\right)+{\mathbf{ffi}}_j)\right]}_{Q_{\mathsf{\ell }}}$	▹ Scale down to $Q_{\mathsf{\ell }}$
23:  return$({\tilde{\mathbf{c}}}_0,{\tilde{\mathbf{c}}}_1)$

Algorithm 2 GPU-Accelerated Key Generation for KLSS
Input: New secret key ${\mathbf{s}}_{\mathbf{B}}\in {\mathcal{R}}_{Q_{\mathsf{\ell }}P}$, old secret key ${\mathbf{s}}_{\mathbf{A}}\prime \in {\mathcal{R}}_{Q_{\mathsf{\ell }}P}$ (on Device). Output: Double-decomposition key ${\mathbf{ksk}}_{double}$ stored in GPU Device memory.        // Step 1: Generate standard key parts in a batched kernel.
1:  parallel for $l\in [0,d-1]$do	▹ Launch a kernel to process all $\omega$ parts in parallel.
2:  Sample a batch of d polynomials ${\mathbf{a}}_l$ and ${\mathbf{e}}_l$ on the GPU.
▹ All polynomial arithmetic is coefficient-wise and parallelized within the kernel.
3:  ${\mathbf{ksk}}_{0,l}\leftarrow {[{\mathbf{a}}_l·{\mathbf{s}}_{\mathbf{B}}+t{\mathbf{e}}_l+P·\mathcal{B}{\left({\mathbf{s}}_{\mathbf{A}}\right)}_l]}_{QP}$
4:  ${\mathbf{ksk}}_{1,l}\leftarrow {[-{\mathbf{a}}_l]}_{QP}$        // Step 2: Apply second decomposition and base-extend in a single, large-scale kernel.
5:  parallel for $(j,l,m)\in \{0,1\}\times [0,d-1]\times [0,d_{double}-1]$do	▹ A massively parallel kernel.
▹ Each thread block be assigned to compute one or more ${\mathbf{ksk}}_{double,j,l,m}$.
6:  Decompose ${\mathbf{ksk}}_{j,l}$ to get $\tilde{\mathcal{D}}{\left({\mathbf{ksk}}_{j,l}\right)}_m$.	▹ RNS decomposition is coefficient-wise.
7:  Let $\mathbf{poly}=\tilde{\mathcal{D}}{\left({\mathbf{ksk}}_{j,l}\right)}_m$.
8:  ${\mathbf{ksk}}_{double,j,l,m}\leftarrow \mathrm{BaseExt}(\mathbf{poly},Q_{\tilde{m}},T)$.	▹ Batched BaseExt with error correction.
9:  return ${\mathbf{ksk}}_{double}$ (residing on the GPU Device).

Algorithm 3 GPU-Accelerated Double-Decomposition KLSS Key Switching.
Input: Ciphertext component ${\mathbf{c}}_i\in {\mathcal{R}}_{Q_{\mathsf{\ell }}}$ (on Host), key ${\mathbf{ksk}}_{double}$ (on Device). Output: Switched ciphertext components $({\tilde{\mathbf{c}}}_0,{\tilde{\mathbf{c}}}_1)\in {\mathcal{R}}_{Q_{\mathsf{\ell }}}^2$ (on Host).   1:  Transfer ${\mathbf{c}}_i$ from Host to GPU Device memory.        // Step 1: Batched Input Extension.   2:  Decompose ${\mathbf{c}}_i$ into $(\mathcal{D}{\left({\mathbf{c}}_i\right)}_0,\dots ,\mathcal{D}{\left({\mathbf{c}}_i\right)}_{d-1})$ on the GPU.
3:  parallel for $l\in [0,d-1]$ do	▹ Launch a kernel for batched base extension.
4:  ${\mathbf{c}}_{\mathrm{ext},l}\leftarrow \mathrm{BaseExt}(\mathcal{D}{\left({\mathbf{c}}_i\right)}_l,q_{\tilde{l}},T)$.	▹ Batched BaseExt
// Step 2: Batched Dot Product in ${\mathcal{R}}_E$.
5:  parallel for $(j,l,m)\in \{0,1\}\times [0,d]\times [0,d_{double}-1]$ do	▹ Batched NTTs and multiplications.
6:  ${\mathbf{temp}}_{j,l,m}\leftarrow {\mathrm{NTT}}_{\mathrm{fwd}}\left({\mathbf{c}}_{\mathrm{ext},l}\right)\odot {\mathrm{NTT}}_{\mathrm{fwd}}\left({\mathbf{ksk}}_{double,j,l,m}\right)$.	▹⊙ is coefficient-wise product.
7:  parallel for $(j,m)\in \{0,1\}\times [0,d_{double}-1]$ do	▹ Parallel reduction over index l.
8:  ${\mathbf{c}}_{j,m}^{\prime \prime }\leftarrow {\sum }_{l=0}^d{\mathbf{temp}}_{j,l,m}$.	▹ Kernel using parallel reduction.
9:  parallel for $j\in \{0,1\}$ do	▹ Parallel CRT reconstruction (another reduction).
10:  ${\mathbf{c}}_j^{\prime \prime }\leftarrow {\sum }_{m=0}^{d_{double}-1}{\mathbf{c}}_{j,m}^{\prime \prime }\odot {\mathrm{NTT}}_{\mathrm{fwd}}\left({\tilde{\mathcal{B}}}_m\right)$.        // Step 3: Batched Base Conversion from ${\mathcal{R}}_T$ back to ${\mathcal{R}}_{Q_{\mathsf{\ell }}P}$.  11:  parallel for$j\in \{0,1\}$ do
12:  ${\mathbf{c}}_j^{\prime }\leftarrow \mathrm{BaseExt}({\mathrm{NTT}}_{\mathrm{inv}}\left({\mathbf{c}}_j^{\prime \prime }\right),T,Q_{\mathsf{\ell }}P)$.	▹ Batched ${\mathrm{NTT}}_{\mathrm{inv}}$ and BaseExt.
// Step 4: Batched Final Scaling.  13:  parallel for $j\in \{0,1\}$ do
14:  ${\mathbf{ffi}}_j\leftarrow -t·\mathrm{BaseExt}({\left[{\mathrm{NTT}}_{\mathrm{inv}}\left(t^{-1}{\mathbf{c}}_j^{\prime }\right)\right]}_P,P,Q_{\mathsf{\ell }})$.	▹ Batched kernels for all steps.
15:  ${\tilde{\mathbf{c}}}_j\leftarrow {\left[P^{-1}({\mathrm{NTT}}_{\mathrm{inv}}\left({\mathbf{c}}_j^{\prime }\right)+{\mathbf{ffi}}_j)\right]}_{Q_{\mathsf{\ell }}}$.  16:  Transfer $({\tilde{\mathbf{c}}}_0,{\tilde{\mathbf{c}}}_1)$ from GPU Device to Host memory.  17:  return $({\tilde{\mathbf{c}}}_0,{\tilde{\mathbf{c}}}_1)$.

4.3. Unified Framework for BFV, BGV, and CKKS

While the original KLSS paper focused primarily on the CKKS scheme, we extended the implementation to encompass all word-type schemes, including BFV and BGV. By designing the framework illustrated in Figure 2, we developed a unified implementation that achieves comparable efficiency across all three schemes, as detailed in

Table 1. Per ciphertext key switching latency for Hybrid and KLSS methods for BFV, BGV, and CKKS schemes on an A100 GPU. All latency values are in milliseconds (ms).

Set #	BFV			BGV			CKKS
	Hybrid [26,41]	Ours	Speedup	Hybrid [26,41]	Ours	Speedup	Hybrid [26,41]	Ours	Speedup
	(ms)	(ms)		(ms)	(ms)		(ms)	(ms)
1	0.94	0.85	1.10×	1.03	0.97	1.06×	1.00	0.95	1.06×
2	0.61	0.68	0.89×	0.67	0.74	0.91×	0.66	0.72	0.92×
3	0.49	0.71	0.69×	0.55	0.81	0.67×	0.53	0.73	0.73×
4	1.36	1.19	1.15×	1.49	1.36	1.10×	1.48	1.32	1.12×
5	0.86	0.79	1.09×	0.96	0.89	1.08×	0.92	0.88	1.04×
6	0.64	0.79	0.80×	0.75	0.85	0.89×	0.71	0.87	0.81×
7	1.86	1.51	1.23×	1.93	1.63	1.18×	1.94	1.67	1.17×
8	1.14	1.03	1.11×	1.20	1.13	1.07×	1.17	1.12	1.05×
9	0.80	0.92	0.88×	0.89	1.03	0.87×	0.91	1.02	0.89×
10	5.58	3.30	1.69×	5.66	3.73	1.52×	5.67	3.62	1.57×
11	3.46	2.96	1.17×	3.55	3.23	1.10×	3.56	3.17	1.12×
12	2.48	2.29	1.09×	2.70	2.58	1.05×	2.70	2.53	1.07×
13	1.91	2.02	0.95×	2.11	2.26	0.94×	2.04	2.30	0.89×
14	8.62	4.41	1.95×	8.62	4.77	1.81×	8.54	4.72	1.81×
15	5.23	4.13	1.27×	5.39	4.53	1.19×	5.32	4.44	1.20×
16	3.90	2.87	1.36×	4.07	3.23	1.26×	4.01	3.29	1.22×
17	2.89	2.63	1.10×	3.09	2.91	1.06×	3.06	2.92	1.05×
18	12.00	5.81	2.06×	12.12	6.29	1.93×	12.17	6.27	1.94×
19	7.41	5.27	1.41×	7.52	5.68	1.32×	7.55	5.68	1.33×
20	5.22	3.73	1.40×	5.51	4.15	1.33×	5.38	4.15	1.30×
21	4.15	3.14	1.32×	4.33	3.62	1.20×	4.26	3.62	1.17×

and

Table 2. Per-ciphertext key switching latency and performance comparison for Hybrid and KLSS methods across BFV, BGV, and CKKS schemes on an NVIDIA RTX 4090 GPU.

Set #	BFV			BGV			CKKS
	Hybrid [26,41]	Ours	Speedup	Hybrid [26,41]	Ours	Speedup	Hybrid [26,41]	Ours	Speedup
	(ms)	(ms)		(ms)	(ms)		(ms)	(ms)
1	0.65	0.60	1.07×	0.71	0.67	1.06×	0.71	0.67	1.05×
2	0.37	0.45	0.83×	0.41	0.51	0.80×	0.40	0.50	0.80×
3	0.29	0.41	0.71×	0.34	0.47	0.72×	0.33	0.46	0.72×
4	0.91	0.85	1.07×	0.98	0.92	1.06×	0.97	0.91	1.06×
5	0.54	0.54	1.00×	0.58	0.60	0.97×	0.57	0.59	0.98×
6	0.39	0.47	0.83×	0.44	0.53	0.82×	0.42	0.53	0.79×
7	1.20	1.15	1.04×	1.29	1.24	1.04×	1.28	1.23	1.04×
8	0.73	0.70	1.04×	0.79	0.77	1.02×	0.78	0.76	1.03×
9	0.51	0.56	0.91×	0.57	0.64	0.90×	0.56	0.62	0.91×
10	3.84	3.03	1.27×	4.03	3.23	1.25×	4.04	3.21	1.26×
11	2.37	2.59	0.92×	2.52	2.75	0.92×	2.51	2.73	0.92×
12	1.74	1.88	0.93×	1.88	2.03	0.93×	1.86	2.02	0.92×
13	1.34	1.58	0.85×	1.46	1.76	0.83×	1.45	1.72	0.84×
14	6.18	4.15	1.49×	6.38	4.42	1.44×	6.38	4.40	1.45×
15	3.83	3.85	0.99×	3.90	4.07	0.96×	3.89	4.06	0.96×
16	2.86	2.56	1.12×	2.94	2.78	1.06×	2.91	2.77	1.05×
17	2.19	2.22	0.99×	2.26	2.43	0.93×	2.24	2.42	0.93×

. Additionally, we adapted our implementation to align with the original Phantom library, where ciphertexts for BGV and CKKS are stored in the NTT domain.

5. Results

5.1. Experimental Setup

Our performance evaluation was conducted on two distinct hardware platforms: a consumer-grade NVIDIA RTX 4090 GPU and a datacenter-class NVIDIA A100 GPU. The A100 was specifically required for evaluating large parameter sets, as the substantial memory footprint of the associated key-switching keys exceeded the memory capacity of the consumer-grade RTX 4090. For our CPU performance baseline, we reference the results reported in [6]. Those experiments were performed on a system running Ubuntu 20.04.3 LTS, equipped with 192 GB of RAM and an Intel Xeon Platinum 8268 CPU (2.90 GHz), with each test utilizing a single thread. The specific parameters used for all benchmarks are detailed in

Table 3. Summary of Parameters used for log N = 15 and log N = 16.

log N	Set #	$\tilde{\mathit{l}}$	ℓ	r	Optimal ${\mathit{r}}_{\mathbf{double}}$
15	1	16	15	1	4
	2	16	14	2	5
	3	16	13	3	5
	4	20	19	1	4
	5	20	18	2	5
	6	20	17	3	5
	7	24	23	1	4
	8	24	22	2	5
	9	24	21	3	7
16	10	32	31	1	5
	11	32	30	2	3
	12	32	29	3	3
	13	32	28	4	6
	14	40	39	1	5
	15	40	38	2	3
	16	40	37	3	5
	17	40	36	4	6
	18	48	47	1	5
	19	48	46	2	3
	20	48	45	3	5
	21	48	44	4	6

.

5.2. GPU Acceleration Performance

As shown in

Table 4. Per ciphertext key switching latency of CPU vs. GPU Implementation (this work).

Set #	CPU [6] (ms)	NVIDIA A100		NVIDIA RTX 4090
		Time (ms)	Speedup	Time (ms)	Speedup
1	84	0.95	88.59×	0.67	124.66×
2	62	0.72	86.68×	0.50	123.04×
3	66	0.73	90.35×	0.46	143.87×
4	112	1.32	85.01×	0.91	122.69×
5	85	0.88	96.15×	0.59	144.52×
6	87	0.87	99.61×	0.53	164.61×
7	140	1.67	84.07×	1.23	113.68×
8	110	1.12	98.13×	0.76	144.39×
9	101	1.02	99.26×	0.62	162.05×
10	451	3.62	124.75×	3.21	140.57×
11	352	3.17	110.95×	2.73	128.96×
12	335	2.53	132.63×	2.02	165.50×
13	301	2.30	131.01×	1.72	174.67×
14	604	4.72	127.92×	4.40	137.34×
15	508	4.44	114.31×	4.06	125.14×
16	479	3.29	145.43×	2.77	172.64×
17	438	2.92	149.91×	2.42	181.35×

, our GPU implementation achieves significant speedups, ranging from $84\times$ to $150\times$ on the NVIDIA A100 and from $114\times$ to $181\times$ on the NVIDIA RTX 4090 (including the host-device data transfer and kernel initialization). This performance difference is attributed to the distinct architectural trade-offs between A100 and RTX 4090. While the A100 features higher memory and bandwidth, the RTX 4090 has a substantially greater number of CUDA cores (16,384 versus 6912 for the A100). The higher speedup on the RTX 4090 indicates that our algorithm is predominantly compute-bound, and thus benefits more from the larger count of parallel processors than from the A100’s superior memory bandwidth.

5.3. Comparison with Hybrid Key Switching

A subject of ongoing discussion in the field is the relative performance of hybrid key-switching techniques (single decomposition) versus the KLSS algorithm [46] (double decomposition). We conduct a direct performance evaluation, comparing our implementation of the KLSS algorithm against a state-of-the-art, GPU-optimized hybrid method by Yang et al. [41]. To ensure a fair and direct comparison, we applied an identical GPU acceleration strategy to both algorithms. The results, presented in Table 1 and Table 2, indicate that neither method demonstrates universal superiority.

Our analysis shows that the hybrid KLSS method, even when configured with optimal decomposition parameters, does not consistently outperform the simpler, more memory-efficient single-decomposition strategy. Specifically, the performance advantage of KLSS diminishes as the parameter r increases or as the multiplication depth ℓ decreases. This observation aligns with the theoretical insights provided by [46], although their experimental validation was confined to CPU architectures.

Conversely, the KLSS method demonstrates superior performance for parameter sets with a large multiplication depth ℓ and a small number of RNS decomposition word size r for the single-decomposition part. Under these favorable conditions, such as those of parameter Set #14, the KLSS approach achieves a speedup of up to 1.49× over the single-decomposition strategy. A more detailed discussion of these trade-offs is presented in Section 6.

6. Discussion

6.1. Single- or Double-Decomposition? A Trade-Off Analysis

The choice between single and double decomposition represents a fundamental trade-off between computational latency and available multiplicative depth. Mono & Güneysu [46] recently contended that prior comparisons to hybrid key switching in [6] were inequitable. They demonstrated that for latency-optimized scenarios, a single-decomposition approach configured with a large gadget vector dimension r (and thus a decomposition base $d=1$) can match or even surpass the performance of double decomposition. Our own experiments, detailed in Table 1 and Table 2, corroborate this finding in a GPU-accelerated context: for shallow circuits where raw speed is paramount, single decomposition is indeed the superior choice.

However, this latency-centric perspective does not capture the full picture. We argue that the double decomposition method remains a crucial tool in scenarios where maximizing multiplicative depth is the primary constraint. This is particularly relevant for applications involving deep arithmetic circuits where bootstrapping is either unavailable or prohibitively expensive. In such cases, the number of available levels, ℓ, is a fixed resource that dictates the complexity of the computable functions.

The advantage of double decomposition lies in its management of the modulus chain. The total modulus is composed of primes for the ciphertext modulus Q and primes for the special modulus P used in key switching. The number of levels, ℓ, is determined by the number of primes composing Q. To achieve low latency with single decomposition, one must use a large r, which in turn requires a large P constructed from multiple prime moduli. These primes are thus consumed by P and are unavailable for Q, effectively reducing the maximum achievable depth ℓ.

In contrast, double decomposition allows for a much smaller special modulus P. By setting the inner gadget dimension $r=1$, P can be constructed from a single prime from the modulus chain. This minimizes the resources allocated to key switching and maximizes the number of primes available for the ciphertext modulus Q. Consequently, for a given set of cryptographic parameters, double decomposition enables a greater multiplicative depth ℓ. Therefore, the recommendation by [46] to use $d=1$ is not universally optimal. The choice of decomposition scheme is not absolute but rather a strategic decision dictated by application-specific requirements: single decomposition for speed in shallow circuits, and double decomposition for depth in complex, non-bootstrapped computations.

6.2. GPU Key Size Constraints

Beyond the latency-focused discussion in [46], a critical and often decisive factor for practical GPU implementations is the strictly limited nature of on-chip GPU memory (VRAM). To achieve the high throughput promised by GPU acceleration, the entirety of the evaluation keys must reside in VRAM to avoid performance-killing data transfers over the PCIe bus. The choice of decomposition scheme directly impacts the feasibility of this requirement.

This trade-off between decomposition parameters and memory consumption is vividly illustrated in the provided plot, which we will reference as Figure 3. The figure plots the key-switching key size against the required multiplication depth, ℓ, for various single- and double-decomposition configurations. Several clear trends emerge:

• Impact of Gadget Dimension: The size of the gadget vector dimension, r (and $r_{double}$ for double decomposition), has a dramatic effect on the total key size. In the single-decomposition case, increasing the dimension from $r=2$ to $r=8$ results in a significant increase in memory footprint.
• The Cost of Double Decomposition: The penalty is even more pronounced with double decomposition. As shown in the figure, moving from ‘Double-Decomp (r = 3, rdouble = 2)’ to ‘(r = 3, rdouble = 8)’ causes a steep rise in key size. Crucially, for comparable parameters, double decomposition consistently requires more memory than single decomposition.

The key sizes shown, reaching up to 0.5 GB, are already substantial. However, it is vital to recognize that these values represent a best-case scenario. The plot likely assumes a moderate polynomial degree N. In practice, higher security requirements often necessitate larger parameters like N = 65,536, which would immediately quadruple the key sizes shown.

Table 5. Summary of maximum key sizes for different polynomial degrees N.

Polynomial Degree N	ℓ	Key Size (MB)
		Max Single Decomposition	Max Double Decomposition
$2^{12}$	60	221	9071
$2^{13}$	60	443	18,143
$2^{14}$	60	885	36,285
$2^{15}$	60	1770	72,570
$2^{16}$	60	3540	145,140

shows the maximum size for a single key-switching key with the different techniques. With double decomposition, a single key-switching key can demand up to 145 GB in the worst case. Furthermore, Figure 3 only accounts for the key switching (relinearization) key. A complete application requires a full set of Galois keys for operations like vector rotations, and the total size of these keys can easily be an order of magnitude larger than the relinearization key alone. Figure 4 further illustrates the dramatic growth of key size with $r_{double}$, while the corresponding efficiency gains fail to keep pace.

When these scaling factors are considered, a key size of 0.5 GB can easily inflate to 20–40 GB or more. This brings the memory requirement into direct conflict with the VRAM capacity of many common GPUs (e.g., 24 GB on an NVIDIA RTX 4090). If the total key size exceeds available VRAM, the system is forced to swap key data between system RAM and VRAM, creating an I/O bottleneck that negates the computational advantages of the GPU. Therefore, while double decomposition may offer greater multiplicative depth, its associated memory cost can render it impractical for GPU acceleration, making single decomposition the only viable option in memory-constrained environments.

7. Conclusions and Future Work

In this work, we addressed the growing need for high-performance and flexible GPU acceleration in FHE. We bridged a significant gap in the existing ecosystem by presenting the first unified, GPU-accelerated implementation of the KLSS key-switching algorithm for the BGV, BFV, and CKKS schemes.

Our extensive benchmarks confirmed that our CUDA-optimized implementation delivers significant speedups over both multi-core CPU baselines and prior state-of-the-art GPU implementations, reinforcing the critical role of GPUs in advancing practical FHE. More importantly, our work provides a detailed analysis of the trade-offs in key-switching design for GPU architectures. We experimentally validated the findings of Mono and Güneysu [46] that single decomposition offers superior latency, but we also demonstrated that this comes at the cost of reduced multiplicative depth. Our analysis highlights that double decomposition, despite its higher latency and memory footprint, remains an essential tool for depth-constrained applications where its efficient use of the modulus chain is paramount. This establishes a clear framework for practitioners: the choice is a strategic balance between latency, circuit depth, and the stringent memory limitations of GPU hardware.

Looking ahead, our work opens several promising avenues for future research. The unified framework and optimized kernels presented here are intentionally designed for extensibility. An immediate and natural extension is the integration of bootstrapping for all three schemes. Our proposed kernels can be directly leveraged for this purpose, as efficient key switching is a core component of the bootstrapping algorithm. Therefore, our work serves as a critical first step toward a complete, GPU-accelerated bootstrapping solution, which would enable computation of arbitrary depth. Further performance gains could be realized by exploring more advanced CUDA features, optimizing memory transfer patterns, and investigating the use of specialized hardware units like Tensor Cores for polynomial arithmetic. Finally, extending our unified architecture to support other parallel platforms, such as FPGAs or other GPU vendors via APIs like SYCL, would further broaden the impact and accessibility of high-performance homomorphic encryption.