## 3 PPDT Classification Model
### Proposed Protocol
Similarly, \(\tilde{P}_{s}\) is also a polynomial with random coefficients except zero, which leads to the classification \(C_{out}\in\mathcal{C}\); that is, the coefficient corresponding to \(\tilde{V}_{s}\). Thus, the client can obtain the classification \(C_{out}\) without knowing the decision tree model \(\mathcal{T}\)
* \(M\)odel holder. The model holder only obtains the ciphertext of data \(X\) in Step 2, and IND-CPA security guarantees the privacy and security of the data. * Cloud server. The server honestly performs homomorphic operations for the system but is curious about the data provided by the client and the model holder. In Step 3, it receives only encrypted inputs using an SHE scheme that satisfies IND-CPA security, ensuring the confidentiality of both user data and model parameters. Even if the server obtains the comparison result vector \(B=[1,b_{1},\dots,b_{m}]\) from \(d\) sent in Step 5, it cannot recover the original data \(X\) nor infer meaningful information about the decision tree \(\mathcal{T}\) (threshold \(t\), path matrix \(P\), and classification result \(V\)). This is due not only to encryption but also to randomization of \(P\) using noise terms \(r_{k}\) and \(r_{k}^{\prime}\) in Step 3, which prevents linkage \(b_{i}(i=1,\dots,m)\) to specific nodes of \(\mathcal{T}\). Beyond technical guarantees, our approach also addresses ethical challenges inherent to PPML in cloud environments. Specifically, it supports secure inference while protecting sensitive user data, ensuring model confidentiality and the reducing risks of unauthorized access or data misuse. These safeguards are especially crucial in sensitive domains such as healthcare and finance, where balancing performance with privacy and intellectual property protection is key to responsible AI deployment. ## 4 Experiments

### Experimental Setup

We implemented the proposed PPDT protocol in C++ where the BFV method [21] in SEAL 3.3 [22] was used as the encryption library. In our implementation, the two comparison protocols were adopted: [PERSON] et al. 's efficiency-enhanced scheme (Protocol-1 in [17]) and [PERSON] et al. 's non-interactive private comparison (XCMP) [15]. The path cost calculation in Section 3.2 was implemented. Parameter Choice. First, to ensure that the above comparison methods can accurately decrypt the comparison results, the parameters \(n,q,p\), and \(\sigma\) of the two methods must respectively satisfy the following two inequality requirements. Second, they must be selected to meet the 128-bit security level. The following parameters were used to ensure that the proposed model worked accurately and had 128-bit security, which is the currently recommended security level in [23]:

* Efficiency-enhanced scheme [17] \(n=2048\), \(\log_{2}q=54\), \(p=40,961\), \(\sigma=3.2\). These satisfy the following inequality: \(q>8p^{2}\sigma^{4}n^{2}+4p\sigma n^{2/3}\). * XCMP [15] \(n=8192\), \(\log_{2}q=110\), \(p=8191\), \(\sigma=3.2\). These satisfy the following inequality: \(q>p^{3}\sigma^{2}n(\sigma n+1)^{2}+2p^{2}\sigma n(\sigma n+1)\). Note that \(\sigma=3.2\) is the default noise standard deviation used in Microsoft SEAL. The inequalities involving \(n,q,p\), and \(\sigma\) ensure the correctness of the corresponding comparison schemes. To support a maximum input bit length of \(\ell\), we chose \(n\) to satisfy the conditions from [PERSON] et al. [17] (i.e., \(\ell^{2}<n\)) and [PERSON] et al. [15] (i.e., \(\ell<\log_{2}n\)). Based on these constraints, the comparison protocols could handle 32-bit and 13-bit integers for [PERSON] et al. 's and [PERSON] et al. 's schemes, respectively. This implies that the efficiency-enhanced scheme [17] supports comparisons of larger integers than does XCMP [15], even with a relatively smaller \(n\). Given the selected \(n\), we chose \(q\) to ensure a 128-bit security level as recommended in [23] and then determined \(p\) such that it satisfied the necessary inequalities while remaining efficient to compute.