Feasibility Study of CUDA-Accelerated Homomorphic Encryption and Benchmarking on Consumer-Grade and Embedded GPUs

Abstract

Fully Homomorphic Encryption (FHE) provides strong data confidentiality during computation but often suffers from high latency on Central Processing Units (CPUs). This study evaluates Graphics Processing Unit (GPU) acceleration for modern FHE libraries across a laptop (NVIDIA GTX 1650 Ti), a server (NVIDIA RTX 4060), and a Jetson Nano 2 GB embedded GPU. We benchmark key generation, arithmetic operations, Boolean-gate evaluation and scheme-specific tasks such as relinearization and key switching, using library-provided benchmarks with an explicit baseline (operation scope, timing boundaries, and parameter tuples). Moreover, we compare GPU-native libraries (NuFHE, Phantom-FHE, and Troy-Nova) with CPU-oriented ones (Microsoft SEAL, HElib, OpenFHE, Cupcake, and TFHE-rs). Results show GPUs deliver significant speedups for targeted operations. For example, NuFHE’s NVIDIA CUDA (Compute Unified Device Architecture) backend achieves about 1.4× faster Boolean-gate evaluation on the laptop and 3.4× faster on the server compared to its OpenCL backend. Likewise, RLWE (Ring Learning With Errors)-based schemes (BFV, CKKS, and BGV) see marked gains for polynomial arithmetic such as Number Theoretic Transform (NTT) when executed via Phantom-FHE. However, attempts to add CUDA support to Microsoft SEAL reveal four main challenges: high-precision modular arithmetic on GPUs, sequential dependencies in SEAL’s design, limited GPU memory and complex build-system changes. In light of these findings, we propose revised guidelines for GPU-first FHE libraries and practical recommendations for deploying high-throughput, privacy-preserving solutions on modern GPUs.

1. Introduction

Fully Homomorphic Encryption (FHE) represents one of cryptography’s most significant theoretical and practical breakthroughs, enabling arbitrary computations on encrypted data without requiring decryption. First conceptualized by Rivest, Adleman, and Dertouzos in 1978, the problem remained unsolved until Craig Gentry’s groundbreaking 2009 construction [1], which demonstrated the first fully homomorphic encryption scheme capable of evaluating arbitrary circuits on ciphertexts.

Gentry’s original lattice-based construction, while revolutionary, suffered from severe practical limitations, with encryption and evaluation times measured in hours or days. This sparked a decade of intensive research leading to significant improvements across three generations of FHE schemes. The second generation, exemplified by BGV [2] and BFV [3], eliminated expensive bootstrapping for bounded-depth circuits and introduced efficient SIMD (Single Instruction, Multiple Data) operations through polynomial-packing techniques. The third generation brought fast bootstrapping solutions, notably FHEW [4] and TFHE [5], reducing bootstrap times from hours to milliseconds and enabling practical Boolean-circuit evaluation.

Despite these advances, computational performance remains the primary barrier to widespread FHE adoption. Even the most optimized CPU implementations exhibit slowdowns on the order of 10³–10⁶× compared to plaintext operations [6]. This performance gap has motivated extensive research into hardware acceleration using specialized platforms, including FPGAs, ASICs, and GPUs.

GPU acceleration has emerged as particularly promising for FHE workloads due to the inherently parallel nature of polynomial arithmetic underlying modern schemes. The core operations, Number Theoretic Transform (NTT), modular arithmetic on large integers, and matrix–vector multiplications, map naturally to GPU architectures with thousands of parallel processing cores. Early GPU implementations demonstrated significant speedups, with optimized NTT kernels achieving 10–100× acceleration over CPU baselines [7,8].

However, existing GPU acceleration research primarily focuses on workstation-class hardware or specialized implementations, leaving practitioners deploying to consumer-grade and embedded systems without clear performance guidance. Furthermore, the integration of GPU acceleration into established CPU-centric libraries like Microsoft SEAL presents significant architectural challenges that remain underexplored in the literature.

Recent surveys highlight this gap. Zhang et al. [9] systematically analyzed 14 FHE accelerators across CPU, GPU, FPGA, and ASIC platforms, identifying that while GPU implementations show promise for specific operations, practical integration with mainstream FHE software stacks remains limited. The authors emphasize the critical need for hardware abstraction layers that enable seamless acceleration without requiring complete library rewrites.

This work addresses these gaps through an evaluation of CUDA-accelerated homomorphic encryption across diverse hardware platforms, ranging from high-end server GPUs to consumer laptops and embedded ARM devices. We systematically benchmark eight representative FHE libraries, including both GPU-native implementations (NuFHE, Phantom-FHE, and Troy-Nova) and well-established CPU-centric solutions (Microsoft SEAL, HElib, and OpenFHE), to quantify the acceleration benefits and identify deployment constraints across different performance tiers.

Our contributions include: (1) the first comprehensive cross-platform FHE performance analysis spanning server, laptop, and embedded GPU hardware; (2) a detailed analysis of the architectural challenges encountered when integrating CUDA support into Microsoft SEAL; (3) a quantitative comparison of GPU-native versus CPU-ported FHE implementations; and (4) practical deployment guidelines for FHE applications targeting consumer-grade and embedded hardware platforms. The results demonstrate that while GPU acceleration can provide dramatic speedups, with Troy-Nova achieving 16–61× improvements over CPU implementations, the benefits depend critically on library architecture, hardware specifications, and operation types. These findings provide essential guidance for practitioners navigating the complex landscape of FHE deployment options.

The rest of this article is organized as follows. Section 2 reviews related work on FHE benchmarking and GPU acceleration. Section 3 introduces the evaluated libraries and distinguishes CPU-first from GPU-native approaches. Section 4 discusses the practical challenges of integrating CUDA into Microsoft SEAL. Section 5 describes the experimental setup across laptop, server, and embedded platforms. Section 6 and Section 7 define the benchmarking baseline and security-level considerations for cross-library comparisons. Section 8 presents and analyzes the performance results. Finally, Section 9 concludes and outlines future work.

2. Related Work

Prior work on FHE performance can be broadly grouped into surveys and systematizations, benchmarking methodologies, and GPU-accelerated execution frameworks.

Surveys of FHE schemes and implementations provide context on the cost drivers of modern libraries and the tradeoffs between arithmetic and Boolean-style schemes [6,10,11]. In particular, Zhang et al. [9] systematize FHE accelerators across CPU, GPU, FPGA, and ASIC platforms and highlight that acceleration is often operation-specific and that integration with mainstream software stacks remains limited.

Several efforts aim to make performance comparisons across schemes and libraries more reproducible. FHEBench [12] empirically compares major FHE schemes using representative implementations from widely used libraries. Gouert et al. [13] propose the Terminator 2 Benchmark Suite and a compiler that targets multiple FHE backends to execute equivalent encrypted programs across libraries. These studies primarily target CPU-centric stacks and focus on scheme/library selection; our work complements them by isolating GPU acceleration effects across server, laptop, and embedded GPUs and by contrasting GPU-native libraries against CPU-first designs.

At the system level, ArctyrEX [14] demonstrates hardware-accelerated encrypted execution of general-purpose applications on GPUs (focusing on CGGI/TFHE-style gate bootstrapping) and introduces scheduling techniques for scaling across multiple GPUs. In parallel, Al Badawi and Polyakov [15] provide a practical overview of common bootstrapping methods and report comparative bootstrapping performance using OpenFHE and HElib implementations.

Our evaluation bridges these directions by reporting both Boolean-gate evaluation and RLWE-based arithmetic operations (e.g., NTT-heavy kernels, relinearization, and key switching) under a consistent timing scope, with an emphasis on feasibility and performance envelopes on consumer-grade and embedded GPUs.

3. Technologies Used

The following homomorphic encryption libraries and tools investigated or employed in the study are described below, along with their main characteristics and links to their official repositories:

3.1. Microsoft SEAL

Microsoft SEAL [16] is an open-source (MIT license) homomorphic encryption library developed in C++ by the Cryptography and Privacy Research group at Microsoft Research. SEAL implements the BFV (Brakerski–Fan–Vercauteren, for exact modular arithmetic), BGV (Brakerski–Gentry–Vaikuntanathan), and CKKS (Cheon–Kim–Kim–Song, for approximate floating-point arithmetic) homomorphic schemes. Recognized for its user-friendly API (Application Programming Interface) and high optimization on CPUs, SEAL supports addition and multiplication operations on encrypted integers or real numbers, as well as SIMD (Single Instruction, Multiple Data) packing techniques (batch encoding of multiple values into a single ciphertext) to accelerate vector calculations. However, SEAL does not offer native GPU support, which motivates exploring extensions via CUDA. The library is actively developed.

3.2. Cupcake

Cupcake [17] is an MIT-licensed library written in Rust that implements an additive version of the Fan–Vercauteren scheme (similar to BFV). It is oriented toward efficiency in homomorphic addition operations on vectors of 8-bit integers (it supports encrypting fixed-length vectors, e.g., 2048, and operating element-wise). Cupcake offers encryption, decryption, addition of two ciphertexts, and re-randomization of a ciphertext to renew its randomness. It does not implement homomorphic multiplication (being an additive partially homomorphic scheme), which simplifies its design and makes it very fast in its domain: homomorphic additions take microseconds. The project has seen little recent activity.

3.3. TFHE-rs

TFHE-rs [18] is a Rust implementation (BSD-3-Clause-Clear with Zama commercial patent license) of the TFHE (Torus FHE) scheme oriented toward Boolean operations and small integer arithmetic on encrypted data. Developed by Zama, it provides a Rust API, C bindings, and WebAssembly (a binary instruction format for a stack-based virtual machine, often shortened to Wasm) support, aiming to be a low-level, stable, simple, and high-performance library for all advanced TFHE functionalities. TFHE-rs supports Boolean operations by default (e.g., logic gates like AND, OR, XOR, and NAND) with programmable bootstrapping (refreshing ciphertexts after each operation to maintain unlimited computation capability) and GPU acceleration, and also offers a limited-precision integer API (up to 8 bits) using bit-packing tricks. It targets developers requiring full control over low-level homomorphic operations and is actively developed.

3.4. NuFHE

NuFHE [19] is an Apache-2.0 licensed implementation of FHE over the torus (TFHE) that leverages GPU acceleration, written in Python (with CUDA kernels and OpenCL support). Essentially, NuFHE allows evaluating homomorphic Boolean gates with the same functionality as TFHE, while executing heavy computations (like fast Fourier transforms (FFT) or NTT for bootstrapping) on a GPU. In fact, NuFHE reports performance improvements of ~100× compared to CPU-based TFHE, reducing NAND gate time from ~13 ms to ~0.13 ms per bit. This represents a significant leap for Boolean logic applications, though the project has not seen recent activity.

3.5. Troy-Nova

Troy-Nova [20] is a homomorphic encryption library (license unspecified) developed as a continuation of Troy, designed for CUDA GPUs. It implements RNS (Residue Number System) versions of the BFV, BGV, and CKKS schemes, closely mirroring Microsoft SEAL’s interface with high-level operations (addition, multiplication, and rotations) executed in parallel on GPUs. Troy-Nova includes optimized utilities for private computation applications, such as encrypted matrix multiplication (Bumblebee-inspired) and encrypted 2D convolutions (Cheetah-inspired). It requires CUDA 11.7+ and has been tested on high-end GPUs (NVIDIA RTX 4090, and A100). While not a mature commercial product, it represents progress toward GPU-accelerated FHE.

3.6. OpenFHE

OpenFHE [21] is a comprehensive open-source C++ library (BSD 2-Clause License) supporting BFV, BGV, CKKS, and TFHE/FHEW schemes (another family of FHE, often focused on Boolean operations). Featuring a modular design, it offers various bootstrapping levels and Python bindings. Primarily optimized for CPUs, it provides a versatile foundation for homomorphic encryption research and applications. This is being actively developed.

3.7. Phantom-FHE

Phantom-FHE [22] is a GPLv3-licensed CUDA/C++ library for GPU-accelerated RNS variants of BFV, BGV, and CKKS (bootstrapping not explicitly supported). Designed for high-performance GPU-based FHE, it targets computationally intensive applications.

3.8. HElib

HElib [23] is a well-established open-source C++ library (Apache License v2.0) implementing BGV (with bootstrapping) and CKKS schemes. Known for rich functionalities and scheme optimizations, it remains a maintained resource for advanced homomorphic encryption operations.

4. Limitations and Challenges Integrating CUDA

An earlier phase of this research into integrating CUDA with Microsoft SEAL highlighted several fundamental challenges. These challenges remain pertinent and are further contextualized by the performance of GPU-native libraries like Phantom-FHE.

The four main challenges identified are:

• Modular Arithmetic Hardware Limitations: SEAL’s RNS implementation uses prime moduli, q_i, up to 60 bits in length. Arithmetic on these moduli produces intermediate values of 128 bits that conflict with GPU architecture. Current GPUs do not have native 128-bit integer operations, so this arithmetic must be decomposed into smaller instructions. In CUDA, emulating these operations typically requires splitting values into 32-bit or 64-bit segments for Barrett or Montgomery reduction (algorithms for efficient modular arithmetic). This emulation increases the low-level GPU instruction count and register pressure per thread, reducing thread occupancy and overall parallelism.
• Inherent Sequential Dependencies: SEAL’s operation sequencing limits GPU utilization. A homomorphic multiplication involves several dependent stages: NTT, point-wise multiply, INTT (Inverse Number Theoretic Transform), then key switching, with each stage executed as CUDA kernel. The latency of launching each kernel (several microseconds) adds up, creating pipeline stalls and underutilizing GPU cores between stages. Similarly, batch encoding/decoding via SEAL’s BatchEncoder relies on iterative algorithms that cannot be vectorized, further limiting concurrency.
• NTT Memory Architecture Mismatch: Implementing the NTT on GPU surfaces memory constraints due to polynomial capacity barriers, where polynomials of a degree N ≥ 2¹⁴ exceed shared-memory and register budgets, forcing global-memory accesses. This is compounded by I/O amplification, as multi-prime RNS NTTs must be broken into staged computations, increasing data traffic compared to a fused on-chip approach. Additionally, memory management overhead arises because manual cudaMalloc/cudaFree for each NTT/INTT (unlike SEAL’s CPU memory pool) introduces latency variability and risks VRAM (Video Random Access Memory) exhaustion given FHE’s large buffer requirements.
• Architectural Integration Barriers: SEAL’s CPU-centric C++17 codebase, heavily reliant on templates and metaprogramming, impedes GPU offloading. This causes code fragmentation since porting templated routines requires separate GPU-specific paths, doubling code variants to maintain them. Build system friction also emerges when integrating NVCC (NVIDIA CUDA Compiler) into SEAL’s CMake (a cross-platform build system generator) setup, increasing build times and complicating cross-platform compatibility. Finally, debugging complexity increases due to the absence of device exceptions, prolonging validation and necessitating custom GPU test harnesses.

The performance achieved by Phantom-FHE, a library architected from the ground up for GPUs, underscores that overcoming these challenges typically requires a holistic, GPU-aware design rather than piecemeal kernel porting. These insights informed our performance tests, pinpointing which homomorphic operations (e.g., NTT and key-switching) can reap the greatest benefits and which hit diminishing returns due to sequential dependencies or memory bottlenecks.

5. Experimental Setup

All experiments were conducted on two different hardware platforms to contrast performance on a mid-range discrete GPU and an embedded device with a limited GPU. The environment is detailed below.

5.1. Laptop Environment (HP Pavilion Gaming)

An HP Pavilion Gaming laptop running Ubuntu 24.04.2 LTS (Long-Term Support) served as our primary mobile workstation for FHE library evaluation. The system features an Intel Core i5-10300H processor with 4 physical cores and 8 threads, paired with approximately 7.5 GB of system RAM. Graphics acceleration is provided by an NVIDIA GeForce GTX 1650 Ti GPU based on the Turing architecture, equipped with 1024 CUDA cores and 4 GB of GDDR6 (Graphics Double Data Rate 6) VRAM. The system utilized NVIDIA driver version 550.144.03 with CUDA 12.4 for full compatibility with CUDA-enabled libraries.

The software environment included GCC 13.3.0, CMake 3.28.3, and Python 3.12.3. All tested FHE libraries (Microsoft SEAL 4.1.2, Helib 2.3.0, Cupcake 0.2.1, NuFHE 0.0.3, and OpenFHE 1.3.1) compiled and executed successfully without modification on this platform. The GTX 1650 Ti, while providing moderate computational capability for single-precision operations, exhibits limitations for 64-bit integer arithmetic due to the absence of dedicated 64-bit ALUs (Arithmetic Logic Units). Additionally, the 4 GB VRAM constraint restricts the feasibility of larger FHE workloads, particularly those involving high-degree polynomial operations requiring substantial memory buffers.

5.2. Server Environment (High-Performance Workstation)

The server platform consisted of a high-performance workstation running Ubuntu 24.04.2 LTS, built around an Intel Core i9-13900 processor featuring 24 cores and 32 threads with 31 GB of system RAM. GPU acceleration was handled by an NVIDIA GeForce RTX 4060 based on the Ada Lovelace architecture, providing 3072 CUDA cores and 8 GB of GDDR6 VRAM. The system employed NVIDIA driver 570.133.07 with CUDA 12.8 for optimal library compatibility.

The development environment utilized GCC 13.3.0 and CMake 4.0.2, successfully supporting compilation and execution of all tested libraries including Microsoft SEAL, HElib, Cupcake, NuFHE, and OpenFHE. The RTX 4060’s substantially higher memory capacity compared to the laptop GPU enables evaluation of more demanding FHE workloads and larger parameter sets. The server’s superior computational resources and expanded VRAM make it particularly suitable for testing performance scaling across different circuit complexities and ciphertext sizes. This platform serves as our primary benchmark environment for assessing the upper bounds of FHE performance on consumer-grade hardware.

5.3. NVIDIA Jetson Nano 2 GB with JetPack 4.6

The NVIDIA Jetson Nano is an embedded platform integrating an ARM (Advanced RISC Machine, a processor architecture family) CPU and an NVIDIA Maxwell GPU with 128 CUDA cores. The model used has only 2 GB of total RAM (shared between CPU and GPU). JetPack 4.6 is the official software distribution based on Ubuntu 18.04 with support for CUDA 10.2 and accelerated libraries for the Nano. This environment represents an extreme low-power case: its GPU is much less powerful (around 472 GFLOPS (Giga Floating-point Operations Per Second) in FP16 (16-bit floating-point precision), lower FP32 performance, and virtually no efficient 64-bit capability) and the limited memory severely restricts the circuit/ciphertext sizes that can be handled.

On the Jetson Nano, compiling Microsoft SEAL with ARM support was attempted. The C++ library was successfully compiled (with some adjustments due to lower RAM availability during compilation). However, running large parameters (e.g., N = 2¹⁵ polynomials with several 50–60 bit primes) proved impractical: the 2 GB memory was quickly exhausted when generating keys and context. Therefore, only reduced configurations (e.g., N = 2¹² or 2¹³, fewer levels) were tested on this device. The Cupcake and TFHE-rs libraries (in Rust) could also be compiled for ARM; Cupcake, handling only 2048 coefficients, was usable, and TFHE-rs, operating on Booleans, also fit in memory, although its performance was slow due to the lack of powerful vector instructions on the Nano’s Cortex-A57 CPU.

It is also important to note that JetPack 4.6 provides a C++14 compiler and CUDA 10 support; this implies that some modern libraries written in C++17/20 require backporting or do not compile without modifications. In our case, TFHE-rs depended on Rust std (standard library) features that worked well on ARM, but SEAL (C++17) required ensuring the toolchain supported that standard. The Jetson Nano proved unsuitable for FHE workloads: although it demonstrates the feasibility of running homomorphic encryption on edge devices, computation times were orders of magnitude higher than on the laptop (even in CPU-only comparisons), and the possibility of using its Maxwell GPU for FHE acceleration was limited by incompatibility with 64-bit integers and memory scarcity. This reinforces the idea that, to exploit CUDA in FHE, more capable and recent generation dedicated GPUs are desirable.

Although more powerful embedded boards (e.g., Jetson AGX Xavier) exist, this paper’s reported results are strictly from the Jetson Nano 2 GB (Maxwell). We did not attempt or include any Xavier benchmarks here.

6. Benchmarking Baseline

This section defines the benchmarking baseline used for cross-library interpretation: operation scope, parameter disclosure, and timing boundaries. Because the reported data come from each repository’s own benchmark module, disclosure status is encoded with compact labels where applicable (Y/P/L/N/-) rather than inferred.

6.1. Operation Definitions

To make results comparable across heterogeneous benchmark suites, we first standardize what each timed primitive represents. Table 1 defines the operations reported in this study and clarifies the timing scope for each (e.g., whether key generation, precomputation, encoding/decoding, and data movement are included). We distinguish core homomorphic primitives from ancillary microbenchmarks so that speedups can be interpreted consistently across CPU-first and GPU-native implementations, even when libraries expose different APIs or internal optimizations.

Table 1. Benchmark operation definitions and timing scope (core HE operations). Timing scope applies to each operation independently. Ancillary and microbenchmark operations are also included.

Operation	Inputs/Outputs (High Level)	Timing Boundary (Includes/Excludes)
Key generation (secret/public/relin/rotation)	Parameter set → key(s)	Includes keygen call; excludes context/setup unless internal.
Encryption (asym/sym)	Encoded plaintext + key → ciphertext	Includes encryption; excludes encode/pack when measured separately.
Decryption	Ciphertext + secret key → plaintext	Includes decryption; excludes decode/unpack when measured separately.
Homomorphic add/sub/XOR	Ciphertext ± ciphertext (or ⊕) → ciphertext	Includes op; key switching only if internal.
Homomorphic multiply/square	Ciphertext × ciphertext → ciphertext	Includes op; relin/rescale separate if exposed.
Relinearize/Rescale/ModSwitch	Ciphertext + eval keys → ciphertext at lower size/level	Includes op; excludes multiplication.
Rotation/EvalAtIndex	Ciphertext + rotation key → rotated ciphertext	Includes rotation; key switching if internal.
Boolean gate eval (TFHE/FHEW)	LWE ciphertext(s) → ciphertext	Includes gate; bootstrapping not separated when internal.
NTT/INTT and polynomial microbench	Polynomial → polynomial in NTT or coefficient domain	Low-level polynomial routines only; not end-to-end HE ops.
Serialization (CKKS)	Ciphertext/key → byte stream	Serialization only; file I/O excluded if not in benchmark.

6.2. Parameterization per Library and Scheme

Table 2 reports the parameter information exported by each repository benchmark module and the associated security labels/claims. When a benchmark output does not expose full cryptographic tuples (N, modulus chain, levels, scale, or key-switch settings), disclosure status is encoded with compact labels where applicable (Y/P/L/N/-) as shown in Table 3 and treated as non-equivalent for strict cross-library claims.

Table 2. Benchmark parameter disclosure and security labels/claims (defaults used in repository benchmark modules; labels are claimed unless independently verified).

Library/Scheme	Parameter Tuple	Security Target	Notes/Source
Microsoft SEAL (BFV/BGV/CKKS)	N ∈ {210–215}; log q ∈ {27,54,109,218,438,881}	128-bit (preset claim)	Repository benchmark module (seal-bench.csv); full plaintext modulus/scale not exported.
HElib (BGV benchmarks)	Ring size ∈ {2048,4096,8192} (N ∈ {211,212,213})	Not exported (not explicitly exported)	BGV mode benchmarked; CKKS tuple/security label not exported in helib-bench.csv.
Cupcake (additive FV)	Record normalization ∈ {10,100,1000}; full crypto tuple Not exported	128-bit estimate	Repository benchmark module output focuses on operation timing, not full tuple export.
TFHE-rs	Default Boolean preset; full tuple not exported in tfhe-bench.csv	≥128-bit (library claim)	Repository benchmark module provides mean+stddev timing fields.
NuFHE	N = 1024 default; other tuple fields Not exported	110-bit (library claim)	Repository benchmark module reports Mean/StdDev/Median; full key/bootstrapping tuple not exported.
OpenFHE RLWE core	ring_dimension ∈ {210,212,213}; chain/levels not fully exported	Preset-dependent (not independently verified)	From openfhe-lib-benchmark.csv (repository benchmark module).
OpenFHE poly microbench	N ∈ {210–216}; towers ∈ {1,2,4,8,16}	Not applicable (microbench)	From openfhe-poly-all-bench.csv; microbenchmark scope only.
OpenFHE BinFHE/FHEW	Preset labels include MEDIUM, STD128, STD128Q, STD128_AP, STD128_LMKCDEY	STD128-labeled presets	From openfhe-binfhe-*.csv benchmark modules; labels are documented claims.
Phantom-FHE (BFV/BGV/CKKS)	N ∈ {212–216}; coeff_modulus_size_bits ∈ {108–1777}; t ∈ {786433,1032193}	Not exported (not explicitly exported)	From phantom-fhe-*-bench.csv; bootstrapping config not exported.
Troy-Nova (BFV/BGV/CKKS)	Not exported (parameter tuple not exported by benchmark output)	Classical128 preset label (claimed)	Repository benchmark module used (troy-nova-bench.csv); exact tuple, version, and commit not recorded in exported CSV.

Table 3. Parameter disclosure visibility matrix by library (benchmark-output export status).

Library	Scheme Family	N	log q/Primes	Levels	t/Scale	Bootstrapping Config	Key-Switch Config	Overall Disclosure
SEAL	BFV/BGV/CKKS	Y	Y	N	N	-	N	P
HElib	BGV (reported suites)	Y	N	N	N	N	N	N
Cupcake	Additive FV	N	N	N	N	-	-	N
TFHE-rs	TFHE Boolean	N	N	N	-	N	-	N
NuFHE	TFHE-like	P	N	N	-	N	-	N
OpenFHE RLWE	BFV/BGV/CKKS ops	Y	N	N	N	-	N	P
OpenFHE BinFHE	FHEW/BinFHE	L	L	L	-	L	L	L
Phantom-FHE	BFV/BGV/CKKS	Y	P	N	P	-	N	P
Troy-Nova	BFV/BGV/CKKS	L	L	L	L	-	L	L

Legend: Y = exported; P = partially exported; L = label-only (preset label without full tuple); N = not exported; - = not applicable.

Security labels were taken from library documentation and benchmark naming conventions: SEAL commonly uses sec_level_type::tc128; OpenFHE BinFHE benchmarks include STD128-labeled presets; Cupcake reports an estimated ~128-bit default; TFHE-rs reports at least 128-bit for validated parameter sets; NuFHE states approximately 110-bit defaults; and Troy-Nova benchmarks were executed under a Classical128 preset label. These labels were not independently re-estimated in this revision.

6.3. Timing Boundaries and Runtime Controls

Timing values were extracted directly from each repository’s benchmark module output: Cupcake Time (ns) normalized per record; TFHE-rs time_ns_per_iter (with stddev_ns when available); NuFHE Mean/StdDev/Median (us); SEAL Time_us (server/Jetson) and real_time (laptop); OpenFHE time_us/time_ms; Phantom-FHE median_time_us; and Troy-Nova Average_Time_us. Each value corresponds to the benchmarked operation scope defined by that repository; setup, transfers, warm-up, and internal bootstrapping details are not uniformly exported across libraries (see Table 4).

Table 4. Timing–scope reporting map by library and benchmark module.

Library	Benchmark Tool/Harness	Reported Inclusion of Context Setup	Reported Inclusion of Key Generation	Reported Inclusion of CPU<->GPU Transfer	Reported Inclusion of Internal Bootstrapping	Timer Source
Microsoft SEAL	Repository benchmark module (seal-bench.csv)	Excluded	Included	Excluded	Not reported	real_time (laptop), Time_us (server/Jetson)
HElib	Repository benchmark module (helib-bench.csv)	Excluded	Included	Excluded	Not reported	Time (ns)
Cupcake	Repository benchmark module (cupcake-bench.csv)	Not reported	Not reported	Excluded	Excluded	Time (ns), normalized per record
TFHE-rs	Repository benchmark module (tfhe-bench.csv)	Excluded	Not reported	Excluded	Included	time_ns_per_iter (+stddev_ns)
NuFHE	Repository benchmark module (nufhe-*.csv)	Excluded	Included	Not reported	Included	Mean/StdDev/Median (us)
OpenFHE	Repository benchmark modules (openfhe-*.csv)	Excluded	Included	Excluded	Included	time_us/time_ms/cpu_us
Phantom-FHE	Repository benchmark module (phantom-fhe-*.csv)	Excluded	Included	Not reported	Excluded	median_time_us/mean_time_us
Troy-Nova	Repository benchmark module (troy-nova-bench.csv)	Excluded	Included	Not reported	Excluded	Average_Time_us

Because benchmark suites differ in what they time and what they export, cross-library comparisons should be interpreted with the scope notes in mind.

6.4. Benchmarking Protocol and Statistical Reporting

This revision reports the statistics exported by each repository benchmark module. Per-run traces are not uniformly exported across all benchmark suites in the current dataset; therefore, a unified cross-library variance model (common CI/p-values) cannot be derived from the exported benchmark summaries alone.

When available, per-suite dispersion metrics are preserved (for example, TFHE-rs stddev_ns and NuFHE StdDev/IQR). For suites exporting only aggregate means/medians, claims are phrased as observed speedups. Thermal stabilization, governor locking, and affinity control were not uniformly recorded across all runs and are treated as explicit limitations.

7. Security Considerations

Cross-library performance interpretation requires caution because benchmark defaults differ across libraries, and strict security equivalence is not always observable from exported outputs. Reported security levels in this manuscript are therefore treated as documented or preset-labeled targets, not independently verified estimator results.

Comparability Policy used in this revision:

(1)

Within-library CPU versus GPU comparisons are considered valid when they use the same benchmarked parameter preset.

(2)

Cross-library comparisons are treated as indicative only when parameter tuples are explicitly known or presets are labeled at a similar target (e.g., STD128).

(3)

When tuples are missing or scopes differ, results are presented as feasibility/performance envelopes rather than absolute superiority claims.

8. Performance Benchmarking

To evaluate performance across CPU-first and GPU-native libraries, benchmarks were executed on laptop, server, and Jetson Nano platforms using each repository’s own benchmark module and default presets unless explicitly noted. Security targets are reported as documentation/preset labels (for example, NuFHE default ~110-bit; OpenFHE STD128 labels; and Troy-Nova Classical128 label) and are not treated as independently verified equivalence classes. Where benchmark outputs only expose aggregate values, claims are reported as observed speedups rather than inferential guarantees.

8.1. Cupcake Library Performance

Cupcake demonstrates exceptional efficiency for additive homomorphic operations on 8-bit integer vectors. Table 5 presents the normalized per-record performance across all three platforms (performance measured in nanoseconds per record). The server consistently achieves the best performance across all operations.

Table 5. Cupcake performance comparison (performance measured in nanoseconds per record).

Operation	Jetson	Laptop	Server	Gap (%)
Addition	77,624	24,696	17,628	340
Decryption	572,335	156,726	95,282	501
Encryption	1,908,189	463,188	329,190	480
Key Generation	5,979,703	1,320,877	929,214	544
Re-randomization	1,572,585	368,071	244,923	542

8.2. TFHE-rs Library Performance

TFHE-rs demonstrates the performance characteristics of CPU-based Boolean homomorphic encryption across different hardware platforms. Table 6 presents benchmarks for fundamental Boolean operations and arithmetic primitives (performance measured in microseconds per iteration, converted from time_ns_per_iter in the benchmark output). Boolean operations show extreme performance variations across platforms, with the server achieving consistent leadership.

Table 6. TFHE-rs performance comparison.

Operation	Jetson (μs)	Laptop (μs)	Server (μs)	Gap (%)
Addition	1,011,458	126,136	66,837	1413
Bit AND	357,036	45,333	22,067	1519
Bit OR	358,679	53,163	21,580	1562
Bit XOR	357,961	53,463	21,973	1529
Multiplication	2,776,091	343,608	133,210	1984
Key Generation	3,202,816	1,007,839	487,905	556
Encryption	1142	443	411	178
Decryption	18	4	3	423

TFHE-rs exhibits the largest performance gaps observed in this study, with Boolean operations showing 1400–1900% server advantages over Jetson. The multiplication operation demonstrates nearly 2000% improvement on server hardware, reflecting the computational intensity of homomorphic Boolean circuit evaluation. Despite these gaps, TFHE-rs provides essential capabilities for privacy-preserving Boolean logic that are unavailable in RLWE-based schemes.

8.3. HElib Library Performance

HElib shows substantial performance variations across platforms and ring sizes. Table 7 summarizes key operations for different polynomial degrees (performance measured in microseconds). The server consistently outperforms other platforms with advantages increasing at larger ring sizes.

Table 7. HElib performance comparison.

Operation	Ring Size	Jetson (μs)	Laptop (μs)	Server (μs)	Gap (%)
Key Generation	211	59,779	11,778	4583	1204
Key Generation	212	122,660	22,769	9815	1150
Key Generation	213	241,378	46,037	19,980	1108
Encryption	211	7060	1184	573	1133
Encryption	212	13,562	2342	1156	1073
Encryption	213	28,994	5738	2264	1180
Multiplication	211	31,477	6819	2204	1328
Multiplication	212	63,108	18,839	4759	1226
Multiplication	213	321,951	92,674	34,544	832

8.4. NuFHE GPU-Native Performance

NuFHE provides a direct comparison between CUDA and OpenCL backends for Boolean operations. Table 8 demonstrates significant GPU acceleration benefits (performance measured in microseconds). The server GPU shows dramatic acceleration compared to CPU and cross-platform GPU performance. The server CUDA implementation achieves a 3.44× speedup over OpenCL GPU and a 5.82× speedup over CPU for NAND-gate operations, while the laptop shows a more modest 1.38× improvement over CPU.

Table 8. NuFHE CUDA vs. OpenCL performance.

Operation	Jetson CUDA	Jetson OpenCL	Laptop CUDA	Laptop OpenCL	Server CUDA	Server OpenCL
Key Generation	943,826	755,829	220,611	236,002	89,718	86,480
Encryption	3992	5229	385	466	185	211
Decryption	1221	1124	124	148	56	59
NAND Gate	601,495	1,089,970	52,622	69,654	12,700	43,646

8.5. Microsoft SEAL Performance Anomaly

Microsoft SEAL shows an observed laptop > server inversion in the collected benchmark outputs, unlike most other libraries. This subsection reports the observation while avoiding a root-cause claim that would require controlled replication and profiling under matched build/runtime settings.

Table 9 summarizes the observed inversion across tested schemes/operations in the current dataset (microseconds). The measured laptop advantage spans approximately 151% to 1578% for these runs; however, this manuscript now treats the pattern as an unresolved anomaly pending build-parity and system-control validation.

Table 9. Detailed performance analysis of Microsoft SEAL across platforms.

Scheme	Parameter Set	Operation	Jetson (μs)	Laptop (μs)	Server (μs)	Laptop Advantage (%)
BFV	N = 212	KeyGen Secret	512	205	515	151
BFV	N = 212	KeyGen Public	897	404	1195	196
BFV	N = 212	Encrypt Secret	1085	555	1748	215
BFV	N = 212	Encrypt Public	1641	570	2631	362
BFV	N = 212	Decrypt	459	207	1506	627
BFV	N = 212	Multiply	4988	2550	16,900	563
BFV	N = 213	KeyGen Secret	1477	491	1979	303
BFV	N = 213	Encrypt Secret	3291	1235	5819	371
BFV	N = 213	Decrypt	1622	873	4535	420
BFV	N = 213	Multiply	18,037	8581	55,693	549
BFV	N = 213	Relinearize	3633	2390	12,537	425
BFV	N = 213	Rotate Rows	3728	2309	12,389	437
CKKS	N = 212	KeyGen Secret	917	319	1379	332
CKKS	N = 212	Encrypt Secret	552	193	717	271
CKKS	N = 212	Decrypt	49	13	178	1269
CKKS	N = 212	Multiply	105	41	428	947
CKKS	N = 212	Square	84	31	344	1006
CKKS	N = 212	Rescale	966	480	2151	348
CKKS	N = 213	KeyGen Secret	2703	1197	4568	282
CKKS	N = 213	Encrypt Secret	917	319	1379	332
CKKS	N = 213	Multiply	846	371	3437	826
CKKS	N = 213	Relinearize	3692	2148	12,488	482
CKKS	N = 213	Rotate Vector	3760	2298	13,272	477
BGV	N = 212	Encrypt Secret	1070	437	1714	292
BGV	N = 212	Decrypt	349	104	1023	883
BGV	N = 212	Multiply	214	63	858	1262
BGV	N = 212	Square	168	45	751	1578
BGV	N = 213	Encrypt Secret	3353	1597	5855	267
BGV	N = 213	Multiply	857	375	3418	811
BGV	N = 213	Relinearize	4338	2306	16,103	598
BGV	N = 213	Rotate Rows	4373	2559	16,750	555

Table 10 indicates that the observed inversion persists across tested polynomial degrees in the available data, with stronger differences at selected mid-/high-complexity points. This trend is descriptive of the current runs and should not be interpreted as architecture-intrinsic without controlled replication.

Table 10. Microsoft SEAL performance scaling across polynomial degrees.

Operation	N = 210	N = 211	N = 212	N = 213	N = 214	N = 215
Laptop: BFV Encrypt	215	555	1235	3472	16,774	44,847
Laptop: BFV Multiply	1010	2550	8581	23,683	97,270	412,885
Laptop: CKKS Multiply	41	48	371	1374	3871	10,919
Server: BFV Encrypt	898	1748	5819	20,496	78,618	292,957
Server: BFV Multiply	8493	16,900	55,693	199,202	792,853	3,170,303
Server: CKKS Multiply	428	855	3437	13,128	51,990	194,701
Advantage: BFV Encrypt	318	215	371	490	369	553
Advantage: BFV Multiply	741	563	549	741	715	668
Advantage: CKKS Multiply	947	1679	826	856	1243	1683

Plausible hypotheses include differences in compiler flags/build options, thread scheduling and affinity, CPU governor/turbo behavior, timing-source semantics (real_time versus Time_us), and optional dependencies (for example, HEXL configuration). In this dataset, these factors were not fully harmonized across systems.

Limitation: root-cause attribution for the SEAL inversion requires controlled replication and profiling under matched build/runtime settings; therefore, the manuscript now reports this result as an anomaly under investigation rather than a systematic architectural characteristic.

Reproduction Plan for the SEAL Inversion

To determine whether the observed inversion is reproducible and causal, the following controlled protocol is required before drawing architectural conclusions:

• Rebuild SEAL on both systems with matched Release flags, explicit architecture settings, and synchronized optional dependencies (including HEXL on/off parity).
• Pin thread counts and affinity (for example, fixed OMP/TBB settings) and record scheduler/NUMA placement.
• Lock CPU governor/turbo policy and record sustained frequencies during benchmark windows.
• Use a consistent timer definition across platforms (same harness semantics for wall-time versus CPU-time).
• Execute repeated runs with reported mean ± std (or median [IQR]) and confidence intervals.

8.6. OpenFHE Library Performance

OpenFHE provides comprehensive FHE capabilities across multiple schemes and parameter sets. Table 11 presents fundamental operation performance across BFV, CKKS, and BGV schemes (performance measured in microseconds). The server consistently outperforms the laptop across all schemes and operations.

Table 11. OpenFHE core operations performance comparison.

Scheme	Operation	Laptop (μs)	Server (μs)	Improvement (%)
BFV	Key Generation	2246	1945	15
BFV	Encryption	3134	2528	24
BFV	Multiplication	5317	3516	51
BFV	EvalAtIndex	1460	715	104
CKKS	Key Generation	3222	2662	21
CKKS	Encryption	2238	1770	26
CKKS	Multiplication	213	135	58
CKKS	Rescale	619	367	69
BGV	Key Generation	3055	2559	19
BGV	Encryption	2192	1722	27
BGV	Multiplication	241	136	77
BGV	EvalAtIndex	3860	1592	142

OpenFHE implements multiple BFV multiplication algorithms with significantly different performance characteristics. Table 12 compares these methods across platforms. It can be observed that Method 3 provides optimal performance on both platforms. Negative gains indicate performance degradation compared to baseline.

Table 12. OpenFHE BFV multiplication method performance comparison.

Method	Laptop (ms)	Server (ms)	Laptop Gain (%)	Server Gain (%)
Method 0 (HPS)	1552	1574	Baseline	Baseline
Method 1 (BEHZ)	1366	2572	12	−63
Method 2 (HPSPOVERQ)	1147	2483	26	−58
Method 3 (HPSPOVERQLEVELED)	849	1813	45	15

Table 13 presents the library’s binary FHE implementation performance for Boolean operations across different parameter sets. The laptop consistently outperforms the server for FHEW operations.

Table 13. OpenFHE FHEW Boolean gate performance.

Parameter Set	Gate Type	Laptop (μs)	Server (μs)	Laptop Advantage (%)
MEDIUM	OR	66,128	91,636	39
MEDIUM	AND	65,492	92,207	41
MEDIUM	XOR	64,034	95,134	49
MEDIUM	NAND	67,438	107,529	59
MEDIUM	NOR	65,558	83,791	28
MEDIUM	XNOR	63,969	91,055	42
STD128	OR	80,916	105,723	31
STD128	AND	79,308	129,413	63
STD128	XOR	79,111	122,802	55
STD128	NAND	82,064	104,129	27
STD128	NOR	77,840	106,307	37
STD128	XNOR	81,186	147,537	82

Finally, Table 14 compares native polynomial arithmetic versus DCRT implementations across different ring sizes. Native implementations show significantly lower execution times than DCRT approaches.

Table 14. Native versus DCRT performance of OpenFHE polynomial operations.

Operation	Ring Size	Native Laptop (μs)	Native Server (μs)	DCRT-4 Laptop (μs)	DCRT-4 Server (μs)
NTT	212	7.67	12.6	18.9	86.0
NTT	213	35.9	65.9	59.4	225
NTT	214	168	267	226	552
Multiplication	212	2.10	13.4	8.02	24.3
Multiplication	213	8.33	51.8	14.3	86.5
Multiplication	214	33.4	212	41.9	454
Base Decompose	212	480	681	27,678	155,924
Base Decompose	213	2096	3274	108,847	619,350
Base Decompose	214	9189	13,226	460,855	2,904,902

8.7. Troy-Nova GPU Acceleration

Troy-Nova demonstrates the most comprehensive and dramatic GPU acceleration benefits observed in this study, achieving transformative speedups across all supported homomorphic schemes. As a GPU-native FHE library designed from the ground up for CUDA acceleration, Troy-Nova provides direct CPU-GPU performance comparisons that quantify the full potential of GPU-accelerated homomorphic encryption.

Table 15 presents a detailed acceleration analysis across BFV, CKKS, and BGV schemes, comparing CPU (HOST) and GPU (DEVICE) implementations on both laptop and server platforms (performance measured in microseconds). GPU implementations achieve 4×–76× speedups, with the server GPU consistently outperforming the laptop GPU.

Table 15. Troy-Nova GPU acceleration analysis. SrvSpd = server-side GPU speedup; LtpSpd = laptop-side GPU speedup.

Scheme	Operation	Server CPU (μs)	Server GPU (μs)	Laptop CPU (μs)	Laptop GPU (μs)	SrvSpd (×)	LtpSpd (×)
BFV	Encode SIMD	202	22	301	35	9.2	8.6
BFV	Decode SIMD	199	42	312	55	4.7	5.7
BFV	Encrypt Asym	7114	126	8048	272	56.6	29.6
BFV	Encrypt Sym	8895	126	9136	302	70.4	30.3
BFV	Decrypt	1462	37	1936	90	39.2	21.5
BFV	Add	24	6	51	10	4.2	4.9
BFV	Multiply	12,247	202	18,833	436	60.6	43.2
BFV	Square	8791	143	14,047	316	61.3	44.5
CKKS	Encode Double	812	75	1104	114	10.8	9.7
CKKS	Decode Double	1185	89	1483	134	13.4	11.1
CKKS	Encrypt Asym	8586	146	10,157	284	58.9	35.8
CKKS	Encrypt Sym	7689	101	8087	205	75.9	39.4
CKKS	Decrypt	56	7	87	16	7.7	5.3
CKKS	Add	24	5	54	9	4.5	6.2
CKKS	Multiply	233	8	356	22	27.9	16.2
CKKS	Square	157	6	231	14	27.4	16.5
CKKS	Rescale	1293	31	1790	72	41.4	24.9
BGV	Encode SIMD	203	20	285	36	10.1	7.9
BGV	Decode SIMD	197	45	292	58	4.4	5.0
BGV	Encrypt Asym	9545	170	11,491	328	56.0	35.0
BGV	Encrypt Sym	8505	122	9191	242	69.6	38.0
BGV	Decrypt	759	28	1053	57	26.8	18.5
BGV	Multiply	232	8	353	22	27.7	16.0
BGV	Square	156	6	232	12	27.1	18.7

Troy-Nova’s GPU acceleration demonstrates several key performance characteristics:

• Encryption Operations: Asymmetric and symmetric encryption operations achieve the most dramatic speedups, with server GPU implementations reaching 56×–76× faster performance than CPU equivalents. These operations benefit maximally from GPU parallelization due to their independent polynomial arithmetic operations across multiple ciphertext components.
• Arithmetic Operations: Homomorphic multiplication and squaring operations show substantial 16×–61× acceleration, representing the core computational bottlenecks in most FHE applications. The server GPU achieves 12,247 → 202 μs for BFV multiplication, a 98.4% time reduction.
• Auxiliary Operations: Encoding, decoding, and basic arithmetic (addition/subtraction) show moderate 4×–13× speedups, reflecting their lower computational intensity and reduced parallelization potential.

The platform-specific acceleration analysis reveals important scaling characteristics as shown in Table 16. Server GPU consistently achieves higher acceleration ratios across all operation categories, with encryption and multiplication operations showing the most dramatic improvements. In addition, we observe that:

Table 16. Troy-Nova GPU acceleration scaling by operation category.

Category	Server Range (×)	Server Avg. (×)	Laptop Range (×)	Laptop Avg. (×)	Server Reduction (%)	Laptop Reduction (%)
Encryption	26.8–75.9	54.1	18.5–39.4	31.4	98.1	96.8
Multiplication	27.1–61.3	45.6	16.0–44.5	30.6	97.8	96.7
Encoding/Decoding	4.4–13.4	8.6	5.0–11.1	7.8	88.4	87.2
Basic Arithmetic	4.2–7.7	5.4	4.9–6.2	5.5	81.5	81.8

• Cross-Scheme Consistency: Troy-Nova demonstrates remarkably consistent acceleration across BFV, CKKS, and BGV schemes, indicating effective optimization of the underlying polynomial arithmetic shared across RLWE-based constructions. Multiplication operations achieve similar 27×–28× speedups across all three schemes on server hardware.
• Memory and Bandwidth Utilization: The superior server GPU performance likely reflects both the higher CUDA core count (3072 vs. 1024) and increased memory bandwidth (8 GB vs. 4 GB GDDR6). This suggests Troy-Nova effectively utilizes available GPU resources and scales appropriately with hardware capabilities.
• Practical Performance Impact: Troy-Nova’s acceleration enables practical deployment scenarios previously limited by CPU performance. For example, BFV homomorphic multiplication improves from 18.8 ms to 0.44 ms on laptop hardware, transforming formerly prohibitive operations into responsive interactive capabilities.

The nature of Troy-Nova’s GPU acceleration, spanning all fundamental FHE operations across multiple schemes, positions it as the most mature GPU-native FHE solution evaluated in this study. The consistent 16×–76× speedups across diverse operation types demonstrate the transformative potential of ground-up GPU-optimized FHE library design.

8.8. Phantom-FHE GPU-Native Performance

Phantom-FHE, designed specifically for GPU acceleration, demonstrates comprehensive GPU-native FHE performance across the BFV, BGV, and CKKS schemes. Table 17 presents performance data for both laptop and server GPU implementations (performance measured in microseconds). BFV and BGV exhibit nearly identical results for most operations across both platforms.

Table 17. Phantom-FHE GPU performance across platforms and schemes.

Operation	Ring Size	BFV Laptop (μs)	BFV Server (μs)	BGV Laptop (μs)	BGV Server (μs)	CKKS Laptop (μs)	CKKS Server (μs)
Secret KeyGen	212	182	241	183	239	183	242
Secret KeyGen	213	210	248	199	248	199	---
Secret KeyGen	214	258	275	270	274	270	275
Secret KeyGen	215	565	377	572	379	572	418
Secret KeyGen	216	2118	964	2075	964	2075	1206
Encryption	212	283	280	471	353	471	333
Encryption	213	270	384	453	384	453	---
Encryption	214	612	550	1069	550	1069	430
Encryption	215	1958	1240	3384	1240	3384	995
Encryption	216	7664	5261	12,299	5261	12,299	4915
Multiplication	212	711	343	260	113	260	99
Multiplication	213	701	132	268	132	268	---
Multiplication	214	2525	409	1153	409	1153	198
Multiplication	215	11,340	2264	6334	2264	6334	1150
Multiplication	216	67,251	19,678	43,653	19,678	43,653	8603
Relinearization	212	376	481	379	480	379	482
Relinearization	213	565	723	541	723	541	---
Relinearization	214	1583	1686	1691	1686	1691	759
Relinearization	215	10,464	3950	11,356	3950	11,356	1590
Relinearization	216	80,550	37,761	86,899	37,761	86,899	10,481

8.9. Operation Taxonomy and GPU Acceleration Drivers

To interpret heterogeneous acceleration results, we group operations by computational driver rather than by library brand (see Figure 1). This taxonomy uses measured patterns from Table 15, Table 16 and Table 17 and existing per-operation timing tables.

Figure 1. Observed Troy-Nova GPU speedup averages by operation category (derived from Table 14; no variance bars because per-run traces are not uniformly available).

• Category 1 (NTT/INTT-heavy polynomial arithmetic): operations dominated by transform kernels and modular multiply–add throughput (for example, RLWE multiply/square paths).
• Category 2 (TFHE bootstrapping and gate evaluation): operations where FFT/NTT-like transforms and key-switch components are repeatedly invoked per gate.
• Category 3 (key switching/relinearization and decomposition): operations sensitive to memory traffic, decomposition strategy, and modulus-switch sequencing.
• Category 4 (overhead-sensitive small operations): lightweight kernels where launch latency and runtime overhead can dominate arithmetic work.

Observed gains align with this taxonomy: Troy-Nova shows the largest improvements in encryption/multiplication categories (Table 16), while smaller operation classes show lower but still meaningful gains. Phantom-FHE and NuFHE patterns are consistent with operation-dependent acceleration rather than uniform scaling.

Quantitative bottleneck attribution remains a limitation because hardware profiling counters were not collected in this manuscript version. A profiling follow-up is planned with Nsight Systems/Compute (or CUPTI), reporting metrics such as dram_read_throughput, achieved_occupancy, kernel launch latency, and memcpy transfer times.

8.10. Cross-Library Performance Analysis

The benchmarking results reveal several critical patterns:

• Platform Consistency (observed): Most datasets follow server > laptop > Jetson Nano ordering, with notable exceptions (SEAL and selected OpenFHE FHEW cases). Because timing scopes and parameter disclosure differ by repository benchmark, this pattern is interpreted as indicative rather than strictly scope-equivalent.
• SEAL and OpenFHE FHEW Inversions (observed): Laptop > server behavior appears for SEAL and some OpenFHE FHEW operations in current runs. These inversions are treated as hypotheses-generating results that require controlled replication and profiling under matched build/runtime settings before causal interpretation.
• Algorithm Selection Impact: OpenFHE demonstrates that algorithm choice dramatically affects performance—Method 3 multiplication provides 45% laptop improvement and 15% server improvement over the default method, while some methods show 58–63% performance degradation on server hardware.
• Implementation Strategy Trade-offs: OpenFHE’s native versus DCRT comparison reveals fundamental trade-offs. Native implementations achieve 2.8×–576× faster single-operation performance, but DCRT approaches enable better parallelization for multi-tower scenarios, highlighting the importance of workload-specific optimization strategies.
• GPU Acceleration Impact: GPU-native designs significantly outperform adapted implementations. NuFHE shows 1.4×–3.4× speedups, while Troy-Nova achieves 16×–61× acceleration. Phantom-FHE demonstrates strong scaling with 2×–7× server advantages at larger ring sizes.
• Boolean Circuit Performance: TFHE-rs exhibits the largest performance gaps, with 1400–2000% server advantages over Jetson, reflecting Boolean circuit evaluation complexity.
• Jetson Nano Feasibility Framing: The Nano results demonstrate that benchmark execution is feasible under severe memory/compute constraints, but performance is substantially slower in this specific device class. These results should not be generalized to newer embedded GPUs (for example, Xavier/Orin) without dedicated measurements.
• Operation Complexity Scaling: Performance gaps increase with computational complexity—simple operations show 300–500% platform differences, complex operations show 800–1600% differences.
• Scheme Optimization: Phantom-FHE demonstrates nearly identical BFV and BGV performance with marginal CKKS differences, indicating shared polynomial arithmetic optimizations. OpenFHE shows similar patterns across schemes for basic operations.

These results provide concrete guidance for FHE deployment decisions, emphasizing the critical importance of library and platform selection for achieving optimal performance.

8.11. Supported Capabilities per Library

In addition to performance, understanding the homomorphic operations each solution supports is crucial for application development. Table 18 presents a comprehensive comparison of functional capabilities across all evaluated libraries, including the GPU-accelerated solutions.

Table 18. FHE library capability comparison.

Feature	SEAL	Cupcake	HElib	TFHE	NuFHE	OpenFHE	Phantom	Troy-Nova
Schemes	BFV, BGV, CKKS	Additive FV	BGV, CKKS	TFHE	TFHE	BFV, BGV, CKKS, BinFHE	BFV, BGV, CKKS	BFV, BGV, CKKS
Data Types	Int, Real	Int (8-bit)	Int	Bool, Small Int	Bool	Int, Real, Bool	Int, Real	Int, Real
Key Generation	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Encryption	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Decryption	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Addition/XOR	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Subtraction	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Multiplication/AND	Yes	No	Yes	Yes	Yes	Yes	Yes	Yes
Relinearization	Yes	N/A	Yes	N/A	N/A	Yes	Yes	Yes
Slot Rotation	Yes	No	Yes	N/A	N/A	Yes	Yes	Yes
Bootstrapping	No	No	Yes	Yes	Yes	Yes	Planned	No
Logic Gates	No	No	No	Yes	Yes	Partial	No	No
Re-randomization	Partial	Yes	Partial	Partial	Partial	Partial	No	No
GPU Acceleration	No	No	No	No	Yes	No	Yes	Yes
Platform Support	CPU, Multi-OS	CPU, Rust	CPU, Multi-OS	CPU, Rust	GPU, Python	CPU, Multi-OS	GPU, CUDA	GPU, CUDA

Yes: natively supported; No: not supported; Partial: achievable through combination of operations; N/A: not applicable to library design.

Some key observations from the capabilities analysis are as follows:

• RLWE-based libraries (SEAL, HElib, OpenFHE, Phantom-FHE, and Troy-Nova) excel at arithmetic operations on packed integer or real number vectors, making them suitable for applications requiring bulk data processing such as machine learning inference or statistical computations.
• LWE/TFHE-based libraries (TFHE, NuFHE) provide direct Boolean logic operations, making them ideal for evaluating arbitrary logic circuits, secure comparisons, or decision tree evaluation.
• Only HElib and the TFHE family support bootstrapping for unlimited computation depth, though at significant computational cost. Other libraries operate in a leveled mode with a predetermined multiplicative depth.
• GPU acceleration is available in three forms: NuFHE (Python with GPU kernels), Phantom-FHE (GPU-native RLWE), and Troy-Nova (GPU-accelerated FHE suite). Each offers different trade-offs between ease of use and performance optimization.
• Cupcake’s additive-only design provides exceptional performance for its limited operation set, while full FHE libraries trade speed for computational expressiveness.
• Platform compatibility varies significantly: CPU-based libraries offer broad OS support, while GPU-accelerated solutions require specific CUDA environments and compatible hardware.

The choice between libraries depends on specific application requirements: arithmetic-heavy applications benefit from RLWE schemes with SIMD packing, while logic-intensive applications require TFHE-based Boolean evaluation capabilities.

9. Conclusions

This comprehensive evaluation of CUDA-accelerated homomorphic encryption across consumer-grade and embedded GPUs reveals significant but nuanced performance benefits that depend critically on library architecture, hardware platform, and operation type.

9.1. Key Performance Findings

Cross-platform benchmarks show large performance variation across libraries and hardware. Server systems generally delivered lower runtimes in the reported datasets, while SEAL and selected OpenFHE FHEW cases showed laptop > server inversions that remain unresolved pending controlled replication/profiling under matched settings.

GPU acceleration showed substantial speedups in GPU-native implementations. In the reported benchmark outputs, Troy-Nova reached 16×–61× host-versus-device gains, while NuFHE showed 1.4×–3.4× CUDA-versus-OpenCL gains.

Jetson Nano results are interpreted as an embedded-feasibility boundary case under strict RAM/compute constraints, not as a universal statement about embedded acceleration. Broader embedded conclusions require measurements on newer devices (for example, Jetson Xavier/Orin) and harmonized parameter sets.

9.2. Library Selection Guidelines

The evaluation supports workload-dependent library selection. For arithmetic-intensive vector workloads, RLWE-based schemes (BFV, BGV, CKKS) in SEAL, HElib, OpenFHE, Phantom-FHE, and Troy-Nova are practical options. For Boolean logic workloads, TFHE-based implementations remain the relevant choice, with NuFHE providing GPU acceleration for gate evaluation.

Cupcake demonstrates that specialized libraries targeting specific operation subsets can achieve exceptional performance within their domain, completing additive operations in microseconds compared to milliseconds for general-purpose FHE libraries. This suggests value in application-specific FHE implementations rather than universal solutions.

9.3. Hardware Deployment Considerations

For the evaluated workloads and benchmark scopes, server-class x86 systems with discrete GPUs provided the strongest observed throughput envelope. Deployment choices should still be validated per workload, parameter set, and runtime constraints because cross-library scope/parameter equivalence is partial in the current dataset.

Memory constraints emerge as a critical deployment factor. High-degree polynomial operations (N ≥ 2¹⁴) with multiple RNS primes can easily exceed 4 GB VRAM limits on consumer GPUs, necessitating careful parameter selection or upgraded hardware for complex applications.

9.4. Integration Challenges and Future Directions

Our architectural analysis indicates four fundamental challenges for integrating CUDA into Microsoft SEAL that also apply to other CPU-centric FHE libraries: GPU memory management complexity, sequential operation dependencies limiting parallelism, lack of native 128-bit modular arithmetic support, and architectural integration barriers requiring significant codebase modifications. We did not implement a CUDA-SEAL prototype or report performance measurements.

These challenges indicate that future progress should combine GPU-first design with measurement-driven optimization. The following concrete work items are prioritized:

• Hybrid CPU-GPU pipeline fusion to reduce kernel-launch overhead and host–device synchronization costs.
• Improved 64-bit/128-bit modular arithmetic strategies (for example, tuned Montgomery/Barrett variants with cooperative groups).
• Cross-library standardized benchmark harness metadata, including mandatory parameter export and timing-scope annotations.
• Expanded embedded feasibility experiments on newer Jetson Xavier/Orin platforms with ARM NEON-aware optimizations.
• Profiling-driven optimization using Nsight Systems/Compute (or CUPTI) with roofline analysis for kernel bottleneck attribution.

The rapid evolution of specialized FHE accelerators, including emerging FPGA and ASIC solutions, indicates a maturing hardware ecosystem. However, our results demonstrate that current GPU technology provides sufficient acceleration for many practical applications when properly leveraged through optimized software implementations.

9.5. Practical Recommendations

For deployment planning, Troy-Nova or Phantom-FHE are suitable options for GPU-accelerated RLWE operations when compatible hardware is available, while OpenFHE or SEAL remain practical CPU-focused general-purpose choices. For Boolean logic workloads, NuFHE is an option when CUDA/OpenCL acceleration is required. For complex parameter sets, higher-memory discrete GPUs are generally preferable.

Development and prototyping can use laptop hardware effectively for many workloads, while embedded deployment conclusions should be limited to the tested Jetson Nano configuration. Additional embedded evaluation on Xavier/Orin-class hardware is needed before broader recommendations.

Large performance differences across configurations reinforce the importance of careful library and hardware selection. The results provide practical guidance for current deployments and identify clear priorities for continued benchmarking and optimization.