{"id":"a2219879-8fbc-4e72-89c3-ef19c44451ca","arxiv_id":"2608.11155","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"high","formal_verification":"none","parameter_count":5,"one_line_summary":"For CKKS homomorphic encryption, single-bit client-side errors show two resilience patterns, and multiplication dominates whenever it is used.","lead":"Researchers flipped single bits in the inputs to an encrypted-computing scheme called CKKS and measured how often wrong answers came out silently. They report that multiplication is the most error-sensitive step and that the failure pattern stays the same across parameters and data.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Client-side bit flips do not establish server-side multiplication sensitivity; the injection-location mismatch and the absence of reported MREP comparisons leave the central claim untested.","rationale":"The reader's weakest assumption—that client-side single-bit flips faithfully represent server-side transient faults—is exactly the load-bearing point that would invalidate the paper's central claim if it fails. My independent reading of the manuscript confirms this is the least secure component of the argument: the methodology in Section II injects into plaintext and ciphertext coefficients, while the motivating scenario in Figure 2 is a faulty CPU corrupting server-side computation. No argument is given for why these two fault locations produce equivalent resilience patterns, and Section II-B provides no quantitative comparison to bridge the gap. The paper also gives no released artifacts or full MREP distributions, so the claimed pattern cannot be independently checked from the text. A targeted experiment that injects faults at the actual server-side arithmetic stages would settle whether the taxonomy transfers. Because this concern is the same one identified by the reader and the evidence gap is real, the reader's REJECT verdict should stand unchanged.","tokens_in":3972,"tokens_out":2704,"duration_ms":25844,"concrete_test":"Run LLTFI fault injection directly inside the CKKS multiplication kernel on the server side, using the same configuration as Fig. 3 (N=64, logQ=60, logDelta=25, gaps=2, epsilon=0.1): flip one bit in an NTT intermediate value, one bit in a coefficient after modular multiplication, one bit in the inverse NTT output, and one bit in a relinearization accumulator. In parallel, inject the same bit-flip set into plaintext and ciphertext coefficients as described in Section II. Compare the resulting MREP distributions and classify each into the addition or multiplication pattern.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that homomorphic multiplication is the most error-sensitive operation in practical HE pipelines rests on an unvalidated transfer from client-side bit flips to server-side faults. Section II states that the single-bit-error model flips each bit of every polynomial coefficient of the plaintext and ciphertext before running the pipeline, but Figure 2 frames the threat as a faulty CPU corrupting server-side computation on encrypted data. A bit flip in a client-side plaintext or ciphertext coefficient is not the same event as a transient fault inside server-side arithmetic: the latter can occur inside NTT, modular coefficient multiplication, inverse NTT, or relinearization, can land in different polynomial positions, can interact with carry logic and RNS limbs, and can happen after prior noise growth. Therefore the resulting MREP distribution, and consequently the addition/multiplication taxonomy, need not match the client-side injection results. Section II-B asserts 'whenever a multiplication is performed on the server, the overall resilience profile consistently follows this pattern' without reporting any MREP values, thresholds, confidence intervals, or a direct Add-versus-Mult comparison under an identical fault set. The paper's main design rule is thus currently an unsupported extrapolation, not an established empirical finding.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript analyzes bit-level fault sensitivity in the CKKS homomorphic encryption scheme. The authors inject single bit-flips into client-side plaintext and ciphertext polynomial coefficients, run the full CKKS pipeline, and measure the effect with the Maximum Relative Error Percentage (MREP). From this they claim two resilience 'patterns' (Addition and Multiplication), that the Multiplication pattern dominates whenever a multiplication is performed on the server, and that these patterns are independent of parameters and data. The abstract states that homomorphic multiplication is 'the most error-sensitive operation in practical HE pipelines.'","tokens_in":4190,"tokens_out":3301,"duration_ms":33315,"significance":"If the central claims were substantiated, the paper would provide a useful fault-tolerance taxonomy for CKKS deployments: distinguishing addition-like resilience from multiplication-like propagation, and directing fault-protection efforts toward multiplication. The paper has one genuine strength: the fault-injection methodology is direct and uses an existing open-source framework (LLTFI), and the experimental setup is described in terms of a custom CKKS implementation with togglable RNS/NTT options. However, the manuscript does not establish its central claims: there are no reported MREP values, no error bars, no parameter sweep, no comparison with rotation or bootstrapping, and the injection model does not match the server-side fault scenario depicted in the paper. The claimed 'parameter and data independence' is asserted from a single displayed configuration. As a result, the significance of the work is currently prospective rather than demonstrated.","major_comments":[{"comment":"The fault model is inconsistent with the claimed threat scenario. Figure 2 illustrates a faulty CPU corrupting server-side computation on encrypted data, but the experiments inject bit-flips into client-side plaintext and ciphertext coefficients before the pipeline runs. A transient fault inside server-side arithmetic can occur in NTT, RNS limb arithmetic, modular multiplication, relinearization, or carry logic, at a different polynomial position and after noise has already grown. The Section II-B statement that 'whenever a multiplication is performed on the server, the overall resilience profile consistently follows this pattern' is therefore an extrapolation, not a result of the experiments described. A direct Add-versus-Mult comparison under the same fault-injection protocol, and preferably with server-side fault injection inside individual CKKS arithmetic stages, is needed before the 'most error-sensitive operation' claim can be evaluated.","section":"Section II (error model) and Figure 2"},{"comment":"The 'domination' claim is not supported by any quantitative comparison. The paper gives no MREP values, no thresholds, no confidence intervals, and no side-by-side comparison of Add-only, Mult-only, Rot-only, or bootstrapped pipelines. The pipeline configurations in Section II list rotations and bootstrapping, but no results for these operations are reported. Figure 3 shows a single configuration (Gaps=2, logQ=60, logDelta=25, N=64, epsilon=0.1) without axes or detailed captions, so the reader cannot verify the claimed pattern or the alleged dominance. The abstract's 'most error-sensitive operation' is thus an overclaim relative to the evidence presented.","section":"Section II-B and Figure 3"},{"comment":"The claim that the observed resilience heuristics are 'independent of both parameters and data' is load-bearing and unsupported. The only displayed experiment uses one ring dimension, one modulus, one scaling factor, one gap count, and one epsilon value. No parameter sweep over N, logQ, logDelta, gap count, or epsilon is reported, and no multiple datasets are tested. A single point cannot establish parameter/data independence; this assertion is one of the three main contributions and requires either a systematic sweep with reported statistics or a much narrower, formal claim.","section":"Section II-C (parameter and data independence)"},{"comment":"The experimental configuration is far from 'practical HE pipelines.' N=64 is an extremely small ring dimension; practical CKKS deployments for machine learning workloads typically use ring dimensions of 2^15 or larger and much larger moduli. If the stated goal is to characterize 'practical' pipelines, the authors must either justify why N=64 is representative or show that the patterns persist at realistic parameter sizes. Without such evidence, the universal wording of the claims ('whenever a multiplication is performed,' 'independent of parameters') is unjustified.","section":"Section II experimental setup"}],"minor_comments":[{"comment":"The description of the Addition pattern is difficult to parse: phrases such as 'exceeding the modulus (Q) resilience' and 'masked plaintext' are used without formal definitions of masking or resilience, and no measured values illustrate the claimed behavior.","section":"Section II-A"},{"comment":"The caption is garbled: 'ptx’, c′0, and c′1 denote computed ciphertext-ciphertext c0, c1, and decrypted ptx respectively' does not clearly identify which curves correspond to which quantities, and the axes, units, and legend are not described.","section":"Figure 3 caption"},{"comment":"The enumeration 'we present that 1). error resilience ... 2). Multiplication pattern dominates ... 3). the two resilience patterns observed are parametric and data independent' contains grammatical and formatting errors, and 'parametric' appears to be used to mean 'parameter-dependent' while the claim later says 'independent of parameters'; the intended meaning should be clarified.","section":"Section I"},{"comment":"The paper says fault injection uses LLTFI, which is designed for machine learning applications, but does not explain how it was adapted to inject into CKKS polynomial coefficients or which code locations were instrumented.","section":"Section II (tooling)"},{"comment":"The phrase 'formal awareness' and 'formally categorized' overstate the level of formality; the analysis is purely empirical and no formal model or theorem is presented.","section":"Conclusion"}],"recommendation":"reject","confidential_remarks":"The manuscript reads as an extended abstract or work-in-progress. The central claims are not testable from the reported data: no MREP numbers, no comparison with other operations, no parameter sweep, and a fault-injection model that does not match the depicted server-side fault scenario. These are not purely presentational issues; establishing the claims would require substantial new experiments and a significant rewriting of the claims. I see no sign of methodological dishonesty, but the paper is not ready for a archival venue in its current form."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: the paper identifies a genuinely new taxonomy of client-side bit-flip resilience in CKKS—addition patterns vs. multiplication patterns—and claims multiplication dominates whenever a multiplication runs. That's an interesting empirical question, and the use of LLTFI plus a custom CKKS implementation to sweep parameters is the right kind of scaffolding. But the paper doesn't actually show the data. There are no MREP values, no distributions, no error bars, no direct Add-vs-Mult comparison under the same fault set, and the parameter/data independence claim is asserted in three lines without a single sweep. So the central claims are currently unsupported.\n\nThe strongest soft spot is the mismatch between the client-side injection model and the server-side threat narrative. Section II flips bits in client-side plaintext and ciphertext coefficients, but Figure 2 frames the problem as a faulty CPU corrupting server-side computation. Those are different events—a flip inside NTT, modular multiplication, or relinearization on the server can land in different polynomial positions after prior noise growth, and the resulting MREP distribution need not match. The abstract's 'most error-sensitive operation in practical HE pipelines' simply isn't established by client-side injection. The title is honest about 'client-side,' but the abstract and conclusion reach further.\n\nWhat's genuinely useful here is the qualitative taxonomy for client-side corruption (e.g., errors during encoding/encryption on a client device). That is new relative to the cited work, and the observation that multiplication patterns dominate addition even on the client side is worth testing properly. But as written, this is a short position paper, not a measurement study. I'd like to see the actual MREP distributions, define the pattern categories quantitatively, compare all operations under identical fault sets, and either demonstrate or drop the independence claim.\n\nWho would get value: researchers working on HE fault tolerance, especially on error detection in client-side encoding/encryption, and maybe architects designing hardened HE accelerators. I would not cite it in its current form, but I'd read a revised version.\n\nFor peer review: I would not desk reject it. The question is legitimate and the taxonomy is new, but it needs major revision and the authors need to supply the missing evidence. A serious referee could guide that.\n\nRecommendation: send back for major revision, or if the venue doesn't allow that, decline with an invitation to resubmit with actual data.","headline":"Plausible new taxonomy, but the paper's central claims are asserted rather than shown.","tokens_in":4735,"tokens_out":2637,"would_cite":false,"duration_ms":24158,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims that homomorphic multiplication is the most error-sensitive operation in practical CKKS pipelines, and that its fault signature dominates the pipeline whenever a multiplication runs.","keywords":["homomorphic encryption","CKKS","transient faults","bit-flip injection","silent data corruption","error resilience","RNS arithmetic","NTT"],"falsifier":"Run a hardware-injected fault experiment during a server-side homomorphic multiplication, for example flipping a bit inside the modular multiplier or NTT unit, and compare the decoded output error distribution with the client-side multiplication pattern; if the server-side faults do not match the same dominance or coefficient-position profile, the paper's characterization is limited to client-side injection.","tokens_in":3772,"feed_emoji":"🔐","tokens_out":7440,"duration_ms":61458,"temperature":0.7,"pith_summary":"This paper tries to establish where transient bit-flip faults actually hurt CKKS, the homomorphic encryption scheme commonly used for approximate arithmetic in machine learning. By flipping each bit of every coefficient of client-side plaintext and ciphertext polynomials and running the full pipeline, the authors find two repeatable fault signatures: an addition pattern and a multiplication pattern. The central claim is that whenever a homomorphic multiplication is performed on the server, the multiplication pattern dominates the overall error behavior. If this is right, fault-protection effort in CKKS deployments can be concentrated on multiplication rather than distributed across all operations, and the observed heuristics transfer across parameter settings and data.","feed_headline":"One operation dominates homomorphic encryption's bit-flip failures","feed_subtitle":"That operation is multiplication, so fault protection can target it instead of every step.","key_machinery":"The central object is the CKKS ciphertext as a pair of polynomials $(c_0(X), c_1(X))$ of degree $N$, representing a plaintext polynomial $p(X)$ in a noisy modular arithmetic domain. The paper's analysis mechanism is sequential single-bit fault injection into every coefficient of the plaintext and ciphertext, measuring recovered-data error as Maximum Relative Error Percentage (MREP), and classifying outcomes by which structural positions (values below the scaling factor $\\Delta$, values beyond modulus $Q$, gap coefficients, the $N/2$-th coefficient) absorb or propagate the bit flip. The addition/multiplication dichotomy is what carries the argument: it organizes otherwise scattered fault outcomes into two reproducible profiles.","core_discovery":"Under single-bit-flip injection in Vanilla and RNS variants of CKKS, bit flips in values below the scaling factor or beyond the modulus are masked, while flips in gap coefficients and the N/2-th coefficient behave differently in the plaintext and in the first ciphertext component versus the second. When multiplication is added, these resilient coefficient positions weaken: in Vanilla CKKS they survive only up to an error threshold, and in RNS CKKS they are completely corrupted. Configurations using NTT or combined RNS+NTT arithmetic are fully susceptible: any single bit flip causes catastrophic decoding or decryption failure, so no comparable pattern exists. The paper concludes that the resilience profiles form two patterns, addition and multiplication, and that the multiplication pattern dominates the pipeline whenever multiplication is present.","pith_inferences":["An extension the paper leaves implicit is that faults injected directly inside server-side arithmetic units, rather than into stored client-side coefficients, may follow the same multiplication-pattern domination; this is testable with fault injection into a modular multiplier.","If the domination transfers, error-detection mechanisms could be applied only to multiplication outputs, cutting the overhead of protecting every homomorphic operation.","The addition-versus-multiplication taxonomy may carry over to other LWE-based schemes whose ciphertexts also split into a data-dependent and a key-dependent component, though the paper does not claim this.","The total vulnerability of NTT and RNS+NTT modes suggests a hardware-design trade-off between speed optimizations and fault tolerance that a quantitative cost comparison could make explicit."],"forward_implications":["A CKKS pipeline that contains at least one homomorphic multiplication inherits the multiplication resilience pattern, so its fault behavior can be predicted from that operation alone.","Fault protection for practical CKKS workloads can prioritize multiplication circuit paths, because addition-only segments show a distinct and more forgiving pattern.","Because the patterns are parameter- and data-independent, the same resilience characterization applies across different ciphertext moduli, scaling factors, ring degrees, and input data.","In NTT and RNS+NTT arithmetic modes, the absence of any resilient coefficient position means a single bit flip is already catastrophic, so those modes need stronger detection or correction.","The two named patterns give a design rule: classify a CKKS pipeline by whether it contains a multiplication, then choose an error-detection strategy accordingly."],"supporting_citations":[{"why":"Defines the CKKS approximate-arithmetic scheme whose plaintext and ciphertext polynomial structure is the object of the fault analysis.","marker":"[6]"},{"why":"Introduces the full RNS variant of CKKS, the configuration whose coefficients are represented with multiple limbs and for which the paper reports the completely corrupted multiplication pattern.","marker":"[7]"},{"why":"Supplies the learning-with-errors hardness assumption that grounds the noise-injection model motivating error sensitivity.","marker":"[8]"},{"why":"Documents silent data corruption at scale, motivating the claim that undetected faults in HE pipelines are a real concern.","marker":"[9]"},{"why":"Provides the fault injection tool used to flip bits in the polynomials for the experiments.","marker":"[13]"}],"fun_headline_variants":["CKKS bit flips: multiplication is the critical step","Multiplication turns CKKS bit flips into silent corruption","Bit flips in CKKS addition are masked, multiplication is not","For homomorphic encryption, fault protection should focus on multiply","CKKS bit flip resilience: only multiplication breaks the pattern"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that flipping a single bit in a client-side plaintext or ciphertext coefficient faithfully represents the transient hardware faults that cause silent data corruption during real server-side execution; if real faults occur inside arithmetic units, in multiple bits, or in different polynomial positions, the observed pattern may not transfer.","fun_headline_variants_meta":{"raw":{"variants":["CKKS bit flips: multiplication is the critical step","Multiplication turns CKKS bit flips into silent corruption","Bit flips in CKKS addition are masked, multiplication is not","For homomorphic encryption, fault protection should focus on multiply","CKKS bit flip resilience: only multiplication breaks the pattern"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000855,"raw_usage":{"total_tokens":3659,"prompt_tokens":831,"completion_tokens":2828,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":447,"completion_tokens_details":{"reasoning_tokens":2746}},"tokens_in":447,"tokens_out":2828,"duration_ms":19888,"temperature":1.0,"reasoning_tokens":2746,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T05:07:42.355201+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a hardware-injected fault experiment during a server-side homomorphic multiplication, for example flipping a bit inside the modular multiplier or NTT unit, and compare the decoded output error distribution with the client-side multiplication pattern; if the server-side faults do not match the same dominance or coefficient-position profile, the paper's characterization is limited to client-side injection.","supporting_citations":[{"cited_title":"A full RNS variant of approximate homomorphic encryption,","cited_arxiv_id":null,"evidence_quote":"Introduces the full RNS variant of CKKS, the configuration whose coefficients are represented with multiple limbs and for which the paper reports the completely corrupted multiplication pattern."},{"cited_title":"Lltfi: Framework agnostic fault injection for machine learning applications (tools and artifact track),","cited_arxiv_id":null,"evidence_quote":"Provides the fault injection tool used to flip bits in the polynomials for the experiments."}],"review_version":1}