{"id":"24fa983f-3bc0-4326-8c4b-9e16cca161a6","arxiv_id":"2505.07329","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"A client-server protocol uses homomorphic encryption to fine-tune a 1B-parameter LLM with LoRA while keeping training data, activations, and the learned adapter weights hidden from the server.","lead":"The authors propose a protocol that lets an organization fine-tune an open-source large language model on private data by encrypting the data and doing most of the heavy computation on a remote server, while keeping the private adaptation weights on a lightweight local client. The system is demonstrated on a Llama-3.2-1B model, showing that homomorphic encryption can be used for private fine-tuning, though the current speed is about 216 seconds per token.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"HE fidelity is demonstrated for only five training steps; the claim that the HE path replicates full 2500-step fine-tuning rests on an untested extrapolation of noise and quantization behavior.","rationale":"The paper has real strengths: the cleartext quantization ablation is systematic and shows that DTok-SC at 8 bits matches FP32 perplexity on Orca-Math, the HE performance benchmarks are concrete, and the five-step loss-fidelity experiment is a reasonable sanity check. The reader's CONDITIONAL verdict is appropriate, and the weakest assumption identified by the reader is the same one I see as most load-bearing: the leap from five HE training steps to the full 2500-step trajectory. This is not an internal inconsistency in the protocol; it is an extrapolation gap in the evidence. The bit-error analysis in Figure 4 demonstrates that noise accumulates with input dimension and corrupts LSBs while leaving the top bits intact, but it does not establish that the top bits remain intact after many rounds of decryption, re-quantization, and backpropagation. The cleartext ablation itself shows that quantization-related instability can emerge only after hundreds of steps (ST-ST at 8-bit, Section 6.1a), so a five-step overlap is weak evidence of long-run stability. A full-length HE run, or at minimum a substantially longer run with per-layer error monitoring, would settle whether the central claim holds. The secondary concern about cleartext scale-factor transmission is worth noting but does not change the primary verdict, since the correctness of the HE training trajectory is the more fundamental issue. Therefore, the reader's CONDITIONAL verdict should remain unchanged, with the condition being a longer HE training evaluation.","tokens_in":14859,"tokens_out":3857,"duration_ms":37244,"concrete_test":"Run the full 2500-step HE fine-tuning of Llama-3.2-1B on Orca-Math with the DTok-SC recipe described in Section 6.1, using the Section 6.3 setup, and compare the loss trajectory and final validation perplexity to the quantized cleartext baseline in Table 2. If the HE loss diverges from the cleartext curve by more than the stochastic-batching noise observed in Figure 3, or if final perplexity degrades by more than 0.01 relative to the 8-bit DTok-SC baseline, the central fidelity claim fails. As a cheaper intermediate check, extend the Section 6.2 loss-fidelity experiment from five steps to at least 100 steps and track the per-layer decrypted-versus-cleartext activation error (for example, max absolute error normalized by scale) to detect drift before it affects the loss.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central feasibility claim is that the HE pipeline can perform private LoRA fine-tuning end-to-end with convergence matching FP32. The evidence for this is (i) a cleartext quantization study over 2500 steps with DTok-SC matching FP32 perplexity, and (ii) an HE execution over exactly five optimization steps whose loss curve overlaps the cleartext curve, plus bit-error measurements on random dot products. The inference from five steps to a full run is the load-bearing step. Each training step under HE involves hundreds of encrypted vector-matrix products; each decrypted output is re-quantized with dynamic per-token scales, and the paper's own bit-error analysis shows non-negligible LSB noise that grows with input dimension (Figure 4). Nothing in the experiments rules out slow accumulation of rounding or truncation errors that leaves the loss curve overlapping for five steps but diverging over hundreds or thousands of steps. The cleartext ablation itself shows that 8-bit ST-ST is stable for about 700 steps then diverges (Section 6.1a), demonstrating that long-run instability can appear only after many steps; the same could happen from HE-specific noise. The claim in Section 6.2 that ciphertext noise growth, modulus switching, and homomorphic operations do not materially perturb gradient computations is based on only five steps, which is not a sufficient sample of training dynamics. A secondary concern is that dynamic per-token activation scales are sent to the server in cleartext, which is data-dependent metadata that the Section 5.4 statement that the server learns no information does not account for; however, the correctness extrapolation is the more load-bearing issue.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper introduces an interactive protocol for private LoRA fine-tuning of open-source LLMs using homomorphic encryption (HE). The server computes linear operations involving the public base weights on encrypted activations, while the client holds the private LoRA adapters and performs non-linear operations. The protocol is implemented with efficient packing, modulus switching, and GPU kernels, and is evaluated on Llama-3.2-1B. The authors report that an 8-bit quantization scheme with dynamic per-token activations and static per-channel weights (DTok-SC) achieves near-FP32 convergence in cleartext (perplexity 1.2391 vs 1.2381), that the HE execution matches cleartext loss over the first five training steps, and that the server-side HE computation costs ~216 s per token per training step on a single RTX 4060 Laptop GPU, with negligible client compute.","tokens_in":15127,"tokens_out":5228,"duration_ms":46604,"significance":"If the claims hold, this is a notable step toward privacy-preserving fine-tuning of large open-source LLMs, demonstrating that a client with minimal compute can outsource the bulk of training to an HE-enabled server while keeping the LoRA weights and sensitive data confidential. The cleartext quantization ablation is thorough and the 8-bit DTok-SC result is a strong, practically useful finding. The protocol transparently builds on Cheetah [12] and adds communication-efficiency optimizations. However, the HE fidelity evidence is limited to five training steps, the backward pass through the base model is not described, and the cleartext transmission of per-token quantization scales conflicts with the stated security guarantee. These gaps must be addressed before the core feasibility claim is fully established.","major_comments":[{"comment":"The claim that HE execution \"faithfully reproduces\" cleartext training dynamics is supported by only five optimization steps. The paper's own cleartext ablation in §6.1(a) shows that 8-bit ST-ST is stable for about 700 steps and then diverges, demonstrating that training instabilities can appear only after many steps. A five-step overlap therefore cannot rule out slow accumulation of HE-specific noise, truncation errors, or quantization drift that could cause divergence at later steps. The authors should either run a full 2500-step HE training (even at reduced scale) or provide a rigorous error-budget analysis that bounds the per-step noise accumulation over hundreds of steps; otherwise the claim that \"ciphertext noise growth, modulus switching, and homomorphic operations do not materially perturb gradient computations\" is overstated.","section":"§6.2, Fig. 3"},{"comment":"The bit-error analysis uses random integer vectors rather than activations and gradients drawn from actual training distributions. Error rates for the MSBs under 1% on random vectors do not directly establish that the γ=12 MSB guarantee holds for the specific magnitudes, signs, and correlation structures encountered in LoRA fine-tuning of Llama-3.2-1B. The impact of LSB noise on the optimizer also depends on how the decrypted outputs are re-quantized with dynamic per-token scales. The analysis should be repeated with representative intermediate tensors from a real fine-tuning run, or the conclusions should be limited to the random-vector setting.","section":"§6.2, Fig. 4"},{"comment":"The protocol description covers only the forward pass through the base weights (Eq. 5 and the packing in §4.3). The paper claims that a full training step includes \"multiple encrypted vector-matrix products per transformer layer during both forward and backward passes,\" but the backward pass is never specified. To support private fine-tuning, the authors must describe how gradients with respect to activations are computed under HE (e.g., using W^T·[grad]_HE), how the client obtains the gradients needed to update the LoRA adapters, and how these operations are packed and communicated. Without this, it is unclear whether the reported 3458-second timings actually correspond to a complete backpropagation step.","section":"§4.1 / §6.3"},{"comment":"The paper states in §4.2 that \"dynamic quantization parameters for activations sent to the server must be computed by the client and also sent,\" meaning per-token activation scales are transmitted in the clear. This appears to contradict the Section 5.4 claim that \"the server learns no information about the client's private data.\" The scale for each token depends on the token's activation extremes and thus reveals statistical information about the private activations and the underlying training data. The authors should either revise the security model to acknowledge and bound this leakage (e.g., via differential privacy on the scales) or modify the protocol so the scales are not exposed to the server.","section":"§4.2 / §5.4"}],"minor_comments":[{"comment":"The abstract says \"demonstrating convergence results using HE-compatible quantization,\" but the convergence results in §6.1 are for quantized cleartext training, while the HE execution is demonstrated over only five steps. The wording should be adjusted to avoid implying that full HE convergence was demonstrated.","section":"Abstract / §6.2"},{"comment":"The values of β=27 and γ=12 are stated without a supporting derivation or analysis. The authors should explain how these parameters were chosen and why they guarantee the claimed precision for the actual dot-product dimensions and quantization scheme used in the experiments.","section":"§4.4"},{"comment":"The statement that latency \"scales approximately linearly with the total number of input tokens (B×C) and the output dimension (dout)\" is presented without direct evidence; Table 4 reports only single-token latencies. A brief scaling experiment or a more careful cost model would strengthen this claim.","section":"§6.3"},{"comment":"The FLOPs estimate assumes the backward pass costs roughly twice the forward pass, which is a common rule of thumb but may not hold precisely for LoRA with HE-based matmuls. The client-side FLOPs estimate is not load-bearing, but a more precise accounting would be useful.","section":"Eq. (10)"},{"comment":"The qualitative results are based on \"converged quantized cleartext models as a proxy for HE results,\" which is acknowledged. It would be valuable to note explicitly that the HE path has not yet been used to produce a fully fine-tuned model, so the qualitative outputs do not validate the HE pipeline end-to-end.","section":"§6.4"}],"recommendation":"major_revision","confidential_remarks":"The paper is from Zama, and the experiments rely on the authors' own Concrete ML library and a self-citation [19]. This is not inherently problematic, but it may warrant an extra check of the reproducibility claims. The manuscript fits the scope of cs.CR, though it sits close to systems/ML; the security model gap around clear-text scales will need to be resolved by the authors."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a competent feasibility study, and the cleartext quantization work is the most solid part. But the central claim that the HE pipeline reproduces full fine-tuning is supported by only five training steps, and the paper overstates what those five steps show.\n\nWhat's new: combining Cheetah-style HE vector-matrix multiplication with LoRA fine-tuning for Llama-3.2-1B is a real combination I haven't seen in the cited literature. The client-server split is clean: server does encrypted linear ops on public base weights, client keeps LoRA adapters and non-linearities. The quantization ablation is genuinely useful—DTok-SC at 8-bit lands at perplexity 1.2391 vs 1.2381 for FP32, and the loss curves show why static per-tensor fails. The GPU timings are concrete: 216 s per token per training step on an RTX 4060, and the client compute estimate is negligible. That's honest engineering evidence.\n\nThe soft spots are real but addressable. First, HE fidelity is shown for exactly five optimization steps. The bit-error analysis uses random vectors, not activations from a training run. Given that the cleartext study itself shows ST-ST diverging after ~700 steps, slow accumulation of HE noise over a full run is not ruled out. The paper's claim that 'homomorphic operations do not materially perturb gradient computations' is stronger than five steps warrant. Second, the client FLOPs estimate omits the cost of encryption, decryption, and client-side scale computations—small, but should be counted. Third, the dynamic per-token activation scales are sent to the server in cleartext; those are data-dependent, so the Section 5.4 claim that the server 'learns no information' needs qualification. Fourth, there's no formal security statement beyond IND-CPA and honest-but-curious, which is fine for a systems paper, but the leakage of scale metadata should be discussed.\n\nThe citation pattern is fine; using Cheetah as a base and citing their own Concrete ML is legitimate, though a commit hash would help reproducibility.\n\nWho should read this: people building privacy-preserving fine-tuning stacks and anyone deciding whether HE is viable for LoRA at 1B scale. It's a serious paper that deserves peer review, but the authors need to either run a longer HE trajectory (even 100-200 steps would help) or explicitly scope the claims to what's demonstrated. I'd send it out.","headline":"Solid HE+LoRA feasibility demo with a thorough quantization study; the full-training fidelity claim rests on only five HE steps and needs either more evidence or tighter scoping.","tokens_in":15766,"tokens_out":3309,"would_cite":false,"duration_ms":27885,"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":"An interactive client-server protocol uses homomorphic encryption to fine-tune an open-source LLM privately, with 8-bit quantization matching FP32-level convergence.","keywords":["homomorphic encryption","LoRA","low-rank adaptation","private fine-tuning","large language models","quantization","RLWE","client-server split"],"falsifier":"Run the complete 2500-step LoRA fine-tuning of Llama-3.2-1B entirely under HE with the paper's parameters ($\\beta=27$, $\\gamma=12$, $N=2048$) and compare the final validation perplexity and the per-step loss trajectory against the 8-bit DTok-SC cleartext run; a divergence in loss or a perplexity noticeably above 1.2391 would show that HE noise and truncation are not benign over full training.","tokens_in":14628,"feed_emoji":"🔐","tokens_out":7452,"duration_ms":67618,"temperature":0.7,"pith_summary":"The paper proposes a protocol that lets a lightweight client privately fine-tune an open-source LLM by outsourcing the heavy linear algebra to a server that works on homomorphically encrypted activations. The client keeps the LoRA adapter matrices and all non-linear operations local, so neither the training text, the intermediate activations, nor the final adapter weights ever appear in cleartext on the server. To make this practical, the authors design an encrypted vector-times-clear-matrix primitive using packed RLWE ciphertexts and show that an 8-bit quantization recipe (dynamic per-token activations, static per-channel weights) brings Llama-3.2-1B fine-tuning to essentially FP32-level convergence, with final perplexity 1.2391 versus 1.2381. On a single laptop GPU a full HE training step for 16 tokens took about 58 minutes, while the client's compute load was below 0.03 MFLOP/s, meaning the bottleneck is server-side HE rather than client hardware.","feed_headline":"Private LoRA fine-tuning works with homomorphic encryption","feed_subtitle":"Llama-3.2-1B reaches FP32-level perplexity at 8 bits while the server sees only ciphertexts.","key_machinery":"The load-bearing primitive is the encrypted vector–clear matrix multiplication $W\\cdot[x]_{\\mathrm{HE}}$, built from RLWE ciphertexts with coefficient packing. The input vector is split into blocks matching polynomial size $N=2048$; the server multiplies each encrypted block by the corresponding cleartext weight block, extracts each dot-product coefficient via SampleExtract into LWE ciphertexts, then packs the per-column LWE results back into one RLWE ciphertext using KeySwitching and homomorphic rotations, finishing with modulus switching for bandwidth. The second essential ingredient is the quantization recipe: symmetric quantization with zero zero-points, so the server evaluates only a single integer dot product, using dynamic per-token ranges for activations and static per-channel ranges for weights at 8 bits.","core_discovery":"The central claim is that LoRA fine-tuning of a public LLM can be split into a server-side encrypted path and a client-side cleartext path without losing training quality. Under an honest-but-curious server, the protocol guarantees that the server never sees the private data: for every linear layer the server computes $W\\cdot[x]_{\\mathrm{HE}}$ on encrypted activations and returns a packed, modulus-reduced ciphertext, while the client decrypts, adds its own low-rank contribution $UDx+b$, applies the activation, and re-encrypts for the next layer. The paper further claims that with 8-bit symmetric quantization using dynamic per-token activation ranges and static per-channel weight ranges (DTok-SC), a 2500-step fine-tuning of Llama-3.2-1B reaches a validation perplexity of 1.2391, statistically indistinguishable from the FP32 baseline of 1.2381. It also reports that the HE execution reproduces the quantized cleartext loss trajectory over the first five training steps and that decrypted dot products keep their 12 most significant bits essentially error-free (below 1% bit-error rate) for input dimensions up to 8192.","pith_inferences":["A forward-only version of this protocol would cost roughly half the training-step time, so the same primitive likely extends to private inference or confidential generation with no cryptographic redesign.","The full 2500-step trajectory has not been run under HE; if error accumulation proves non-benign, a periodic re-encryption or noise-refresh step would be needed, which the current protocol does not include.","The split only protects the client's data; because the client necessarily decrypts $Wx$ in cleartext, the scheme would not keep a proprietary base model confidential from the client.","Whether the 8-bit DTok-SC recipe remains near-FP32 on larger models, such as 7B or 70B classes, is an open empirical question since activation ranges and gradient dynamics change with scale."],"forward_implications":["A data owner can fine-tune a public LLM on sensitive records while the remote server observes only ciphertexts, and the resulting LoRA adapters never leave the client.","The 8-bit DTok-SC quantization recipe is sufficient for near-FP32 fine-tuning, so 16-bit precision is unnecessary when this granularity and dynamic range are used.","The client hardware requirement essentially disappears (about 0.025 MFLOP/s per step), so a machine without a GPU can drive the training.","Training latency scales roughly linearly with tokens, and because token computations are independent, spreading the work across multiple identical servers divides the per-token cost accordingly.","Per-step bandwidth stays modest (about 267 kB per HE linear-layer invocation for 16 tokens), keeping the scheme usable over ordinary internet connections."],"supporting_citations":[{"why":"Defines LoRA, the low-rank adapter method that the protocol trains privately.","marker":"[11]"},{"why":"Supplies the RLWE/TFHE primitives (SampleExtract, KeySwitching, rotations, modulus switching) used in the encrypted matrix-vector product.","marker":"[5]"},{"why":"Provides the earlier RLWE-to-LWE vector-matrix product protocol that the paper extends with packing and modulus switching.","marker":"[12]"},{"why":"Lays out the integer quantization formalism that the 8-bit DTok-SC recipe adapts to HE-compatible training.","marker":"[13]"},{"why":"Defines the Llama-3.2-1B architecture and weights used in all convergence and benchmark experiments.","marker":"[2]"},{"why":"Transfers the encrypted vector-matrix primitive to transformer inference, the starting point for the training extension.","marker":"[10]"}],"fun_headline_variants":["Private LoRA fine-tuning with homomorphic encryption","Encrypted fine-tuning matches FP32 perplexity","Server sees only ciphertexts during private fine-tuning","Fine-tune Llama-3.2 on encrypted data without GPU","HE-based LoRA fine-tuning with client-side GPU savings"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The protocol rests on the assumption that the HE parameters ($\\beta=27$, $\\gamma=12$, $N=2048$) keep enough correct bits in every decrypted dot product that the least-significant-bit truncation and quantization noise never destabilize a long training run, a property tested on five training steps and random-vector dot products rather than on a full 2500-step HE trajectory.","fun_headline_variants_meta":{"raw":{"variants":["Private LoRA fine-tuning with homomorphic encryption","Encrypted fine-tuning matches FP32 perplexity","Server sees only ciphertexts during private fine-tuning","Fine-tune Llama-3.2 on encrypted data without GPU","HE-based LoRA fine-tuning with client-side GPU savings"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001602,"raw_usage":{"total_tokens":6387,"prompt_tokens":952,"completion_tokens":5435,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":568,"completion_tokens_details":{"reasoning_tokens":5356}},"tokens_in":568,"tokens_out":5435,"duration_ms":37145,"temperature":1.0,"reasoning_tokens":5356,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T22:19:03.885295+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the complete 2500-step LoRA fine-tuning of Llama-3.2-1B entirely under HE with the paper's parameters ($\\beta=27$, $\\gamma=12$, $N=2048$) and compare the final validation perplexity and the per-step loss trajectory against the 8-bit DTok-SC cleartext run; a divergence in loss or a perplexity noticeably above 1.2391 would show that HE noise and truncation are not benign over full training.","supporting_citations":[{"cited_title":"In: International Conference on Learning Representations (2022), https://openreview.net/forum?id=nZeVKeeFYf9","cited_arxiv_id":null,"evidence_quote":"Defines LoRA, the low-rank adapter method that the protocol trains privately."},{"cited_title":"Journal of Cryptology 33(1), 34–91 (2020)","cited_arxiv_id":null,"evidence_quote":"Supplies the RLWE/TFHE primitives (SampleExtract, KeySwitching, rotations, modulus switching) used in the encrypted matrix-vector product."},{"cited_title":"In: 31st USENIX Security Symposium (USENIX Security 22)","cited_arxiv_id":null,"evidence_quote":"Provides the earlier RLWE-to-LWE vector-matrix product protocol that the paper extends with packing and modulus switching."},{"cited_title":"In: Proceedings of the IEEE conference on computer vision and pattern recognition","cited_arxiv_id":null,"evidence_quote":"Lays out the integer quantization formalism that the 8-bit DTok-SC recipe adapts to HE-compatible training."},{"cited_title":"Advances in neural information processing systems 35, 15718–15731 (2022)","cited_arxiv_id":null,"evidence_quote":"Transfers the encrypted vector-matrix primitive to transformer inference, the starting point for the training extension."}],"review_version":1}