CodeCipher: Learning To Obfuscate Source Code Against LLMs

We appreciate for your valuable comment.

The performance of the obfuscated models has an evident decrease compared with the original models across three tasks in Section 5.2.

As an obfuscation method, some performance reduction is expected. The goal of CodeCipher, however, is to perturb code to prevent reading, execution, and data collection for training, all while minimizing this performance drop. Our experimental results indicate that CodeCipher achieves a significantly smaller performance reduction compared to conventional obfuscation techniques.

Some important technical details are missing, especially in the discrete gradient search algorithms. Why is single gradient computation inadequate? What is the motivation behind using the nearest valid token, and how do we get the nearest? The motivation part of the proposed algorithm can be strengthened.

The motivation behind the discrete gradient search algorithm is detailed in Section 4.1, paragraph 2. In response to your questions: A single gradient computation is inadequate because it is difficult to pinpoint a valid token. Instead, the multi-step gradient search dynamically adjusts the gradient direction based on intermediate token projections, allowing for more accurate token replacements. Experiments in Section 5.4 demonstrate the effectiveness of this approach.

We select the nearest valid token because it represents an actual word embedding rather than an imaginary vector, enabling more precise gradient calculations. The nearest valid token is identified by calculating the dot product with the normalized embeddings of existing words. We have also strengthened the motivation behind this algorithm in the revised version (Section 4.1).

The prompt used is casual and does not have a rigorous design.

We use a straightforward prompt style to reflect typical prompting methods employed by general users. This simple approach aligns with widely adopted practices in code-related tasks, such as the prompts used by DeepSeekCoder for code completion: https://github.com/deepseek-ai/DeepSeek-Coder/blob/main/Evaluation/HumanEval/eval_instruct.py.

The analysis of the transferability is weak. The ability to generalize is an interesting and important finding. However, more analysis should be discussed to explain why it works across closed models.

We agree that this is an interesting and significant finding. The observed generalizability may be due to the key patterns extracted in the token cipher mapping, which is likely regarded as essential across different models. However, further experiments are necessary to validate this hypothesis, and we plan to explore this in future work.

In Section 5.2, why only choose 200 samples from 2 million samples of CodeSearchNet and how to get the compilation rate using code snippets?

We believe you are referring to the experiment in Section 5.3. Testing the entire dataset would be computationally expensive and time-consuming, so we chose a representative subset of 200 samples. Through several rounds of experimentation, we found that this subset size yields stable results. We consider this subset sufficient to support our key findings. The compilation rate is computed using the built-in compile() function in Python.

Will performance be affected by the training epochs? How to get the best hyper-parameters?

Yes, the number of training epochs impacts the performance, as a higher number of epochs typically results in a greater obfuscation degree, which may lead to a performance decline. Our current parameters are chosen to balance obfuscation level with minimal performance impact. Following your comments, we conducted additional experiments to evaluate the effects of different learning rates and other hyperparameters. The new results are included in the revision.

Thank you for your insightful comments.

How to obtain LLM's embeddings if LLMs are closed-source?

Our method is primarily built on white-box models. In cases where the LLMs are closed-source, we take the trainable white-box model as a proxy, then apply the learned cipher mapping to the closed-source model. As demonstrated in Section 5.6, code obfuscated by a local white-box model transfers effectively to a remote closed-source model.

If the LLM is open-source, I question whether the proposed approach is necessary. With access to trained LLMs for local execution, code privacy may no longer be a significant issue.

While large white-box LLMs are readily available for local deployment and execution, limited computational resources may prevent individual users from deploying them locally, necessitating a client-server architecture. We have added this point in the revised manuscript in the first paragraph of Section 1.

Adaptive attacks are not discussed in this paper. If an attacker understands how the approach works, could they potentially generate the confusion mapping themselves and deobfuscate the obfuscated code?

Though our method is built on white-box models, the trained transformation mapping is inherently black-box. Since we do not disclose the model parameters, even if an attacker understands how the approach works, they would be unable to replicate the obfuscation process or perform de-obfuscation. In the revision, we have added the discussion of this point in Appendix E.

We appreciate the reviewer's insightful comments. Below we provide the point-by-point response to each of the weaknesses you raised:

Why not use privacy protection metrics (i.e. TopK)?

1. The primary goal of CodeCipher is to obfuscate source code to prevent it from execution, reading, and data collection for training. Therefore, we employ commonly accepted privacy protection metrics within the code domain, such as 'Compilation Rate' (to measure the usability of the obfuscated code), 'Edit Distance' (to quantify the readability after obfuscation), and 'PPL' (to quantify the loss when the obfuscated code is collected for training). In Section 5.3, we conducted extensive experiments about the efficacy of privacy protection of our methods.

2. The top-k accuracy you suggest is not applicable in our problem context because it requires a list of predictions, whereas our output consists of code segments or texts. It is also crucial to note that in our approach, the obfuscated code is taken as input to the server model, rather than being part of the server's output. So we don't have the 'ground truth' prediction to calculate the Top-K metric.

Why do you compare with identifier renaming (Chakraborty et al., 2022) which is unrelated with code obfuscation? And why it's performance decrease in your experiments?

We apologize for incorrectly citing Chakraborty et al.'s work as an "identifier renaming" approach. Identifier renaming is a traditional and widely used method for source code obfuscation; in the revised version, we have updated the citation to more relevant studies.

TextObfuscator is a SOTA approach for preserving inference privacy. Why don't you compare with it?

TextObfuscator is a relevant technique developed primarily for natural language, and we attempted to adapt it for source code to compare with CodeCipher. However, we encountered several challenges that made this comparison infeasible. First, TextObfuscator outputs vector representations rather than discrete tokens, making it difficult to accurately measure the degree of obfuscation and potentially leading to unreliable comparison results. Second, TextObfuscator depends on task-specific loss functions, which are not directly applicable to our code generation task and would require substantial modifications to model architecture and training processes. As a result, we have not included this comparison in the current version and instead leave the adaptation and evaluation of TextObfuscator for future work.

In Figure 5(b), the obfuscated code still has tokens like "password" which is in the original code, how can you ensure the user's password "securePassword123" will not show in the obfuscated code?

The current approach primarily focuses on perturbing code tokens that reduce readability and executability, but it does not yet guarantee the removal of all sensitive tokens in all cases. Ensuring complete obfuscation of specific sensitive data, such as "securePassword123," is a promising direction for further optimization and refinement in future work.

However, we believe these weaknesseses may not be enough to obscure the strengths of our paper. Since the embedding perturbation methodology is very different from previous papers, It offers a lightweight, practical solution that only involves minimal data perturbation on the client side. It also brings a lot of interesting problems to be solved in future work. Maybe our method can gradually become a new branch of code privacy protection.

Missing extensive experiments on the discrete gradient search

Thanks for your suggestion. We conducted experiments on the discrete gradient search in Section 5.4, wherein we ablate the discrete gradient search part and tested the effect on the final performance. We also experimented by varying the learning rates of the discrete gradient search part. The results are provided in Table 3.

Following your advice, we have conducted more extensive experiments on the discrete gradient search part. We vary the number of sub-steps as well as the learning rates. The results are updated in Appendix C in the new revision. The results are consistent with previous observations, demonstrating the efficacy of the discrete gradient search.

We appreciate the reviewer for the comprehensive and valuable comments. We have meticulously reviewed each of your points and provided corresponding clarifications as follows:

Only rule-based baselines are compared.

CodeCipher is not solely compared with rule-based methods. In addition to the conventional code obfuscation methods (rule-based), we also compare it with two LLM-based approaches, including 1) directly instructing LLMs for obfuscation and 2) obfuscating and then informing LLMs. Details of these baselines, including their setup and implementation, are provided in Section 5.1.

More related techniques need to be mentioned and compared, such as cryptography-based approaches (e.g., Homomorphic Encryption, Multi-Party Computation, Functional Secret Sharing, Differential Privacy in Inference), detection-based approaches (e.g., Direct Detection, Contextual Inference Detection), and hardware-based approaches.

We appreciate your suggestion and the comprehensive references. However, these cryptography-based, detection-based, and hardware-based approaches differ significantly in technical scope and are thus challenging to compare directly with CodeCipher. One key reason is that they often necessitate complex modifications to both client- and server-side model architectures and training methodologies to enable privacy-preserving communication. For example, homomorphic encryption requires substantial changes to the self-attention architecture, which differs significantly from our technical scope.

In contrast, CodeCipher offers a lightweight, practical solution that only involves minimal data transformations on the client side without altering the model itself or requiring server modifications. This simplicity makes CodeCipher a more accessible option for obfuscation in many application settings. Following your advice, we have revised the related work section to include a more comprehensive differentiation of our work.

Question: can the proposed idea be applicable and scalable for state-of-the-art code generation models? How does the proposed idea work on state-of-the-art code generation models?

In Section 5.6, we evaluate the transferability of our approach, wherein we feed the obfuscated code by our method into other models, including the state-of-the-art models such as DeepSeekCoder and CodeLlama. Results show that our approach can be applicable and scalable for state-of-the-art code generation models.