Pith. sign in

REVIEW 4 major objections 5 minor 53 references

FIDESlib: A Fully-Fledged Open-Source FHE Library for Efficient CKKS on GPUs

T0 review · 4 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read FIDESlib claims to be the first open-source CKKS library with GPU bootstrapping and full OpenFHE interoperability, reporting 70x faster bootstrapping than AVX-optimized OpenFHE.

desk verdict Plausible and well-engineered GPU CKKS library, but the headline speedups are not yet verifiable: no code release, no precision measurements, and the reported speedup numbers do not fully agree. read the letter →

arxiv 2507.04775 v1 pith:OMO23RTD submitted 2025-07-07 cs.CR

Carlos Agulló-Domingo (1) , Óscar Vera-López (1) , Seyda Guzelhan (2) , Lohit Daksha (2) , Aymane El Jerari (3) , Kaustubh Shivdikar (4) , Rashmi Agrawal (2) , David Kaeli (3)
show 5 more authors
Ajay Joshi (2) José L. Abellán (1) ((1) Universidad de Murcia (2) Boston University (3) Northeastern University (4) Advanced Micro Devices)
This is my paper
classification cs.CR
keywords CKKSfullyhomomorphicencryptionGPUaccelerationbootstrappingOpenFHERNSarithmeticNTTprivacy-preservingmachinelearning
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

FIDESlib is presented as the first open-source CKKS homomorphic encryption library that implements every server-side operation, including bootstrapping, on GPUs while remaining fully interoperable with OpenFHE's client-side key generation, encoding, encryption, and decryption. The paper's central claim is that this combination removes the main obstacle to practical GPU-accelerated privacy-preserving machine learning in cloud settings: until now, open GPU libraries either lacked bootstrapping or were not drop-in compatible with the widely used OpenFHE workflow. In benchmarks on four NVIDIA GPUs, FIDESlib reports faster execution than Phantom on every operation the two libraries share, and bootstrapping speedups of 70–74x over AVX-optimized OpenFHE. If the claim holds, encrypted inference and training can run on commodity GPUs at speeds orders of magnitude beyond CPU baselines while keeping the same security guarantees as OpenFHE clients.

What carries the argument

The load-bearing mechanism is a memory-conscious GPU kernel stack. RNS polynomials are stored as stacks of per-prime limbs; independent limb operations are split into separate CUDA kernels launched on separate streams, with a tunable limb-batch parameter that balances L2 cache locality against CPU kernel-launch overhead. The (i)NTT is a hierarchical 2D Radix-2 transform that touches global memory only four times per element, and elementwise stages are fused into the transform kernels to cut memory traffic by up to ten operations per element. Modular reduction uses improved Barrett and Shoup multiplication to avoid expensive wide divisions. Bootstrapping adapts OpenFHE's CoeffToSlot/ApproxModEval/SlotToCoeff pipeline, using BSGS and Paterson-Stockmeyer evaluation, sparse DFT block matrices, and hoisted rotations to reduce the cost of the many ciphertext rotations.

What would settle it

Run the bootstrapping benchmark in Table VI on the same RTX 4090 with identical parameters $([N,L,\Delta,dnum] = [2^{16}, 26, 2^{59}, 4])$ in both FIDESlib and OpenFHE-HEXL, and measure the actual message precision after decryption, for example the log2 of the maximum absolute error. If FIDESlib's precision falls below OpenFHE's, the claimed 70x speedup does not transfer to an equal-accuracy comparison.

Watch

Extended reading notes

Core claim

The discovery claimed is a complete and fast open-source GPU path for the CKKS scheme: FIDESlib implements all RNS-based CKKS primitives—modular arithmetic, (i)NTT, base conversion, key switching, rescaling, rotations, and bootstrapping—as GPU kernels, while delegating encoding, key generation, encryption, and decryption to OpenFHE through a thin adapter layer. The authors report that on an RTX 4090, FIDESlib beats Phantom on every operation both support and outperforms multi-threaded AVX-optimized OpenFHE by 30x to 465x on individual primitives; bootstrapping, which Phantom does not support, runs at least 70x faster than HEXL-accelerated OpenFHE, with amortized times below a millisecond at 16,384 slots. The software architecture is designed for extension to a multi-GPU backend, and the library ships unit tests, integration tests against OpenFHE, and microbenchmarks.

Load-bearing premise

The reported speedups assume that matching CKKS parameter sets produce equal output precision in FIDESlib and OpenFHE, but no precision measurements are shown; if FIDESlib's bootstrapping is less accurate, the speed advantage is partly an accuracy tradeoff.

Editorial extensions

If this is right

  • An OpenFHE-based application could swap in FIDESlib for server-side CKKS operations without changing client code, making GPU acceleration a drop-in upgrade for existing workflows.
  • With bootstrapping available on GPU at sub-millisecond amortized times, deep circuits and iterative training loops that previously required CPU nodes become feasible in cloud deployments.
  • The reported cross-GPU scaling across four platforms implies the design can track GPU hardware improvements rather than requiring new algorithms for each generation.
  • The open-source release with unit and integration tests gives researchers a reproducible base for further CKKS optimization and for benchmarking new GPU kernels.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The equal-precision assertion is the point a skeptical reader should test first: the paper states that matching parameter sets imply equal message precision but shows no precision measurements, so the speedups could overstate the practical gain if FIDESlib's bootstrapping uses a coarser approximation.
  • The singleton-context design means applications needing multiple parameter sets must run separate processes; the paper does not quantify the engineering cost this imposes on multi-tenant cloud servers.
  • The limb-batching and kernel-fusion strategy is not specific to CKKS and could plausibly accelerate other memory-bound lattice cryptography workloads, though FIDESlib does not evaluate those.
  • If the benchmark methodology were applied to AMD GPUs or datacenter parts like the A100, the optimal limb-batch values would likely shift, so the reported speedup ratios may not transfer directly across vendors or architectures.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper presents FIDESlib, a GPU-accelerated CKKS library that implements all server-side CKKS operations, including bootstrapping, and is designed to interoperate with OpenFHE for client-side operations such as key generation, encryption, and decryption. The authors describe a series of GPU optimizations (limb batching, modular-arithmetic kernels, hierarchical NTT, operation fusion, hoisted rotations, and an adapted bootstrapping pipeline) and report benchmark results on four GPU platforms. The central claims are that FIDESlib outperforms the Phantom GPU library on all shared operations and achieves at least a 70x speedup over AVX-optimized OpenFHE for bootstrapping. The paper also highlights its unit and integration testing infrastructure and a multi-GPU design roadmap.

Significance. If the performance and interoperability claims hold, FIDESlib would be a valuable open-source contribution to the FHE ecosystem: a complete GPU CKKS server backend that can be dropped into OpenFHE-based client workflows, with bootstrapping support and a test suite. The detailed description of kernel optimizations (Section III.F) is a useful engineering reference, and the integration-testing approach against OpenFHE is a strength. However, the two most consequential claims — the 70x bootstrapping speedup and the equivalence of precision across implementations — are not yet backed by released artifacts or precision measurements, which limits the current significance.

major comments (4)
  1. [Section IV.B, Table VI] The claim that 'the achieved message precision is equal across all implementations' is load-bearing for the 70x bootstrapping speedup but is not supported by any precision or decryption-error measurement. CKKS bootstrapping accuracy depends on the degree of the ApproxModEval polynomial, the number of double-angle iterations, and the CoeffToSlot/SlotToCoeff matrix decomposition (Section III.F.7), so identical parameter tuples [N, L, Delta, dnum] do not guarantee equal precision. Please report measured precision (e.g., log2 of the absolute error or decryption-error variance) for each configuration in Table VI and demonstrate that FIDESlib's output has the same precision as OpenFHE's output. Without this, the speedup may partly reflect a coarser approximation rather than pure performance.
  2. [Footnote 1; Section IV.B] The manuscript states that FIDESlib will be released 'after completion of the review process,' but the paper's central identity is an open-source library, and the benchmark results are reported as single numbers without error bars or run-to-run variance. Independent verification is currently impossible, which is particularly problematic for a performance paper with speedups exceeding 300x in Table V. Please provide a public repository URL (or a detailed artifact appendix with build scripts, exact library versions, and benchmark commands), and report standard deviations over repeated runs for the main benchmark tables. At minimum, state explicitly which figures/tables are single-run and which are averaged.
  3. [Section III.F.1, Figure 7] The 'best limb batch' parameter is selected per platform after performance evaluation (Figure 7), which creates a risk of overfitting the comparison. The paper does not describe whether a similarly tuned configuration was used for the Phantom baseline or whether the same selection procedure was applied to OpenFHE's settings. Please state the configuration-selection methodology for all libraries and provide sensitivity data (e.g., a table of timings for several limb-batch values on each platform) so readers can judge whether the reported speedups are robust across plausible configurations.
  4. [Section VI (Conclusions)] The speedup figures in the conclusions ('up to 227.8x and 74.4x') are not directly reconcilable with the numbers implied by Table VI, where the FIDESlib column's parenthetical speedups appear to be relative to OpenFHE (e.g., 73.5 ms vs. 18,224 ms gives 248x, and vs. the 5,204 ms HEXL time gives 70.8x). Please standardize the reported speedup basis (OpenFHE vs. HEXL) throughout the abstract, introduction, results, and conclusions, and ensure the table headers make clear which baseline each parenthetical value refers to.
minor comments (5)
  1. [Abstract and Section I] The abstract says 'no less than 70x speedup' while Section I says 'up to 74x' and Section VI says 'up to 227.8x and 74.4x'; these statements should be made consistent, distinguishing the speedup over OpenFHE from the speedup over AVX-optimized OpenFHE.
  2. [Table VI] Table VI is very hard to parse: the rows and columns are visually cluttered, and the 'A' entries for amortized time are not defined in the caption. Consider splitting into separate tables for time and speedup, or adding explicit column headers for each baseline.
  3. [Introduction (reference numbering)] In the introduction, 'OpenFHE [10]' appears to be a citation error; OpenFHE is reference [34], while [10] is the CKKS scheme paper. Please verify all reference numbers.
  4. [Section III.E] The singleton-context limitation (only one parameter set can be active at a time) is mentioned but not discussed in the evaluation; a sentence on how this affects real multi-application deployments would help readers assess practical usability.
  5. [Figure 3] The NTT data-movement diagram lacks axis labels and a legend; adding explicit labels for the '32B' transaction and the transpose/bit-reversal steps would improve readability.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the central claims are empirical benchmark results against external libraries, not derivations from fitted inputs or self-citations.

full rationale

FIDESlib's central claims are that it is the first open-source CKKS GPU library with full server-side functionality including bootstrapping, that it interoperates with OpenFHE client operations, and that it outperforms Phantom and AVX-optimized OpenFHE. These claims are supported by direct measurements reported in Tables V, VI, and VII against external baselines (OpenFHE, HEXL-enabled OpenFHE, and Phantom) on named GPU platforms. No fitted parameter is used to produce a predicted speedup, and no theoretical result is derived from an assumption that already contains the claimed outcome. The statement in Section IV.B that 'the achieved message precision is equal across all implementations' is an empirical fairness assertion rather than a circular step; it may be insufficiently substantiated, but it does not make the benchmark a tautology. Citations to prior work by overlapping authors, such as the memory-aware design reference [45] and the improved Barrett reduction [50], supply algorithmic techniques and design guidance, but the paper's performance conclusions are not inferred from those citations; they come from the paper's own benchmark experiments. The planned release after review is a reproducibility and availability concern, not a circularity concern. Under the review rule that circularity must be exhibited as an equation, fit, or self-citation chain that forces the result, no such reduction appears in this manuscript.

Assumptions & free parameters 1 free parameters · 3 assumptions · 0 invented entities

This is a systems implementation paper, so the central result is an artifact rather than a mathematical derivation. There are no invented entities and no fitted model parameters beyond implementation tuning choices; the key dependencies are the correctness of the CKKS scheme, the OpenFHE client operations, and the GPU hardware assumptions.

free parameters (1)
  • limb_batch = varies per GPU (Fig. 7, e.g., 2-12)
    The paper tunes the number of limbs processed per kernel launch per platform to maximize HMult performance and reports the best value. The central performance comparisons depend on this hand-chosen parameter, and no equivalent tuning is described for baseline libraries.
assumptions (3)
  • domain assumption CKKS scheme and its security assumptions (RLWE hardness) hold
    The paper relies on the CKKS cryptosystem as described in [10] and inherits its security; this is not proved in the paper.
  • domain assumption OpenFHE client-side operations (KeyGen, Encrypt, Decrypt) are correct and secure
    FIDESlib delegates all client-side operations to OpenFHE (Section III.A), so the security of the overall system depends on OpenFHE's implementation.
  • domain assumption The described GPU hardware (memory bandwidth, L2 cache size, shared memory) behaves as standard and performance results generalize
    The optimizations are motivated by characteristics of NVIDIA GPUs (Section II.B); if those assumptions fail on other GPUs, the speedups may not transfer.

how reviews work

0 comments
Cite this review

Pith. "Pith review of FIDESlib: A Fully-Fledged Open-Source FHE Library for Efficient CKKS on GPUs." pith.science (2026). https://pith.science/paper/OMO23RTD

@misc{pith2026250704775,
  author       = {Pith},
  title        = {Pith review of: FIDESlib: A Fully-Fledged Open-Source FHE Library for Efficient CKKS on GPUs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OMO23RTD}},
  note         = {Machine review of arXiv:2507.04775}
}
read the original abstract

Word-wise Fully Homomorphic Encryption (FHE) schemes, such as CKKS, are gaining significant traction due to their ability to provide post-quantum-resistant, privacy-preserving approximate computing; an especially desirable feature in Machine-Learning-as-a-Service (MLaaS) cloud-computing paradigms. OpenFHE is a leading CPU-based FHE library with robust CKKS operations, but its server-side performance is not yet sufficient for practical cloud deployment. As GPU computing becomes more common in data centers, many FHE libraries are adding GPU support. However, integrating an efficient GPU backend into OpenFHE is challenging. While OpenFHE uses a Hardware Abstraction Layer (HAL), its flexible architecture sacrifices performance due to the abstraction layers required for multi-scheme and multi-backend compatibility. In this work, we introduce FIDESlib, the first open-source server-side CKKS GPU library that is fully interoperable with well-established client-side OpenFHE operations. Unlike other existing open-source GPU libraries, FIDESlib provides the first implementation featuring heavily optimized GPU kernels for all CKKS primitives, including bootstrapping. Our library also integrates robust benchmarking and testing, ensuring it remains adaptable to further optimization. Furthermore, its software architecture is designed to support extensions to a multi-GPU backend for enhanced acceleration. Our experiments across various GPU systems and the leading open-source CKKS library to date, Phantom, show that FIDESlib offers superior performance and scalability. For bootstrapping, FIDESlib achieves no less than 70x speedup over the AVX-optimized OpenFHE implementation.

Figures

Figures reproduced from arXiv: 2507.04775 by the authors.

Figure 1
Figure 1. High-Level Functionality Overview in FIDESlib. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Data class diagram. classes, such as CKKS::Parameters, CKKS::Ciphertext, CKKS::Plaintext, and CKKS::KeySwitchingKey, which store the data in GPU memory. For the CKKS::Ciphertext class, the reverse process is also supported, transferring the data, along with static noise estimation data, back to an OpenFHE ciphertext object for decryption. C. Software design The FIDESlib codebase is organized into four namespaces: 1)… view at source ↗
Figure 3
Figure 3. Data movement diagram of the Radix-2 2D/Hierarchical NTT algorithm implemented in FIDESLib. constants are also precomputed, enabling Shoup modular multiplication to speed up the NTT butterflies. The iNTT is implemented with Gentleman-Sande butterflies instead of Cooley-Tukey butterflies, which take a bit-reversed evaluation polynomial and output a normal-ordered coefficient polynomial. This approach eliminates the n… view at source ↗
Figures from the paper (4 more)
Figure 5
Figure 5. Figure 5: P tMult+Rescale. Best limb batch. 5 10 15 20 25 30 Processed Limbs 0 500 1000 1500 2000 2500 3000 3500 Time (us) Platform 4060Ti A4500 V100 4090 [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 4
Figure 4. Figure 4: (i)NTT performance comparison (lower is better). [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 7
Figure 7. Figure 7: HMult with maximum levels. Limb batch comparison. [13, 5, 36, 2] [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: HMult with maximum levels. Parameter set [log(N), L, ∆, dnum] comparison. Slots Levels OpenFHE HEXL-24 threads FIDESlib-RTX 4090 64 13 18 224 T 5 204 (3.50×) 73.5 (248×) 21 904 A 6 255 88.3 512 11 18 268 T 7 781 (2.35×) 93.3 (196×) 3 243 A 1 381 16.6 16384 9 20 079 T 9…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

53 extracted references · 44 canonical work pages

  1. [1]

    Mlaas: Machine learning as a service,

    M. Ribeiro, K. Grolinger, and M. A. Capretz, “Mlaas: Machine learning as a service,” in 2015 IEEE 14th international conference on machine learning and applications (ICMLA) . IEEE, 2015, pp. 896–902

    work page 2015

  2. [2]

    Mishra, Machine learning in the AWS cloud: Add intelligence to applications with Amazon Sagemaker and Amazon Rekognition

    A. Mishra, Machine learning in the AWS cloud: Add intelligence to applications with Amazon Sagemaker and Amazon Rekognition . John Wiley & Sons, 2019

    work page 2019

  3. [3]

    S. R. Sukhdeve and S. S. Sukhdeve, Google Cloud Platform for Data Science. Apress Berkeley, CA, 2023

    work page 2023

  4. [4]

    K ¨orner and K

    C. K ¨orner and K. Waaijer, Mastering Azure Machine Learning: Perform large-scale end-to-end advanced machine learning in the cloud with Microsoft Azure Machine Learning . Packt Publishing Ltd, 2020

    work page 2020

  5. [5]

    Cost of a Data Breach Report,

    IBM, “Cost of a Data Breach Report,” 2024, https://www.ibm.com/reports/data-breach

    work page 2024

  6. [6]

    First steps to quantum resilience: Identifying ‘broken concepts’ in australia’s national security laws,

    S. Lloyd-Jones and K. Manwaring, “First steps to quantum resilience: Identifying ‘broken concepts’ in australia’s national security laws,” ANU Journal of Law and Technology , September 2024, forthcoming. [Online]. Available: https://ssrn.com/abstract=4976322

    work page 2024

  7. [7]

    FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard,

    National Institute of Standards and Technology (NIST), “FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard,” Au- gust 2024, https://csrc.nist.gov/pubs/fips/203/final

    work page 2024

  8. [8]

    FIPS 204: Module-Lattice-Based Digital Signature Standard,

    National Institute of Standards and Technology, “FIPS 204: Module-Lattice-Based Digital Signature Standard,” August 2024, https://csrc.nist.gov/pubs/fips/204/final

    work page 2024

Show all 53 references
  1. [9]

    Announcing Is- suance of Federal Information Processing Standards,

    F. R. T. D. J. of the United States Government, “Announcing Is- suance of Federal Information Processing Standards,” August 2024, https://www.federalregister.gov/d/2024-17956

    2024

  2. [11]

    Accelerating fully homomorphic encryption through architecture-centric analysis and optimization,

    W. Jung, E. Lee, S. Kim, J. Kim, N. Kim, K. Lee, C. Min, J. H. Cheon, and J. H. Ahn, “Accelerating fully homomorphic encryption through architecture-centric analysis and optimization,” IEEE Access, vol. 9, pp. 98 772–98 789, 2021

    2021

  3. [12]

    Intel hexl: Accelerating homomorphic encryption with intel avx512-ifma52,

    F. Boemer, S. Kim, G. Seifu, F. D. M. de Souza, and V . Gopal, “Intel hexl: Accelerating homomorphic encryption with intel avx512-ifma52,”

  4. [13]

    Practical solutions in fully homomorphic encryption: a survey analyzing existing acceleration methods,

    Y . Gong, X. Chang, J. Mi ˇsi´c, V . B. Mi ˇsi´c, J. Wang, and H. Zhu, “Practical solutions in fully homomorphic encryption: a survey analyzing existing acceleration methods,” Cybersecurity, vol. 7, no. 1, 3

  5. [14]

    Why Data Center GPUs Are Essential to Innovation,

    Intel, “Why Data Center GPUs Are Essential to Innovation,” https://www.intel.com/content/www/us/en/products/docs/discrete- gpus/data-center-gpu/what-is-data-center-gpu.html, 2024, [Online; accessed 13-December-2024]

    2024

  6. [15]

    Phantom: a cuda-accelerated word-wise homomorphic encryption library,

    H. Yang, S. Shen, W. Dai, L. Zhou, Z. Liu, and Y . Zhao, “Phantom: a cuda-accelerated word-wise homomorphic encryption library,” IEEE Transactions on Dependable and Secure Computing , 2024

    2024

  7. [16]

    Cheddar: A swift fully homomorphic encryption library for cuda gpus,

    J. Kim, W. Choi, and J. H. Ahn, “Cheddar: A swift fully homomorphic encryption library for cuda gpus,” arXiv preprint arXiv:2407.13055 , 2024

    2024 arXiv

  8. [17]

    Heaan private ai homomorphic encryption library. fully homomorphic encryption with ckks scheme, faster bootstrapping and gpu-acceleration

    C. INC., “Heaan private ai homomorphic encryption library. fully homomorphic encryption with ckks scheme, faster bootstrapping and gpu-acceleration.” 2022, https://heaan.it/

    2022

  9. [18]

    HEonGPU: a GPU-based fully homomorphic encryption library 1.0,

    A. S ¸ah ¨Ozcan and E. Savas ¸, “HEonGPU: a GPU-based fully homomorphic encryption library 1.0,” Cryptology ePrint Archive, Paper 2024/1543, 2024. [Online]. Available: https://eprint.iacr.org/2024/1543

    2024

  10. [19]

    Over 100x faster bootstrapping in fully homomorphic encryption through memory- centric optimization with gpus,

    W. Jung, S. Kim, J. H. Ahn, J. H. Cheon, and Y . Lee, “Over 100x faster bootstrapping in fully homomorphic encryption through memory- centric optimization with gpus,” IACR Transactions on Cryptographic Hardware and Embedded Systems , pp. 114–148, 2021

    2021

  11. [20]

    The new implementation of troy, a cuda based gpu parallelized implementation of rlwe homomorphic encryption schemes

    lightbulb128, “The new implementation of troy, a cuda based gpu parallelized implementation of rlwe homomorphic encryption schemes.” 2023, https://github.com/lightbulb128/troy-nova

    2023

  12. [21]

    He- booster: An efficient polynomial arithmetic acceleration on gpus for fully homomorphic encryption,

    Z. Wang, P. Li, R. Hou, Z. Li, J. Cao, X. Wang, and D. Meng, “He- booster: An efficient polynomial arithmetic acceleration on gpus for fully homomorphic encryption,” IEEE Transactions on Parallel and Distributed Systems, vol. 34, no. 4, pp. 1067–1081, 2023

    2023

  13. [22]

    Tensorfhe: Achieving practical computation on encrypted data using gpgpu,

    S. Fan, Z. Wang, W. Xu, R. Hou, D. Meng, and M. Zhang, “Tensorfhe: Achieving practical computation on encrypted data using gpgpu,” in 2023 IEEE International Symposium on High-Performance Computer Architecture (HPCA), 2023, pp. 922–934

    2023

  14. [23]

    Liberate.FHE: A New FHE Library for Bridging the Gap be- tween Theory and Practice with a Focus on Performance and Accuracy,

    DESILO, “Liberate.FHE: A New FHE Library for Bridging the Gap be- tween Theory and Practice with a Focus on Performance and Accuracy,” 2023, https://github.com/Desilo/liberate-fhe, https://github.com/FHE- org/fhe-org.github.io/files/14896471/07-Kim.pdf

    2023

  15. [24]

    Google test,

    Google, “Google test,” 2024, accessed: 2024-12-17. [Online]. Available: https://github.com/google/googletest

    2024

  16. [25]

    Google benchmark,

    ——, “Google benchmark,” 2024, accessed: 2024-12-17. [Online]. Available: https://github.com/google/benchmark

    2024

  17. [26]

    Fully homomorphic encryption using ideal lattices,

    C. Gentry, “Fully homomorphic encryption using ideal lattices,” in Proceedings of the forty-first annual ACM symposium on Theory of computing, 2009, pp. 169–178

    2009

  18. [27]

    (leveled) fully ho- momorphic encryption without bootstrapping,

    Z. Brakerski, C. Gentry, and V . Vaikuntanathan, “(leveled) fully ho- momorphic encryption without bootstrapping,” ACM Transactions on Computation Theory (TOCT) , vol. 6, no. 3, pp. 1–36, 2014

    2014

  19. [28]

    Somewhat practical fully homomorphic encryption,

    J. Fan and F. Vercauteren, “Somewhat practical fully homomorphic encryption,” Cryptology ePrint Archive , 2012

    2012

  20. [29]

    Tfhe: fast fully homomorphic encryption over the torus,

    I. Chillotti, N. Gama, M. Georgieva, and M. Izabach `ene, “Tfhe: fast fully homomorphic encryption over the torus,” Journal of Cryptology , vol. 33, no. 1, pp. 34–91, 2020

    2020

  21. [30]

    Fhew: bootstrapping homomorphic en- cryption in less than a second,

    L. Ducas and D. Micciancio, “Fhew: bootstrapping homomorphic en- cryption in less than a second,” in Annual international conference on the theory and applications of cryptographic techniques . Springer, 2015, pp. 617–640

    2015

  22. [31]

    Homomorphic encryption for arithmetic of approximate numbers,

    J. H. Cheon, A. Kim, M. Kim, and Y . Song, “Homomorphic encryption for arithmetic of approximate numbers,” in Advances in Cryptology– ASIACRYPT 2017: 23rd International Conference on the Theory and Applications of Cryptology and Information Security, Hong Kong, China, December...

    2017

  23. [32]

    Design and implementation of helib: a homomorphic encryption library,

    S. Halevi and V . Shoup, “Design and implementation of helib: a homomorphic encryption library,” Cryptology ePrint Archive , 2020

    2020

  24. [33]

    Simple encrypted arithmetic library 2.3. 1,

    K. Laine, “Simple encrypted arithmetic library 2.3. 1,” Microsoft Research https://www. microsoft. com/en- us/research/uploads/prod/2017/11/sealmanual-2-3-1. pdf, 2017

    2017

  25. [34]

    Openfhe: Open-source fully homomorphic encryption library,

    A. Al Badawi, J. Bates, F. Bergamaschi, D. B. Cousins, S. Erabelli, N. Genise, S. Halevi, H. Hunt, A. Kim, Y . Lee et al. , “Openfhe: Open-source fully homomorphic encryption library,” in proceedings of the 10th workshop on encrypted computing & applied homomorphic cryptograph...

    2022

  26. [35]

    A full rns variant of approximate homomorphic encryption,

    J. H. Cheon, K. Han, A. Kim, M. Kim, and Y . Song, “A full rns variant of approximate homomorphic encryption,” in Selected Areas in Cryptography–SAC 2018: 25th International Conference, Calgary, AB, Canada, August 15–17, 2018, Revised Selected Papers 25 . Springer, 2019, pp. 347–368

    2018

  27. [36]

    Approximate homomorphic encryption with reduced approximation error,

    A. Kim, A. Papadimitriou, and Y . Polyakov, “Approximate homomorphic encryption with reduced approximation error,” in Cryptographers’ Track at the RSA Conference . Springer, 2022, pp. 120–144

    2022

  28. [37]

    Better bootstrapping for approximate homomorphic encryption,

    K. Han and D. Ki, “Better bootstrapping for approximate homomorphic encryption,” in Cryptographers’ Track at the RSA Conference. Springer, 2020, pp. 364–390

    2020

  29. [38]

    Bootstrapping for approximate homomorphic encryption,

    J. H. Cheon, K. Han, A. Kim, M. Kim, and Y . Song, “Bootstrapping for approximate homomorphic encryption,” in Advances in Cryptology– EUROCRYPT 2018: 37th Annual International Conference on the The- ory and Applications of Cryptographic Techniques, Tel Aviv, Israel, April 29-M...

    2018

  30. [39]

    Faster homomorphic linear transformations in helib,

    S. Halevi and V . Shoup, “Faster homomorphic linear transformations in helib,” in Annual International Cryptology Conference. Springer, 2018, pp. 93–120

    2018

  31. [40]

    Faster homomorphic discrete fourier transforms and improved fhe bootstrapping,

    J. H. Cheon, K. Han, and M. Hhan, “Faster homomorphic discrete fourier transforms and improved fhe bootstrapping,” Cryptology ePrint Archive, 2018

    2018

  32. [41]

    High-precision boot- strapping of rns-ckks homomorphic encryption using optimal minimax polynomial approximation and inverse sine function,

    J.-W. Lee, E. Lee, Y . Lee, Y .-S. Kim, and J.-S. No, “High-precision boot- strapping of rns-ckks homomorphic encryption using optimal minimax polynomial approximation and inverse sine function,” in Advances in Cryptology–EUROCRYPT 2021: 40th Annual International Conference on...

    2021

  33. [42]

    Efficient bootstrapping for approximate homomorphic encryption with non-sparse keys,

    J.-P. Bossuat, C. Mouchet, J. Troncoso-Pastoriza, and J.-P. Hubaux, “Efficient bootstrapping for approximate homomorphic encryption with non-sparse keys,” in Annual International Conference on the Theory and Applications of Cryptographic Techniques . Springer, 2021, pp. 587–617

    2021

  34. [43]

    Bootstrap- ping for approximate homomorphic encryption with negligible failure- probability by using sparse-secret encapsulation,

    J.-P. Bossuat, J. Troncoso-Pastoriza, and J.-P. Hubaux, “Bootstrap- ping for approximate homomorphic encryption with negligible failure- probability by using sparse-secret encapsulation,” in International Con- ference on Applied Cryptography and Network Security. Springer, 202...

    2022

  35. [44]

    Improved bootstrapping for approx- imate homomorphic encryption,

    H. Chen, I. Chillotti, and Y . Song, “Improved bootstrapping for approx- imate homomorphic encryption,” in Annual International Conference on the Theory and Applications of Cryptographic Techniques . Springer, 2019, pp. 34–54

    2019

  36. [45]

    Mad: Memory-aware design techniques for accelerating fully homomorphic encryption,

    R. Agrawal, L. De Castro, C. Juvekar, A. Chandrakasan, V . Vaikuntanathan, and A. Joshi, “Mad: Memory-aware design techniques for accelerating fully homomorphic encryption,” in Proceedings of the 56th Annual IEEE/ACM International Symposium on Microarchitecture, ser. MICRO ’23...

    2023

  37. [46]

    Ark: Fully homomorphic encryption accelerator with runtime data generation and inter-operation key reuse,

    J. Kim, G. Lee, S. Kim, G. Sohn, M. Rhu, J. Kim, and J. H. Ahn, “Ark: Fully homomorphic encryption accelerator with runtime data generation and inter-operation key reuse,” in 2022 55th IEEE/ACM International Symposium on Microarchitecture (MICRO). IEEE, Oct. 2022, p. 1237–1254...

    2022

  38. [47]

    Does fully homomorphic encryption need compute acceleration?

    L. de Castro, R. Agrawal, R. Yazicigil, A. Chandrakasan, V . Vaikuntanathan, C. Juvekar, and A. Joshi, “Does fully homomorphic encryption need compute acceleration?” 2021. [Online]. Available: https://arxiv.org/abs/2112.06396

    2021 arXiv

  39. [48]

    Agrawal and A

    R. Agrawal and A. Joshi, On Architecting Fully Homomorphic Encryption-based Computing Systems , 01 2023

    2023

  40. [49]

    Gme: Gpu-based microarchitectural extensions to accelerate homomorphic encryption,

    K. Shivdikar, Y . Bao, R. Agrawal, M. Shen, G. Jonatan, E. Mora, A. Ingare, N. Livesay, J. L. Abell ´an, J. Kim et al. , “Gme: Gpu-based microarchitectural extensions to accelerate homomorphic encryption,” in Proceedings of the 56th Annual IEEE/ACM International Symposium on M...

    2023

  41. [50]

    Accelerating polynomial multi- plication for homomorphic encryption on gpus,

    K. Shivdikar, G. Jonatan, E. Mora, N. Livesay, R. Agrawal, A. Joshi, J. L. Abell ´an, J. Kim, and D. Kaeli, “Accelerating polynomial multi- plication for homomorphic encryption on gpus,” in 2022 IEEE Interna- tional Symposium on Secure and Private Execution Environment Design ...

    2022

  42. [51]

    Logistic regression on homomorphic encrypted data at scale,

    K. Han, S. Hong, J. H. Cheon, and D. Park, “Logistic regression on homomorphic encrypted data at scale,” Proceedings of the AAAI Conference on Artificial Intelligence , vol. 33, no. 01, pp. 9466–9471, Jul. 2019. [Online]. Available: https://ojs.aaai.org/index.php/AAAI/article/...

    2019

  43. [52]

    Accelerated Computing with HIP,

    Y . Sun, T. Baruah, and D. Kaeli, “Accelerated Computing with HIP,” https://community.amd.com/t5/instinct-accelerators/accelerated- computing-with-hip-textbook/ba-p/620840, 2022, ingram Spark Publishing

    2022

  44. [2021]

    Available: https://arxiv.org/abs/2103.16400

    [Online]. Available: https://arxiv.org/abs/2103.16400

    arXiv

  45. [2024]

    Available: https://doi.org/10.1186/s42400-023-00187-4

    [Online]. Available: https://doi.org/10.1186/s42400-023-00187-4

    doi

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.