## 4 HeFUN: An iLHE-Based SNNI Framework
### Hefun
The core architecture of both HeFUN and prevailing HE-MPC hybrid frameworks encompasses two fundamental components: linear layer evaluation and the evaluation of the non-linear function, specifically the ReLU function. While the linear layer evaluation in these frameworks uniformly employs homomorphic encryption, the difference arises in the treatment of non-linear layer evaluation, namely, HeFUN implements HeRelU, whereas HE-MPC hybrid-based frameworks opt for either the GC or ABY protocol. This section delves into the communication complexity inherent in the ReLU evaluation within HeFUN as compared to that within existing HE-MPC hybrid frameworks (Section 5.1). HeReLU serves as a potential alternative to the GC/ABY protocols in HE-MPC hybrid-based frameworks, which reduces the communication complexity in SNNI. To compare HeFUN with LHE-based frameworks, we first compare the ciphertext refreshing component. In particular, we compare HeRefresh with the bootstrapping technique in the existing HE schemes (Section 5.2). Subsequently, we benchmark HeFUN alongside the prevalent LHE-based frameworks using a real-world dataset (Section 5.3). All experiments are run on a PC with a single Intel i9-13900K running at 5.80 GHz and 64 GB of RAM, running Ubuntu 22.04. Overall, the results presented below show that:

* Compared to current HE-MPC frameworks, HeFUN requires less communication rounds in evaluating the ReLU activation function (Section 5.1). * Compared to existing bootstrapping procedures, HeRefresh is much faster (Section 5.2). * Compared to current LHE-based frameworks, HeFUN outperforms the current LHE-based approach in terms of accuracy and inference time (Section 5.3). ### Comparison with Hybrid HE-MPC Approach

The current state-of-the-art HE-MPC hybrid-based approach is Gazelle [15]. Within Gazelle's framework, the server directly computes linear layers using HE operators of the LHE scheme in an offline phase. To evaluate non-linear layers, Gazelle leverages GC [19] to handle the bitwise operations required by ReLU (online phase). Finally, because each layer in an NN consists of alternating linear and non-linear layers, Gazelle also elaborates on an efficient method to switch between the two aforementioned primitives using a novel technique based on additive secret sharing. Gazelle's primary bottleneck is the cost of evaluating GC for the ReLU activation function [15; 69]. Compared to Gazelle, HeFUN can evaluate the ReLU function _solely_ based on an HE scheme, hence avoiding the expensive GC protocol that significantly reduces communication rounds and communication cost. We now compare the procedure of evaluating the ReLU function between HeFUN and Gazelle regarding communication rounds and communication cost. In both frameworks, i.e., HeFUN and Gazelle, after computing the linear layers homomorphically or receiving the client's encrypted input, the server holds an encrypted vector \([x]\). The objective for both HeFUN and Gazelle is to enable the server to obtain \([\text{ReLU}(x)]\). In Gazelle, the server and the client perform the following steps:

* _Conversion from HE to MPC:_ The server additively blinds \([x]\) with a random mask \(\mathbf{r_{1}}\) and sends the masked ciphertext \([x+\mathbf{r_{1}}]\) to the client. * _MPC circuit evaluation:_ The client decrypts \([x+\mathbf{r_{1}}]\). Then, the client (holds \(\mathbf{x}+\mathbf{r_{1}}\)) and the server (holds \(\mathbf{r_{1}}\) and a randomness \(\mathbf{r_{2}}\)) run GC to compute \(\text{ReLU}(\mathbf{x}+\mathbf{r_{1}}-\mathbf{r_{1}})+\mathbf{r_{2}}=\text{ReLU}(\mathbf{x})+\mathbf{r_{ 2}}\) without leaking \(\mathbf{x}+\mathbf{r_{1}}\) to the server and \(\mathbf{r_{1}}\) and \(\mathbf{r_{2}}\) to the client. Finally, the client sends \([\text{ReLU}(\mathbf{x})+\mathbf{r_{2}}]\) to the server. * _Conversion from MPC to HE:_ The server homomorphically subtracts \(\mathbf{r_{2}}\) and obtains \([\text{ReLU}(\mathbf{x})]\). The main bottleneck of Gazelle is step 2, i.e., the client and the server run GC, which requires a huge communication [15].