{"id":"db6d063f-f687-4e26-864a-5cf48d089be2","arxiv_id":"2505.14797","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"MASER combines majority-vote weight pruning with multi-key homomorphic encryption to reduce privacy-preserving federated learning overhead by 3 to 8 times while keeping accuracy within about 1 percent of vanilla FL.","lead":"A new federated learning system called MASER encrypts only the most important 10 percent of model weights using multi-key homomorphic encryption, cutting computation and communication costs by 3 to 8 times compared with existing encrypted FL methods. It keeps accuracy close to unencrypted federated learning on MNIST and CIFAR-10, making private cross-institutional training more practical.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Key manager trust is the load-bearing weak point: a compromised key manager can substitute its own public key and decrypt all client updates, so the privacy claim rests on an unstated TCB.","rationale":"The central contribution of MASER is a privacy-preserving FL framework with strong efficiency gains. The efficiency claim (3.03-8.29x) is an ablation of pruning 90% of parameters and is plausible; the accuracy numbers, while lacking error bars, are secondary because even a modest accuracy drop would not invalidate the efficiency contribution. The most load-bearing condition for the central claim is therefore the privacy guarantee. That guarantee relies on the aggregated public key pk being a trustworthy sum of client keys. The paper explicitly says 'we employ a trusted key manager' (Section 4.2) but never includes the key manager in the threat model (Section 3), which only considers an honest-but-curious server and non-majority malicious clients. A malicious key manager can replace pk with a key of its own choosing and decrypt all ciphertexts, since clients encrypt under pk and the key manager sees the ciphertexts (in the deployment, it is co-located with the server). No proof or verification step prevents this substitution. The reader's weakest_assumption identifies exactly this gap, and our analysis agrees. Fixing it requires either stating the trust assumption explicitly (which weakens the claimed protection) or adding verifiable distributed key generation. Thus the paper should remain CONDITIONAL pending this clarification.","tokens_in":21938,"tokens_out":12131,"duration_ms":105799,"concrete_test":"Run one MASER round with 5 clients and a modified key manager that sets the aggregated public key to its own key pair (sk_KM, pk_KM) instead of the sum of client public keys. Check whether the key manager can decrypt the clients' encrypted slices before aggregation. If decryption succeeds, the privacy claim fails unless the paper explicitly adds the key manager to the trusted-computing base or provides a verifiable key aggregation scheme (e.g., zero-knowledge proofs that each client knows its secret key and that pk equals the sum of the submitted public keys).","verdict_should_be":"UNCHANGED","load_bearing_attack":"MASER's privacy guarantee collapses if the key manager is malicious or compromised. Section 4.2 introduces a 'trusted key manager' that aggregates client public keys (Algorithm 1, lines 1-3), but Section 3's threat model only covers an honest-but-curious server and non-majority malicious clients; the key manager is never placed in the adversary set. Because clients encrypt their slices under the aggregated public key pk (Algorithm 1, line 12), a key manager that substitutes its own key pair for pk can decrypt every client's ciphertext directly. In the implementation (Section 5.3), the server and key manager run on the same machine, so the key manager observes all ciphertexts. No verification mechanism confirms that pk is actually the sum of the clients' public keys. Therefore the abstract's claim of 'strong privacy guarantees' and the reconstruction-attack evaluation in Section 5.6 (Figure 6) are conditional on an unstated trust assumption not included in the threat model.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes MASER, a multi-key homomorphic encryption (MKHE) based framework for cross-silo federated learning. To reduce the overhead of MKHE, clients prune their locally trained models with magnitude-based pruning at a per-round threshold κ, send binary masks to the server, and the server produces a global mask by majority voting; clients retain only the masked (important) parameters, slice them to the CKKS slot count, encrypt them under an aggregated public key pk, and the server aggregates homomorphically. Partial decryption by clients and merging at the server yield the plaintext aggregated model, which is then reconstructed in its original shape by the server. Experiments on MNIST and CIFAR-10 with 5 clients under IID and non-IID splits compare MASER against vanilla FedAvg/FedProx, FedPHE, BatchCrypt, MaskCrypt, FRL, a GraSP-based masking baseline, and an unpruned MKHE baseline. The paper reports accuracy comparable to or better than vanilla FL (e.g., 75.63% vs 74.27% on CIFAR-10 IID) at 10% retention, a 3.03-8.29x reduction in overhead relative to the MKHE baseline, and robustness to mask-poisoning by 20-40% malicious clients.","tokens_in":22185,"tokens_out":10730,"duration_ms":91052,"significance":"If the claims hold, MASER is a useful engineering contribution: reducing the practical cost of MKHE-based FL to 1.48-5x the runtime of vanilla FL (versus 4.7-39x for the unpruned MKHE variant) is an order-of-magnitude improvement in the deployability of multi-key HE for FL. The paper ships a real end-to-end implementation (Golang MKCKKS wrapped via cgo and imported into Python Flower/PyTorch), reports overhead measurements over 5 runs with standard deviations, includes a robustness experiment under 20% and 40% malicious clients, and includes a GraSP ablation that supports the claim that per-round re-pruning matters. The consensus-based mask and slicing design is simple and plausible. However, the two central claims—strong privacy guarantees and 3.03-8.29x efficiency over existing MKHE-based FL approaches—are currently stronger than what the manuscript supports: the privacy claim depends on a trusted key manager that is absent from the threat model, and the efficiency ratio is measured against a self-constructed ablation rather than an existing MKHE-FL system. These gaps are addressable within the scope of a revision.","major_comments":[{"comment":"The key manager is load-bearing for the privacy claim but is never placed in the adversary set. Section 3 defines the adversary as an honest-but-curious server and non-majority malicious clients; Section 4.2 then introduces a trusted key manager who aggregates the public keys, and in the implementation (Section 5.3) the key manager runs on the same machine as the server. A key manager that substitutes its own key pair for the aggregated pk (Algorithm 1, line 3) can decrypt every client's slice ciphertext directly, and because no verification of the aggregated key is specified, the abstract's strong privacy guarantees hold only under an unstated trust assumption. The stress-test concern is confirmed by the manuscript text: the revision should either add the key manager (including its co-location with the server) to the threat model with an explicit honest-and-non-colluding assumption, or provide a verifiable or distributed key-aggregation mechanism and a separate deployment, since the current text conflates the protocol's claimed guarantee with the experimental configuration.","section":"Sec. 4.2, Algorithm 1 lines 1-3, Sec. 3"},{"comment":"The privacy evaluation does not exercise the claimed adversary. The Geiping et al. reconstruction attack is defined against plaintext gradients or model updates, yet for MASER the attack is run on ciphertexts (Figure 6 caption), so near-zero ASR is obtained by construction and carries no evidential weight for the protocol's privacy; the actual guarantee is semantic security of MKCKKS under RLWE. The manuscript should either reframe this experiment as a sanity check and argue privacy from the cryptographic assumptions, or evaluate the relevant adversaries (e.g., an honest-but-curious server that sees the decrypted aggregated model, the per-client masks, and all ciphertexts; or a malicious client holding partial-decryption outputs), and should analyze what the plaintext masks reveal about client data.","section":"Sec. 5.6, Figure 6"},{"comment":"The accuracy comparison lacks statistical support. Section 5.5 reports 5 runs, but Figures 2 and 3 show single accuracy curves with no error bars or seed variance; the headline result that MASER-10% outperforms vanilla FL by about 1.3-1.4 points on CIFAR-10 (75.63 vs 74.27 IID; 76.64 vs 75.32 non-IID) is surprising for a model that discards 90% of the weights and is not explained in the text, since possible regularization or optimization artifacts are not discussed. Add error bars or a seed table and either provide an explanation for the improvement or soften the claim from surpassing to comparable.","section":"Sec. 5.4, Figures 2 and 3"},{"comment":"The headline 3.03 to 8.29 times more efficient than existing MKHE-based FL approaches overstates what is measured. The comparison baseline MKHE-based FL is constructed by the authors as MASER without sparsification (Section 5.2), i.e., an ablation, not an existing approach; no actual MKHE-FL system (e.g., SecFed [14], xMKCKKS [15], DHSA [57]) is benchmarked, so the ratio is partly by construction. The efficiency improvement over the ablation is a legitimate result, but the abstract and conclusion should attribute it as relative to a non-sparsified MKHE baseline, and ideally include at least one external MKHE-FL implementation or reported-cost comparison to support the existing approaches phrasing.","section":"Abstract, Sec. 5.2, Sec. 5.5"}],"minor_comments":[{"comment":"The assignment pk_i ← pk is confusing; it should read something like each client sets pk to the received aggregated public key.","section":"Algorithm 1, line 3"},{"comment":"The phrase By pruning only 10% of the model weights, MASER-90% slightly reduces the total run time is confusing about what MASER-90% means; rephrase as pruning 10% of weights and retaining 90%.","section":"Sec. 5.5"},{"comment":"The caption and the (ASR, PSNR) tuples do not clearly associate each numeric pair with the reconstructed image it belongs to; please relabel the figure panels.","section":"Figure 6"},{"comment":"The statement that code will be publicly released upon acceptance should be replaced by an artifact link or a detailed reproducibility appendix in the revision, since the MKCKKS integration via cgo and the array substitution for the Go map are nontrivial and not independently verifiable as described.","section":"Sec. 5.3"},{"comment":"The sensitivity to the pruning threshold κ is reported only for MNIST; since the CIFAR-10 overhead depends heavily on the slice count, add threshold-sensitivity results for CIFAR-10 as well.","section":"Appendix A"},{"comment":"The notation is loose in places: the encryption description says d0 and d1 are used to sample the weight parameters in the ring R2q, and the level-l ciphertext definition introduces k without defining it; please clean up the definitions.","section":"Sec. 2.2"},{"comment":"The paper never analyzes what the per-client plaintext masks reveal about client data, even though the server sees every local mask every round; add at least a brief leakage analysis for the masks.","section":"Sec. 4.2 and Sec. 3"}],"recommendation":"major_revision","confidential_remarks":"I recommend major revision. The paper is a credible systems contribution with a real implementation, and the efficiency gains are likely real, but the privacy guarantee as stated does not match the threat model: a trusted key manager is outside the adversary set and is co-located with the honest-but-curious server in the experiments, and the privacy experiment in Section 5.6 is set up so that it trivially passes (the attack is applied to ciphertexts rather than plaintext updates). The accuracy claims also need error bars or seed statistics, and the headline efficiency comparison is against a self-constructed ablation rather than an existing MKHE-FL system. These issues are fixable: state the trust assumptions explicitly (or add verifiable key aggregation), fix the attack evaluation, add statistical support to the accuracy curves, and re-scope the baseline comparison. I would also ask for the code artifact before acceptance, given the nontrivial cgo wrapper."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: MASER is a useful engineering result that combines known pieces—magnitude pruning, round-wise majority-vote masks, CKKS slot slicing, xMKCKKS—to make multi-key HE in cross-silo FL practical. The headline claim is plausible: at 10% pruning, the system runs about 3-8x faster than an MKHE FL baseline and only 1.5-5x slower than unencrypted FedAvg/FedProx, with accuracy close. That's worth having.\n\nWhat's actually new: the specific combination, and the measured overhead data. The implementation is a piece of work: they wrapped a Go MKCKKS library into Python via cgo/ctypes, ran clients and server on two separate machines, and give 5-run timing with error bars. The robustness test with 20-40% malicious clients sending bogus masks is a reasonable sanity check. The paper is honest that the components are known; its contribution is integration and measurement.\n\nSoft spots, in order of size.\n\nFirst, the privacy claim rests on an unstated trust assumption. Section 4.2 introduces a 'trusted key manager' that sums the client public keys and hands back pk. The threat model in Section 3 never puts that manager in the adversary set. If the key manager is malicious or compromised, it can replace pk with its own key and decrypt every client's encrypted slices. The implementation even runs the key manager on the same machine as the server. No distributed key generation or verification is offered. This doesn't kill the efficiency finding, but it does mean 'strong privacy guarantees' is too strong as stated. A reviewer should push for either a distributed key-generation protocol or an explicit threat model that includes a semi-honest/tamper-evident key manager.\n\nSecond, accuracy plots have no error bars, and the CIFAR-10 result where MASER-10% beats vanilla FL by ~1.4 points is surprising and unexplained. It may be pruning-induced regularization, but one line of speculation isn't enough; this needs seeds or a stability check.\n\nThird, the efficiency multiplier is against a self-constructed MKHE baseline, so '3.03-8.29x' is partly by construction. That's acceptable—the paper is about adding pruning and slicing—but the abstract should say the comparison is to their own MKHE-FL implementation, not an independently optimized third-party one.\n\nMinor: local masks are sent in plaintext, and the privacy analysis (Figure 6) doesn't consider what mask patterns leak. Probably low sensitivity, but worth a sentence.\n\nWho it's for: people working on HE-based FL who want a concrete efficiency benchmark and a clearly stated trust trade-off. It deserves a serious referee. I'd send it to review with a request to fix the key manager issue and tighten the accuracy claims.\n\nVerdict: conditional accept.","headline":"Solid efficiency paper with a real trust-model gap: the 3-8x speedup is credible, but the privacy guarantee depends on a trusted key manager that the threat model never mentions.","tokens_in":22640,"tokens_out":4045,"would_cite":true,"duration_ms":35955,"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":"MASER makes multi-key homomorphic encryption practical for cross-silo federated learning by pruning model updates to a consensus-chosen 10% before encryption, cutting overhead 3.03 to 8.29 times while keeping accuracy on par with vanilla…","keywords":["multi-key homomorphic encryption","federated learning","model pruning","consensus mask","cross-silo","homomorphic aggregation","privacy-preserving machine learning"],"falsifier":"Run MASER with a malicious key manager that replaces the aggregated public key with one whose secret key it knows, then try to decrypt a captured encrypted slice from a client; if the plaintext model update is recovered, the privacy guarantee collapses without the trust assumption.","tokens_in":21775,"feed_emoji":"🔐","tokens_out":6989,"duration_ms":62161,"temperature":0.7,"pith_summary":"This paper proposes MASER, a privacy-preserving federated learning framework that makes multi-key homomorphic encryption affordable by encrypting only a small, consensus-selected slice of each model update. In MASER every client still holds its own encryption key, so the server aggregates ciphertexts and no single client can decrypt another's update. Before encryption, clients prune their local models by weight magnitude and vote through the server on a shared global mask, so all clients sparsify the same positions and aggregation remains meaningful. The authors report that with only 10% of weights retained, MASER runs 3.03 to 8.29 times faster than a standard MKHE-based FL baseline and 1.48 to 5 times slower than unencrypted FL, while keeping accuracy nearly identical to vanilla federated averaging. The main caveat is that the scheme relies on a trusted key manager to sum the clients' public keys.","feed_headline":"Pruning before encryption cuts homomorphic FL cost by up to 8x","feed_subtitle":"Consensus-masked multi-key HE keeps accuracy on par with unencrypted FL at only 1.48-5x the runtime.","key_machinery":"The load-bearing mechanism is consensus-based sparsification plus slot-based slicing. Magnitude-based pruning produces a binary local mask per client; the server fuses these by majority voting into a global mask that all clients apply, which keeps the sparse updates aligned so homomorphic addition yields a meaningful aggregate. The surviving parameters are reshaped into slices that exactly fill the n/2 plaintext slots of the CKKS/MKCKKS ciphertext space, minimizing the number of encryptions and the size of transmitted ciphertexts. Clients encrypt under an aggregated public key and later perform partial decryption with their own secret keys, so the server only ever sees ciphertexts.","core_discovery":"MASER's central claim is that sparsifying before encryption, guided by a per-round majority-voted mask, is what makes multi-key homomorphic encryption practical for cross-silo federated learning. Experiments on MNIST and CIFAR-10 in both IID and non-IID settings show that retaining only the top 10% of weights by magnitude keeps test accuracy within 0.2 percentage points of unencrypted FedAvg on MNIST and slightly exceeds vanilla FL on CIFAR-10, while cutting total runtime by 3.03x to 8.29x relative to encrypting the full model with MKHE. The paper argues that encrypting every parameter is unnecessary because a small set of large-magnitude weights carries almost all the information, provided all clients agree on which parameters to keep.","pith_inferences":["The privacy guarantee is conditional on the trusted key manager: if that party is malicious or compromised, it can replace the aggregated public key and read all client updates, something the paper's threat model never considers.","Because the measured cost is dominated by ciphertext transmission and encryption, the same consensus-prune-then-slice recipe should transfer to other homomorphic backends or to secure aggregation, with gains growing as models get larger and sparser.","The small accuracy gain over vanilla FL on CIFAR-10 suggests the majority-vote mask acts as a regularizer; a testable extension is whether the consensus mask also dampens client drift under stronger non-IID skew."],"forward_implications":["The reported 1.48x to 1.58x runtime over unencrypted FL means a multi-key HE privacy layer moves from research prototype to a deployable option for cross-silo settings.","A 10% pruning threshold sits near the efficiency-accuracy sweet spot: keeping 90% of weights barely changes accuracy but can inflate encrypted traffic by an order of magnitude (e.g., 62.85 MB to 633.92 MB for CIFAR-10 slices).","Because MASER only assumes arithmetic aggregation, it can carry FedAvg, FedProx, and any aggregation rule expressible as additions, so existing FL pipelines can be wrapped in the protocol without changing the optimizer.","The per-round majority-vote mask also supplies robustness against malicious clients: experiments with 20% and 40% non-majority malicious clients show negligible accuracy degradation."],"supporting_citations":[{"why":"Supplies the xMKCKKS public-key aggregation that MASER adopts so all clients encrypt under one summed key while keeping secret keys private.","marker":"[15]"},{"why":"Provides the MKCKKS multi-key homomorphic scheme and its partial decryption/merge operations that MASER relies on for ciphertext aggregation.","marker":"[25]"},{"why":"Defines the FedAvg aggregation rule that MASER uses in IID settings and the main unencrypted baseline for overhead comparison.","marker":"[22]"},{"why":"Defines FedProx, the non-IID aggregation rule and unencrypted baseline that MASER extends with encryption.","marker":"[17]"},{"why":"Supplies MaskCrypt, a selective-encryption baseline that motivates MASER's full encryption of the sparsified update.","marker":"[13]"},{"why":"Supplies FedPHE, a packing-based single-key HE baseline whose overhead MASER seeks to undercut with stronger multi-key privacy.","marker":"[12]"},{"why":"Supplies FRL, a ranking-based privacy baseline that MASER compares against on accuracy and convergence.","marker":"[19]"},{"why":"Supplies GraSP, the prune-at-initialization baseline (MAIN-GraSP) used to show per-round mask recalculation matters.","marker":"[31]"},{"why":"Supplies the magnitude-based pruning criterion that generates MASER's local masks.","marker":"[18]"}],"fun_headline_variants":["Prune before encrypt: multi-key HE FL gets 8x speedup","Consensus mask cuts homomorphic FL overhead to near-vanilla","Encrypt only 10% top weights: private FL at 1.5x cost","MASER prunes then encrypts: MKHE-FL efficiency leap"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole privacy story depends on a key manager who honestly aggregates clients' public keys and never abuses that position, yet the threat model never makes the key manager an adversary.","fun_headline_variants_meta":{"raw":{"variants":["Prune before encrypt: multi-key HE FL gets 8x speedup","Consensus mask cuts homomorphic FL overhead to near-vanilla","Encrypt only 10% top weights: private FL at 1.5x cost","MASER prunes then encrypts: MKHE-FL efficiency leap"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000328,"raw_usage":{"total_tokens":1823,"prompt_tokens":925,"completion_tokens":898,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":541,"completion_tokens_details":{"reasoning_tokens":815}},"tokens_in":541,"tokens_out":898,"duration_ms":9036,"temperature":1.0,"reasoning_tokens":815,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T15:28:52.054021+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run MASER with a malicious key manager that replaces the aggregated public key with one whose secret key it knows, then try to decrypt a captured encrypted slice from a client; if the plaintext model update is recovered, the privacy guarantee collapses without the trust assumption.","supporting_citations":[{"cited_title":"Efficient multi-key ho- momorphic encryption with packed ciphertexts with application to oblivious neural network inference,","cited_arxiv_id":null,"evidence_quote":"Provides the MKCKKS multi-key homomorphic scheme and its partial decryption/merge operations that MASER relies on for ciphertext aggregation."},{"cited_title":"Maskcrypt: Federated learning with selective homomorphic encryption,","cited_arxiv_id":null,"evidence_quote":"Supplies MaskCrypt, a selective-encryption baseline that motivates MASER's full encryption of the sparsified update."},{"cited_title":"Efficient and straggler-resistant homomorphic encryption for hetero- geneous federated learning,","cited_arxiv_id":null,"evidence_quote":"Supplies FedPHE, a packing-based single-key HE baseline whose overhead MASER seeks to undercut with stronger multi-key privacy."},{"cited_title":"Every vote counts: Ranking-Based training of federated learning to resist poisoning attacks,","cited_arxiv_id":null,"evidence_quote":"Supplies FRL, a ranking-based privacy baseline that MASER compares against on accuracy and convergence."},{"cited_title":"Learning both weights and connections for efficient neural network,","cited_arxiv_id":null,"evidence_quote":"Supplies the magnitude-based pruning criterion that generates MASER's local masks."}],"review_version":1}