{"id":"18a815ba-47fd-4671-a3e2-0e20724da166","arxiv_id":"2505.11058","paper_version":1,"verdict":"UNVERDICTED","confidence":"HIGH","novelty_score":1.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A review of how physical measurements like power, timing, and electromagnetic emissions can break homomorphic encryption implementations despite their mathematical security.","lead":"This paper surveys known side-channel attacks on homomorphic encryption, a technique that lets computers calculate on encrypted data. It organizes the attacks into categories, summarizes case studies, and lists mitigation strategies such as constant-time code and masking.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Cloud transferability of single-trace power/EM results is the load-bearing soft spot; a remote cache-timing case only partially covers it.","rationale":"The central claim that FHE implementations leak side-channel information is supported by several peer-reviewed attacks cited in the survey, so the claim is not baseless. However, the survey's language about real-world deployments and cloud risk goes beyond what the cited local, low-frequency hardware experiments establish. The reader identified this transferability issue as the weakest assumption; I agree it is the main soft spot, but only partially, because the remote cache-timing case study provides some evidence that at least one side-channel class can operate without physical proximity. The proposed concrete experiment would test whether the single-trace power results survive realistic clock frequencies and whether the remote cache-timing attack works on current cloud-class software, which would settle whether the practical-impact conclusion needs qualification. Since the paper is explicitly a review with no new research claim, the original UNVERDICTED verdict remains appropriate; the concern does not change the verdict, it sharpens the condition under which the survey's practical conclusions should be accepted.","tokens_in":13132,"tokens_out":5570,"duration_ms":61446,"concrete_test":"Repeat the REVEAL setup of Sec. 4.1 with the target core clocked at 50 MHz, 200 MHz, and 1 GHz while keeping SEAL v3.2 and the same measurement equipment; record plaintext-recovery probability and number of traces required. Also run the Sec. 4.4 cache-timing attack against a current SEAL/OpenFHE build in a Docker container on a shared cloud CPU using only network-visible timing, and check whether the vulnerable Barrett-reduction path still exists in the installed library version. Failure of either experiment would require narrowing the survey's conclusion to physically accessible or low-frequency deployments.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The survey's practical-impact conclusion that real-world FHE deployments 'often face challenges' rests mainly on single-trace power-analysis demonstrations on a RISC-V FPGA at 1.5 MHz (Sec. 4.1) and an ARM Cortex-M4F (Sec. 4.2), with Sec. 4.1 itself conceding that higher clock frequencies increase noise. FHE's main deployment environment is shared cloud servers, where power/EM acquisition is far harder and the vulnerable code paths may differ from the tested library versions. The remote cache-timing attack in Sec. 4.4 is evidence for one channel, but it does not validate the other channels or the broader claim. So the headline 2^128 to 2^4.4 result and the urgency of the mitigations are not yet tied to cloud-scale deployments; the paper would need at least one demonstration at realistic frequency/virtualization or a clear statement that only physically accessible deployments are affected.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"This manuscript is a survey of side-channel analysis for homomorphic encryption. It introduces a taxonomy of passive and active side-channel attacks, provides background on BGV/BFV and CKKS, summarizes six published attack case studies (including REVEAL, NTT-based key-generation leakage, LWE/LWR message leakage, a cache-timing attack on SEAL, a single-trace attack on masked lattice encryption, and a key-recovery attack on TFHE/FHEW via induced decryption errors), and lists mitigation strategies such as constant-time programming, masking, shuffling, and randomized noise. The paper's central claim is that FHE's theoretical security does not ensure implementation security and that real-world deployments leak exploitable information through power, timing, electromagnetic, and fault channels, with the REVEAL attack cited as reducing the security level from 2^128 to 2^4.4.","tokens_in":13206,"tokens_out":8171,"duration_ms":77032,"significance":"If the survey's reporting is accurate, it is a useful consolidated reference for practitioners and researchers entering FHE side-channel analysis. Its strengths are that the case studies are drawn from peer-reviewed or widely referenced works and are mostly described faithfully, and that the paper highlights a genuinely important gap between FHE's mathematical security and its implementation security. The paper does not claim new attacks or countermeasures; its value is organizational and expository. The main weakness is that the practical-impact conclusion is broader than the experimental evidence: most of the featured power/EM attacks were demonstrated in local, low-frequency laboratory settings, while the paper's motivation emphasizes cloud deployment.","major_comments":[{"comment":"The paper's motivating claim that FHE deployments 'often face challenges' from side channels (Sec. 1.1) is broader than the evidence it cites. The strongest attacks use single-trace power/EM measurements on a RISC-V FPGA at 1.5 MHz (Sec. 4.1) and an ARM Cortex-M4F (Sec. 4.2), and Sec. 4.1 itself concedes that higher frequencies increase noise and may require advanced equipment. The remote cache-timing result in Sec. 4.4 covers one channel only and does not establish that power/EM attacks transfer to shared cloud hardware. The authors should either provide concrete evidence of transferability to realistic cloud or virtualized deployments, or explicitly restrict their practical-impact conclusions to physically accessible devices.","section":"1.1, 4.1, 4.2, 4.4"},{"comment":"The statement that masking and blinding are 'particularly susceptible to single-trace side-channel attacks [15] [34]' is not supported by the cited case studies: REVEAL (Sec. 4.1) and the cache-timing attack (Sec. 4.4) target unmasked SEAL implementations. The relevant single-trace attack on masked lattice-based encryption is described in Sec. 4.5 as [35]. Please correct the citations or qualify the claim, since this sentence is the main evidence that masking is not a standalone defense.","section":"5.2"},{"comment":"The headline result that REVEAL 'reduces the security level of the plaintext encryption from 2^128 to 2^4.4' needs a precise definition of the metric being reported. Is this the post-attack complexity for recovering a complete plaintext, for a single coefficient, or after averaging over per-coefficient success rates? The original source should be quoted with its exact metric; without this context, readers cannot interpret the severity of the attack or compare it with other reported attacks.","section":"4.1"}],"minor_comments":[{"comment":"The secret key is described as 'a random ternary polynomial (-1, 0, and 0 coefficients)', which should read coefficients in {-1, 0, 1}. In addition, the public-key encryption equation introduces 'a' without defining it after pk1 and pk2 have been defined; unify the notation with the public-key components.","section":"2.6, Eq. (13)-(15)"},{"comment":"Passive side-channel attacks are called 'tamper attacks' in the first paragraph of Section 3; this is incorrect, because tampering is an active attack. Please fix the taxonomy wording.","section":"3"},{"comment":"The definitions of polynomial approximation and Chebyshev polynomials are repeated nearly verbatim in three places; consolidate them into a single background subsection to avoid redundancy.","section":"2.4, 2.7, 2.8"},{"comment":"Some citations are mismatched: [18] is cited for the early RSA homomorphism but points to an OpenFHE repository, and [23] is cited as a homomorphic encryption library but points to a tutorial page. Please audit the reference list.","section":"References and Section 2"},{"comment":"The abstract and the introduction contain duplicated sentences, such as the passage about enabling secure processing of encrypted data and the PHE/FHE categorization; tighten these passages.","section":"Abstract and Section 1"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is a competent survey rather than a novel research contribution. Its central message is credible and supported by external, peer-reviewed attack papers, but the scope of the practical-impact claims needs to be reined in, and several factual and presentational errors should be corrected. I would consider the paper acceptable for a survey-oriented venue after revision, but it is unlikely to meet the bar for a top-tier security research venue in its current form."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a survey, not a research paper. Its value is that it pulls together the recent FHE-specific side-channel results—REVEAL on BFV, the NTT key-gen leak on CKKS, the remote cache-timing attack on SEAL, and the full key-recovery on TFHE/FHEW—into one place, with a standard SCA taxonomy and a mitigation list. If you want a quick map of the area, it is handy. The BGV/BFV summary is simplified but internally consistent, and the case-study citations go to peer-reviewed venues.\n\nThe soft spots are real but mostly editorial. There is duplicated text (the Chebyshev paragraph appears twice), at least one embarrassing typo (secret key sampled from '-1, 0, and 0 coefficients' instead of {-1,0,1}), and several self-citations to the author's own website for background facts. None of that is misconduct; it is sloppiness.\n\nThe substantive concern is cloud transferability. The headline claim that real-world FHE deployments 'often face challenges' is supported primarily by the REVEAL power analysis on a RISC-V FPGA at 1.5 MHz and an ARM Cortex-M4F evaluation. The paper itself notes the frequency limitation. FHE is mostly deployed in shared clouds, where power/EM acquisition is much harder; the remote cache-timing attack is evidence for one channel but does not validate the others. The paper either needs a demonstration at realistic cloud frequencies/virtualization or should explicitly scope the threat model to physically accessible deployments. That is a genuine gap, not a nitpick, but it undercuts urgency more than accuracy: the described attacks did work against the tested versions.\n\nWho is this for? Non-specialists and engineers choosing FHE libraries who need a warning that implementation security matters. Specialists already know these papers. I would not cite it as a primary source for any of the attacks; I would cite the originals.\n\nRecommendation: it deserves peer review as a survey, but the authors should fix the duplication and the typo, tone down the comprehensiveness claim, and add an explicit threat-model section. I'd accept it for review and then press for major revision.","headline":"Useful survey of FHE side-channel attacks, but its cloud-applicability claim outruns the evidence and the text needs cleanup before it can be trusted as a reference.","tokens_in":13790,"tokens_out":2587,"would_cite":false,"duration_ms":25001,"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":"This survey argues that fully homomorphic encryption implementations leak plaintexts and keys through side channels, despite the mathematical security of the underlying schemes.","keywords":["side-channel analysis","homomorphic encryption","fully homomorphic encryption","power analysis","timing attacks","fault injection","lattice-based cryptography","single-trace attack"],"falsifier":"Run the REVEAL attack procedure against a current SEAL or OpenFHE deployment on a standard cloud-server CPU at normal clock speed and check whether a single power or electromagnetic trace still recovers the plaintext's error coefficients; if the noise floor prevents recovery, the survey's strongest practical claim fails.","tokens_in":12853,"feed_emoji":"🔓","tokens_out":8966,"duration_ms":80527,"temperature":0.7,"pith_summary":"The paper sets out to show that fully homomorphic encryption, although built on mathematically secure lattice problems, is vulnerable in practice through side channels that leak information about plaintexts, secret keys, or intermediate values. It organizes the threat space into passive and active attacks—power, timing, electromagnetic, and fault—and reviews real case studies on major FHE libraries. The strongest reported results include a single-trace power attack that drops BFV plaintext security from $2^{128}$ to $2^{4.4}$, a neural-network attack recovering secret-key coefficients from CKKS key generation with 98.6% accuracy, a cache-timing attack needing only eight ciphertexts for full key recovery, and a malicious-server fault attack recovering full TFHE/FHEW keys with a few thousand client queries. The survey matters because FHE is being positioned for privacy-preserving cloud and machine-learning computation, where implementation leakage would undermine the confidentiality the scheme promises.","feed_headline":"Homomorphic encryption leaks secrets despite math security","feed_subtitle":"Survey: single-trace power, cache, and fault attacks recover plaintexts and secret keys from FHE libraries.","key_machinery":"The load-bearing objects are the specific implementation components of FHE where data-dependent behavior shows up: Gaussian error sampling in BFV encryption, the number theoretic transform (NTT)—a fast polynomial multiplication step used throughout lattice cryptography—Barrett modular reduction in SEAL, and bootstrapping with LWE error terms. These are the points where branch operations, Hamming-weight differences, and memory-access patterns create measurable power, timing, or electromagnetic differences. The survey's taxonomy of side-channel analysis—simple versus differential, passive versus active, and the power, timing, electromagnetic, and fault channels—organizes how those leak points can be reached, and the case studies show which component each attack targets.","core_discovery":"On its own terms, the paper's central claim is that every main layer of an FHE implementation—error sampling, key generation, modular multiplication, and decryption—has been shown to leak, and the leaks are exploitable in practice. It presents the REVEAL attack on SEAL's BFV encryption as the first single-trace side-channel attack on homomorphic encryption, recovering error-polynomial coefficients and reducing plaintext security from $2^{128}$ to $2^{4.4}$ on a RISC-V FPGA at 1.5 MHz. It then reports that a two-stage neural-network classifier can recover ternary secret-key coefficients from the number theoretic transform in CKKS key generation with 98.6% accuracy, and that this holds even against random delay insertion and under maximum compiler optimization. It also describes a remote cache-timing attack on Barrett modular multiplication that uniquely determines the SEAL secret key with as few as eight triggering ciphertexts, and a server-side attack that induces decryption errors to recover full TFHE and FHEW keys with 19,838 and 7,565 client queries. The survey concludes that masking, blinding, shuffling, and even constant-time implementations are each insufficient as standalone defenses, because single-trace and profiling-based attacks bypass them.","pith_inferences":["The strongest demonstrations were run on low-frequency embedded-class hardware (a 1.5 MHz RISC-V FPGA and an ARM Cortex-M4F); whether the same signal-to-noise ratios hold on full-speed cloud CPUs and virtualized instances is an open question this survey does not settle.","If these attacks generalize to cloud hardware, the natural next target is bootstrapping, which evaluates the decryption circuit with the secret key and is the most compute-heavy phase; the paper does not make this extension.","A practical consequence the authors leave implicit is that side-channel audits should become part of FHE library release criteria, with power, electromagnetic, and cache-timing tests run at the target deployment frequency before production use.","A testable prediction from the survey's synthesis is that a masked FHE implementation with an unmasked NTT or Gaussian sampler will remain vulnerable to single-trace key recovery; confirming it would require a new experiment beyond the cited cases."],"forward_implications":["If the surveyed attacks are representative, FHE confidentiality cannot be assumed from mathematical security alone; deployments must be evaluated for implementation leakage.","Single-trace attacks make masking, blinding, and random delays insufficient on their own, because a single well-placed measurement can bypass the randomization.","A malicious cloud server that controls ciphertexts can, in principle, recover a client's TFHE or FHEW secret key by inducing decryption errors and timing the client's responses, inverting the cloud-privacy model.","FHE libraries need constant-time rewrites of low-level helpers such as conditional-selection macros and hardened key generation, not just constant-time modular arithmetic.","Because several attacks target the NTT and Gaussian sampling, the same leakage classes are likely to reappear in any lattice-based FHE stack that shares these components."],"supporting_citations":[{"why":"Reports the REVEAL single-trace power attack on SEAL BFV encryption, the paper's headline evidence that plaintext security collapses from $2^{128}$ to $2^{4.4}$.","marker":"[15]"},{"why":"Reports the single-trace neural-network attack recovering secret-key coefficients from CKKS key generation's NTT with 98.6% accuracy on an ARM Cortex-M4F.","marker":"[32]"},{"why":"Reports the cache-timing attack on SEAL's Barrett modular multiplication that determines the secret key with as few as eight triggering ciphertexts.","marker":"[34]"},{"why":"Reports the server-side decryption-error attack that recovers full TFHE and FHEW secret keys with 19,838 and 7,565 client queries.","marker":"[36]"},{"why":"Reports single-trace key recovery on masked lattice-based encryption via NTT leakage, used to argue masking is not a standalone defense.","marker":"[35]"},{"why":"Shows message leakage in LWE/LWR-based NIST candidates, used to argue the vulnerabilities are algorithmic rather than implementation-specific.","marker":"[33]"}],"fun_headline_variants":["FHE leaks: single-trace attacks break implementations","Single-trace attacks rip open FHE implementations","Side-channel attacks breach FHE's privacy promise","FHE libraries vulnerable to power, cache, and fault attacks","Homomorphic encryption leaks despite math security"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The survey's practical urgency rests on the assumption that side-channel leaks demonstrated on low-frequency, local hardware (a 1.5 MHz RISC-V FPGA and an ARM Cortex-M4F) transfer to the full-speed cloud servers where FHE is mainly deployed, and the paper notes that higher frequencies add noise.","fun_headline_variants_meta":{"raw":{"variants":["FHE leaks: single-trace attacks break implementations","Single-trace attacks rip open FHE implementations","Side-channel attacks breach FHE's privacy promise","FHE libraries vulnerable to power, cache, and fault attacks","Homomorphic encryption leaks despite math security"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000489,"raw_usage":{"total_tokens":2399,"prompt_tokens":930,"completion_tokens":1469,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":546,"completion_tokens_details":{"reasoning_tokens":1396}},"tokens_in":546,"tokens_out":1469,"duration_ms":11402,"temperature":1.0,"reasoning_tokens":1396,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T20:58:28.107014+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the REVEAL attack procedure against a current SEAL or OpenFHE deployment on a standard cloud-server CPU at normal clock speed and check whether a single power or electromagnetic trace still recovers the plaintext's error coefficients; if the noise floor prevents recovery, the survey's strongest practical claim fails.","supporting_citations":[{"cited_title":"Reveal: Single-trace side-channel leakage of the seal homomorphic encryption library,","cited_arxiv_id":null,"evidence_quote":"Reports the REVEAL single-trace power attack on SEAL BFV encryption, the paper's headline evidence that plaintext security collapses from $2^{128}$ to $2^{4.4}$."},{"cited_title":"Using second-order power analysis to attack dpa resistant software,","cited_arxiv_id":null,"evidence_quote":"Reports the single-trace neural-network attack recovering secret-key coefficients from CKKS key generation's NTT with 98.6% accuracy on an ARM Cortex-M4F."},{"cited_title":"On exploiting message leakage in (few) nist pqc candidates for practical message recovery attacks,","cited_arxiv_id":null,"evidence_quote":"Reports the cache-timing attack on SEAL's Barrett modular multiplication that determines the secret key with as few as eight triggering ciphertexts."},{"cited_title":"Cache-timing attack on the seal homomorphic encryption library,","cited_arxiv_id":null,"evidence_quote":"Reports single-trace key recovery on masked lattice-based encryption via NTT leakage, used to argue masking is not a standalone defense."},{"cited_title":"Leaking secrets in homomorphic encryption with side-channel attacks,","cited_arxiv_id":null,"evidence_quote":"Shows message leakage in LWE/LWR-based NIST candidates, used to argue the vulnerabilities are algorithmic rather than implementation-specific."}],"review_version":1}