CodeCipher: Learning To Obfuscate Source Code Against LLMs

## Abstract

Abstract While code large language models have made significant strides in AI-assisted coding tasks, there are growing concerns about privacy challenges. The user code is transparent to the cloud LLM service provider, inducing risks of unauthorized training, reading, and execution of sensitive code. Such fear of data leaking prevents developers from submitting their code to LLMs.
In this paper, we propose CodeCipher, a novel method that perturbs privacy from code while preserving the original response from LLMs. CodeCipher transforms the LLM’s embedding matrix so that each row corresponds to a different word in the original matrix, forming a token-to-token confusion mapping for obfuscating source code. The new embedding matrix is optimized through minimizing the task-specific loss function. To tackle the challenge from the discrete and sparse nature of word vector spaces, CodeCipher adopts a discrete optimization strategy that aligns the updated vector to the nearest valid token in the vocabulary before each gradient update.
We demonstrate the effectiveness of our approach on three AI-assisted coding tasks including code completion, summarization, and translation. Results show that our model successfully confuses the source code while preserving the original LLM’s performance. 1 1 1 Code and data available at https://anonymous.4open.science/r/CodeCipher_final-9D7E/

## 1 Introduction

The rise of code large language models (code LLMs), including CodeLlama (Rozière et al., ) and DeepSeek-Coder (Guo et al., ), has ushered in a new phase for the research on code intelligence. These code language models have made significant strides in improving the quality of code generation and have achieved high pass rates across multiple benchmark datasets such as HumanEval (Chen et al., ), and MBPP (Austin et al., ). With the increasing reliance on these models for AI-assisted coding tasks, there is a growing need to leverage remote LLM cloud services, which enable broader scalability and enhance the capabilities of these models by offloading computations to powerful cloud infrastructure.

LLM cloud services allow users to perform AI coding tasks without the need for computational infrastructure.
However, providing code LLMs as services raises significant privacy concerns, which limit their practical applications (Yao et al., ; Yan et al., ). As users’ code is transparent to these remote systems, there is a risk of exposing and misusing sensitive or proprietary information. Such fear of data leaking prevents many developers from submitting their code directly to LLMs. Therefore, privacy-preserving mechanisms in LLM deployment are required to ensure user trust and further expand code LLM usage.

Code obfuscation techniques have been common solutions to defend code against unauthorized access, which disguises elements of a piece of code while maintaining its output. Existing techniques adopt rule-based perturbations, such as renaming variables with semantically meaningless symbols (Jain et al., ) and injecting dead code (Chakraborty et al., ), to obscure human comprehension of code semantics. However, since LLMs also rely on meaningful symbols and other human-readable code structures (Ding et al., ; Rodeghero et al., ). Brute code obfuscation could significantly degrade the capability of LLMs and thus are inapplicable in practice.

In this work, we propose CodeCipher, a novel learning-based code obfuscation technique tailored for LLMs. CodeCipher safeguards code from unauthorized training, reading, compiling, and execution, without sacrificing LLM service quality. The core idea behind CodeCipher is to transform the LLM’s embedding matrix so that each row corresponds to a different word in the original matrix.
This process creates a token-to-token confusion mapping, which the system uses to obfuscate tokens when encountering new code snippets.

The new embedding matrix is optimized by minimizing the task-specific loss.
Due to the discrete and sparse nature of word embedding space, straightforward gradient descent can not pinpoint the embedding of a valid token. To tackle this problem, we adopt a discrete optimization strategy: at each iteration, the algorithm updates the perturbation vector, projects it onto the nearest valid token in the embedding space, and recalculates gradients based on the new projection.

The efficacy of our approach was rigorously assessed across three AI-assisted coding tasks: code completion, code summarization, and code translation. Results revealed that our method surpassed a range of conventional obfuscation methods in terms of both the level of confusion and the preservation of performance for downstream tasks. These findings affirm the practicability of our approach for enhancing privacy and security in LLMs.

## 2 Related Work

Privacy Protection for Large Language Models
While LLMs have brought tremendous value to many fields, they have also sparked deep concerns among users regarding data privacy and security (Nasr et al., ).
Numerous studies have been conducted on model security in previous research (Fan et al., ; Yan et al., ; Lin et al., ).
On the model side, federated learning and differential privacy are commonly used to protect privacy leakage during model training. Homomorphic encryption is widely used during model inference (Lin et al., ). On the user side, privacy protection focuses on marking or transforming user’s data. Watermarking, the most common technology, embeds hidden markers in data to detect its use in model training (Sun et al., ).
Another method is data transformation, which makes data unintelligible or unusable even if leaked. Traditionally, this involves rule-based removal of sensitive information (Machanavajjhala et al., ). More recently, LLMs have been leveraged to obscure sensitive data (Song et al., ). Users can construct privacy-preserving prompts, mixing real and fake inputs to prevent the server from identifying the true prompt (Utpala et al., ). For example, TextObfuscator (Zhou et al., ) obfuscates input sentences at the embedding level, replacing tokens with semantically equivalent words to maintain model performance.

Our approach also focuses on data transformation but is specifically tailored for code scenarios. Unlike natural language, it is not just strings or prompts that need protection—the entire algorithm must be safeguarded. Rule-based removal of sensitive information is insufficient, and simply replacing variable names with synonyms, as done by TextObfuscator, leaves the code largely understandable, reducing the effectiveness of obfuscation.

Privacy Protection for Code LLMs
Data leakage is also a concern in large language models for code (LLM4Code), which are often trained on open-source code repositories that may contain sensitive information. Studies (Feng et al., ; Huang et al., ; Al-Kaswan et al., ) have shown that specific prompts can extract private data like passwords and server keys from large models. Numerous solutions have been proposed to address this issue, such as adding watermarks to detect unauthorized use of training data (Sun et al., ), training models on desensitized data (though its impact on performance is still unknown) (Yang et al., ), and distilling models to smaller, more secure local models (Shi et al., ). However, ensuring the safe and private use of LLMs, especially for code generation, remains a critical challenge that requires further research.

Code Obfuscation
Code obfuscation aims to reduce the readability of source code through code transformation, reorganization, and modification (Behera & Bhaskari, ). Commonly used code obfuscation techniques include identifiers renaming (Jain et al., ), control flow flattening (László & Kiss, ), dead code injection (Chakraborty et al., ), self-modifying code (Giffin et al., ), and property encryption (Pandey & Rouselakis, ).
The applications of code obfuscation are twofold. On the one hand, it makes the logic and structure of code harder to understand, complicating static and dynamic code analysis, and preventing attackers from assessing sensitive information or altering functionality. As a result, it is widely applied in software security to prevent reverse engineering, code theft, and vulnerability exploitation. On the other hand, code obfuscation can be viewed as introducing disturbance noise to the code data, and thus can be used as adversarial training samples to enhance the robustness of code language models (Jain et al., ; Zhou et al., ).

While code obfuscation has been widely used for code security, its applicability to LLMs remains largely unexplored. Traditional rule-based methods achieve the goal of obfuscation, but they are not specifically tailored to LLMs. As a consequence, the code representations learned by LLMs can be altered, leading to significant performance degradation.

## 3 Problem Statement

Given a transformer-based code language model $P_{\Phi}(y|x)$ parameterized by $\Phi$ and a downstream task (e.g., code summarization) represented by a parallel dataset: $\mathcal{T}=\{(x^{(i)},y^{(i)})\}$ $i=1,..,N$, where $x$ and $y$ are input and target sequences of tokens.
For each input source code $x=\{w_{1},...,w_{n}\}$, our goal is to transform it into obfuscated code $x^{\prime}=\{w^{\prime}_{1},...,w^{\prime}_{n}\}$ which differs from $x$ in lexicons while retaining task-specific performance (e.g., code completion) when processed by an LLM, formally:

$$ $\min_{x^{\prime}=g(x)}||s(P_{\Phi}(x^{\prime}),y)-s(P_{\Phi}(x),y)||$ (1) $$

where $g:\mathcal{V}$$\rightarrow$$\mathcal{V}$ denotes a confusion function that maps any token in the vocabulary into an obfuscated one; $s:Y$$\times$$Y$$\rightarrow$$R$ denotes a task-specific scoring function such as Pass@K in the code completion task.

## 4 CodeCipher: Learning to Obfuscate Source Code

Figure: Figure 1: The overall framework of CodeCipher. It freezes the entire LLM and merely optimizes a perturbed embedding matrix $\mathbf{E}^{\prime}$ for the embedding layer.
Refer to caption: x1.png

In this paper, we propose a learning-based method to find the optimal confuse function $g(\cdot)$ between code tokens. Unlike previous rule-based methods, we move our focus to the embeddings of code tokens. The core idea behind CodeCipher is to transform the LLM’s embedding matrix so that each row corresponds to a different word in the original matrix. The transformation establishes a token-to-token confusion mapping, which the system uses to obfuscate tokens when encountering new code snippets.
Our method consists of three stages as illustrated in Figure 1: (i) transforms the LLM’s embedding matrix to a permutation, establishing a token-to-token confusion mapping; (ii) optimizes the transformation of embedding by minimizing the task-specific loss function; addresses the intricacies involved in the discretization process, particularly the alignment of continuous word vectors to valid tokens; and (iii) obfuscates code using the trained model. A more comprehensive description of the algorithm can be found in Appendix A.

### 4.1 Embedding Permutation

For any code snippet $x=(w_{1},...,w_{n})$, the embedding layer of an LLM converts the tokens into a sequence of continuous vectors:

$$ $\mathbf{e}_{1},...,\mathbf{e}_{T}=\mathbf{E}(w_{1}),...,\mathbf{E}(w_{T})$ (2) $$

where $\mathbf{E}\in\mathbf{R}^{|\mathcal{V}|\times d}$ represents the embedding matrix in the LLM’s embedding layer, $|\mathcal{V}|$ denotes the vocabulary size, and $d$ represents the dimension of word embeddings.

Figure: Figure 2: Illustration of Embedding Perturbation. The occurrence of token def can be reasonably substituted with ret through embedding transition, thereby obfuscating source code with these tokens.
Refer to caption: x2.png

To perturb the code tokens, we create a learnable confusion mapping within their word embedding space, as illustrated in Figure 2.
Specifically, given the original embedding matrix $\mathbf{E}$, we introduce a trainable embedding matrix $\mathbf{E}^{\prime}$$\in$$\mathbf{R}^{|\mathcal{V}|\times d}$. The matrix $\mathbf{E}^{\prime}$ is a permutation of $\mathbf{E}$, meaning that $\forall\mathbf{e}^{\prime}\in\mathbf{E}^{\prime}$, $\mathbf{e}^{\prime}\in\mathbf{E}$. This ensures that every embedding in $\mathbf{E}^{\prime}$ can be mapped back to its corresponding token in the vocabulary.
$\mathbf{E}$ and $\mathbf{E}^{\prime}$ establishes a confusion mapping: each row $\mathbf{e}_{i}$ $\in$ $\mathbf{E}^{\prime}$ represents the perturbed word vector corresponding to the original word vector in the same row of $\mathbf{E}$.

With the learnable confusion mapping, we design the obfuscation process as follows: for each token $w$ in the input code, we obtain its original embedding $\mathbf{e}=\mathbf{E}(w)$ using the embedding layer of the LLM. Then, we transform the embedding to $\mathbf{e}^{\prime}=\mathbf{e}+\Delta\mathbf{e}$, where $\Delta\mathbf{e}$ denotes the perturbation of $\mathbf{e}$ in the corresponding row in $\mathbf{E}$.

The perturbed vector $\mathbf{e}^{\prime}$ is then decoded to the nearest token in the vocabulary through a lookup function
$w^{\prime}=\textsc{Dec}_{\mathcal{V}}(\mathbf{e}^{\prime})$,
designated as the perturbed token.
With this perturbation process, the entire sequence can be obfuscated as:

$$ $x^{\prime}=(w^{\prime}_{1},...,w^{\prime}_{n})=\textsc{Dec}_{\mathcal{V}}( \mathbf{e}^{\prime}_{1},...,\mathbf{e}^{\prime}_{n})$ (3) $$

### 4.2 Training

Our training objective is to find an optimal $\mathbf{E}^{\prime}$ that minimizes the task-specific loss function $\mathcal{L}_{\mathrm{task}}$ when applied to the obfuscated code.
A straightforward idea is to optimize $\mathcal{L}_{\mathrm{task}}$ using gradient descent.
For a code input, we update the embedding $\mathbf{e}$ for each token as follows:

$$ $\mathbf{e}^{\prime}=\mathbf{e}-\eta\nabla_{\mathbf{e}}\mathcal{L}_{task}(x^{ \prime})$ (4) $$

where $\eta$ represents the learning rate, $\nabla_{\mathbf{e}}\mathcal{L}$ denotes the gradient of the loss function w.r.t. the current embedding $\mathbf{e}$.

However, direct gradient descent encounters the intrinsic limitation in the word embedding space.
Code tokens reside on a sparse, discrete manifold in the embedding space. As illustrated in Figure 3, a single gradient computation is inadequate for pinpointing the exact position of a token in the embedding space, thereby hindering precise vector manipulation.

Figure: Figure 3: Illustration of discrete gradient search. Standard gradient descent perturbs token A along the gradient direction, often leading to suboptimal perturbations within the decoding boundary. Our discrete gradient search mitigates this issue by introducing mini-steps along valid tokens, ensuring more meaningful perturbations.
Refer to caption: x3.png

Inspired from Yuan et al. (), we develop a discrete gradient search algorithm. During each gradient update, the algorithm aligns the updated vector with semantically meaningful tokens, ensuring transitions occur between valid tokens in the original embedding space. More specifically, the algorithm performs gradient update in Equation 4 along a finer-grained trajectory $v_{1},...,v_{t}$. At each mini step, the embedding vector is incrementally perturbed and then projected onto the nearest valid token vector in the vocabulary. The gradient is then recalculated based on this new token, guiding further refinements in the following iterations. Formally,

$$ $v_{t+1}=\Pi_{\mathcal{V}}(v_{t}-\eta\nabla_{v_{t}}\mathcal{L}_{\text{task}}(v_ {t}))$ (5) $$

where ${v}_{t}$ denotes the token vector at the $t^{th}$ step; $\Pi_{\mathcal{V}}$ denotes the projection operation which aligns the updated vector onto the nearest word’s vector within the vocabulary space $\mathcal{V}$; $\eta$ represents the learning rate; $\nabla_{{v}_{t}}\mathcal{L}({v}_{t})$ denotes the gradient of the loss function $\mathcal{L}$ with respect to ${v}_{t}$.

This iterative process continues for a certain number of steps, at which point we select the vector with the lowest task loss and perform the final projection, designating it as the perturbed token.

To prevent over-obfuscation, we limit the training process to a maximum of $N$ iterations. The training early stops if the perplexity deviation of a code sample reaches a predefined threshold $\delta$. We define $\delta$ as a linear function that increases with each step $i$, namely, $\delta=\alpha\cdot i+\beta$, where $\beta$ indicates the initial threshold and $\alpha$ controls the rate at which the threshold increases throughout the training process.

### 4.3 Code Obfuscation

Once the new embedding matrix is trained, it establishes a confusion function that maps each token in the vocabulary to its obfuscated counterpart. For any new input code snippet, CodeCipher converts the tokens by referencing this mapping table, producing an obfuscated version of the code. The obfuscated code can then be sent to a cloud LLM with the same specifications as the one used for training.

## 5 Experiments

### 5.1 Common Setup

As a proof of concept, we build and evaluate CodeCipher with CodeLlama-7B (Rozière et al., ), a representative white-box code LLM. We will show in Section 5.6 that the obfuscated code generated by CodeLlama-7B can be transferred to a wide range of model specifications including different sizes and black-box LLMs. More details about the hyperparameter setting can be found in Table 4 in the Appendix.

We train and evaluate our obfuscation model on three AI-assisted coding tasks.

Code Completion.
A task that completes the subsequent code given users’ partial code.
We train our model on the MultiPL-E dataset (the Python subset from the Leetcode section) (Cassano et al., ), which comprises 446 code snippets. We test the model on the HumanEval benchmark (Chen et al., ) which contains 164 Python programming problems. For each problem, we obfuscate the first half of the code, provide it to the LLM, and ask it to complete the remaining half. As the obfuscated half code might prevent the final output from being compiled, we guide the model to re-generate the entire code from head using the prompt in Appendix B.
Code Summarization.
A task that provides a succinct natural language summary for a given code fragment (Sridhara et al., ). We train and test our obfuscation model on the CodeSearchNet benchmark (Husain et al., ) using the prompt in Appendix B.
Code Translation.
A task that translates source code written in one language to another (Pan et al., ). We train our model on the Java-to-Python subset of XLCoST (Zhu et al., ) and test it on the Java-to-Python subset of HumanEval-X (Zheng et al., ).
We use google-java-format(^2^22https://github.com/google/google-java-format) to ensure consistent line breaks and indentation across the code, aligning it with the formatting of the test dataset. This process resulted in a total of 2,374 data pairs. In the prompt in Appendix B, we explicitly instructed the model to avoid class-based code structures.

Baselines.
We compare CodeCipher with both rule-based and LLM-based code obfuscation approaches.
1) Random perturbation, which randomly replaces a portion of tokens in the code with non-semantic symbols.
2) Identifier renaming, which replaces variable and function names with non-semantic symbols (Chakraborty et al., ). It is implemented from Spoon (Pawlak et al., ).
3) Dead branch injection, which inserts code blocks that never execute (e.g., while(false)). It is implemented from NatGen (Chakraborty et al., ).
4) Remove symbols, which removes formatting and syntactic symbols such as whitespace and parentheses from the code. 5) Prompting LLMs, which prompts GPT-4o directly to obfuscate code using the prompt in Appendix B.
6) Obfuscation + Inform, which obfuscates identifiers in the source code and explicitly informs the LLM about this obfuscation in the prompt (e.g., “Generate a docstring for the code where the identifiers are obfuscated.”). Previous work has shown that LLMs can better handle obfuscated code when they are made aware of the obfuscation upfront (Yan & Li, ).

### 5.2 Performance Preservation

We measure the efficacy of CodeCipher based on two competitive objectives: task performance (i.e., Pass@k (Chen et al., ), k=1,10,100) and obfuscation degree (including perplexity measured by the LLM and edit distance to the original code).
We start by presenting the efficacy in performance preservation, in other words, how the code obfuscated by CodeCipher maintains the performance of downstream tasks.
Table 1 shows the results of various methods in the code completion task(^3^33We show results of other tasks in Appendix). To ensure a fair comparison, we maintained a consistent level of obfuscation across all approaches and compared their accuracy on downstream tasks. The results indicate that CodeCipher effectively confuses source code without substantially compromising the original model’s performance. For instance, “identifier renaming” and “random” perturbation drop Pass@1 from 50.60% to 42.68% and 40.24%, respectively, whereas our approach only reduces it to 47.56%.
The results demonstrate that our method achieves a superior balance between code obfuscation and model performance compared to the baselines, making it more practical in real-world applications.

**Table 1: Results of Performance Preservation on the Code Completion Task.**
| Method | Task-specific Performance |  | Obfucation Degree |  |  |  |
| --- | --- | --- | --- | --- | --- | --- |
| Pass@1(%) | Pass@10(%) | Pass@100(%) |  | PPL | Edit distance(%) |  |
| Origin | 50.60 | 68.68 | 79.27 |  | 3.56 | 0 |
| Random perturb | 40.24 | 61.34 | 75.00 |  | 5.95 | 3.86 |
| Rule-based Obfuscation |  |  |  |  |  |  |
| Identifier renaming | 42.68 | 61.15 | 75.00 |  | 5.64 | 8.74 |
| Dead branch injection | 39.63 | 60.23 | 71.95 |  | 4.71 | 9.21 |
| Remove symbols | 37.20 | 60.93 | 75.60 |  | 6.09 | 3.38 |
| LLM-based Obfuscation |  |  |  |  |  |  |
| Encipher with LLM prompting | 39.02 | 60.33 | 72.56 |  | 4.57 | 8.94 |
| Obfuscation + Inform | 41.46 | 57.67 | 70.12 |  | 5.64 | 8.74 |
| CodeCipher (ours) | 47.56 | 65.20 | 77.15 |  | 6.09 | 9.41 |

To comprehensively assess CodeCipher under different obfuscation levels. We vary the confusion degree of various methods and compare their task performance. We compare CodeCipher with random perturbation and identifier renaming, two strong baselines in the previous results. We control the obfuscation degree by varying the proportion of perturbed tokens in the entire code. The results are presented in Figure 4. Across all tasks and metrics, our method exhibits consistent strength over baselines under different obfuscation levels. The results suggest that our method strikes a more effective balance between code obfuscation and maintaining performance on downstream tasks.

Figure: (a) Pass@1 under different edit distances for code completion
Refer to caption: x4.png

### 5.3 Privacy Protection

Having established that CodeCipher effectively preserves the task performance, we now assess its efficacy in privacy protection, the primary objective of code obfuscation. We aim to determine whether the obfuscation can obscure the information, and prevent the code from compiling, execution, and model training.

Setup:
We conduct experiments on the CodeSearchNet dataset which was collected from real-world projects in GitHub and may involve more private information. The raw dataset consists of 2 million samples. We randomly sampled 200 code samples and obfuscate them using various methods.
We adopt three metrics: 1) Compilation Rate, the proportion of compilable code among all obfuscated code,
2) Deobfuscation Rate, which measures the proportion of obfuscated code that can be deobfuscated by LLMs.
We compute this proportion using the recall score, i.e., proportion of tokens in the original code that also appear in the deobfuscated code.
3) Deobfuscation Distance, refers to the edit distance that the deobfuacated code deviate from the original code. For ease of comparison, we also compute the edit distances for the initially obfuscated code.
We deobfuscate the obfuscated code by prompting CodeLlama-7b-Instruct. The prompt used for deobfuscation is provided in Appendix B.

Results:
As can be seen from Table 2, CodeCipher disrupts the compilability of all obfuscated code, thereby preventing its reuse.
Particularly, the obfuscated code is challenging for LLMs to restore, with only 34% of tokens successfully restored. The same phenomenon can be seen from the deobfuscation distance.
For all methods, the edit distances of the deobfuscated code are greater than those of the initially obfuscated code, probably because the deobfuscation process introduces additional modifications to the code. Notably, the code obfuscated by CodeCipher exhibits the largest edit distance from the original code compared to other methods. The results suggest that our approach successfully obfuscates code and enhances privacy protection.

**Table 2: Performance on Privacy Protection on the CodeSearchNet Benchmark**
| Method | Compilation | Deobfuscation | Deobfuscation Distance (%) |  |
| --- | --- | --- | --- | --- |
| Rate (%) | Rate (%) | Before deobfus. | After deobfus. |  |
| Random | 6 | 35 | 10.23 | 39.89 |
| Identifier renaming | 76 | 38 | 10.27 | 39.09 |
| Dead branch injection | 96 | 35 | 10.25 | 37.77 |
| Remove symbols | 0 | 36 | 10.34 | 38.91 |
| LLM prompting | 84 | 32 | 10.39 | 39.44 |
| Obfuscation+Inform | 76 | 38 | 10.27 | 39.09 |
| CodeCipher (ours) | 0 | 34 | 10.42 | 43.18 |

### 5.4 Ablation Study

In this section, we conduct an ablation study on the discrete gradient search, a key step in our algorithm. We replace the discrete gradient search with traditional gradient descent, namely, a single gradient descent followed by decoding. We also vary the learning rates of gradient descent, a critical factor in our approach. As shown in Table 3, relying solely on a single-step gradient descent remarkably affects the code completion results. Traditional gradient descent results in suboptimal performance under all learning rates, indicating the efficacy of discrete gradient search in our method.

**Table 3: Ablation study of the discrete gradient search on the code completion task**
| Model | Pass@1(%) | Pass@10(%) | Pass@100(%) | PPL | Edit distance(%) |
| --- | --- | --- | --- | --- | --- |
| CodeCipher | 47.56 | 65.20 | 77.15 | 6.09 | 9.41 |
| - w/o discrete gradient search (lr=5$e$-3) | 39.63 | 57.25 | 67.68 | 5.07 | 2.70 |
| - w/o discrete gradient search (lr=1$e$-2) | 39.02 | 58.70 | 73.17 | 5.62 | 3.88 |
| - w/o discrete gradient search (lr=2$e$-2) | 43.90 | 63.52 | 77.04 | 5.66 | 4.42 |

### 5.5 Case Study

Figure 5 presents two practical examples by CodeCipher.
We observe that CodeCipher obfuscates sensitive information such as email address and passwords in the original code. The privacy contained therein is protected. Nonetheless, the model remains capable of understanding the code and generating correct but insensitive responses.
In summary, the results show that our approach effectively obfuscates the sensitive information to LLMs, while preserving its functional correctness.

Figure: (a) A case for code completion. We obfuscate the first half of the original code and ask the LLM to regenerate the entire code given the obfuscated part.
Refer to caption: x7.png

### 5.6 Transferability

Our approach is developed on white-box LLMs where the embedding layers and task gradients are accessible. In practice, there is always a need to apply the model in a new LLM, particularly black-box LLMs which provide only an API interface to users. We are unable to fine-tune these models based on their parameters. In this section, we aim to evaluate whether the obfuscated code generated by our method can still achieve good performance on other models.

Setup:
We used the obfuscated code generated by CodeLlama-7B with a perturbed embedding layer to evaluate the performance on other models. We conducted the experiments on the code completion task, which is one of the most common and general tasks. The representative models chosen for evaluation include StarCoder (Li et al., ), DeepSeek-Coder (Guo et al., ), and GPT-3.5-turbo (OpenAI, ), which have shown strong performance on AI coding tasks. We employed greedy decoding during inference, and the HumanEval dataset was used for testing.

Results:
As shown in Figure 6, our method obtains relatively stable Pass@1 scores in each model through different obfuscating models, and in most cases, the deviation from original scores is within 10%. In particular, in the black-box LLM GPT-3.5-turbo, the obfuscated codes outperform its original results, showing that our method remains high efficacy on other models. We hypothesize that our method learns common token mappings that are portable across LLMs. Overall, the results suggest that our method is not tied to any specific version of the LLM; instead, it is a general approach that works independently of the LLM version used. In practical applications, we can develop our method on a local proxy model such as the open-sourced CodeLlama-7B and apply the learned token confusion mapping to other cloud LLM servers.

Figure: Figure 6: Results of the transferability test. The vertical axis represents different obfuscation models while the horizontal axis represents different test models. In each cell, the first line indicates the Pass@1 value achieved by the test model under the obfuscation model, and the value in parentheses shows the difference compared to the Pass@1 result without any obfuscation.
Refer to caption: x9.png

## 6 Conclusion

In this paper, we propose CodeCipher, a novel code obfuscation method tailored for LLMs. CodeCipher learns a transformation on the word embedding space, establishing a confusion mapping between code tokens that can be used for code obfuscation. The embedding transformation is optimized by minimizing the task-specific loss. A discrete gradient search algorithm is designed to tackle the sparsity challenge in the embedding space. Experiments on three AI-assisted coding tasks demonstrate that our method achieves a superior balance between code obfuscation and model performance compared to traditional rule-based methods.

## Appendix A The Algorithm

The detailed algorithm for our approach is presented in Algorithm 1

Figure: Algorithm 1 CodeCipher Algorithm

## Appendix B Prompt Templates

## Appendix C Hyperparameter Setting

The hyperparameters for the three tasks are provided in Table 4.

**Table 4: Hyperparameter Setting.**
| Hyperparameter | Code Completion | Code Summarization | Code Translation |
| --- | --- | --- | --- |
| Learning rate ($\eta$) | 0.002 | 0.002 | 0.002 |
| Max sample number (N) | 32 | 32 | 32 |
| $\alpha$ | 1.5 | 1.5 | 2.0 |
| $\beta$ | $\frac{1}{90}$ | $\frac{1}{20}$ | $\frac{1}{90}$ |
| Maximum iterations per session (T) | 10 | 10 | 10 |

## Appendix D Results on other tasks

Tables 5 and 6 show the results on the code summarization and translation tasks, respectively. We observe the same trend as in the code completion task: CodeCipher increases the perplexity and edit distance to the original code while achieving higher performance in the downstream tasks.
In code summarization, our approach attains a PPL that is 2.73 times higher than the original while keeping the reduction in BLEU scores within 2%.
In code translation, the PPL of our obfuscated code is three times higher than the original, yet the Pass@1 decreases by only 4%, and the Pass@100 score remains unchanged.
These results confirm the efficacy of our approach in code obfuscation.

**Table 5: Results on Code Summarization. We employ BLEU-4 (Papineni et al., ), ROUGE-L (Lin, ), and METEOR (Banerjee & Lavie, ) as the performance measures.**
| Method | Task-specific Performance |  | Obfucation Degree |  |  |  |
| --- | --- | --- | --- | --- | --- | --- |
| BLEU | ROUGE-L | METEOR |  | PPL | Edit distance(%) |  |
| Origin | 21.00 | 22.50 | 34.95 |  | 6.52 | 0 |
| Random perturb | 20.08 | 19.75 | 30.50 |  | 28.05 | 10.23 |
| Rule-based Obfuscation |  |  |  |  |  |  |
| Identifier renaming | 20.47 | 20.50 | 32.55 |  | 17.79 | 10.27 |
| Dead branch injection | 20.57 | 19.00 | 32.71 |  | 8.14 | 10.25 |
| Remove symbols | 20.00 | 21.25 | 32.86 |  | 18.02 | 10.34 |
| LLM based Obfuscation |  |  |  |  |  |  |
| Encipher with LLM prompting | 20.03 | 21.75 | 20.99 |  | 9.27 | 10.39 |
| Obfuscation + Inform | 19.80 | 20.50 | 30.95 |  | 17.79 | 10.27 |
| CodeCipher (ours) | 20.58 | 21.75 | 33.34 |  | 34.03 | 10.42 |

**Table 6: Results on Code Translation. We employ the widely used Pass@k (Chen et al., ) (k=1,10,100) as the performance measures.**
| Method | Task-specific Performance |  | Obfucation Degree |  |  |  |
| --- | --- | --- | --- | --- | --- | --- |
| Pass@1(%) | Pass@10(%) | Pass@100(%) |  | PPL | Edit distance(%) |  |
| Origin | 61.59 | 85.90 | 92.68 |  | 2.05 | 0 |
| Random perturb | 51.83 | 74.65 | 87.80 |  | 6.10 | 7.30 |
| Rule-based Obfuscation |  |  |  |  |  |  |
| Identifier renaming | 50.61 | 82.00 | 90.85 |  | 3.37 | 11.63 |
| Dead branch injection | 49.39 | 75.29 | 86.59 |  | 6.52 | 10.05 |
| Remove symbols | 47.50 | 76.88 | 85.76 |  | 6.25 | 3.79 |
| LLM-based Obfuscation |  |  |  |  |  |  |
| Encipher with LLM prompting | 57.31 | 82.55 | 92.07 |  | 3.09 | 10.36 |
| Obfuscation + inform | 44.51 | 76.91 | 91.46 |  | 3.37 | 11.63 |
| CodeCipher (ours) | 59.15 | 83.97 | 92.68 |  | 6.53 | 12.68 |

## Peer Reviews

confidence: 3
contribution: 3
initial_rating: 6
presentation: 3
questions: 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?

Jingxuan He, Martin Vechev. Large Language Models for Code: Security Hardening and Adversarial Testing. 2023. In CCS. https://arxiv.org/abs/2302.05319.

Erik Nijkamp, Bo Pang, Hiroaki Hayashi, Lifu Tu, Huan Wang, Yingbo Zhou, Silvio Savarese, and Caiming Xiong. 2023. CodeGen: An Open Large Language Model for Code with Multi-Turn Program Synthesis. In ICLR. https://arxiv.org/
abs/2203.13474

Daniel Fried, Armen Aghajanyan, Jessy Lin, Sida Wang, Eric Wallace, Freda Shi, Ruiqi Zhong, Wen-tau Yih, Luke Zettlemoyer, and Mike Lewis. 2023. InCoder: A Generative Model for Code Infilling and Synthesis. In ICLR. https://arxiv.org/
abs/2204.05999

Loubna Ben Allal, Raymond Li, Denis Kocetkov, Chenghao Mou, Christopher Akiki, Carlos Muñoz Ferrandis, Niklas Muennighoff, Mayank Mishra, Alex Gu, Manan Dey, et al. 2023. SantaCoder: Don’t Reach for the Stars! CoRR
abs/2301.03988 (2023). https://arxiv.org/abs/2301.03988
soundness: 3
strengths: The idea of using a token-to-token confusion mapping is interesting.

The efficacy of the proposed approach was assessed across three AI-assisted coding tasks: code completion, code summarization, and code translation.

Results revealed that the proposed method surpassed a range of conventional obfuscation methods in terms of both the level of confusion and the preservation of performance for downstream tasks.
summary: The paper introduces CodeCipher, a new learning-based code obfuscation technique tailored for LLMs. 

CodeCipher safeguards code from unauthorized training, reading, compiling, and execution, without sacrificing LLM service quality. 

The main idea behind CodeCipher is to transform the LLM’s embedding matrix so that each row corresponds to a different word in the original matrix. This process creates a token-to-token confusion mapping, which the system uses to obfuscate tokens when encountering new code snippets.
weaknesses: Only rule-based baselines are compared.

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):

W.-j. Lu, Z. Huang, Z. Gu, J. Li, J. Liu, K. Ren, C. Hong, T. Wei, and W. Chen, “Bumblebee: Secure two-party inference framework for large transformers,” Cryptology ePrint Archive, 2023.

I. Zimerman, M. Baruch, N. Drucker, G. Ezov, O. Soceanu, and L. Wolf, “Converting transformers to polynomial form for secure inference over homomorphic encryption,” arXiv preprint arXiv:2311.08610, 2023.

X. Liu and Z. Liu, “Llms can understand encrypted prompt: Towards privacy-computing friendly transformers,” arXiv preprint arXiv:2305.18396, 2023.

Detection-based Approaches (e.g., Direct Detection, Contextual Inference Detection):

S. Kim, S. Yun, H. Lee, M. Gubri, S. Yoon, and S. J. Oh, “Propile: Probing privacy leakage in large language models,” 2023.
N. Mireshghallah, H. Kim, X. Zhou, Y. Tsvetkov, M. Sap, R. Shokri, and Y. Choi, “Can llms keep a secret? testing privacy implications of language models via contextual integrity theory,” 2023.

Hardware-based Approaches (e.g., Data Locality, Confidential Computing with Trusted Execution Environment (TEE)):

Y. Wang, Y. Lin, X. Zeng, and G. Zhang, “Privatelora for efficient privacy preserving llm,” arXiv preprint arXiv:2311.14030, 2023.

T. South, G. Zuskind, R. Mahari, and T. Hardjono, “Secure community transformers: Private pooled data for llms.” 2023.

W. Huang, Y. Wang, A. Cheng, A. Zhou, C. Yu, and L. Wang, “A fast, performant, secure distributed training framework for large language model,” arXiv preprint arXiv:2401.09796, 2024.

---

confidence: 4
contribution: 2
initial_rating: 3
presentation: 2
questions: **Questions:**

- As the line 100 described, the application of code obfuscation are twofold. One is for privacy protection, and another one is for the robustness of code language models. Since the method is not aimed at improving the robustness of the code language model, why not use privacy protection metrics(i.e. TopK, which is a token-level metric that measures the percentage of correct words in the attacker's top k predictions)? You use the obfucation degree to measure the performance. How can you prove the effectiveness of privacy protection?
- In line 272, you compared  with an identifier renaming approach(Chakraborty et al., 2022). This approach is about naturalizing source code can enhance the performance of generation on three tasks.   Why do you use this approach which is unrelated with code obfuscation? And why it's performance decrease in your experiments? TextObfuscator is a SOTA approach for preserving inference privacy. Why don't you compare with it?

- 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?

**Minor comments:**

- In Table 1, the "Origin" method is not defined.
- In Figure 6, missing the references of other LLMs(i.e. deepseekcoder)
soundness: 2
strengths: **Strengths:**

- The paper proposed a novel approach to obfuscate the code.
- The proposed approach can preserve better performance than other code obfuscation methods.
summary: **Summary:**

This paper studies the way of obfuscating source code for LLMs.  The proposed approach transforms the LLM’s embedding matrix so that each row corresponds to a different word in the original matrix, forming a token-to-token confusion mapping for obfuscating source code. The paper introduce a discrete optimization strategy that aligns the updated vector to the nearest valid token in the vocabulary before each gradient update.
weaknesses: **Weaknesses:**

- Missing important metrics and SOTA baselines for privacy protection
- Missing extensive experiments on the discrete gradient search

---

confidence: 3
contribution: 4
initial_rating: 8
presentation: 3
questions: 1. Discuss how to obtain LLM's embeddings if LLMs are closed-source.
2. Clarify the motivation of CodeCipher when LLMs are open-source. 
3. Discuss adaptive attacks.
soundness: 4
strengths: This paper addresses the important research problem of preserving code privacy when submitting code to LLMs. It introduces an interesting approach to achieve this by transforming the LLM’s embedding matrix into a new one, creating a token-to-token confusion mapping that obfuscates the source code.

The effectiveness of the proposed approach is demonstrated through three code analysis tasks.
summary: This paper proposes CodeCipher, which perturbs privacy from code while preserving the original response from LLMs. CodeCipher transforms the LLM’s embedding matrix so that each row corresponds to a different word in the original matrix, forming a token-to-token confusion mapping for obfuscating source code. The new embedding matrix is optimized through minimizing the task-specific loss function. CodeCipher is evaluated on three AI-assisted coding tasks including code completion, summarization, and translation. Results show that CodeCipher successfully confuses the source code while preserving the original LLM’s performance.
weaknesses: The feasibility of CodeCipher depends on access to the LLM's embeddings, which raises some concerns. First, if the LLM is closed-source, are the embeddings accessible? Could the authors clarify this? Second, 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.

Second, 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?

---

confidence: 3
contribution: 2
initial_rating: 5
presentation: 2
questions: - 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?
- Will performance be affected by the training epochs?  How to get the best hyper-parameters?
soundness: 2
strengths: - The research problem is interesting. With the wide use of LLMs, the security problem is essential.
- The evaluation is from different aspects, which is good.
summary: This paper introduces CodeCipher, a method designed to transform input code sequences into an obfuscated format to mitigate the risk of data leakage when using cloud-based large language models (LLMs). Specifically, the approach modifies the embedding matrix of the LLM, ensuring that each row corresponds to a different word for the purpose of obfuscation. To optimize this transformation, a discrete gradient search algorithm is employed, leveraging the vector representation of the nearest word. Extensive experiments, including performance preservation, privacy protection, ablation studies, and transferability assessments, validate the effectiveness of the proposed technique.
weaknesses: - The performance of the obfuscated models has an evident decrease compared with the original models across three tasks in Section 5.2. 
- 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 prompt used is casual and does not have a rigorous design.
- 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.

Meta-review: This submission received mixed reviews and sits at the boundary. Reviewers Co3V and 7KDk raised concerns regarding the comparison with baselines and transferability analysis. While the authors provided a rebuttal addressing these points, their arguments lacked sufficient detail, leaving some concerns unresolved. Additionally, Reviewer v6Ge, who provided the highest rating, did not actively advocate for acceptance during the discussion phase. Given the remaining concerns and the current positioning of this submission, I regretfully recommend rejection.

Decision: Reject