FIDESlib: GPU-Accelerated CKKS Library

Updated 4 July 2026

FIDESlib is a fully open-source, GPU-accelerated CKKS library that integrates server-side encrypted computation with client-side OpenFHE operations.
It optimizes homomorphic encryption primitives using GPU kernel fusion, efficient memory management, and parallel limb-wise execution to deliver up to 227× speedups over CPU baselines.
Designed for ML-as-a-Service and secure cloud computing, FIDESlib leverages advanced bootstrapping and RNS optimizations to enable practical privacy-preserving approximate computing.

FIDESlib is presented most explicitly in current arXiv literature as a fully open-source, GPU-accelerated, server-side CKKS library designed to make privacy-preserving approximate computing practical while remaining fully interoperable with well-established client-side OpenFHE operations (Agulló-Domingo et al., 7 Jul 2025). In parallel, the same label also appears in other research contexts as a software framework, a deployable-system shorthand, or an implementation context for domain-specific inference and decoding pipelines, so its meaning is context-dependent across literatures (Boffi et al., 2023, Khabbazian, 17 Jun 2025, Yu et al., 4 Jun 2026, Taraldsen et al., 2017).

1. Primary meaning in homomorphic encryption

In the homomorphic-encryption literature, FIDESlib denotes a split CKKS software stack in which client-side operations stay in OpenFHE—including key generation, encryption, decryption, encoding/decoding—while server-side operations are implemented in FIDESlib on the GPU, including homomorphic addition/multiplication, rescaling, rotations, key switching, and bootstrapping (Agulló-Domingo et al., 7 Jul 2025). The stated target is cloud deployment, especially ML-as-a-Service (MLaaS) and other settings where approximate arithmetic on encrypted data is required.

The underlying scheme is CKKS, which the paper describes as the appropriate FHE scheme for approximate arithmetic and as especially suited to ML and signal-processing style workloads. The same source also emphasizes the central systems problem: CKKS operations incur a 2–5 orders of magnitude slowdown over plaintext computation, many kernels are memory-bound, and even AVX-optimized OpenFHE remains too slow for latency-sensitive server-side execution (Agulló-Domingo et al., 7 Jul 2025).

The architectural argument for GPU acceleration is tied directly to bandwidth and parallelism. The paper compares a DDR5 CPU system at about 81 GB/s with an RTX 4090 GPU at about 1 TB/s, and stresses that CKKS workloads move large ciphertext and key objects through RNS limbs, NTT/iNTT stages, and modulus-management routines. This makes GPU memory bandwidth, on-chip caches, and parallel limb-wise execution central rather than incidental (Agulló-Domingo et al., 7 Jul 2025).

The paper further positions FIDESlib as distinct from prior GPU efforts because it is described as the first open-source server-side CKKS GPU library that is fully interoperable with well-established client-side OpenFHE operations, and as the first implementation featuring heavily optimized GPU kernels for all CKKS primitives, including bootstrapping (Agulló-Domingo et al., 7 Jul 2025).

2. CKKS execution model and cryptographic scope

FIDESlib’s CKKS layer is organized around standard server-side primitives. The paper lists operations such as ScalarAdd, PtAdd, HAdd, ScalarMult, PtMult, HMult, Rescale, Conjugate, and HRotate, with representative forms

$\texttt{HAdd}(\|x\|,\|y\|)\to \|x+y\|$

and

$\texttt{HMult}(\|x\|,\|y\|)\to \|x\odot y\|.$

It also defines the usual CKKS parameters N, n, Q, L, \Delta, and dnum, together with NTT and iNTT for transform-domain execution (Agulló-Domingo et al., 7 Jul 2025).

The implementation focus is explicitly server-side. OpenFHE remains the client-side front end, and FIDESlib accelerates the expensive homomorphic computation without replacing the client stack. The paper states that the security guarantees remain those of OpenFHE because the trusted cryptographic correctness on the client side is unchanged, and that FIDESlib uses a thin adapter layer to move data between OpenFHE objects and simplified GPU-side representations (Agulló-Domingo et al., 7 Jul 2025).

A notable technical component is fast base conversion. The paper gives a matrix-style expression for RNS base conversion and states that FIDESlib accelerates it by caching partial results in shared memory, using two GPU threads per vector-matrix operation, and accumulating partial sums in 128-bit integers before modular reduction (Agulló-Domingo et al., 7 Jul 2025). This is significant because ModUp, ModDown, and Rescale dominate practical CKKS implementations and often determine end-to-end throughput.

Bootstrapping is treated as a first-class primitive rather than an optional extension. The pipeline is described as consisting of CoeffToSlot, ApproxModEval, and SlotToCoeff. ApproxModEval uses Chebyshev cosine approximation, BSGS, Paterson-Stockmeyer, and double-angle iterations to extend approximation range, while CoeffToSlot and SlotToCoeff are generalized into a single routine implemented as homomorphic DFT-like transforms with sparse block matrices, BSGS, and hoisted rotations (Agulló-Domingo et al., 7 Jul 2025).

3. GPU-oriented software architecture

The software architecture is divided into four namespaces: FIDESlib, FIDESlib::CKKS, FIDESlib::test, and FIDESlib::bench (Agulló-Domingo et al., 7 Jul 2025). This separation reflects a layered design: low-level GPU arithmetic and utilities, CKKS classes and kernels, Google Test-based correctness checks, and Google Benchmark-based performance measurement.

The object model is likewise layered. Ciphertext, Plaintext, and KeySwitchingKey are composed of RNSPoly; RNSPoly is composed of one or more LimbPartitions; LimbPartition contains Limbs; and Limb stores a VectorGPU device buffer (Agulló-Domingo et al., 7 Jul 2025). The paper presents this structure as supporting GPU memory ownership, limb-wise partitioning, and future multi-GPU distribution.

Memory management is handled through VectorGPU, which uses RAII, allocates GPU memory on construction, frees it on destruction, and uses CUDA stream-ordered memory allocation. The paper also notes the existence of unmanaged VectorGPU objects for special cases, and describes a choice between stack-of-arrays and flattened representations depending on lifetime and size (Agulló-Domingo et al., 7 Jul 2025).

A distinctive implementation choice is the use of a singleton design pattern for contexts and precomputation results. The reason given is that GPU constant memory is limited to 64 KB, multiple concurrent parameter sets are hard to support efficiently, and globally declared precomputed values simplify kernel invocation (Agulló-Domingo et al., 7 Jul 2025). This is presented as somewhat unorthodox but practical for GPU execution.

The kernel strategy is organized by dependency structure. The paper classifies operations as having no dependencies (for example modular addition, multiplication, modulus switching), intra-limb dependencies (such as NTT, iNTT, automorphism), or cross-limb dependencies (such as ModUp, ModDown, Rescale). FIDESlib responds with separate kernels for independent limbs, asynchronous CUDA streams, and limb batching to reduce CPU launch overhead while balancing locality, cache reuse, occupancy, and launch cost (Agulló-Domingo et al., 7 Jul 2025).

At the arithmetic level, the library implements improved Barrett reduction and Shoup modular multiplication where appropriate. For transforms, it uses Radix-2 FFT-style NTT and hierarchical / 2D NTT; the paper states that this design cuts accesses to about four memory accesses per element, computes some twiddle factors on the fly, and uses Gentleman-Sande butterflies in iNTT to avoid explicit bit reversal (Agulló-Domingo et al., 7 Jul 2025). The paper also identifies kernel fusion—including Rescale fusion, ModDown fusion, HMult fusion, and dot-product fusion—as a central bandwidth optimization.

4. Benchmarking, workload results, and reported speedups

The benchmarking methodology combines Google Test for unit and integration tests against OpenFHE outputs with Google Benchmark for microbenchmarks and workload benchmarks (Agulló-Domingo et al., 7 Jul 2025). Reported platforms include a Ryzen 9 7900 CPU, RTX 4060 Ti, RTX A4500, V100, and RTX 4090. A default parameter set is given as

$[N, L, \Delta, dnum] := [2^{16}, 29, 59, 4].$

The main baselines are OpenFHE baseline, OpenFHE with Intel HEXL and 24 threads, and the Phantom GPU CKKS library. Phantom is treated as the strongest existing open-source GPU CKKS baseline, but the paper notes that it lacks scalar add, scalar mult, HSquare, and bootstrapping (Agulló-Domingo et al., 7 Jul 2025).

On an RTX 4090, the paper reports the following selected primitive-level speedups over the OpenFHE baseline:

Primitive	Reported speedup
`ScalarAdd`	76.89×
`PtAdd`	295.65×
`HAdd`	154.67×
`ScalarMult`	98.32×
`PtMult`	465.72×
`Rescale`	325.44×
`HRotate`	334.90×
`HMult`	374.61×

The same source adds that HMult is over 100× faster than multi-threaded CPU OpenFHE, and that Rescale is over 30× faster (Agulló-Domingo et al., 7 Jul 2025). For bootstrapping, the central claim is stronger still: FIDESlib is reported as up to 74.4× faster than AVX-optimized OpenFHE, up to 227.8× faster than baseline OpenFHE, and in the abstract achieves no less than 70x speedup over the AVX-optimized OpenFHE implementation (Agulló-Domingo et al., 7 Jul 2025). Representative bootstrapping times include 73.5 ms for 64 slots and 93.3 ms for 512 slots, while larger slot counts improve amortized efficiency (Agulló-Domingo et al., 7 Jul 2025).

The paper also includes an application benchmark: encrypted logistic regression on 45,000 loan eligibility samples using mini-batch gradient descent, with ciphertexts encoding 1,024 samples, 32-dimensional padded feature vectors, and bootstrapping every iteration (Agulló-Domingo et al., 7 Jul 2025). Reported times are:

Iteration: OpenFHE 1,555 ms, HEXL OpenFHE 448 ms, FIDESlib 23 ms
Iteration + Bootstrap: OpenFHE 16,233 ms, HEXL OpenFHE 7,233 ms, FIDESlib 169 ms

Within the paper’s framing, these figures are intended to show that FIDESlib accelerates not only isolated primitives but also a realistic approximate-ML workload.

5. Other uses of the name in the literature

The label FIDESlib is not confined to the CKKS/GPU setting. In the supplied literature, the same name is used in multiple domain-specific ways:

Context	Use of the name	Source
Fictitious-domain FSI	Software library/framework underlying a parallel solver	(Boffi et al., 2023)
Fair data exchange	“FIDESlib-style” deployable fair exchange system	(Khabbazian, 17 Jun 2025)
RAG decoding	Implementation context for token-selective decoding in a RAG pipeline	(Yu et al., 4 Jun 2026)
Fiducial inference	Tool intended to operationalize fiducial/conditional fiducial reasoning	(Taraldsen et al., 2017)

In fluid–structure interaction, FIDESlib appears as the software library or framework in which a parallel fictitious-domain solver is realized. The solver is implemented in Fortran90 using PETSc and MUMPS, assembles and solves a monolithic FSI saddle-point system, and is reported to be robust primarily when paired with a block-triangular preconditioner rather than a block-diagonal one (Boffi et al., 2023). There, FIDESlib is not the governing theory; it is the computational framework embodying the solver architecture.

In fair data exchange, the term appears indirectly as a descriptor for a practical deployment style. The 2025 FDE implementation uses KZG commitments, Reed–Solomon structure, a lightweight hash-derived mask, ElGamal only on a pseudorandom $\Theta(\lambda)$ subset, and a constant-time zk-SNARK for consistency between encryption layers; the summary characterizes the result as much closer to a FIDESlib-style deployable system (Khabbazian, 17 Jun 2025). In that usage, the name functions as a systems shorthand rather than the title of the protocol itself.

In retrieval-augmented generation, FIDES—expanded as Faithful Inference via Deep Evidence Signals—is a training-free decoder that uses dual forward passes and three signals, Opposition, Shift, and Noise, to assign a token-specific contrastive coefficient under retrieval-memory conflict (Yu et al., 4 Jun 2026). The summary explicitly speaks of using FIDESlib in a RAG pipeline, treating the library notion as an engineering embodiment of the decoder.

The fiducial-inference note on parameters restricted to a curve does not introduce a software package named FIDESlib, but it states that the problem is directly relevant to tools such as FIDESlib, which aim to operationalize fiducial or conditional fiducial reasoning in concrete models (Taraldsen et al., 2017). A plausible implication is that the name has circulated not only as a concrete codebase but also as a generic label for implementation-oriented frameworks.

A recurrent source of confusion is orthographic proximity to several distinct systems. "Fides: Managing Data on Untrusted Infrastructure" introduces TFCommit and an auditable distributed data-management system named Fides, not FIDESlib (Maiyya et al., 2020). "Fidelius: Protecting User Secrets from Compromised Browsers" presents an enclave-backed browser architecture with trusted I/O paths, again not FIDESlib (Eskandarian et al., 2018). "FISLAB - the Fuzzy Inference Tool-box for SCILAB" describes a Scilab fuzzy-inference toolbox; its own summary states that the paper does not mention FIDESlib directly, and any relationship must be inferred cautiously (0903.4307). These distinctions matter because the shared prefix does not indicate a shared codebase, API, or research lineage.

For the 2025 CKKS library specifically, the paper is explicit about current limitations and future work. The present version is single-GPU; multi-GPU support is “work in progress”; AMD/HIP support is planned; the singleton/context design is a practical workaround that limits concurrent parameter sets within one process; and the library is planned for release after review, rather than already broadly released at submission time (Agulló-Domingo et al., 7 Jul 2025). The software architecture is nonetheless described as intentionally prepared for future multi-GPU backends through partitioning of ciphertext data across devices and structures that can generalize to multiple LimbPartitions (Agulló-Domingo et al., 7 Jul 2025).

Taken together, the literature supports a two-level understanding of the term. In its most concrete and technically specified sense, FIDESlib denotes a GPU-native, OpenFHE-interoperable CKKS library centered on efficient server-side homomorphic computation, especially bootstrapping (Agulló-Domingo et al., 7 Jul 2025). More broadly, the same label is used across several areas to denote a software embodiment of technically demanding inference, verification, or coupled-solver workflows (Boffi et al., 2023, Khabbazian, 17 Jun 2025, Yu et al., 4 Jun 2026, Taraldsen et al., 2017). This suggests that the name is currently best read as both a specific cryptographic library and a broader implementation-oriented signifier whose exact referent depends on disciplinary context.