---
title: 'FIDESlib: GPU-Accelerated CKKS Library'
url: https://www.emergentmind.com/topics/fideslib
type: topic
---

# FIDESlib: GPU-Accelerated CKKS Library

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** [2507.04775]. 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 [2301.10041][2506.14944][2606.05644][1706.03805].

## 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** [2507.04775]. 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 [2507.04775].

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 [2507.04775].

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** [2507.04775].

## 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 [2507.04775].

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 [2507.04775].

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** [2507.04775]. 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** [2507.04775].

## 3. GPU-oriented software architecture

The software architecture is divided into four namespaces: **`FIDESlib`**, **`FIDESlib::CKKS`**, **`FIDESlib::test`**, and **`FIDESlib::bench`** [2507.04775]. 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 `LimbPartition`s; `LimbPartition` contains `Limb`s; and `Limb` stores a `VectorGPU` device buffer [2507.04775]. 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 [2507.04775].

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 [2507.04775]. 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 [2507.04775].

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 [2507.04775]. 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 [2507.04775]. 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** [2507.04775].

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** [2507.04775]. 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** [2507.04775]. Representative bootstrapping times include **73.5 ms** for **64 slots** and **93.3 ms** for **512 slots**, while larger slot counts improve amortized efficiency [2507.04775].

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** [2507.04775]. 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 | [2301.10041] |
| Fair data exchange | “FIDESlib-style” deployable fair exchange system | [2506.14944] |
| RAG decoding | Implementation context for token-selective decoding in a RAG pipeline | [2606.05644] |
| Fiducial inference | Tool intended to operationalize fiducial/conditional fiducial reasoning | [1706.03805] |

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 [2301.10041]. 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** [2506.14944]. 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 [2606.05644]. 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 [1706.03805]. 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.

## 6. Distinctions, limitations, and related systems

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 [2001.06933]. **"Fidelius: Protecting User Secrets from Compromised Browsers"** presents an enclave-backed browser architecture with trusted I/O paths, again not FIDESlib [1809.04774]. **"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 [2507.04775]. 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 `LimbPartition`s [2507.04775].

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 [2507.04775]. More broadly, the same label is used across several areas to denote a software embodiment of technically demanding inference, verification, or coupled-solver workflows [2301.10041][2506.14944][2606.05644][1706.03805]. 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.

Source: https://www.emergentmind.com/topics/fideslib