Investigate potential GPU backends for CKKS

[AlexanderViand]

Several CKKS GPU implementations exist and are increasingly essential to achieving acceptable wall clock times for heavy PPML workloads.

• PhantomFHE - encryptorion-lab/phantom-fhe - 📃 Phantom: A CUDA-Accelerated Word-Wise Homomorphic Encryption Library
• LiberateFHE - Desilo/liberate-fhe - 🌐 fhe.desilo.dev
• FIDESlib - CAPS-UMU/FIDESlib - 📃 FIDESlib_ISPASS_Poster
• HEaaN GPU - closed source but available - 🌐iheaan.com
• CHEDDAR - unknown availability - 📃 Cheddar: A Swift Fully Homomorphic Encryption Library for CUDA GPUs

and probably more that I'm forgetting or haven't heard of

EDIT: There's also scale-snu/ckks-gpu-core but it's probably less "library to be used by others" and more "paper artifact"?

[j2kun]

Another closed source option is Lattica, a startup that reached out to us a few weeks ago.

[carlostriste]

Hello guys, I'm Carlos, the main developer of FIDESlib, right now we're focusing on GPU optimizations for a research paper deadline close by, but I hope during summer we can get the API more closely aligned with OpenFHE so that we can write a wrapper that looks just like OpenFHE's API.

In short, we have to improve Context/Parameter/Key handling to match OpenFHE's.

I think at that point FIDESlib will be a good match for HEIR.

[j2kun]

get the API more closely aligned with OpenFHE so that we can write a wrapper that looks just like OpenFHE's API.

I'd say there's not a major reason to do that for our sake. We'd have a separate backend for your target either way. The main thing we would ask for is a relatively stable API, and clarity on parameter requirements.

[carlostriste]

After getting some experience developing workloads with the current version of the library, we're gonna make changes to the API for sure.

I think it would be useful to make it at least a functional superset of OpenFHE's, that would make development easier (from the FHE programmer's point of view) as it is useful to have a functional CPU version of any GPU program for debugging purposes. So maybe a lowering from the OpenFHE dialect to a FIDESlib dialect is a good approach.

[AlexanderViand]

I just stumbled across another OpenFHE-but-with-GPU library: leodec/openfhe-gpu-public which seems to have been built for this paper. Looking at the example, it already looks pretty close to the existing API, just with a CPUContext instead of a normal CryptoContext?

[ephemer4l]

Hi all. I'm Efe from the HEonGPU team. I’ve spoken very briefly with Dr. Kun at a couple of conferences about this project and I wanted to share what we’ve been working on, since it seems relevant to this thread.

HEonGPU is a CUDA-based homomorphic encryption library that runs entirely on the GPU. It supports BFV, CKKS, and TFHE, including full bootstrapping support (regular, slim, bit, and gate for CKKS; gate bootstrapping for TFHE), multiparty computation, unsigned integer types (huint8 to huint256), and logic operations. The general design principle is for everything from arithmetic to bootstrapping and key switching to be executed on the GPU, and the codebase is structured around multi-stream concurrency for high throughput.

The API is written in C++ and designed to be stable and straightforward to use. Users work with standard objects like Context, KeyGenerator, Encryptor, Evaluator, and so on. There are scheme-specific examples in the repository showing how this looks in practice. Parameters are configured explicitly at the Context level before any keys are generated. This includes the polynomial modulus degree, the coefficient modulus chain (either explicitly or using default presets), the plaintext modulus (for BFV), and bootstrapping mode (e.g. selecting between regular, slim, bit, or gate bootstrapping). Once set, the context is frozen and used across all encryption and evaluation operations. Key-switching modes (including digit decomposition settings) are also fixed at context creation. Galois keys and relinearization keys are generated manually and attached as needed. It was the aim to build the setup process such that the user knows exactly which parameters are active, and the system won’t silently reconfigure or adapt them.

On the storage side, the library incorporates an ExecutionOptions struct where the user can specify whether inputs live on the host or device, and whether they should return to their original location after an operation.

Performance-wise, CKKS regular bootstrapping at N = 2^16 runs in under 170ms on an RTX 4090. The bit and gate bootstrapping variants run significantly faster (around 2–3 microseconds amortized per slot). Tangentially, the TFHE implementation for unsigned arithmetic outperforms tfhe-rs and other known CUDA-based work. Detailed timings and benchmarks are in the README.

The general architecture of the library is described in ePrint 2024/1543, and a separate paper focuses on key-switching optimizations: ePrint 2025/124. A paper focused specifically on the CKKS bootstrapping implementation is currently in preparation.

HEonGPU also integrates tightly with other GPU libraries such as GPU-NTT and GPU-FFT, developed alongside it. Several projects have already been built on top of HEonGPU, including PIRonGPU and RNGonGPU, which speak to its maturity and interface stability.

Just wanted to put this out there as a candidate you might want to keep in mind. Feel free to reach out if you want technical details or have thoughts about how it might fit into HEIR’s backend model.

cc @Alisah-Ozcan

Thanks.

[asraa]

Hey @sidjay10! I heard from Edward that you may also be working on a GPU backend - do you have a link or some info on it?

We'll probably be discussing and brainstorming all these potential backends in the next week or two so I just wanted to make sure we included your work too!

[johannesmono]

A compiled library version of CHEDDAR is available on GitHub now: https://github.com/scale-snu/cheddar-fhe.