Pith. sign in

REVIEW 4 major objections 7 minor 1 cited by

Robust and Secure Code Watermarking for Large Language Models via ML/Crypto Codesign

T0 review · 4 major / 7 minor · reviewed 2026-08-09 · deepseek-v4-flash

Pith's one-line read This paper claims that watermarks can be embedded in LLM-generated code without breaking it, and that ownership can be proven without revealing the watermark.

desk verdict The ML watermarking is a credible incremental step, but the ZKP verification claim is vacuous as written: the proof relation in Algorithm 1 is trivially satisfiable for any embedding. read the letter →

arxiv 2502.02068 v3 pith:SJEN6DAB submitted 2025-02-04 cs.CR cs.CLcs.LG

classification cs.CRcs.CLcs.LG
keywords codewatermarkingLLM-generatedzero-knowledgeproofzk-SNARKT5detectability-fidelity-robustnessadversarialrobustnessintellectualpropertyprotection
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that code watermarking can be both strong and practical if the insertion and extraction networks are trained end-to-end on a large pretrained code model, and if verification is handled by a zero-knowledge proof that never reveals the signature. It presents RoSeMary, which hides a binary message by choosing syntactic transformations and variable renames, and reports near-perfect detection (0.97 AUROC) while keeping the watermarked code's pass rate within a few points of the original on HumanEval, MBPP, and EvalPlus. The paper also shows the same watermark survives variable-rename and refactor attacks, and that a third party can verify ownership in about 120 ms using a zk-SNARK proof of about 18.75 KB. A sympathetic reader would take the paper to be establishing that the detectability-fidelity-robustness tri-objective can be satisfied by combining a pretrained code encoder with adversarial training and cryptographic verification, rather than by sampling watermarked tokens at generation time.

What carries the argument

The load-bearing object is the end-to-end trained watermark insertion/extraction pair. The insertion module uses the CodeT5 encoder to fuse code features with the watermark message, and two decoders output distributions over syntactic transformations and over variable renames; executing the highest-probability choices yields the watermarked code. A second encoder-decoder pair recovers the message, and the whole system is trained with a weighted sum of a functionality loss, a detectability loss, and a robustness loss, where adversarial noise is added to the transformation probabilities during training. For verification, the decoder weights and the signature become private witnesses in a zk-SNARK circuit that checks the bit error rate between the recovered message and the owner's signature on the public embedding.

What would settle it

Take a code snippet that was never watermarked, compute its embedding with the owner's public encoder, and try to find any decoder and signature that satisfy the bit-error-rate threshold inside the described zk-SNARK circuit; if such a witness exists and the proof verifies, the ownership claim fails.

Watch

Extended reading notes

Core claim

The central discovery is that swapping the shallow from-scratch transformer of prior neural code watermarking for a pretrained CodeT5 encoder, and training the insertion and extraction heads jointly, produces watermarked code that keeps its functionality while letting the hidden message be recovered even after adversarial edits. The paper further discovers that the message extraction step can be moved inside a zk-SNARK circuit, so an owner can prove that a snippet's embedding decodes to a known signature within a chosen bit-error-rate threshold without exposing the signature or the decoder. On three code benchmarks the system reaches 0.97 AUROC, keeps pass-rate drops under five percentage points, and verifies proofs in under 120 ms.

Load-bearing premise

The load-bearing premise is that a proof whose public input is an embedding computed by the owner, with the decoder and signature as private inputs, establishes that a specific disputed code snippet came from the owner's system; if the embedding is not derived from the snippet inside the circuit, the proof only shows that some decoder and signature match the embedding, not that the snippet itself was watermarked.

Editorial extensions

If this is right

  • A code-LLM provider could watermark snippets after generation in a single forward pass without altering the model's decoding behavior, since insertion takes about 0.027 seconds per sample and keeps pass rates within five points of the original.
  • One proof, about 18.75 KB, can be verified by any third party in roughly 120 ms, so the owner never needs to reveal or re-encode the signature after each verification.
  • Under a 50% variable-rename attack the detection AUROC stays above 0.93, and under full refactoring by Qwen2.5-Coder-32B it stays at 0.73, showing the watermark survives common code-rewriting attacks.
  • The loss-weight ablation shows that increasing the robustness weight can improve attack resistance while keeping the pass rate flat, at the cost of a small drop in detection TPR when using MBPP.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper, the same end-to-end adversarial-training recipe could transfer to other low-entropy structured outputs like SQL queries, configuration files, or protocol messages, where inference-time watermarking has even less room to hide a signal.
  • Beyond the paper, the security of the ownership proof depends on the embedding being a faithful, collision-resistant representation of the snippet; if the embedding is not recomputed inside the circuit, a proof only shows that some decoder and signature match the embedding, not that the snippet itself was watermarked.
  • Beyond the paper, the reported 4-bit-to-8-bit message-length ablation (AUROC drops from 0.97 to 0.88) implies a practical capacity ceiling; scaling to longer signatures would require either more transformation channels or a larger code context.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 7 minor

Summary. The paper proposes RoSeMary, an end-to-end code watermarking framework for LLM-generated code. It trains a CodeT5-based insertion module and a shallow decoder to embed and extract short binary signatures via syntactic and variable-rename transformations, and uses Halo2-based zk-SNARKs to enable verification without revealing the signature. Experiments report high AUROC values, watermarked pass rates around 95-98%, robustness to variable renaming and refactoring, and a ZKP verification time of about 120 ms.

Significance. If the ZKP construction were sound, the ML/Crypto codesign would be a valuable step toward practical code watermarking. The ML component is plausible and the empirical comparison to existing watermarking methods is useful, though the evaluation is incomplete in several respects. However, the central security claim—that RoSeMary provides publicly verifiable proof that a code snippet was generated by a proprietary LLM—is not supported by the described ZKP relation. This flaw is load-bearing because it concerns the paper's main advertised novelty.

major comments (4)
  1. [Section 3.4 and Algorithm 1] The zero-knowledge relation in Algorithm 1 is trivially satisfiable. The private inputs are the decoder Re and the signature M, with no commitment or public binding to the owner's fixed watermarking system. For any public embedding x and any chosen signature M*, a malicious prover can choose an affine decoder Re satisfying Re(x)=M*, yielding BER=0. The circuit therefore accepts even if x is not derived from a watermarked snippet and even if Re is not the owner's model. The proof does not establish that the disputed code was watermarked by the owner, nor that the embedding corresponds to the code under dispute. Consequently, the Section 3.4 claim of publicly verifiable proofs is unsupported. This is a fundamental soundness problem in the central contribution.
  2. [Section 4.2 and Table 1] The abstract claims "unaltered watermarked code functionality," but Table 1 reports watermarked pass rates of 95.12% on HumanEval, 97.64% on MBPP, and 95.39% on EvalPlus. No pass rates for the original unwatermarked code are reported, so the stated "less than 5% pass rate drop" cannot be verified from the paper. The reported numbers themselves imply a 4-5% drop relative to perfect functionality, which contradicts the word "unaltered." The authors should report original pass rates, provide error bars, and temper the fidelity claim accordingly.
  3. [Appendix A and Table 6] The evaluation uses only 4-bit messages. Appendix A, Table 6 shows that increasing the message length to 8 bits reduces AUROC from 0.97 to 0.88 and TPR from 0.99 to 0.73 on MBPP. A 4-bit message space admits only 16 distinct signatures, which is too small for meaningful owner identification in practice. The paper's claims of high detectability and practical usability therefore hinge on an unreasonably short signature. The authors should evaluate longer message lengths or provide a clear security and usability justification for the 4-bit choice.
  4. [Section 3.4 and Algorithm 1] The public input S(T,M)_embed is produced by the owner's private encoder Se. The paper assumes this embedding reveals nothing sensitive, but no analysis is provided; because the embedding is computed by a trained encoder, it may encode recoverable information about the signature M. Moreover, the verifier cannot check that the public embedding was actually computed from the disputed code snippet, since neither the original code nor the encoder is part of the circuit's public inputs. This breaks the link between the proof and the code being disputed. The protocol needs to bind the proof to the code snippet, for example by committing to the code or recomputing the embedding inside the circuit.
minor comments (7)
  1. [Table 1 caption] The table caption lists "DS-1000" as a dataset, but the column headers and the text in Section 4.1 refer to EvalPlus; these labels should be reconciled.
  2. [Section 4.2] The sentence beginning "Compared to KGW (Kirchenbauer et al., 2023b) KGW watermarks..." contains a duplicated phrase and should be rewritten.
  3. [References] References Chen et al. 2021a and Chen et al. 2021b appear to describe the same arXiv report; the authors should consolidate or clearly differentiate them.
  4. [Section 4.3 and Table 2] The verification time is reported as an average over 25 examples, but no standard deviation or per-example distribution is given; the same lack of error bars affects the robustness results in Figure 3.
  5. [Algorithm 1] Line 4 uses both S(T,M)_embed and Se(S(T,M)) without clarifying whether the public embedding itself is the circuit input or is recomputed inside the circuit; this ambiguity should be resolved.
  6. [Section 3.4] The text describes Re as composed of batch normalization, fully-connected, ReLU, and dropout layers, but Algorithm 1 calls it a "shallow linear decoder"; the architecture used in the ZKP should be stated precisely.
  7. [Section 2] The claim of "first-of-its-kind ML/Crypto codesign" is overstated given the existence of ZKROWNN, which is cited for ZK verification of DNN watermarks; the novelty should be positioned more carefully.

Circularity Check

1 steps flagged · score 6.0 of 10

Algorithm 1's ZKP proof is vacuously satisfiable because Re and M are uncommitted private inputs, so the publicly verifiable ownership proof reduces to an arbitrary decoder choice rather than to the disputed code.

  1. other [Section 3.4, Algorithm 1]
    "Public Values: Watermarked text embedding S(T, M)embed, Target bit error rate (BER) θ; Private Input: Shallow linear decoder Re, Signature M; Circuit: M ′ = zkFeedForward(Re) on input Se(S(T, M)); valid BER = zkBER (M, M′, θ); return valid BER"

    Both Re and M are private, uncommitted witnesses. For any public embedding x and any chosen signature M*, a prover can set M=M* and choose Re (e.g., the affine Linear layer in Table 8) with Re(x)=M*, giving BER=0<θ. The circuit then returns valid for every x, regardless of whether x was produced by the owner's watermarked code. The claimed conclusion that the proof shows 'a code snippet was generated from a proprietary code LLM' (Section 3.4) is therefore not entailed: the validity condition is satisfiable by construction for any input, so the verification reduces to an existential statement over unconstrained private values rather than to any binding of the disputed code to the owner's fixed encoder. The proof's validity is, by construction, independent of the ownership claim.

full rationale

The ML watermarking claims are self-contained: RoSeMary is trained end-to-end on CodeSearchNet and evaluated on held-out HumanEval, MBPP, and EvalPlus benchmarks; the z-score detection test follows from the stated binomial message model rather than from fitted constants, and the robustness results use held-out variable-rename and refactor attacks. The one significant reduction-by-construction is in the secure verification component: Algorithm 1's proof relation is trivially satisfiable for arbitrary public embeddings because the decoder Re and signature M are private, uncommitted inputs chosen by the prover. This makes the central 'publicly verifiable proof of ownership' claim unsupported, though it does not invalidate the independently measured watermark detection and fidelity results. Score 6 reflects that one advertised central claim reduces by construction while the core ML evaluation remains independent.

Assumptions & free parameters 4 free parameters · 5 assumptions · 0 invented entities

The core ML result rests on hand-chosen hyperparameters (message length, loss weights, noise scale) and the unvalidated Rf approximation assumption. The ZKP protocol additionally assumes a binding relation between the proof and the disputed code that the paper does not establish.

free parameters (4)
  • Message length = 4 bits
    Headline results use 4-bit signatures. Table 6 shows 8-bit messages drop AUROC from 0.97 to 0.88 and TPR from 0.99 to 0.73, so the choice is performance-critical.
  • Training loss weights (wf, wd, wr) = 1, 1, 0.05 in final setup; varied in Table 3
    Hand-chosen to balance functionality, detectability, and robustness; no principled selection criterion or sensitivity analysis is provided.
  • Gaussian noise std sigma_p = 0.1
    Used in Equation 1 to simulate adversarial transformations during training; no sensitivity analysis is reported.
  • ZKP BER threshold theta = not reported
    Controls whether a proof is accepted. No default value or sensitivity analysis is given in the paper.
assumptions (5)
  • ad hoc to paper The Rf approximator reliably models the non-differentiable watermark insertion/extraction, so feature-space losses preserve functionality.
    Equation 4 defines Lf through Rf, but the paper provides no validation that Rf's approximation error is small enough to guarantee functional correctness across transformations.
  • domain assumption The syntactic transformations in Appendix B preserve code semantics for all benchmark programs.
    Relied on in Section 3.2 and Appendix B; only empirical pass rates support it, and Table 1 shows 4 to 5 percent of watermarked code fails tests.
  • domain assumption CodeT5's pretrained feature space has the property that feature closeness implies functional equivalence.
    The functionality loss Lf assumes this property; no independent evidence is provided beyond pass rates.
  • ad hoc to paper The Gaussian noise in Equation 1 adequately represents the space of adversarial transformations an attacker will apply.
    Adversarial robustness training relies on this assumption; only variable-rename and refactor attacks are evaluated.
  • standard math Halo2/EZKL circuits correctly implement the BF16-quantized decoder and BER computation, with sound and zero-knowledge properties.
    The paper depends on these library properties but provides no formal verification or reproduction code.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Robust and Secure Code Watermarking for Large Language Models via ML/Crypto Codesign." pith.science (2026). https://pith.science/paper/SJEN6DAB

@misc{pith2026250202068,
  author       = {Pith},
  title        = {Pith review of: Robust and Secure Code Watermarking for Large Language Models via ML/Crypto Codesign},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SJEN6DAB}},
  note         = {Machine review of arXiv:2502.02068}
}
read the original abstract

This paper introduces RoSeMary, the first-of-its-kind ML/Crypto codesign watermarking framework that regulates LLM-generated code to avoid intellectual property rights violations and inappropriate misuse in software development. High-quality watermarks adhering to the detectability-fidelity-robustness tri-objective are limited due to codes' low-entropy nature. Watermark verification, however, often needs to reveal the signature and requires re-encoding new ones for code reuse, which potentially compromising the system's usability. To overcome these challenges, RoSeMary obtains high-quality watermarks by training the watermark insertion and extraction modules end-to-end to ensure (i) unaltered watermarked code functionality and (ii) enhanced detectability and robustness leveraging pre-trained CodeT5 as the insertion backbone to enlarge the code syntactic and variable rename transformation search space. In the deployment, RoSeMary uses zero-knowledge proofs for secure verification without revealing the underlying signatures. Extensive evaluations demonstrated RoSeMary achieves high detection accuracy while preserving the code functionality. RoSeMary is also robust against attacks and provides efficient secure watermark verification.

Figures

Figures reproduced from arXiv: 2502.02068 by the authors.

Figure 1
Figure 1. Overview of watermark insertion and extraction. The Code LLM owner watermarks the code before distributing the snippets to end users. The third-party arbitrator leverages zero￾knowledge proofs to verify the ownership without requiring the owner to reveal the encoded watermark. acquiring high-quality code training data (Lu et al., 2021; Puri et al., 2021). Nevertheless, AI-generated code may be used for malicious pur… view at source ↗
Figure 2
Figure 2. RoSeMary watermarking procedure. The watermark insertion takes the original code and watermark message as input and fuses their features by CodeT5’s encoder Se. Two sets of decoders Sd1 and Sd2 predicts the probability over the available syntactic transformations and the renamed variable over the vocabulary. Then, the watermark extraction module decodes watermarks from the syntactic-transformed and variable-renamed … view at source ↗
Figure 3
Figure 3. Robustness evaluation results under Variable-rename At￾tack (VA) and Refactor Attack (RA). performance in [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Watermarked example randomly selected from Hu￾manEval (Chen et al., 2021a). The upper code shows the original code and the lower code shows the watermarked code, where all watermarks are successfully extracted. Watermark Insertion Overhead The time taken for wa￾termark…
Figure 5
Figure 5. Figure 5: Watermarked example from HumanEval (Chen et al., 2021a) and MBPP (Austin et al., 2021). The left code shows the original code and the right code shows the watermarked code, where all watermarks are successfully extracted. D. RoSeMary’s Implementation Details Hardware I…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Multi-Channel Spread-Spectrum Code Watermarking

    cs.CR 2026-07 unverdicted novelty 7.0 of 10

    A training-free post-hoc code watermark embeds 24-bit identifiers via multi-channel spread-spectrum encoding over naming conventions and semantic pattern pairs, with majority voting and Reed-Solomon recovery.

Pith tools

Reviewed August 9, 2026 · model on record in the stance chip above.