Pith. sign in

REVIEW 3 major objections 4 minor 46 references

Input–output consistency checks can protect CKKS encrypted computation on CPUs, detecting every single-bit transient fault examined while adding only about 6.8% runtime overhead.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-01 14:34 UTC pith:WO6WFVL7

load-bearing objection Overhead claims are solid; the 100% detection claim is broader than the mechanism supports — faults in operand loads or result stores are invisible to an input-output consistency check. the 3 major comments →

arxiv 2607.18720 v1 pith:WO6WFVL7 submitted 2026-07-21 cs.AR

An Efficient Fault-Tolerance Scheme for CKKS Computation on CPUs

Jianan Mu , Ge Yu , Tenghui Hua , Liang Kong , Jing Ye , Xing Hu , Meng Li , Xiaowei Li
show 1 more author
Huawei Li
This is my paper
classification cs.AR
keywords fully homomorphic encryptionCKKSsilent data corruptionfault tolerancechecksumnumber theoretic transformRNStransient faults
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The paper tries to establish that silent hardware faults during CKKS fully homomorphic encryption on ordinary CPUs can be caught cheaply by checking each polynomial operator's input against its output, rather than duplicating computation or adding dedicated hardware. It claims this catches all evaluated non-crashing single-bit corruptions — 150,000 injected cases across NTT/INTT, basis conversion, and element-wise multiplication — while adding just 6.0–8.4% runtime, versus 33.4% for a direct checksum approach and over 100% for duplicated execution. The efficiency comes from three restructurings: accumulating unreduced products in wide CPU registers so modular reductions happen once per bucket; folding checksum computation into the operator's own dataflow so no extra polynomial scans occur; and fusing redundant boundary checks between adjacent operators. If correct, dependable encrypted inference, database queries, and machine learning on CPU-based FHE stacks become practical without specialized accelerators.

Core claim

On the paper's own terms, the central claim is that the three major CKKS polynomial operators — NTT/INTT, basis conversion, and element-wise multiplication — can be protected on general-purpose CPUs by verifying a checksum invariant between each operator's inputs and outputs, and that the verification can be reshaped to fit CPU arithmetic and memory behaviour. The authors reimplemented the protected operators in an open-source FHE library and report 100% empirical detection of 150,000 non-crashing corrupted-result cases under random single-bit transient faults, with application accuracy staying near the fault-free baseline across fault rates from 10^-12 to 10^-6. They report runtime overhead

What carries the argument

The load-bearing object is the checksum invariant: for a linear operator y = F(x), the checker precomputes vectors e and d with e^T = d^T F so that the input-side checksum Σ e_i x_i equals the output-side checksum Σ d_i y_i under fault-free execution; any single-bit corruption that changes the operator result ideally breaks the equality. Three mechanisms make this cheap on CPUs. Modulus-aware bucket checksum (Eq. 3) accumulates up to s(q) unreduced coefficient products in a 128-bit accumulator and performs one Barrett reduction (the multiply-and-shift modular reduction) per bucket, cutting modular reductions from N to v(q). Dataflow-fused in-operator checking embeds the input-side accumulati

Load-bearing premise

The load-bearing premise is that every single-bit fault that corrupts an operator result also disturbs the side of the checksum invariant the checker actually sees; but faults in operand loads or in stores made after checksum accumulation change both sides together and are invisible by construction, so the claimed 100% detection rate holds only if such instructions are excluded from the fault-injection set.

What would settle it

Inject a single-bit flip into a load that reads a coefficient at an operator's input boundary, or into a store that writes an operator's output after the checksum accumulator has been updated, and check whether the protected pipeline reports a mismatch; if the corrupted ciphertext passes the checksum, the universal single-bit detection claim fails.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • Encrypted inference workloads such as LoLA, MLP, ResNet-20, and VGG-16 keep near-fault-free accuracy across fault rates where unprotected CKKS collapses, because corrupted operators are detected and re-executed.
  • Protection overhead stays in a 6.0–8.4% band for both ciphertext primitives and full applications, making checksum-based fault detection viable for CPU-based FHE deployment.
  • Each detected fault costs less than 1% of end-to-end runtime to recover from, because only the affected operator or short fused segment is re-executed.
  • The three optimizations contribute jointly: removing cross-operator fusion raises overhead to roughly 111%, further removing bucket checksum to roughly 125%, and removing in-operator fusion to the roughly 133% basic-checksum baseline.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same bucket-checksum and dataflow-fusion ideas should transfer to other RNS-based FHE schemes and libraries, since they exploit only coefficient bit-widths and operator linearity, not CKKS-specific details.
  • The 100% detection figure is contingent on what counts as an 'eligible' fault site: a flip in an operand load at an operator boundary changes both the input checksum and the operator's inputs together, and a flip in a store after the checksum accumulator is updated leaves the in-memory output wrong while the accumulator stays correct; such faults are invisible by construction, so the result should
  • Cross-operator fusion weakens fault localization: after fusion, a mismatch at the segment output re-executes two operators, so there is a latency-versus-detection-granularity knob that parameter selection could trade off.
  • The detection scheme could be tested beyond random single-bit faults, for example with double-bit flips or faults in address and comparator instructions; the paper's own limitation statement says such models remain future work.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 4 minor

Summary. This paper proposes a checksum-based fault-detection scheme for CKKS polynomial operators (NTT/INTT, EWM, BConv) on CPUs, with three optimizations to reduce protection overhead: modulus-aware bucket checksum that batches modular reductions using wide accumulators (Eq. 3), dataflow-fused in-operator checking that piggybacks checksum accumulation on live loads/stores (Algorithm 1), and cross-operator check fusion that removes redundant boundary checks (Eqs. 5–7). The authors implement the scheme in OpenFHE and evaluate it on four encrypted inference applications and CKKS primitives. They report 100% empirical detection over 150,000 non-crashing single-bit fault injections and 6.0–8.4% runtime overhead (average 6.8%), a 4.9x reduction relative to a basic checksum baseline. The overhead results are supported by a progressive ablation and hardware-counter profiling.

Significance. If the detection claim can be scoped to a well-defined fault model, this is a solid engineering contribution. The algebraic invariants are parameter-free, the bucket-size formula in Eq. (2) is closed-form, and the ablation/hardware-counter data consistently attribute the overhead reduction to the three proposed optimizations; 1,000-run averaging and 150,000 fault cases are reasonable. The main concern is that the described checks are consistency checks over register-level values, so single-bit faults in operand loads or output stores at operator boundaries are invisible by construction. The 'eligible dynamic instructions' filter is undefined, making the headline 100% detection rate unreproducible and, if loads/stores are eligible, impossible. The paper's value would survive a narrowed scope ('protection of the arithmetic datapath'), but the current claims overstate the coverage.

major comments (3)
  1. [§4.3.1, §4.3.2, Algorithm 1] The checks are input-output consistency checks over register-level values, so single-bit faults in an operand load at an operator boundary are invisible by construction: C_in is accumulated from the same loaded a_i that feeds the computation (Algorithm 1 lines 6–7), and in EWM C_in and C_out are the same product Σ a_i k_i on both sides. A fault in a store after C_out has been accumulated (line 13) likewise corrupts memory without changing the checked values. The 'eligible dynamic instructions' of §3.1 is never defined; if it includes loads/stores, the 100% detection in Table II cannot hold; if it excludes them, the fault model and claims must be narrowed. This is load-bearing for the abstract and §5.2.
  2. [§5.2, Table II] The detection-rate methodology is unreproducible as reported. The 150,000 'non-crashing corrupted-result cases' are sampled from an unspecified eligible-instruction set; no PinFI configuration, instruction-class filter, or artifact is provided. Without knowing whether memory, address, control-flow, or checksum instructions are eligible, the reader cannot interpret or repeat the experiment. Please specify the exact eligible instruction classes per operator, report detection rates stratified by fault class (e.g., arithmetic vs. load/store), and provide the injection script/artifact or a precise pseudocode description. The current '100%' is broader than what the described mechanism can guarantee.
  3. [§4.2.1, Eq. (2)] The overflow bound s(q)·(q−1)^2 ≤ 2^D − 1 is derived for fault-free operands in [0, q−1]. Under the single-bit fault model of §3.1, a flipped bit in a load or ALU result can produce an operand up to 2^64−1, so a bucket of s(q) products can exceed the 128-bit accumulator. The claim that no dynamic overflow check is required therefore does not hold in exactly the faulty cases the scheme must detect. Please clarify whether overflow-induced behavior (including false accept by wrap-around) is accounted for in the empirical 100% detection claim, or state an additional bound/assumption on faulted operands.
minor comments (4)
  1. [§2.2 vs. §4.3.1] The notation for checksum vectors is inconsistent: in §2.2 the encoding vector is e and the decoding vector is d, while in §4.3.1 e is called the decode vector. Please unify the notation.
  2. [Algorithm 1, line 12] Computing b = floor(i/s) for every output coefficient introduces a per-element division (or a constant-division optimization). The paper does not mention how this is handled in the implementation; consider describing an incrementing bucket counter or noting the compiler strength reduction.
  3. [Figure 1] The figure caption contains stray text ('Version Evaluation on (a)？ Barrier') that appears to be an editing artifact. Please clean it up.
  4. [Table I] The table formatting is garbled: entries such as '2 16 215 30≈1560 128' are hard to parse. Please use proper math notation (e.g., N = 2^16, slots = 2^15, log2 Q ≈ 1560) and clarify the meaning of each column.

Circularity Check

0 steps flagged

No circularity found: the checksum invariants are parameter-free algebraic identities and the three optimizations are structural transformations; the 100% detection claim has a non-circular coverage gap.

full rationale

The derivation chain is self-contained. Eq. (2) derives bucket sizes from a bit-width bound s(q)=floor((2^D-1)/(q-1)^2) with no fitted constants; Eq. (3) is a rearrangement of the coefficient-sum with Barrett reductions postponed per bucket; Eq. (4) is modular linearity. The NTT encode/decode vectors are determined by the transform matrix (e^T = d^T F), EWM and BConv checks are direct algebraic definitions, and cross-operator fusion (Eqs. 5-7) propagates an identical checksum state only when the decode and encode vectors coincide, which is an algebraic identity rather than a fitted prediction. No load-bearing step relies on a self-citation; the only overlapping-author citation ([33]) supports the background linearity of NTT and is not used to force the scheme. The 100% detection rate in Table II is empirical, not derived, and the paper's own mechanism description indicates that a single-bit fault in an operator input load (Algorithm 1 lines 6-7 accumulate C_in from the same a_i that feeds the butterflies) or in a store after the final accumulator would change both sides consistently and evade the invariant. This is a validity/coverage concern, not circularity: the invariant is not equivalent to the claimed prediction by construction, and the empirical claim is under-specified because Section 3.1's 'eligible dynamic instructions' is undefined. The paper's limitation statement ('The reported 100% detection rate is empirical and applies to the collected non-crashing cases under the evaluated fault model') narrows but does not repair this missing injection-policy definition. Such concerns belong to correctness risk, not to circularity of the derivation.

Axiom & Free-Parameter Ledger

0 free parameters · 6 axioms · 0 invented entities

No fitted parameters: bucket sizes are closed-form (Eq. 2), decode vectors derive from the transform, and overhead/detection numbers are measurements. The central claim rests on the five assumptions listed, plus the fault-site-coverage premise — the load-bearing one that receives no explicit statement and is challenged by §4.3.1–4.3.2's placement of accumulation.

axioms (6)
  • domain assumption At most one single-bit fault occurs per low-level polynomial-operator invocation, and faults are independent.
    The entire detection argument and the 100% claim are conditioned on this (§3.1); multiple/correlated faults are out of scope and acknowledged in §6. A single checksum functional cannot guarantee detection of structured multiple errors.
  • standard math The NTT/INTT checksum invariant Σ a_i ≡ Σ e_i·NTT(a)_i (mod q) holds with precomputed decode vector e, and every e_i ≠ 0 mod q.
    Linear-algebra invariant from §2.2 (e^T = d^T F). Relies on exact linearity over each RNS tower and on moduli such that single-coefficient errors change the weighted sum. Standard ABFT, not proved in the paper.
  • domain assumption The RNS moduli in the evaluated configurations are ~50–60 bits, leaving spare headroom in the 128-bit accumulator.
    §4.2.1: bucket-checksum benefit depends on q ≈ 50–60 bits (Table I). For moduli near 62+ bits, s(q) → 1 and the optimization's benefit largely vanishes. Configuration-dependent, not a fitted parameter.
  • domain assumption Adjacent operators pass the same polynomial representation, so Dec_f(y) = Enc_g(y) at fused boundaries.
    §4.2.3/§4.4: fusion is only instantiated when boundary checks coincide; the evaluated pipeline (Fig. 12) has two such boundaries (BConv→NTT, EWM→INTT). Other pipelines would see less fusion benefit.
  • domain assumption PinFI instruction-level fault injection with the stated eligibility policy faithfully samples transient hardware faults.
    §3.1/§5.1: the 100% detection and accuracy curves are generated under this protocol; 'eligible dynamic instructions' is never enumerated, so fault-site coverage (loads vs. arithmetic vs. stores) is unknown — central to whether the reported 100% generalizes.
  • ad hoc to paper A consistency check that sees every single-bit fault corrupting an operator result must detect faults in operand loads and in stores made after decode accumulation.
    This is the load-bearing premise challenged by the paper's own placement of accumulation (§4.3.1–4.3.2): faults in loads at segment inputs and in stores after decode accumulation shift both sides of the invariant together and are invisible by construction. The paper never states this residual class explicitly.

pith-pipeline@v1.3.0-alltime-deepseek · 19565 in / 28256 out tokens · 264241 ms · 2026-08-01T14:34:51.365066+00:00 · methodology

0 comments
read the original abstract

Fully homomorphic encryption (FHE) enables computation on encrypted data, but its long ciphertext dataflow and high-dimensional modular arithmetic make it vulnerable to silent data corruption caused by transient hardware faults. Existing protection methods either target dedicated accelerators or impose substantial execution, modular-arithmetic, and memory-access overheads on CPUs. This work presents an efficient fault-tolerance scheme for CPU-based CKKS computation. It checks the input-output consistency of polynomial operators while reducing protection overhead at three levels. First, modulus-aware bucket checksum exploits wide CPU accumulators to reduce expensive modular reductions. Second, dataflow-fused in-operator checking embeds checksum accumulation into operator dataflows, avoiding separate scans of long ciphertext polynomials. Third, cross-operator check fusion eliminates redundant checksum computations between adjacent operators while preserving end-to-end checking invariants. We implement the scheme in OpenFHE and evaluate it on representative encrypted applications and ciphertext primitives under random single-bit transient faults. It achieves a 100 percent empirical detection rate across 150,000 non-crashing corrupted-result cases and maintains application accuracy close to the fault-free baseline over a wide range of fault rates. The scheme incurs only 6.0 percent to 8.4 percent runtime overhead, averaging 6.8 percent, and reduces average protection overhead by 4.9 times compared with direct checksum-based protection.

Figures

Figures reproduced from arXiv: 2607.18720 by Ge Yu, Huawei Li, Jianan Mu, Jing Ye, Liang Kong, Meng Li, Tenghui Hua, Xiaowei Li, Xing Hu.

Figure 1
Figure 1. Figure 1: (a) Typical application scenarios of FHE. (b) Fault [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Vulnerability evaluation on four CKKS homomorphic [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Vulnerability evaluation of fault injection on different [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 6
Figure 6. Figure 6: Hardware-counter profile of basic checksum-based [PITH_FULL_IMAGE:figures/full_fig_p005_6.png] view at source ↗
Figure 5
Figure 5. Figure 5: Runtime overhead of basic checksum-based protection [PITH_FULL_IMAGE:figures/full_fig_p005_5.png] view at source ↗
Figure 7
Figure 7. Figure 7: Modulus-aware bucket checksum. Bit-width utilization. In OpenFHE, each RNS coefficient is stored in a 64-bit word, while multiplying two coefficients already requires a 128-bit intermediate to hold the unreduced product. Most RNS moduli in our evaluated CKKS configura￾tions are approximately 50–60 bits. For ai , bi ∈ [0, q − 1], the product satisfies aibi ≤ (q−1)2 and occupies at most 2⌈log2 q⌉ bits. There… view at source ↗
Figure 9
Figure 9. Figure 9: Cross-operator check fusion. 4.2.3 Methodology 3: Cross-operator check fusion: CKKS computation is a static pipeline composed of multiple poly￾nomial operators. This static structure exposes opportunities to fuse redundant checks introduced by operator-by-operator protection. As shown in [PITH_FULL_IMAGE:figures/full_fig_p007_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Protected NTT dataflow with dataflow-fused in [PITH_FULL_IMAGE:figures/full_fig_p008_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Protected EWM with dataflow-fused in-operator [PITH_FULL_IMAGE:figures/full_fig_p009_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Protected CKKS pipeline with cross-operator check [PITH_FULL_IMAGE:figures/full_fig_p009_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Application-level reliability under different fault rates. [PITH_FULL_IMAGE:figures/full_fig_p010_13.png] view at source ↗
Figure 14
Figure 14. Figure 14: Overall performance comparison [PITH_FULL_IMAGE:figures/full_fig_p011_14.png] view at source ↗
Figure 15
Figure 15. Figure 15: Progressive ablation study on protection overhead. [PITH_FULL_IMAGE:figures/full_fig_p012_15.png] view at source ↗
Figure 16
Figure 16. Figure 16: Fine-grained hardware-counter profile of checksum protection on NTT and EWM. [PITH_FULL_IMAGE:figures/full_fig_p012_16.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

46 extracted references · 2 linked inside Pith

  1. [1]

    Gentry,A fully homomorphic encryption scheme

    C. Gentry,A fully homomorphic encryption scheme. Stanford university, 2009

    2009

  2. [2]

    Fully homomorphic encryption without modulus switch- ing from classical gapsvp,

    Z. Brakerski, “Fully homomorphic encryption without modulus switch- ing from classical gapsvp,” inAdvances in Cryptology – CRYPTO 2012. Springer, 2012, pp. 868–886

    2012

  3. [3]

    (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

  4. [4]

    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

  5. [5]

    Homomorphic encryption for arithmetic of approximate numbers,

    J. H. Cheon, A. Kim, M. Kim, and Y . Song, “Homomorphic encryption for arithmetic of approximate numbers,” inAdvances in Cryptology – ASIACRYPT 2017. Springer, 2017, pp. 409–437

    2017

  6. [6]

    Privacy-preserving graph-based ma- chine learning with fully homomorphic encryption for collaborative anti- money laundering,

    F. Effendi and A. Chattopadhyay, “Privacy-preserving graph-based ma- chine learning with fully homomorphic encryption for collaborative anti- money laundering,” inInternational Conference on Security, Privacy, and Applied Cryptography Engineering. Springer, 2024, pp. 80–105

    2024

  7. [7]

    Privacy preserving chest x-ray classification in latent space with homomorphically encrypted neural inference,

    J. Kim, G. Jo, S. Ra, and H. Park, “Privacy preserving chest x-ray classification in latent space with homomorphically encrypted neural inference,” inInternational Conference on Medical Image Computing and Computer-Assisted Intervention. Springer, 2025, pp. 485–495

    2025

  8. [8]

    He3db: An efficient and elastic encrypted database via arithmetic-and- logic fully homomorphic encryption,

    S. Bian, Z. Zhang, H. Pan, R. Mao, Z. Zhao, Y . Jin, and Z. Guan, “He3db: An efficient and elastic encrypted database via arithmetic-and- logic fully homomorphic encryption,” in2023 ACM SIGSAC Conference on Computer and Communications Security (CCS), 2023, pp. 2930– 2944

    2023

  9. [9]

    {GAZELLE}: A low latency framework for secure neural network inference,

    C. Juvekar, V . Vaikuntanathan, and A. Chandrakasan, “{GAZELLE}: A low latency framework for secure neural network inference,” in27th USENIX security symposium (USENIX security 18), 2018, pp. 1651– 1669

    2018

  10. [10]

    Privacy-preserving machine learning with fully homomorphic encryption for deep neural network,

    J.-W. Lee, H. Kang, Y . Lee, W. Choi, J. Eom, M. Deryabin, E. Lee, J. Lee, D. Yoo, Y .-S. Kimet al., “Privacy-preserving machine learning with fully homomorphic encryption for deep neural network,”IEEE Access, vol. 10, pp. 30 039–30 054, 2022

    2022

  11. [11]

    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,” inProceedings of the AAAI Conference on Artificial Intelligence, vol. 33, no. 1, 2019, pp. 9466– 9471

    2019

  12. [12]

    Low latency privacy preserving inference,

    A. Brutzkus, R. Gilad-Bachrach, and O. Elisha, “Low latency privacy preserving inference,” inInternational Conference on Machine Learning. PMLR, 2019, pp. 812–821

    2019

  13. [13]

    Spec cpu: The next generation,

    M. Madhav, A. Lee, A. Mejia, B. Moore, C. Soppadandi, C. Cambly, C. M ¨ullner, D. Bowers, D. Reiner, D. Bakhvalovet al., “Spec cpu: The next generation,”arXiv preprint arXiv:2605.01575, 2026

    Pith/arXiv arXiv 2026

  14. [14]

    Silent data corruptions: Microar- chitectural perspectives,

    G. Papadimitriou and D. Gizopoulos, “Silent data corruptions: Microar- chitectural perspectives,”IEEE Transactions on Computers, vol. 72, no. 11, pp. 3072–3085, 2023

    2023

  15. [15]

    Silent data corruptions at scale,

    H. D. Dixit, S. Pendharkar, M. Beadon, C. Mason, T. Chakravarthy, B. Muthiah, and S. Sankar, “Silent data corruptions at scale,”arXiv preprint arXiv:2102.11245, 2021

    Pith/arXiv arXiv 2021

  16. [16]

    {GlitchFHE}: Attacking fully homomorphic encryption using fault injection,

    L. L. Mankali, M. Nabeel, F. Raees, M. Maniatakos, O. Sinanoglu, and J. Knechtel, “{GlitchFHE}: Attacking fully homomorphic encryption using fault injection,” in34th USENIX Security Symposium (USENIX Security 25), 2025, pp. 8481–8500

    2025

  17. [17]

    Reliafhe: Resilient design for fully homomorphic encryption accelerators,

    F. Li, M. Kumar, R. Zhu, M. Zheng, Q. Lou, and X. Xin, “Reliafhe: Resilient design for fully homomorphic encryption accelerators,” in Proceedings of the 31st ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2, 2026, pp. 1605–1621

    2026

  18. [18]

    Reliability analysis of fully ho- momorphic encryption systems under memory faults,

    R. A. Rajagede and Y . Solihin, “Reliability analysis of fully ho- momorphic encryption systems under memory faults,”arXiv preprint arXiv:2509.20686, 2025

    arXiv 2025

  19. [19]

    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 . Leeet al., “Openfhe: Open-source fully homomorphic encryption library,” inproceedings of the 10th workshop on encrypted computing & applied homomorphic cryptography, 2022, pp. 53–63

    2022

  20. [20]

    TFHE-rs: A Pure Rust Implementation of the TFHE Scheme for Boolean and Integer Arithmetics Over Encrypted Data,

    Zama, “TFHE-rs: A Pure Rust Implementation of the TFHE Scheme for Boolean and Integer Arithmetics Over Encrypted Data,” 2022, https: //github.com/zama-ai/tfhe-rs

    2022

  21. [21]

    Concrete ML: a privacy-preserving machine learning library using fully homomorphic encryption for data scientists,

    ——, “Concrete ML: a privacy-preserving machine learning library using fully homomorphic encryption for data scientists,” 2022, https: //github.com/zama-ai/concrete-ml

    2022

  22. [22]

    F1: A fast and programmable accelerator for fully homomorphic encryption,

    N. Samardzic, A. Feldmann, A. Krastev, S. Devadas, R. Dreslinski, C. Peikert, and D. Sanchez, “F1: A fast and programmable accelerator for fully homomorphic encryption,” in2021 54th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), 2021, pp. 238– 252

    2021

  23. [23]

    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,” in2022 55th IEEE/ACM International Symposium on Microarchitecture (MICRO), 2022, pp. 1237–1254

    2022

  24. [24]

    Sharp: A short- word hierarchical accelerator for robust and practical fully homomorphic encryption,

    J. Kim, S. Kim, J. Choi, J. Park, D. Kim, and J. H. Ahn, “Sharp: A short- word hierarchical accelerator for robust and practical fully homomorphic encryption,” in2023 50th Annual International Symposium on Computer Architecture (ISCA), 2023, pp. 1–15

    2023

  25. [25]

    Craterlake: a hardware accelerator for efficient unbounded computation on encrypted data,

    N. Samardzic, A. Feldmann, A. Krastev, N. Manohar, N. Genise, S. Devadas, K. Eldefrawy, C. Peikert, and D. Sanchez, “Craterlake: a hardware accelerator for efficient unbounded computation on encrypted data,” in2022 49th Annual International Symposium on Computer Architecture (ISCA), 2022, pp. 173–187

    2022

  26. [26]

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

    R. Agrawal, L. De Castro, C. Juvekar, A. Chandrakasan, V . Vaikun- tanathan, and A. Joshi, “Mad: Memory-aware design techniques for accelerating fully homomorphic encryption,” in2023 56th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), 2023, pp. 685–697

    2023

  27. [27]

    Bitpacker: Enabling high arithmetic efficiency in fully homomorphic encryption accelerators,

    N. Samardzic and D. Sanchez, “Bitpacker: Enabling high arithmetic efficiency in fully homomorphic encryption accelerators,” in2024 ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), 2024, pp. 137–150

    2024

  28. [28]

    Algorithm-based fault tolerance for matrix operations,

    K.-H. Huang and J. A. Abraham, “Algorithm-based fault tolerance for matrix operations,”IEEE Transactions on Computers, vol. 100, no. 6, pp. 518–528, 1984

    1984

  29. [29]

    Algorithm-based fault tolerance for fft networks,

    S.-J. Wang and N. K. Jha, “Algorithm-based fault tolerance for fft networks,”IEEE Transactions on Computers, vol. 43, no. 7, pp. 849– 854, 1994

    1994

  30. [30]

    Efficient error detection methods for the number theoretic transforms in lattice-based algorithms,

    M. Abdelmonem, L. Holzbaur, H. Raddum, and A. Zeh, “Efficient error detection methods for the number theoretic transforms in lattice-based algorithms,” inInternational Conference on Constructive Approaches for Security Analysis and Design of Embedded Systems. Springer, 2025, pp. 185–210

    2025

  31. [31]

    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,” inSelected Areas in Cryptography – SAC 2018. Springer, 2019, pp. 347–368

    2018

  32. [32]

    Better bootstrapping for approximate homomorphic encryption,

    K. Han and D. Ki, “Better bootstrapping for approximate homomorphic encryption,” inTopics in Cryptology – CT-RSA 2020. Springer, 2020, pp. 364–390

    2020

  33. [33]

    Scalable and conflict-free ntt hardware accelerator design: Methodology, proof, and implementation,

    J. Mu, Y . Ren, W. Wang, Y . Hu, S. Chen, C.-H. Chang, J. Fan, J. Ye, Y . Cao, H. Li, and X. Li, “Scalable and conflict-free ntt hardware accelerator design: Methodology, proof, and implementation,”IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 42, no. 5, pp. 1504–1517, 2023

    2023

  34. [34]

    Fourier transforms and the fast fourier transform algo- rithm,

    P. Heckbert, “Fourier transforms and the fast fourier transform algo- rithm,”Computer Graphics, vol. 2, no. 1995, pp. 15–463, 1995. 13

    1995

  35. [35]

    High-precision rns-ckks on fixed but smaller word-size architectures: Theory and application,

    R. Agrawal, J. H. Ahn, F. Bergamaschi, R. Cammarota, J. H. Cheon, F. D. M. de Souza, H. Gong, M. Kang, D. Kim, J. Kim, H. de Lassus, J. H. Park, M. Steiner, and W. Wang, “High-precision rns-ckks on fixed but smaller word-size architectures: Theory and application,” in 2023 11th Workshop on Encrypted Computing & Applied Homomorphic Cryptography, 2023, pp. 23–34

    2023

  36. [36]

    Accelerating he operations from key decomposition technique,

    M. Kim, D. Lee, J. Seo, and Y . Song, “Accelerating he operations from key decomposition technique,” inAdvances in Cryptology – CRYPTO

  37. [37]

    Implementing the rivest shamir and adleman public key en- cryption algorithm on a standard digital signal processor,

    P. Barrett, “Implementing the rivest shamir and adleman public key en- cryption algorithm on a standard digital signal processor,” inConference on the Theory and Application of Cryptographic Techniques. Springer, 1986, pp. 311–323

    1986

  38. [38]

    Faster interleaved modular multiplication based on barrett and montgomery reduction methods,

    M. Knezevic, F. Vercauteren, and I. Verbauwhede, “Faster interleaved modular multiplication based on barrett and montgomery reduction methods,”IEEE Transactions on Computers, vol. 59, no. 12, pp. 1715– 1721, 2010

    2010

  39. [39]

    Detection and prevention of silent data corruption in an exabyte-scale database system,

    D. F. Bacon, “Detection and prevention of silent data corruption in an exabyte-scale database system,” inThe 18th IEEE Workshop on Silicon Errors in Logic–System Effects, 2022

    2022

  40. [40]

    Hardware sentinel: Protecting software applications from hardware silent data corruptions,

    R. Dutta, H. D. Dixit, R. Van Riel, G. Vunnam, and S. Sankar, “Hardware sentinel: Protecting software applications from hardware silent data corruptions,” inProceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2, 2025, pp. 482–497

    2025

  41. [41]

    Cores that don’t count,

    P. H. Hochschild, P. Turner, J. C. Mogul, R. Govindaraju, P. Ran- ganathan, D. E. Culler, and A. Vahdat, “Cores that don’t count,” in Proceedings of the Workshop on Hot Topics in Operating Systems, 2021, pp. 9–16

    2021

  42. [42]

    Silent data corruption by 10x test escapes threatens reliable computing,

    S. Mitra, B. Parthasarathy, S. Banerjee, R. Govindaraju, P. Hochschild, E. Liu, M. Fuller, M. Dixon, and P. Ranganathan, “Silent data corruption by 10x test escapes threatens reliable computing,”IEEE Design & Test, vol. 42, no. 6, pp. 40–53, 2025

    2025

  43. [43]

    LOT-ECC: Localized and tiered reliability mechanisms for commodity memory systems,

    A. N. Udipi, N. Muralimanohar, R. Balasubramonian, A. Davis, and N. P. Jouppi, “LOT-ECC: Localized and tiered reliability mechanisms for commodity memory systems,” inProceedings of the 39th Annual International Symposium on Computer Architecture, 2012, pp. 285–296

    2012

  44. [44]

    Thundervolt: Enabling aggressive voltage underscaling and timing error resilience for energy efficient deep learning accelerators,

    J. J. Zhang, K. Rangineni, Z. Ghodsi, and S. Garg, “Thundervolt: Enabling aggressive voltage underscaling and timing error resilience for energy efficient deep learning accelerators,” inProceedings of the 55th Annual Design Automation Conference, 2018, pp. 19:1–19:6

    2018

  45. [45]

    Quantifying the accuracy of high-level fault injection techniques for hardware faults,

    J. Wei, A. Thomas, G. Li, and K. Pattabiraman, “Quantifying the accuracy of high-level fault injection techniques for hardware faults,” inProceedings of the 44th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 2014, pp. 375– 382. 14

    2014

  46. [2023]

    Springer, 2023, pp. 70–92

    2023