{"id":"305a18b9-a7bb-4770-9a0a-1b65ab1c6287","arxiv_id":"2607.18720","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A checksum-based consistency check detects single-bit hardware faults in CPU-based CKKS encrypted computation with 6.0–8.4% runtime overhead (average 6.8%), a 4.9× reduction versus direct checksum protection.","lead":"This paper describes a way to catch random hardware errors in encrypted (homomorphic) computation running on ordinary CPUs, adding only about 7% to the runtime. It checks that the inputs and outputs of each polynomial step agree through lightweight checksums, and was tested on standard encrypted machine-learning workloads.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"100% detection is structurally impossible for input-load/output-store single-bit faults because the checksum and operator consume the same corrupted value; Table II's eligibility filter is unspecified.","rationale":"I read the paper as an engineering claim: a CPU-friendly ABFT scheme for CKKS with 6.8% overhead. The overhead part is credible: the three optimizations map to measured instruction and L1D reductions, the ablation is monotone, and the hardware-counter data are consistent. The reliability part is the weak spot. The 100% detection claim is the strongest sentence in the abstract and is the one that would justify deploying the scheme for SDC protection. But the described checks are consistency checks, not absolute checks; they cannot see faults that affect both sides of the invariant. This is not a disagreement with consensus; it is an internal structural limitation of input-output ABFT. The paper's own Limitations section covers multiple faults and platform generality but omits this blind class, so the limitation text does not save the claim. Since the reader already identified the same concern and the fix is to scope the claim and provide injection details or an artifact, I do not move the verdict: CONDITIONAL remains appropriate. If the authors rerun with load/store sites included and 100% still holds, it would be surprising and would upgrade to ACCEPT; if they confirm the blind class and narrow the claim, the paper is acceptable with the corrected scope.","tokens_in":20157,"tokens_out":5337,"duration_ms":52742,"concrete_test":"Inject one single-bit fault into the load instruction for an EWM input coefficient a_i (the load whose value is used both to compute a_i*k_i and to accumulate C_in), with all other instructions fault-free. Use the same PinFI setup as Table II, classify as an error case if the final EWM output differs from the fault-free run, and record whether the checksum reports a mismatch. If the output differs and no mismatch is reported -- as the invariant algebra predicts -- Table II's 100% cannot hold for the stated fault model. Repeat with an NTT store of a final-stage output after C_out accumulation. Either result settles the concern; the authors should also report the exact instruction predicate defining 'eligible dynamic instructions' in Sec. 3.1.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central detection claim is load-bearing and is not supported by the described mechanism. The protected invariant is an input-output consistency check, so any single-bit fault that corrupts a value before it is split into the checksum side and the computation side is invisible by construction. Concretely: (i) in Algorithm 1 lines 6-7, C_in accumulates a_i from the same load that feeds the NTT butterflies; the checksum identity sum a_i = sum e_i * NTT(a)_i mod q holds for any a, so a bit flip in that load changes the output and C_in consistently; (ii) in Sec. 4.3.2, C_in = sum a_i*k_i and C_out = sum (a_i*k_i mod q) are the same product on both sides, so a fault in either operand load leaves the equality true while the output differs from the fault-free value; (iii) a store fault after the final butterfly corrupts the in-memory tower but not the already-accumulated C_out. The same structure applies to BConv. Table II's 150,000 non-crashing error cases can only show 100% if the unstated 'eligible dynamic instructions' filter (Sec. 3.1) excludes exactly these load/store sites. The Limitations section acknowledges multi-fault cases but does not list this single-fault blind class. Without the injection policy or artifact, the headline '100% detection rate' is broader than what the design can deliver.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":20399,"tokens_out":21576,"duration_ms":187017,"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":[{"comment":"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.","section":"§4.3.1, §4.3.2, Algorithm 1"},{"comment":"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.","section":"§5.2, Table II"},{"comment":"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.","section":"§4.2.1, Eq. (2)"}],"minor_comments":[{"comment":"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.","section":"§2.2 vs. §4.3.1"},{"comment":"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.","section":"Algorithm 1, line 12"},{"comment":"The figure caption contains stray text ('Version Evaluation on (a)？ Barrier') that appears to be an editing artifact. Please clean it up.","section":"Figure 1"},{"comment":"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.","section":"Table I"}],"recommendation":"major_revision","confidential_remarks":"The overhead story and algebraic checksum machinery are sound, but the reliability claim needs careful scoping. I would not reject outright; if the authors clarify the eligible-instruction filter and revise the '100% detection' / 'full protection' language to cover only faults inside the checked arithmetic datapath, the paper could be acceptable. The fault-injection artifact/scripts are important for verification."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: the 6.8% overhead number is credible and the three optimizations are well-motivated and well-ablated. The 100% detection rate in Table II is not supported by the described design, because any fault that corrupts a value before it is split between the checksum path and the compute path passes by construction. That's a real flaw, but it's a scope-and-claim problem, not a reason to discard the paper.\n\nWhat's new: applying ABFT checksums to CPU-based CKKS with three concrete optimizations — modulus-aware bucket checksum (exploiting 128-bit accumulator headroom), dataflow-fused in-operator checks, and cross-operator check fusion. The overflow math (Eqs. 2-4) is correct, the ablation in Fig. 15 and hardware-counter data in Fig. 16 are consistent, and the 4.9x overhead reduction versus basic checksum is a solid engineering result. The paper is honest that the checksum invariants are standard ABFT; the contribution is the CPU packaging.\n\nWhere it gets soft: the detection claim. The stress-test note is right. In Algorithm 1, the input checksum accumulates the same loaded coefficient that feeds the butterflies, and the EWM checksum compares sum a_i*k_i with sum (a_i*k_i mod q) — same product on both sides. A single-bit flip in an operand load changes both sides equally, so the equality still holds. Same for a store fault after the decode accumulation: the in-memory output is wrong, the accumulator is right. The paper never defines the 'eligible dynamic instructions' filter (§3.1), so we can't tell whether Table II's 150,000 cases excluded these sites. If they were included, 100% cannot hold. The Limitations section covers multi-fault cases but not this single-fault blind class.\n\nA second, minor concern: no code or data released. Given the injection policy is what determines the detection scope, the artifact matters here, not just for reproducibility.\n\nWho it's for: people building reliable FHE software stacks on CPUs. The overhead contribution alone is worth citing. The paper deserves a serious referee, and I'd accept it with a required revision: state the injection scope, restate detection as covering faults that break input-output consistency, enumerate the blind classes, and release the artifact. The core engineering story stands.","headline":"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.","tokens_in":21043,"tokens_out":2608,"would_cite":true,"duration_ms":24218,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["fully homomorphic encryption","CKKS","silent data corruption","fault tolerance","checksum","number theoretic transform","RNS","transient faults"],"falsifier":"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.","tokens_in":19923,"feed_emoji":"🛡️","tokens_out":6004,"duration_ms":48720,"temperature":0.7,"pith_summary":"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.","feed_headline":"Catches 150,000 injected faults at 6.8% overhead","feed_subtitle":"Checksum invariants fused into NTT, basis-conversion, and multiplication dataflows cut protection overhead 4.9x on CPUs.","key_machinery":"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","core_discovery":"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","pith_inferences":["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."],"forward_implications":["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."],"fun_headline_variants":["100% fault catch on 150k flips, 6.8% overhead","CPU checksums catch all 150k faults, add 6.8%","Slash FHE fault-check overhead 4.9x on CPUs","150k fault flips caught, overhead only 6.8%","Fused checksums: 100% CKKS fault detection at 6.8%"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["100% fault catch on 150k flips, 6.8% overhead","CPU checksums catch all 150k faults, add 6.8%","Slash FHE fault-check overhead 4.9x on CPUs","150k fault flips caught, overhead only 6.8%","Fused checksums: 100% CKKS fault detection at 6.8%"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000234,"raw_usage":{"total_tokens":1357,"prompt_tokens":789,"completion_tokens":568,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":533,"completion_tokens_details":{"reasoning_tokens":463}},"tokens_in":533,"tokens_out":568,"duration_ms":6714,"temperature":1.0,"reasoning_tokens":463,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T14:34:51.365066+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[],"review_version":1}