Optimized and Privacy-Preserving MAX/MIN Protocols for Large-Scale Data

Abstract

In the era of big data, data is key to the accuracy of analytical models, and cloud computing services are often used to efficiently process large volumes of data. However, outsourcing sensitive data to a third-party cloud service provider results in a loss of direct control over the data, raising serious security concerns. The target of this study is to propose highly efficient and privacy-preserving protocols that compute the maximum/minimum value in large-scale data. To achieve the improvements in efficiency, the proposed protocols reuse the intermediate results generated in independent subprotocols. Existing privacy-preserving maximum/minimum protocols are based on approximation methods that sacrifice accuracy or reveal information during execution. They use costly comparison operations that are proportional to the size of the input data and are not suitable for large-scale data applications. In contrast, the proposed protocols theoretically reduce the number of communication rounds by 25%, the communication size by 50%, and the computational cost by 42% compared to the existing protocols. Nevertheless, the accuracy and privacy are fully maintained. In order to demonstrate these efficiency improvements concretely, we conducted experiments and demonstrated that the proposed protocols reduce the communication volume by half and the execution time by 22%. Because the proposed protocols support parallel execution, their performance can be substantially enhanced in cloud environments that provide large-scale parallel processing resources. Even data owners with restricted computational capabilities can use the protocols without exposing their information. Under the secure version, even cloud servers executing the protocol learn nothing about the input data or the computation results.

1. Introduction

The advent of big data has rendered data analytics an indispensable tool for extracting knowledge from voluminous and intricate datasets. In various areas such as agriculture, finance, education, and healthcare, big data analytics plays a crucial role in uncovering latent patterns and correlations, thereby enabling more informed decision-making [1]. For example, it facilitates personalized medicine in healthcare and was used to track the spread of disease during the COVID-19 pandemic. The timely analysis of such large-scale data requires high-performance and scalable computing solutions to process large datasets [2]. It is very expensive to build such large-scale infrastructure individually. In contrast, cloud computing allows users to access scalable computing resources on demand and pay only for what they use. This approach leads to a substantial reduction in initial expenses. The features of the “pay-as-you-go” model and low initial investment make cloud computing particularly well-suited to big data analytics [3]. Even small and medium-sized enterprises can now conduct large-scale data analytics without requiring costly data centers.

However, when data is outsourced to an external cloud service provider, the data owners lose direct control over the data. If the provider is malicious, the data may be at risk of exposure [4]. Surveys consistently highlight security and privacy as the primary concerns regarding cloud adoption. For example, 2022 Cloud Computing TechReport noted that ‘confidentiality/security concerns’ were the main issue for 62% of cloud users [5]. In the case of sensitive personal information such as medical records or financial data, strong countermeasures must be in place to ensure privacy even if the cloud infrastructure is not trusted. To mitigate these risks, data owners commonly encrypt their data before uploading it to the cloud. However, conventional encryption schemes make it impossible to process the data without decryption. Furthermore, even if the data is encrypted, the cloud may still infer sensitive information by analyzing access patterns during computation.

There are two main techniques for privacy-preserving computation: multiparty computation (MPC) and homomorphic encryption (HE). HE is an encryption scheme that enables computations to be performed on encrypted data without decryption [6]. As a type of HE, partially homomorphic encryption (PHE) allows for an unlimited number of specific operations (e.g., addition), but it does not support arbitrary computation. MPC enables multiple parties to jointly compute a predefined function over their private inputs without disclosing these inputs to one another. Each party only receives the result and learns nothing about the other parties’ inputs. As MPC operates on secret shares, rather than encrypted data, our work adopts homomorphic encryption due to its suitability for our model. Specifically, we focus on additively homomorphic encryption, a type of PHE that supports the addition operation over ciphertexts. Since applying privacy-preserving techniques inevitably increases the computational overhead, it is important to develop the protocols that improve efficiency. In particular, it is imperative to minimize the number of computations and communications associated with large-scale parameters (e.g., the amount of data in large-scale data) to optimize overall protocol performance. Furthermore, in order to make full use of the parallel processing capabilities of clouds, protocols must be designed with parallelizability in mind.

Various computations have been proposed for privacy-preserving large-scale data analytics, such as maximum/minimum [7,8,9], comparison [10,11,12], and equality [13,14,15]. The privacy-preserving maximum/minimum ($ppMAX/ppMIN$) protocols are especially versatile and can be applied to many scenarios. For example, it is used in sealed-bid auctions [9], electronic voting [16], sensor networks, IoT monitoring [17], health care [18], and privacy-preserving machine learning [19]. In the privacy-preserving hierarchical clustering protocol of [20], the ppMAX/ppMIN protocols are executed as many as the amount of input data in each round, accounting for nearly half (45–50%) of the total execution time. Therefore, the development of an efficient ppMAX/ppMIN protocols for large-scale dataset can significantly benefit a wide range of applications and improve the efficiency of many other privacy-preserving protocols.

However, existing ppMAX/ppMIN protocols use approximation techniques to improve efficiency, which can lead to inaccurate results, or when the results are accurate, a significant amount of execution time is required. Futhermore, they reveal information during execution. For example, the protocols in [18,21] are based on the CKKS approximate homomorphic encryption scheme developed by Cheon et al. [22], and the works of [8,21] use approximation approaches to compute the maximum/minimum values privately. These protocols may result in inaccurate results. Although the authors of [7,8,17,23] propose efficient ppMAX/ppMIN protocols for IoT environments, these protocols expose a substantial amount of information. The protocols in [16,24] are not based on approximation techniques; however, the authors of [16] showed results for small-scale auctions and voting with only 10–30 inputs, and a sealed-bid auction of [24] with 1230 bidders takes approximately 30 min. The efficiency of these works is extremely low, and therefore, it is essential to develop more efficient ppMAX/ppMIN protocols. This study aims to design ppMAX/ppMIN protocols that significantly improve efficiency.

Table 1. Performance comparison of the existing and proposed protocols.

	Number of Input Data Points (n)	Execution Time (s)
[16]	4	5.38
[24]	1230	1800
[20]	7050	212
[Ours (Secure version)]	7050	166

presents a comparison of the execution times between the existing protocols and the proposed ones.

Contribution

This study enhances the efficiency of the prior protocols that compute the maximum or minimum value from an input dataset while preserving data privacy. The proposed protocols are called $ipMAX/ipMIN$ (Improved Privacy-Preserving Maximum/Minimum) protocols. The proposed ipMAX/ipMIN protocols are classified as a secure version and an efficient version. In comparison to the prior protocols [20], the secure version theoretically reduces the number of communication rounds by 25%, the communication volume by 50%, and the computational cost by 42%. For a detailed theoretical analysis, refer to the efficiency evaluation in Section 3. To validate this analysis, we implemented the proposed protocols and conducted experiments. The results demonstrated that the communication volume is reduced by half and the execution time by 22% compared to the prior protocols. Detailed experimental results are presented in Section 4. These efficiency gains are achieved by eliminating communications and computation whose volume is proportional to the amount of input data. This reduction makes the protocols more suitable for large-scale data applications. Despite these improvements, there is no loss of accuracy or privacy in the results of the secure version. The key idea is the integration of independently executed subprotocols in the prior protocols [20]. By reusing intermediate results generated by these subprotocols—particularly those proportional to the size of the input data—the proposed protocols minimize redundant computations and transmissions, enabling a protocol design that is well suited to large-scale data applications.

The proposed protocols not only improve efficiency but also retain all the advantages of existing protocols. They support the parallel execution for each data point since the computations for each data point are independent and can be processed simultaneously. In other words, since the round complexity, which is proportional to the execution time, is independent of the amount of input data, they are well suited to large-scale data environments. As the execution time decreases in proportion to the number of parallel computations (threads), it is expected that the performance of the proposed protocols is significantly enhanced in cloud environments that support massive parallelism. Prior ppMAX/ppMIN protocols [18,25,26] rely on comparatively costly comparison operations whose number scales with the input size; as a result, their execution time increases significantly as the dataset grows. In contrast, the proposed protocols use equality operations, which are substantially cheaper than comparison operations, and their cost scales with the bit length of each data value, rather than with the number of input data points. Because the bit length is typically much smaller than the dataset size in large-scale settings, the proposed protocols are particularly suitable for large-scale data analytics. In addition, when the maximum/minimum are multiple, the proposed protocols return all such values, thereby providing results that are both more complete and more precise.

Even if data owners have limited computational resources that are not capable of large-scale data computation, they can still participate in the proposed protocols and obtain results since all computations are performed exclusively by the cloud servers with no assistance from the data owners. That is, the role of the data owners is limited to submitting their input data to the cloud servers and receiving the final outputs; they are not involved in any additional communication or computation during the protocol execution. From a privacy standpoint, the secure version discloses no information about either the input data or the computation results. Because all values processed by the cloud are represented either as ciphertexts or as randomized data, and the executing cloud servers learn no meaningful information, the secure version preserves data privacy even when deployed in an external cloud environment. Major cloud service providers (e.g., Amazon, Google, and Microsoft) offer powerful computing resources capable of massive parallel processing, which enables the proposed protocols to efficiently compute the maximum/minimum value. Moreover, the protocols also protect data access patterns since all data are processed uniformly, regardless of the results. The efficient version provides higher efficiency than the secure version because it terminates immediately when the maximum/minimum is determined. In other words, the efficient version gains efficiency by exposing information. Therefore, the secure version and the efficient version should be chosen according to the application environment, considering the trade-off between security and efficiency. The main contributions of this work are summarized as follows:

• We design efficient and privacy-preserving protocols that compute the exact Maximum/minimum value over large-scale data under a dual non-colluding cloud server model.
• We present an explicit privacy–efficiency trade-off through two variants: a secure version and an efficient version. The checking bit set in the efficient version enables multi-level choices between security and efficiency).
• Through a protocol-level fusion redesign, we structurally eliminate redundant costs that scale with the number of input data points, making the protocols well suited for large-scale data.
• While maintaining the privacy level and accuracy of the state-of-the-art scheme, the proposed protocol reduces communication rounds by 25%, the communication volume by 50%, the computation cost by 42%, and the execution time by 22%.

The remainder of this paper is organized as follows: Section 2 provides the background knowledge needed to understand this work, such as the system model, additively homomorphic encryption, efficiency evaluation measures, and the secure equality functionality used in the proposed protocols. Section 3 presents the proposed ipMAX/ipMIN protocols, along with their efficiency evaluation, and Section 4 demonstrates their efficiency with experiments. Section 5 reviews related works, and Section 6 concludes this work.

2. Preliminaries

This section introduces the background knowledge necessary to understand this paper. Section 2.1 describes the system model of the proposed protocols, and Section 2.2 explains their adversary model. Section 2.3 explains the additively homomorphic encryption scheme, and Section 2.4 explains the metrics used to evaluate the efficiency of the protocols. Section 2.5 provides a brief introduction to the secure equality functionality used in the proposed protocols and its existing implementations. Lastly, Section 2.6 briefly explains the prior protocol [20] that our work improves upon.

Table 2. Notations.

Notation	Description
$\left[n\right]$	The set $\{1,2,\cdots ,n\}$ for $n\in {\mathbb{Z}}^{+}$.
$〚n〛$	The set $\{n,\cdots ,1,0\}=\left[n\right]\cup \left\{0\right\}$ for $n\in {\mathbb{Z}}^{+}$.
$\overline{d}$	The 1’s complement of d with $0\le d<2^l$, which is computed by toggling each bit of the value d. For example, the 1’s complement of the binary number d = 0110 0101 is $\overline{d}=10011010$.
$\overline{d_j}$	The 1’s complement of a single bit $d_j\in \{0,1\}$, which is computed as $\overline{d_j}=1-d_j$.
${\left\{d_i\right\}}_{i\in I}$	The dataset $\{d_{i_1},d_{i_2},\cdots ,d_{i_n}\}$ for a set $I=\{i_1,i_2,\cdots ,i_n\}$, where $0\le d_i<2^l$.
${\langle d\rangle }_B$	As a special case of a dataset, the bit-decomposed form of a value d for $0\le d<2^l$. It is denoted by ${\langle d\rangle }_B=\{d_{l-1},\cdots ,d_1,d_0\}={\left\{d_j\right\}}_{j\in 〚l-1〛}$ where $d={\sum }_{j=0}^{l-1}{d}_j·2^j$ and $d_j\in \{0,1\}$.
${\langle E\left(d\right)\rangle }_B$	The encrypted bit-decomposed data of a value d for $0\le d<2^l$. It is denoted by ${\langle E\left(d\right)\rangle }_B=\{E\left(d_{l-1}\right),\cdots ,E\left(d_1\right),E\left(d_0\right)\}={\left\{E\left(d_j\right)\right\}}_{j\in 〚l-1〛}$ where $d={\sum }_{j=0}^{l-1}{d}_j·2^j$ and $d_j\in \{0,1\}$.
${\langle E\left(\overline{d}\right)\rangle }_B$	The encrypted 1’s complement of the bit-decomposed data for a value d. It is denoted by ${\langle E\left(\overline{d}\right)\rangle }_B=\{E\left(\overline{d_{l-1}}\right),\cdots ,E\left(\overline{d_1}\right),E\left(\overline{d_0}\right)\}={\left\{E\left(\overline{d_j}\right)\right\}}_{j\in 〚l-1〛}$ where $d={\sum }_{j=0}^{l-1}(1-\overline{d_j})·2^j$ and $\overline{d_j}\in \{0,1\}$.
$E\left(C_i\right)\leftarrow E\left(1\right)$ $(i\in [n\left]\right)$	The operations for a dataset. They are performed in parallel on each data point, but for succinctness, we simplify them. For example, the notation in the Notation column means the following operations:
	for each $i\in \left[n\right]$ do                     $E\left(C_i\right)\leftarrow E\left(1\right)$ end for
	The operation notation for a dataset can be appropriately modified according to the operation.
$r{\in }_{R}S$	For a set, S, the notation denotes that a value, r, is chosen from the set S uniformly at random.
$DH\to CSP:E\left(m\right)$	This notation denotes that DH sends a message $E\left(m\right)$ to CSP.
$x·y$	The ordinary multiplication for two values, x and y.
$E\left(x\right)\ast E\left(y\right)$	The homomorphic addition of two encrypted data, $E\left(x\right)$ and $E\left(y\right)$, as introduced in Section 2.3.

summarizes the notations used throughout this paper.

2.1. System Model

The proposed protocols operate in a dual cloud server setting under a non-collusion assumption. This setting involves two entities: a data host (DH) and a cryptographic service provider (CSP). The non-collusion assumption means that DH and CSP behave independently and do not share their intermediate results or internal states. In real-world environments, the DH and CSP can operate in physically or logically isolated cloud-based environments without collusion. Each cloud server operates across separate cloud platforms (e.g., AWS and Azure), which enhances scalability and isolation. To start the proposed protocols, CSP generates a key pair consisting of an encryption key (public key, PK) and a decryption key (secret key, SK). Then, the CSP distributes the PK to both DH and data owners. The data owners then encrypt their data using the PK and send them to the DH. To execute the proposed protocols, it is imperative that DH holds encrypted input data and CSP holds SK. The DH and CSP then execute the proposed ipMAX/ipMIN protocols through computation and communication, according to the specifications of these protocols. Upon the completion of the protocols, the DH obtains the encrypted index of the maximum/minimum value in the input data, while the CSP does not obtain any information. The encrypted index can be changed to the encrypted maximum/minimum value easily. The proposed protocols are particularly useful in cross-institutional scenarios, e.g., multiple hospitals identifying the maximum values in encrypted patient metrics, or companies securely outsourcing minimal cost computations without revealing raw data.

2.2. Adversary Model and Security Definition

The adversary model is classified as semi-honest adversary and malicious adversary models. In the semi-honest adversary model, a compromised party correctly follows the protocol specification but attempts to obtain information about the inputs and outputs by analyzing the transmitted data and the intermediate results. In the malicious adversary model, a compromised party behaves arbitrarily to achieve its goals, regardless of the protocol. The protocols designed under the semi-honest adversary model are significant, as they represent the first step in developing protocols with superior security. In runtime environments, robustness against semi-honest attackers is achieved by deploying the protocol on secure communication channels (e.g., TLS). It can be extended to provide robustness against a malicious adversary by using either zero-knowledge proofs [27] or consistency checks [28]. The proposed protocol (secure version) ensures that no information is revealed to either of the two cloud servers under semi-honest adversary model, as long as they do not collude. This model is reasonable and suitable for practical systems because major cloud service providers typically prioritize their reputation over any potential benefit from collusion, and because real-world constraints—such as legal, contractual, and compliance obligations—make collusion costly and risky in deployment.

To prove the security of the proposed protocol in a formal manner, we adopt the standard security definition for the semi-honest adversary model [10,29].

Definition 1.

Let x denote the input of party p, let ${\Pi }_p\left(\pi \right)$ denote the execution image of party p when running protocol π, and let y denote the output of party p computed by protocol π. A protocol, π, is secure if ${\Pi }_p\left(\pi \right)$ can be simulated, given only x and y, and if the distribution of the simulated image is computationally indistinguishable from the distribution of ${\Pi }_p\left(\pi \right)$. That is, party p learns no information from protocol π beyond what is implied by its input and output.

In this definition, the image includes the party’s input and output, as well as the received messages during the protocol execution. After presenting the proposed protocol in Section 3, we prove its security under this definition.

2.3. Additively Homomorphic Encryption

The proposed protocols are based on an encryption scheme that supports additive homomorphism. In the experimental evaluation presented in Section 4, this encryption scheme is instantiated with the Paillier cryptosystem. Paillier is a probabilistic public-key encryption scheme that provides semantic security, meaning that an adversary given only a ciphertext cannot infer any information about the underlying plaintext. Although Paillier is used in our implementation, the proposed protocols are compatible with any additively homomorphic encryption scheme. We denote the encryption and decryption functions as $E_{pk}(·)=E(·)$ and $D_{sk}(·)=D(·)$, respectively, where $pk$ and $sk$ are the public and secret keys. For simplicity, we omit the explicit key subscripts hereafter. The additive homomorphic property allows plaintext additions to be carried out directly on ciphertexts without requiring decryption. Formally, for any two values, $a,b\in {\mathbb{Z}}_N$, the following equation holds:

$$\begin{array}{cc}\hfill D(E\left(a\right)\ast E\left(b\right)mod{N}^2)& =a+bmodN\hfill \end{array}$$

(1)

$$\begin{array}{cc}\hfill D\left(E{\left(a\right)}^{b}mod{N}^2\right)& =a·bmodN\hfill \end{array}$$

(2)

For brevity, the terms $mod{N}^2$ and $modN$ are omitted from subsequent equations.

2.4. Efficiency Evaluation

Since the proposed protocols are executed through the interactions and computations of two cloud servers (DH and CSP) in the dual non-colluding cloud server model, their efficiency is determined by communication and computation costs. Accordingly, we evaluate the efficiency of a protocol using these two costs. In particular, our evaluation considers the number of communication rounds, the communication volume, and the computational costs incurred by DH and CSP. As the computational cost, we only consider encryption/decryption and exponentiation operations since other operations, such as homomorphic addition and permutation, have little influence on the overall performance. We assume that the execution times of the encryption and decryption are identical. The computation cost of the protocol is evaluated for three cases: the normal case, precomputation, and parallel execution. The normal case is the total number of operations required to execute a protocol. Precomputation is meaningful because it can reduce online execution time significantly by performing operations that are independent of input (e.g., encrypting random values) in advance. The parallel execution case means the number of sequential batches, with sufficiently many parallel threads assumed; i.e., independent encryption/decryption and exponentiation operations across data points are counted as one batch when executed concurrently. Following the protocol descriptions in Section 3, we analyze its efficiency theoretically by computing its communication and computation costs. In Section 4, we evaluate the efficiency of the proposed protocols based on the experimental results.

2.5. Secure Equality (SEQ) Functionality: $F_{SEQ}$

This section introduces the secure equality functionality $F_{SEQ}$ used in the proposed protocols, along with the existing protocol [30] that realizes it. In this paper, the invocation of the $SEQ$ functionality is represented as an interactive protocol that DH and CSP run with a third party to compute the functionality $F_{SEQ}$ ideally.

Intuitively, $F_{SEQ}$ computes whether two values, $\gamma$ and $\rho$, are equal, where the input data $\gamma$ and $\rho$ are bitwise. Formally, the functionality $F_{SEQ}$ receives two encrypted datasets, ${\left\{E\left({\gamma }_k\right)\right\}}_{k\in 〚\theta -1〛}$ and ${\left\{E\left({\rho }_k\right)\right\}}_{k\in 〚\theta -1〛}$, from DH, as well as a secret key, $SK$, from CSP. Then, it sends $E\left(q\right)$ to the DH and nothing to the CSP, where $E\left(q\right)=E\left(1\right)$ if ${\gamma }_k={\rho }_k$ for all k, and otherwise, $E\left(q\right)=E\left(0\right)$. We represent the functionality $F_{SEQ}$ as follows.

$$\begin{array}{cc}\hfill \left(E\right(q),\perp )& \leftarrow F_{SEQ}({\{E\left({\gamma }_k\right),E\left({\rho }_k\right)\}}_{k\in 〚\theta -1〛},SK)\hfill \\ \hfill & \mathrm{where}\{{\gamma }_k,{\rho }_k\}\in {\{0,1\}}^2,E\left(q\right)=\left\{\begin{array}{c}E\left(1\right),\mathrm{if}{\gamma }_k={\rho }_k\mathrm{for}\forall k\hfill \\ E\left(0\right),\mathrm{otherwise}\hfill \end{array}\right.\hfill \end{array}$$

(3)

The real protocol for privately computing the functionality $F_{SEQ}$ was proposed in the existing work [30]. As with the proposed protocols, the existing protocol [30] was implemented in the dual non-colluding cloud server model and was formally proven secure in the semi-honest adversary model. The protocol requires transmitting the data of size $(\theta +1)C$ in a single communication round and computing $(\theta +1)$ encryptions/decryptions and $(2\theta +1)$ exponentiations. When executed in parallel, the number of encryption/decryption and exponentiation operations can be reduced to 2 and 3, respectively. The detailed communication and computation costs are summarized in

Table 3. Costs of SEQ protocol in [30].

(a) Communication costs
	Rounds	Volume
	DH & CSP	DH		CSP
Costs	1	$\theta ·C$		$1·C$
(b) Computation costs
Case	DH		CSP
	Enc/Dec	Exp	Enc/Dec	Exp
Normal case	0	$2\theta +1$	$\theta +1$	0
Precomputation	0	$2\theta +1$	$\theta +1$	0
Parallel execution	0	3	2	0

C is the size (in bits) of a ciphertext. $Enc/Dec$ is the number of encryption/decryption operations. $Exp$ is the number of exponentiation operations. $Parallelexecution$ means the number of sequential batches, with the assumption of sufficiently many parallel threads.

.

2.6. Prior Protocol

This section explains the existing ppMAX/ppMIN protocols [20], which we improve upon in the next section. In Algorithm 1, the input dataset is ${\left\{{\langle E\left(d_i\right)\rangle }_B\right\}}_{i\in \left[n\right]}$, and the output dataset is ${\left\{E\left(C_i\right)\right\}}_{i\in \left[n\right]}$, where the data point $d_i$ corresponding to $C_i=1$ is the maximum. In the algorithm, n is the number of input data points, l is the bit length of each data point, and $\theta$ is the bit length of the number n. The secure multiplication functionality, denoted as $F_{SM}$, is a cryptographic operation that multiplies two original plaintext values.

Algorithm 1 ppMAX/ppMIN protocols [20]
Input: ${\left\{{\langle E\left(d_i\right)\rangle }_B\right\}}_{i\in \left[n\right]}$ where ${\langle E\left(d_i\right)\rangle }_B=\{E\left(d_{i,l-1}\right),\cdots ,E\left(d_{i,1}\right),E\left(d_{i,0}\right)\}$ and $d_{i,j}\in \{0,1\}$ Output: ${\left\{E\left(C_i\right)\right\}}_{i\in \left[n\right]}$, where $C_i=1$ if the corresponding data $d_i$ is the maximum, and otherwise, $C_i=0$.
1: $E\left(C_i\right)\leftarrow E\left(1\right)$	$(i\in \left[n\right])$
2: for $j=l-1$ to 0 do
3:    $(E\left(P_i\right),\perp )\leftarrow F_{SM}(\{E\left(C_i\right),E\left(d_{i,j}\right)\},SK)$	$(i\in \left[n\right])$
4:    $E\left(s\right)\leftarrow {\prod }_{i=1}^{n}E\left(P_i\right)$
5:    ${\left\{E\left({\gamma }_k\right)\right\}}_{k\in 〚\theta -1〛}\leftarrow E\left(s\right)\ast E\left(\rho \right)$	$\left(\rho {\in }_R{\mathbb{Z}}_N\right)$
6:    $(E\left(q\right),\perp )\leftarrow F_{SEQ}({\{E\left({\gamma }_k\right),E\left({\rho }_k\right)\}}_{k\in 〚\theta -1〛},SK)$
7:    $(E\left(t_i\right),\perp )\leftarrow F_{SM}(\{E\left(C_i\right),E\left(q\right)\},SK)$	$(i\in \left[n\right])$
8:    $E\left(C_i\right)\leftarrow E\left(t_i\right)\ast E\left(P_i\right)$	$(i\in \left[n\right])$
9: end for 10: return ${\left\{E\left(C_i\right)\right\}}_{i\in \left[n\right]}$

The protocols process one bit input at a time in an iterative manner, beginning with the most significant bit and proceeding toward the least significant bit. In each iteration of the loop, the following operations are carried out: first, the multiplication $P_i\leftarrow C_i\ast d_{i,j}$ is computed for each data point (line 3), and the value s is obtained by aggregating all of the $P_i$ values (line 4). Then, the value $\gamma =s+\rho$ is computed and bit-decomposed (line 5). The SEQ functionality checks whether all bits of $\gamma$ and $\rho$ are identical, and the result is denoted as q (line 6), which indicates whether $s=0$. Subsequently, the data point $C_i\leftarrow C_i\ast q+P_i$ is updated for each data point (lines 7–8). In order to protect data privacy, all data are encrypted using an additively homomorphic encryption scheme, and all computations are performed in a privacy-preserving manner. The SM and SEQ protocols are independently performed and securely implemented in prior works [30,31].

However, considering the optimization of the protocols, the communication and computation costs can be significantly reduced by leveraging intermediate computational results produced during the execution of these subprotocols. In order to achieve optimal efficiency in large-scale data, it is critical to minimize communication proportional to the amount of input data, which is typically the largest parameter in large-scale data. In this work, we eliminate communication by leveraging intermediate computational results within the subprotocols. In the next section, we present a detailed description of the proposed ipMAX/ipMIN protocols, which improve the efficiency of the existing ppMAX/ppMIN protocols.

3. Improved Privacy-Preserving Maximum/Minimum (ipMAX/ipMIN) Protocols

This study improves the efficiency of prior protocols [20] that compute the maximum or minimum value from an input data while preserving the privacy of the data. We call our improved protocols the ipMAX/ipMIN (Improved Privacy-Preserving Maximum/Minimum) protocols. The proposed protocols are classified as a secure version and an efficient version. The secure version computes the exact maximum/minimum value without disclosing any information about either the inputs or the outputs. In contrast, the efficient version can achieve faster execution at the cost of limited leakage: it reveals the bit position at which the maximum/minimum value becomes determined, while all other information remains protected. To improve efficiency, we integrate the subprotocols invoked in the prior protocol and redesign the protocols using a cancellation-based construction. Specifically, the prior protocols [20] use two independent subprotocols: the secure multiplication and the secure equality protocols. Each subprotocol is defined and executed in isolation, meaning that any intermediate computational results generated within the subprotocol remain encapsulated and unused by other protocols. However, in the proposed protocols, we integrate these independent subprotocols, reuse intermediate computation results, and redesign the protocols with a cancellation structure that cancels out random masking terms. As a result, the proposed protocols structurally remove redundant communication and computation overhead that grows linearly with the dataset size n, thereby alleviating a key bottleneck in large-scale environments. More concretely, when compared with the protocol of [20], the secure version requires 25% fewer communication rounds and 50% less total communication. It also reduces the total number of encryption/decryption computations by 42%. The efficient version can reduce them more.

The proposed protocols retain all the advantages of the existing ppMAX/ppMIN protocols, in addition to the aforementioned efficiency improvements. The proposed protocols allow all input data points to be processed in parallel, since the computations for individual data points are mutually independent. In other words, the round complexity—which directly affects execution time—is independent of the input dataset size. This makes the protocols highly scalable and efficient for large-scale data processing. The performance of the protocols is enhanced in proportion to the number of parallel operations. Therefore, when deployed in a cloud computing environment with massive parallel computing capabilities, it is expected that their performance significantly increases with the degree of parallelism. Earlier ppMAX/ppMIN schemes [18,25,26] rely on comparison operations whose cost scales with the number of input data points. By contrast, our protocols use more efficient equality checks, and their cost depends on the bit length of the input data point, rather than on the number of inputs. In large-scale settings, where the bit length of data is typically much smaller than the total number of inputs, this design provides a clear computational advantage. Moreover, the proposed protocols return all of the maximum/minimum values when duplicates exist, yielding more complete results than prior approaches.

From a privacy perspective, the secure version does not leak information about either the input data or the final output, because all values processed by DH and CSP are represented as encrypted or randomized values. In addition, the protocols are resistant to data-access-pattern attack, since every data point is processed uniformly, regardless of intermediate outcomes. These properties make the proposed protocols suitable for secure execution in outsourced cloud environments. Major cloud providers, including Amazon, Google, and Microsoft, offer infrastructures with strong parallel-processing capabilities, making the proposed protocols well suited for efficiently executing the proposed maximum/minimum protocols. Furthermore, data owners (input parties) do not participate in any computation or communication beyond the initial transmission of input data and the final receipt of computational results. In other words, all computations are performed exclusively by the cloud servers without any assistance from the data owners. Therefore, even data owners with resource-constrained devices (e.g., mobile phones or IoT devices) can participate in the proposed protocols and obtain the final result without performing heavy computations themselves.

The functionality of the proposed ipMAX/ipMIN, denoted as $F_{ipMAX/ipMIN}$, is defined as follows:

• Functionality $F_{ipMAX/ipMIN}$: It receives the encrypted input datasets ${\left\{{\langle E\left(d_i\right)\rangle }_B\right\}}_{i\in \left[n\right]}$ from DH and a decryption key SK from CSP. It then returns the encrypted output datasets ${\left\{E\left(C_i\right)\right\}}_{i\in \left[n\right]}$ to the DH, where $C_i=1$ if the corresponding data point, $d_i$, is the maximum/minimum, and otherwise, $C_i=0$. The functionality $F_{ipMAX/ipMIN}$ is represented as follows:

$$\begin{array}{c}\hfill ({\left\{E\left(C_i\right)\right\}}_{i\in \left[n\right]},\perp )\leftarrow F_{ipMAX/ipMIN}({\left\{{\langle E\left(d_i\right)\rangle }_B\right\}}_{i\in \left[n\right]},SK)\end{array}$$

(4)

We present the secure version in Section 3.1 and the efficient version in Section 3.2. Figure 1 shows the flowcharts of the secure and efficient versions.

3.1. Secure Version of the ipMAX/ipMIN Protocols

3.1.1. Secure Version of the ipMAX Protocol

The secure variant of the ipMAX protocol determines the maximum value of the input dataset without leaking any information about either the inputs or the intermediate/final computational outcomes. In this protocol, each input data point, $d_i$, is paired with an auxiliary data, $C_i\in \{0,1\}$. Each $d_i$ is assumed to be represented using l bits. The maximum is determined by repeatedly updating the auxiliary data $C_i$, examining one bit of input data at a time from the most significant bit to the least significant bit. Accordingly, the procedure runs for l iterations in total.

• Auxiliary data $C_i$: The value $C_i$ indicates whether the corresponding input $d_i$ is the maximum candidates, i.e., the data points still considered possible maxima. More precisely, $C_i=1$ means that $d_i$ is still a candidate, whereas $C_i=0$ means that it has already been eliminated from the set of maximum candidates. Initially, all data points belong to the candidate set. As the protocol proceeds, some candidates are discarded on the basis of bitwise computations. By the end of the procedure, the remaining data point(s) with $C_i=1$ are determined as the maximum value(s). The maximum value is determined from the candidate set, and once a data point $d_i$ is removed from the candidate dataset (that is, once $C_i$ changes from 1 to 0), it cannot re-enter in later iterations; the transition $C_i=1\to 0$ is permitted, whereas $C_i=0\to 1$ is not.
• Intuitive Idea: The ipMAX protocol finds the maximum by updating the auxiliary data $C_i$ bit by bit, using the current bit $d_{i,j}$ in each iteration, starting from bit position $(l-1)$ and moving down to bit position 0. At a given iteration, candidate data points whose current bit is 1 (i.e., those satisfying $C_i{d}_{i,j}=1$) are regarded as the predicted maximum candidates. This follows from the observation that, when two binary values, such as $a=11011000$ and $b=11010110$, are compared from the most significant bit downward, the higher-order bits (bits 7 through 4) are identical (1101), and thus, no ordering can yet be determined. However, at the third bit, $a_3=1$ and $b_3=0$, which clearly indicates that a > b, regardless of the remaining lower (2-0)-th bits. In the last step, the ipMAX protocol removes the unpredicted maximum data—which are determined to be smaller—from the candidate set, and thus the candidate data is consistently greater than the non-candidate data. Each iteration of the proposed protocol consists of three steps, whose ideas are as follows:

• Step 1: The protocol privately computes $\gamma =s+\rho$, where s denotes the number of predicted maximum candidates ($s=\sum C_i{d}_{i,j}$), and $\rho$ is a random value used to blind the number s. This step corresponds to lines 3–5 of Algorithm 1.
• Step 2: The protocol uses the SEQ functionality to privately determine whether $s+\rho$ is equal to $\rho$, which is equivalent to checking whether $s=0$. If $s=0$ (i.e., $s+\rho =\rho$), the protocol sets $q=1$, and otherwise (i.e., $s+\rho \ne \rho$), it sets $q=0$. This step corresponds to line 6 of Algorithm 1.
• Step 3: Based on the value of s, the protocol privately updates the auxiliary data $C_i$, according to $C_i\leftarrow C_{i}q+C_i{d}_{i,j}$. If $s\ne 0$ (equivalently, $q=0$, meaning that at least one predicted maximum candidate exists), all non-predicted data are removed from the candidate set, and only the predicted data remain, i.e., $C_i\leftarrow C_i{d}_{i,j}$. If $s=0$ (equivalently, $q=1$, meaning that no predicted maximum candidate exists), then all $C_i{d}_{i,j}=0$, so the candidate set remains unchanged, i.e., $C_i\leftarrow C_i$, and the protocol proceeds to the next iteration. This step corresponds to lines 7–8 of Algorithm 1.

By repeating this update process from the most significant bit to the least significant bit, the ipMAX protocol gradually eliminates smaller values—namely, the unpredicted maximum data—from the candidate set. Consequently, the data point(s) that remain in the candidate set at the end of the protocol correspond to the maximum value.

Algorithm 2 presents the secure version of the ipMAX protocol, and 

Table 4. Example of the secure version of the ipMAX Protocol (Algorithm 2).

j	${\left\{{\langle \mathit{E}\left({\mathit{d}}_{\mathit{i}}\right)\rangle }_{\mathit{B}}\right\}}_{\mathit{i}\in \left[5\right]}$	s	$\mathit{\rho }$	${\left\{\mathit{E}\left({\mathit{\gamma }}_{\mathit{k}}\right)\right\}}_{\mathit{k}\in 〚2〛}$	$\mathit{E}\left(\mathit{q}\right)$	${\left\{\mathit{E}\left({\mathit{C}}_{\mathit{i}}\right)\right\}}_{\mathit{i}\in \left[5\right]}$
·	·	·	·	·	·	$\left\{E\right(1),E(1),E(1),E(1),E(1\left)\right\}$
7	$\left\{E\right(0),E(0),E(0),E(0),E(0\left)\right\}$	0	3	$\left\{E\right(0),E(1),E(1\left)\right\}$	$E\left(1\right)$	$\left\{E\right(1),E(1),E(1),E(1),E(1\left)\right\}$
6	$\left\{E\right(1),E(1),E(1),E(0),E(0\left)\right\}$	3	7	$\left\{E\right(0),E(1),E(0\left)\right\}$	$E\left(0\right)$	$\left\{E\right(1),E(1),E(1),E(0),E(0\left)\right\}$
5	$\left\{E\right(0),E(0),E(0),E(1),E(1\left)\right\}$	0	4	$\left\{E\right(1),E(0),E(0\left)\right\}$	$E\left(1\right)$	$\left\{E\right(1),E(1),E(1),E(0),E(0\left)\right\}$
4	$\left\{E\right(1),E(1),E(0),E(1),E(0\left)\right\}$	2	6	$\left\{E\right(0),E(0),E(0\left)\right\}$	$E\left(0\right)$	$\left\{E\right(1),E(1),E(0),E(0),E(0\left)\right\}$
3	$\left\{E\right(0),E(0),E(1),E(0),E(1\left)\right\}$	0	1	$\left\{E\right(0),E(0),E(1\left)\right\}$	$E\left(1\right)$	$\left\{E\right(1),E(1),E(0),E(0),E(0\left)\right\}$
2	$\left\{E\right(1),E(0),E(1),E(1),E(0\left)\right\}$	1	5	$\left\{E\right(1),E(1),E(0\left)\right\}$	$E\left(0\right)$	$\left\{E\right(1),E(0),E(0),E(0),E(0\left)\right\}$
1	$\left\{E\right(0),E(1),E(1),E(1),E(0\left)\right\}$	0	2	$\left\{E\right(0),E(1),E(0\left)\right\}$	$E\left(1\right)$	$\left\{E\right(1),E(0),E(0),E(0),E(0\left)\right\}$
0	$\left\{E\right(1),E(0),E(1),E(0),E(1\left)\right\}$	1	3	$\left\{E\right(1),E(0),E(0\left)\right\}$	$E\left(0\right)$	$\left\{E\right(1),E(0),E(0),E(0),E(0\left)\right\}$

In line 10, $\gamma =s+\rho$, where $s={\sum }_{i=1}^n{C}_i{d}_{i,j}$ is the number of predicted maximum data, and $\rho$ is a random value. The bit length of input data is $l=8$. The bit length of the number of the input data points is $\theta =3$. - Input: ${\left\{{\langle E\left(d_i\right)\rangle }_B\right\}}_{i\in \left[5\right]}=\{{\langle E\left(85\right)\rangle }_B,{\langle E\left(82\right)\rangle }_B,{\langle E\left(79\right)\rangle }_B,{\langle E\left(54\right)\rangle }_B,{\langle E\left(41\right)\rangle }_B\}$. - Output: ${\left\{E\left(C_i\right)\right\}}_{i\in \left[5\right]}=\{E\left(1\right),E\left(0\right),E\left(0\right),E\left(0\right),E\left(0\right)\}$ (indicating that the maximum value is 85).

provides an illustrative example for clarity. The protocol takes the encrypted dataset ${\left\{{\langle E\left(d_i\right)\rangle }_B\right\}}_{i\in \left[n\right]}$ as input and outputs an auxiliary dataset ${\left\{E\left(C_i\right)\right\}}_{i\in \left[n\right]}$, where the maximum value is the $d_i$ associated with $C_i=1$. In other words, the data point(s) that remain in the candidate set at the end of the protocol—namely, those with $C_i=1$—are identified as the final maximum value(s). Here, n is the number of input data points, l is the bit length of each data point, and $\theta$ is the bit length of the number n.

Algorithm 2 Secure version of the ipMAX protocol.
Input: ${\left\{{\langle E\left(d_i\right)\rangle }_B\right\}}_{i\in \left[n\right]}$, where ${\langle E\left(d_i\right)\rangle }_B=\{E\left(d_{i,l-1}\right),\cdots ,E\left(d_{i,1}\right),E\left(d_{i,0}\right)\}$, $d_i={\sum }_{j=0}^{l-1}{d}_{i,j}·2^j$ and $d_{i,j}\in \{0,1\}$ Output: ${\left\{E\left(C_i\right)\right\}}_{i\in \left[n\right]}$, where $C_i=1$ if the corresponding data $d_i$ is the maximum, and otherwise, $C_i=0$.
DH: 1: $E\left(C_i\right)\leftarrow E\left(1\right)$	$(i\in \left[n\right])$
2: for $j=l-1$ to 0 do
3:    $E\left({\alpha }_i\right)\leftarrow E\left(C_i\right)\ast E\left(r_i\right)$	$(r_i{\in }_R{\mathbb{Z}}_N,i\in \left[n\right])$
4:    $E\left({\beta }_i\right)\leftarrow E\left(d_{i,j}\right)\ast E\left(t_i\right)$	$(t_i{\in }_R{\mathbb{Z}}_N,i\in \left[n\right])$
5:    $E\left(x_i\right)\leftarrow E{\left(C_i\right)}^{N-t_i}\ast E{\left(d_{i,j}\right)}^{N-r_i}\ast E(N-r_i{t}_i)$	$(i\in \left[n\right])$
6:    $E\left(\lambda \right)\leftarrow E\left(\rho \right)\ast {\prod }_{i=1}^{n}E\left(x_i\right)$	$\left(\rho {\in }_R{\mathbb{Z}}_N\right)$
7:    $DH\to CSP:{\left\{E\left({\alpha }_i\right)\right\}}_{i\in \left[n\right]},{\left\{E\left({\beta }_i\right)\right\}}_{i\in \left[n\right]},E\left(\lambda \right)$
CSP: 8:    Decrypt $E\left({\alpha }_i\right),E\left({\beta }_i\right),E\left(\lambda \right)$	$(i\in \left[n\right])$
9:    $w_i\leftarrow {\alpha }_i·{\beta }_i$	$(i\in \left[n\right])$
10:    $\gamma \leftarrow \lambda +{\sum }_{i=1}^n{w}_i$
11:    Encrypt ${\gamma }_k$	$(k\in 〚\theta -1〛)$
12:    $CSP\to DH:{\left\{E\left({\gamma }_k\right)\right\}}_{k\in 〚\theta -1〛}$
DH & CSP: 13:    $(E\left(q\right),\perp )\leftarrow F_{SEQ}({\{E\left({\gamma }_k\right),E\left({\rho }_k\right)\}}_{k\in 〚\theta -1〛},SK)$
DH: 14:    $E\left(\delta \right)\leftarrow E\left(q\right)\ast E\left(\tau \right)$	$\left(\tau {\in }_R{\mathbb{Z}}_N\right)$
15:    $DH\to CSP:E\left(\delta \right)$
CSP: 16:    Decrypt $E\left(\delta \right)$
17:    $y_i\leftarrow {\alpha }_i·\delta +w_i$	$(i\in \left[n\right])$
18:    Encrypt $y_i$	$(i\in \left[n\right])$
19:    $CSP\to DH:{\left\{E\left(y_i\right)\right\}}_{i\in \left[n\right]}$
DH: 20:    $E\left(z_i\right)\leftarrow E{\left(C_i\right)}^{N-\tau }\ast E{\left(q\right)}^{N-r_i}\ast E(N-r_i\tau )$	$(i\in \left[n\right])$
21:    $E\left(C_i\right)\leftarrow E\left(x_i\right)\ast E\left(y_i\right)\ast E\left(z_i\right)$	$(i\in \left[n\right])$
22: end for 23: return  ${\left\{E\left(C_i\right)\right\}}_{i\in \left[n\right]}$

For brevity, we describe the data in an intuitive, non-encrypted form. At the beginning of the protocol, DH initializes all data points as the maximum candidates (line 1). As explained above, DH and CSP then jointly find the maximum value by updating the auxiliary data $C_i$ for one bit of each input data point in every iteration, proceeding from the ($l-1$)-th bit down to the 0th bit (lines 2–22). We assume that, in the ($l-j$)-th iteration, DH and CSP update the auxiliary data $C_i$ using the j-th bit of $d_i$, for each $i\in \left[n\right]$ and $j=l-1,\cdots ,0$.

• (Step 1: lines 3–12) privately computing the number of predicted maximum data: DH first generates ${\alpha }_i$ and ${\beta }_i$, corresponding to $C_i$ and $d_{i,j}$, as follows (lines 3–4).

$$\begin{array}{cc}E\left({\alpha }_i\right)\hfill & \leftarrow E(C_i+r_i)\hfill \end{array}$$

(5)

$$\begin{array}{ccccccccccccccccccc}& & & & & & & & & & & & & & & & & \hfill E\left({\beta }_i\right)& \leftarrow E(d_{i,j}+t_i)(r_i,t_i{\in }_R{\mathbb{Z}}_N,i\in \left[n\right])\hfill \end{array}$$

(6)

It computes $x_i$ and then aggregates all $x_i$ along with a random value $\rho$ to compute $\lambda$ as follows (lines 5–6).

$$\begin{array}{cccccccc}& & & & \hfill E\left(x_i\right)& \leftarrow E(-t_i{C}_i-r_i{d}_{i,j}-r_i{t}_i)\hfill & \hfill & (i\in [n\left]\right)\hfill \end{array}$$

(7)

$$\begin{array}{cccc}\hfill E\left(\lambda \right)& \leftarrow E(\rho +\sum _{i=1}^n{x}_i)\hfill & \hfill & \left(\rho {\in }_R{\mathbb{Z}}_N\right)\hfill \end{array}$$

(8)

It sends all ${\alpha }_i$, ${\beta }_i$ ($i\in \left[n\right]$), and $\lambda$ to a CSP (line 7). Upon receiving the ciphertexts, the CSP decrypts them (line 8), computes $w_i$ (line 9), and aggregates all $w_i$ values with $\lambda$ to compute $\gamma$ (line 10) as follows. Here, $\gamma =s+\rho$ where s is the number of predicted maximum data and is blinded by a random value $\rho$. The correctness of $\gamma$ will be shown later.

$$\begin{array}{cc}\hfill w_i& \leftarrow {\alpha }_i·{\beta }_i(i\in \left[n\right])\hfill \end{array}$$

(9)

$$\begin{array}{cc}\hfill \gamma & \leftarrow \lambda +\sum _{i=1}^n{w}_i\hfill \end{array}$$

(10)

It encrypts $\gamma$ bitwise by the $\theta$ bits of the bit length of n and sends the bitwise encrypted data to the DH (lines 11–12). The DH reuses the random value $\rho$ in Step 2 and the computed data $x_i$ in Step 3, while the CSP reuses ${\alpha }_i$ and $w_i$ in Step 3.

• (Step 2: line 13) privately comparing the number of predicted maximum data to zero: The DH and CSP privately compute q, which indicates whether $\gamma$ (= $s+\rho$) is equal to $\rho$, which is equivalent to checking whether $s=0$. To do this, the protocol uses the SEQ functionality introduced in Section 2.5. That is, DH and CSP interact with a third party that is assumed to implement the SEQ functionality ideally.

$$\begin{array}{cc}\hfill \left(E\right(q),\perp )\leftarrow & F_{SEQ}({\{E\left({\gamma }_k\right),E\left({\rho }_k\right)\}}_{k\in 〚\theta -1〛},SK)\hfill \\ \hfill & \mathrm{where}E\left(q\right)=\left\{\begin{array}{c}E\left(1\right),\mathrm{if}{\gamma }_k={\rho }_k\mathrm{for}\forall k\hfill \\ E\left(0\right),\mathrm{otherwise}\hfill \end{array}\right.\hfill \end{array}$$

(11)

• (Step 3: lines 14–21) privately updating the auxiliary data $C_i$: The DH computes $\delta$ to blind q as follows and sends it to the CSP (lines 14–15).

$$\begin{array}{c}\hfill E\left(\delta \right)\leftarrow E(q+\tau )\left(\tau {\in }_R{\mathbb{Z}}_N\right)\end{array}$$

(12)

The CSP decrypts the received data $\delta$ (line 16) and computes $y_i$ using ${\alpha }_i$ and $w_i$ computed in Step 1, as follows (line 17). The CSP encrypts all $y_i$ and sends them back to the DH (lines 18–19).

$$\begin{array}{c}\hfill y_i\leftarrow {\alpha }_i·\delta +w_i(i\in \left[n\right])\end{array}$$

(13)

The DH computes $z_i$ (line 20) and the auxiliary data $C_i$ using the data $x_i$ from Step 1 and the data $y_i$ received from the CSP as follows (line 21). The correctness of $C_i$ will be shown later.

$$\begin{array}{cccc}\hfill E\left(z_i\right)& \leftarrow E(-\tau C_i-r_{i}q-r_i\tau )\hfill & \hfill & (i\in [n\left]\right)\hfill \end{array}$$

(14)

$$\begin{array}{cccc}\hfill E\left(C_i\right)& \leftarrow E(x_i+y_i+z_i)\hfill & \hfill & (i\in [n\left]\right)\hfill \end{array}$$

(15)

• Correctness: We now verify that, in Step 1, $\gamma =s+\rho$, where $s=\sum C_i{d}_{i,j}$ denotes the number of predicted maximum data. Indeed, $C_i{d}_{i,j}=1$ when the corresponding data point is a predicted maximum data, and $C_i{d}_{i,j}=0$ otherwise.

$$\begin{array}{cccc}\hfill \gamma & =\lambda +\sum w_i\hfill & \hfill & (\mathrm{line}10)\hfill \\ \hfill & =\rho +\sum x_i+\sum {\alpha }_i{\beta }_i\hfill & \hfill & (\mathrm{lines}6,9)\hfill \\ \hfill & =\rho +\sum \{(C_i+r_i)(d_{i,j}+t_i)-(t_i{C}_i+r_i{d}_{i,j}+r_i{t}_i)\}\hfill & \hfill & (\mathrm{lines}3–5)\hfill \\ \hfill & =\rho +\sum \{(C_i{d}_{i,j}+t_i{C}_i+r_i{d}_{i,j}+r_i{t}_i)-(t_i{C}_i+r_i{d}_{i,j}+r_i{t}_i)\}\hfill \\ \hfill & =\rho +\sum \left(C_i{d}_{i,j}\right)=s+\rho \hfill \end{array}$$

(16)

We also show that the auxiliary data $C_i=x_i+y_i+z_i$ of line 21 corresponds to $C_i=C_{i}q+C_i{d}_{i,j}$ described in Step 3 of the intuitive idea.

$$\begin{array}{cccc}\hfill C_i=& x_i+y_i+z_i\hfill & \hfill & (\mathrm{line}21)\hfill \\ \hfill =& ({\alpha }_i\delta +w_i)-(\tau C_i+r_{i}q+r_i\tau )-(t_i{C}_i+r_i{d}_{i,j}+r_i{t}_i)\hfill & \hfill & (\mathrm{lines}5,17,20)\hfill \\ \hfill =& \{(C_i+r_i)(q+\tau )+(C_i+r_i)(d_{i,j}+t_i)\}\hfill \\ \hfill & -(\tau C_i+r_{i}q+r_i\tau )-(t_i{C}_i+r_i{d}_{i,j}+r_i{t}_i)\hfill & \hfill & (\mathrm{lines}3,4,9,14)\hfill \\ \hfill =& \{(C_{i}q+\tau C_i+r_{i}q+r_i\tau )-(\tau C_i+r_{i}q+r_i\tau )\}\hfill \\ \hfill & +\{(C_i{d}_{i,j}+t_i{C}_i+r_i{d}_{i,j}+r_i{t}_i)-(t_i{C}_i+r_i{d}_{i,j}+r_i{t}_i)\}\hfill \\ \hfill =& C_{i}q+C_i{d}_{i,j}\hfill \end{array}$$

(17)

Efficiency Evaluation: The ipMAX protocol requires $3l$ communication rounds, and its communication-volume complexity is $\mathcal{O}\left(3nlC\right)$, where n denotes the number of input data points, l is the bit length of each data value, and C represents the size of a ciphertext. Note that the round cost, which directly impacts the execution time, is independent of the dataset size n. Compared to the prior protocol [20], the proposed protocol reduces the round cost by 25% (from $4l$ to $3l$), and the complexity of communication volume by approximately 50% (from $\mathcal{O}\left(6nlC\right)$ to $\mathcal{O}\left(3nlC\right)$). In addition, the complexity of the encryption/decryption operations is reduced by approximately 42%. While the prior protocol requires $\mathcal{O}\left(12nl\right)$ encryption/decryption operations, the proposed protocol reduces this to $\mathcal{O}\left(7nl\right)$.

Table 5. The communication and computation costs for a single iteration (i.e., one bit) of the secure version. These operations are repeated for a total of l iterations.

(a) Communication costs
Step	Rounds	Volume
		DH		CSP
Step 1	1	$(2n+1)·C$		$\theta ·C$
Step 2	1	$\theta ·C$		$1·C$
Step 3	1	$1·C$		$n·C$
Total	3	$(2n+\theta +2)·C$		$(n+\theta +1)·C$
(b) Computation costs
Case	Step	DH		CSP
		Enc/Dec	Exp	Enc/Dec	Exp
Normal case	Step 1	$3n+1$	$2n$	$2n+\theta +1$	0
	Step 2	0	$2\theta +1$	$\theta +1$	0
	Step 3	$n+1$	$2n$	$n+1$	0
	Total	$4n+2$	$4n+2\theta +1$	$3n+2\theta +3$	0
Precom- putation	Step 1	0	$2n$	$2n+\theta +1$	0
	Step 2	0	$2\theta +1$	$\theta +1$	0
	Step 3	0	$2n$	$n+1$	0
	Total	0	$4n+2\theta +1$	$3n+2\theta +3$	0
Parallel execution	Step 1	1	1	2	0
	Step 2	0	3	2	0
	Step 3	1	1	2	0
	Total	2	5	6	0

n is the number of input data points. l is the bit length of the data. $\theta$ is the bit length of the number n. $Parallelexecution$ means the number of sequential batches, with sufficiently many parallel threads assumed.

shows the communication cost (communication rounds and volume) and the computation cost (number of encryption/decryption and exponentiation operations) executed by DH and CSP at each step.

We analyze the communication and computation costs of the ipMAX protocol with respect to the number n of input data points, which is typically the largest parameter in large-scale data applications. Each step of the protocol requires one communication round. In Step 1, the DH sends $2n$ ciphertexts, while in Step 3, the CSP returns n ciphertexts. In terms of computation, the DH performs $3n$ encryption operations in Step 1 to encrypt random values, but these operations can be eliminated by precomputation. Similarly, the DH performs additional n encryption operations for random values in Step 3, which can also be removed by precomputation. Moreover, when executing the protocol in parallel, the encryption/decryption and exponentiation operations can be performed concurrently (i.e., parallel execution). The SEQ protocol in Step 2 is executed only once per iteration, regardless of the number of input data points. These steps are repeated l times that corresponds to the bit length of the data. The detailed communication and computation costs are provided in Table 5.

Table 6. Size of input/output for the number of the input data points and parallel operations (assuming m divides n).

	Input Data (Bits)	Output Data (Bits)
One input data point	$lC$	C
n input data points	$nlC$	$nC$
m parallel processing of the n input data points	${\displaystyle \frac{n}{m}}lC$	${\displaystyle \frac{n}{m}}C$

and

Table 7. Minimum memory size of DH and CSP for the number of the input data points and parallel operations (assuming m divides n).

	DH (Bits)	CSP (Bits)
One input data point	$(4+1)C$	$(2+1)C$
n input data points	$(4n+1)C$	$(2n+1)C$
m parallel processing of the n input data points	$(4{\displaystyle \frac{n}{m}}+1)C$	$(2{\displaystyle \frac{n}{m}}+1)C$

, respectively, present the sizes of the input/output and the minimum memory requirements of DH and CSP for the number of input data points and the degree of parallelism. Since each input data point $d_i$ is encrypted as encrypted bit-decomposed data ${\langle E\left(d_i\right)\rangle }_B$, a single input data point requires $lC$ bits. After the protocol terminates, the result for one input data point is included in a single ciphertext $E\left(C_i\right)$. For an encrypted one-bit input ciphertext $E\left(d_{i,j}\right)$, in Step 1 the DH generates $E\left(C_i\right)$, $E\left({\alpha }_i\right)$, $E\left({\beta }_i\right)$, $E\left(x_i\right)$, and $E\left(\lambda \right)$; hence DH requires $5C$ bits of memory. The CSP requires $3C$ bits because it receives $E\left({\alpha }_i\right)$, $E\left({\beta }_i\right)$, and $E\left(\lambda \right)$ from DH. Steps 2 and 3 do not require more memory than Step 1 (This statement assumes that the SEQ protocol in [30] is used in Step 2. In Step 2, the required memory depends on the specific SEQ protocol used). For n input data points, the overall data size scales approximately linearly with n. In particular, since $E\left(\lambda \right)$ in Step 1 is computed only once for all input data points, DH requires $(4n+1)C$ bits, and CSP requires $(2n+1)C$ bits because it receives a single $E\left(\lambda \right)$ from DH. Detailed data size and memory requirements are provided in Table 6 and Table 7. We now evaluate the per-server memory usage when the computation is parallelized across m parallel servers, assuming that m divides n. In this setting, the n input data points are partitioned across the m servers, so that each server processes ${\displaystyle \frac{n}{m}}$ data points. In addition, extra communication is required to compute the global aggregated $\gamma$ across all m servers (line 10) and to distribute the resulting $\delta$ back to each server (line 16), which incurs an additional transmission overhead of approximately ${\displaystyle \frac{1}{2}}mC$ for each operation.

• Security: We now formally prove the security of the secure version of the ipMAX protocol. Let ${\pi }_{ipMAX}^{SEC}$ denote the secure version of the ipMAX protocol described in Algorithm 2. We then prove the following theorem.

Theorem 1.

${\pi }_{ipMAX}^{SEC}$ privately computes $F_{ipMAX}$ in the presence of a semi-honest adversary.

We first show that the CSP learns no information during the protocol execution because it observes only ciphertexts and plaintexts blinded by random values. We then show that the DH learns no information because it observes only ciphertexts.

Proof of Theorem 1.

According to Algorithm 2, the execution image of the CSP is as follows:

$$\begin{array}{cc}\hfill {\Pi }_{CSP}\left({\pi }_{ipMAX}^{SEC}\right)=& \{{\{E\left({\alpha }_i\right),C_i+r_i\}}_{i\in \left[n\right]},{\{E\left({\beta }_i\right),d_{i,j}+t_i\}}_{i\in \left[n\right]},\hfill \\ \hfill & \{E\left(\lambda \right),\rho +\sum _i{x}_i\},\{E\left(\delta \right),q+\tau \}\}\hfill \end{array}$$

(18)

Here, $E\left({\alpha }_i\right)$,$E\left({\beta }_i\right)$, $E\left(\lambda \right)$, and $E\left(\delta \right)$ are ciphertexts received from the DH for $i\in \left[n\right]$, and $C_i+r_i$, $d_{i,j}+t_i$, $\rho +{\sum }_i{x}_i$, and $q+\tau$ are the corresponding decrypted data, respectively. Since $r_i$ is a random value chosen from ${\mathbb{Z}}_N$, the value $C_i+r_i$ is randomized. Similarly, since $t_i$, $\rho$, and $\tau$ are random values in ${\mathbb{Z}}_N$, the values $d_{i,j}+t_i$, $\rho +{\sum }_i{x}_i$, and $q+\tau$ are also randomized. The simulated image of the CSP can be constructed as follows:

$$\begin{array}{c}\hfill {\Pi }_{CSP}^S\left({\pi }_{ipMAX}^{SEC}\right)=\{{\{{\alpha }_i^{\prime },r_i^{\prime }\}}_{i\in \left[n\right]},{\{{\beta }_i^{\prime },t_i^{\prime }\}}_{i\in \left[n\right]},\{{\lambda }^{\prime },{\rho }^{\prime }\},\{{\delta }^{\prime },{\tau }^{\prime }\}\}\end{array}$$

(19)

In the simulated image, ${\alpha }_i^{\prime }$, ${\beta }_i^{\prime }$, ${\lambda }^{\prime }$, and ${\delta }^{\prime }$ for $i\in \left[n\right]$ are values chosen uniformly at random from ${\mathbb{Z}}_{N^2}$. Since $E(·)$ is a semantically secure encryption scheme and the encrypted value is in ${\mathbb{Z}}_{N^2}$, the ciphertexts $E\left({\alpha }_i\right)$, $E\left({\beta }_i\right)$, $E\left(\lambda \right)$, and $E\left(\delta \right)$ are computationally indistinguishable from random values ${\alpha }_i^{\prime }$, ${\beta }_i^{\prime }$, ${\lambda }^{\prime }$, and ${\delta }^{\prime }$, respectively. Likewise, $r_i^{\prime }$, $t_i^{\prime }$, ${\rho }^{\prime }$, and ${\tau }^{\prime }$ are chosen uniformly at random from ${\mathbb{Z}}_N$. Hence, these simulated random values are computationally indistinguishable from $C_i+r_i$, $d_{i,j}+t_i$, $\rho +{\sum }_i{x}_i$, and $q+\tau$. Combining these analysis, we can conclude that the CSP obtains no information about $C_i$, $d_{i,j}$, ${\sum }_i{x}_i$, and q in the secure version of ipMAX. On the other hand, the execution image of the DH is as follows:

$$\begin{array}{c}\hfill {\Pi }_{DH}\left({\pi }_{ipMAX}^{SEC}\right)=\{{\left\{E\left({\gamma }_k\right)\right\}}_{k\in 〚\theta -1〛},E\left(q\right),{\left\{E\left(y_i\right)\right\}}_{i\in \left[n\right]}\}\end{array}$$

(20)

Here, $E\left({\gamma }_k\right)$ and $E\left(y_i\right)$ are ciphertexts received from the CSP for $k\in 〚\theta -1〛$ and $i\in \left[n\right]$, and $E\left(q\right)$ is a ciphertext received from the third party that executes $F_{SEQ}$. A simulated image of the DH can be constructed as follows:

$$\begin{array}{c}\hfill {\Pi }_{DH}^S\left({\pi }_{ipMAX}^{SEC}\right)=\{{\left\{{\gamma }_k^{\prime }\right\}}_{k\in 〚\theta -1〛},q^{\prime },{\left\{y_i^{\prime }\right\}}_{i\in \left[n\right]}\}\end{array}$$

(21)

For the simulated image, ${\gamma }_k^{\prime }$, $q^{\prime }$, and $y_i^{\prime }$ are independently sampled uniformly from ${\mathbb{Z}}_{N^2}$ for $k\in 〚\theta -1〛$ and $i\in \left[n\right]$. By the semantic security of $E(·)$, and since the ciphertext is in ${\mathbb{Z}}_{N^2}$, the ciphertexts $E\left({\gamma }_k\right)$, $E\left(q\right)$, and $E\left(y_i\right)$ cannot be distinguished computationally from the random samples ${\gamma }_k^{\prime }$, $q^{\prime }$, and $y_i^{\prime }$, respectively. It follows that, under the secure version of ipMAX, DH gains no information regarding ${\gamma }_k$, q, and $y_i$. Accordingly, the above simulation-based argument shows that the proposed ipMAX protocol is secure in the semi-honest model. From an intuitive perspective, under the dual non-colluding cloud server setting, DH sees only encrypted values, whereas CSP observes ciphertexts, together with plaintext values masked by randomness. Accordingly, as long as DH and CSP remain non-colluding, the secure version of ipMAX reveals no information about either the input data or the computation results in the semi-honest setting.    □

The ipMAX protocol also provides protection against attacks based on data access patterns. Informally, it either applies the same computations independently to each data point, regardless of the intermediate outcomes, or operates on a single aggregated value obtained from all data points. Concretely, the values $x_i$, $y_i$, and $z_i$ are computed by applying the same equations in every case, regardless of the results of the intermediate computations (lines 3–5 and 17–21). The remaining operations (lines 6–16) are applied only to a single value obtained by aggregating all data points. Accordingly, because neither DH nor CSP can infer any information about the input data or the computation outcomes, the protocol is resilient to the attacks that exploit data access patterns.

3.1.2. Secure Version of the ipMIN Protocol

The secure variant of the ipMIN protocol determines the minimum value in the input dataset while preserving the privacy of both the input data and the computation results. Following the same approach as in the prior work [19], the ipMIN algorithm is derived by running the ipMAX algorithm on the 1’s complement of the input data. That is, the ipMAX protocol can be used to compute the minimum by replacing each data value $d_i$ with its 1’s complement $\overline{d_i}$. Accordingly, the ipMIN protocol can be formally expressed as follows:

$$\begin{array}{c}\hfill F_{ipMIN}({\left\{{\langle E\left(d_i\right)\rangle }_B\right\}}_{i\in \left[n\right]},SK)=F_{ipMAX}({\left\{{\langle E\left(\overline{d_i}\right)\rangle }_B\right\}}_{i\in \left[n\right]},SK)\end{array}$$

(22)

In summary, the ipMIN protocol is realized by executing the ipMAX protocol on the 1’s complement of the input dataset, whereas the original ipMAX protocol is executed on the unmodified input data. As a result, the efficiency and security properties of ipMIN are identical to those of ipMAX, since the two protocols share the same structure and sequence of operations. For clarity, an illustrative example of the ipMIN protocol is provided in

Table 8. Example of secure version of the ipMIN Protocol (Algorithm 2).

j	${\left\{{\langle \mathit{E}\left({\mathit{d}}_{\mathit{i}}\right)\rangle }_{\mathit{B}}\right\}}_{\mathit{i}\in \left[5\right]}$	s	$\mathit{\rho }$	${\left\{\mathit{E}\left({\mathit{\gamma }}_{\mathit{k}}\right)\right\}}_{\mathit{k}\in 〚2〛}$	$\mathit{E}\left(\mathit{q}\right)$	${\left\{\mathit{E}\left({\mathit{C}}_{\mathit{i}}\right)\right\}}_{\mathit{i}\in \left[5\right]}$
·	·	·	·	·	·	$\left\{E\right(1),E(1),E(1),E(1),E(1\left)\right\}$
7	$\left\{E\right(1),E(1),E(1),E(1),E(1\left)\right\}$	5	2	$\left\{E\right(1),E(1),E(1\left)\right\}$	$E\left(0\right)$	$\left\{E\right(1),E(1),E(1),E(1),E(1\left)\right\}$
6	$\left\{E\right(0),E(0),E(1),E(1),E(1\left)\right\}$	3	6	$\left\{E\right(0),E(0),E(1\left)\right\}$	$E\left(0\right)$	$\left\{E\right(0),E(0),E(1),E(1),E(1\left)\right\}$
5	$\left\{E\right(0),E(1),E(0),E(0),E(0\left)\right\}$	0	3	$\left\{E\right(0),E(1),E(1\left)\right\}$	$E\left(1\right)$	$\left\{E\right(0),E(0),E(1),E(1),E(1\left)\right\}$
4	$\left\{E\right(1),E(0),E(0),E(1),E(1\left)\right\}$	2	4	$\left\{E\right(1),E(1),E(0\left)\right\}$	$E\left(0\right)$	$\left\{E\right(0),E(0),E(0),E(1),E(1\left)\right\}$
3	$\left\{E\right(0),E(1),E(1),E(1),E(1\left)\right\}$	2	1	$\left\{E\right(0),E(1),E(1\left)\right\}$	$E\left(0\right)$	$\left\{E\right(0),E(0),E(0),E(1),E(1\left)\right\}$
2	$\left\{E\right(1),E(0),E(1),E(0),E(1\left)\right\}$	1	8	$\left\{E\right(0),E(0),E(1\left)\right\}$	$E\left(0\right)$	$\left\{E\right(0),E(0),E(0),E(0),E(1\left)\right\}$
1	$\left\{E\right(0),E(1),E(0),E(0),E(0\left)\right\}$	0	5	$\left\{E\right(1),E(0),E(1\left)\right\}$	$E\left(1\right)$	$\left\{E\right(0),E(0),E(0),E(0),E(1\left)\right\}$
0	$\left\{E\right(1),E(0),E(1),E(1),E(0\left)\right\}$	0	7	$\left\{E\right(1),E(1),E(1\left)\right\}$	$E\left(1\right)$	$\left\{E\right(0),E(0),E(0),E(0),E(1\left)\right\}$

The bit length of input data is $l=8$. The bit length of the number of the input data points is $\theta =3$. - Input: ${\left\{{\langle E\left(\overline{d_i}\right)\rangle }_B\right\}}_{i\in \left[5\right]}=\{{\langle E\left(\overline{106}\right)\rangle }_B,{\langle E\left(\overline{85}\right)\rangle }_B,{\langle E\left(\overline{50}\right)\rangle }_B,{\langle E\left(\overline{38}\right)\rangle }_B,{\langle E\left(\overline{35}\right)\rangle }_B\}$. - Output: ${\left\{E\left(C_i\right)\right\}}_{i\in \left[5\right]}=\{E\left(0\right),E\left(0\right),E\left(0\right),E\left(0\right),E\left(1\right)\}$ (indicating that the minimum value is 35).

.

3.2. Efficient Version of the ipMAX/ipMIN Protocols

The efficient version of the ipMAX/ipMIN protocols improves upon the efficiency of the secure version. Consistent with [19], the proposed protocols also provide an efficient version by adding the specific step. As described above, the proposed protocols find the maximum/minimum value through iterative updates of the auxiliary data $C_i$, processing one bit per iteration from the most significant bit to the least significant bit. The secure version consistently performs all l iterations, regardless of the input dataset to ensure that no information about the input or output is leaked. However, the efficient version checks if the maximum/minimum value is determined at each iteration, and if the maximum/minimum value is determined, it terminates immediately, thereby reducing the number of iterations and improving efficiency.

The efficient version is designed to terminate as soon as only one data point remains in the candidate set. As described in the previous section, the protocols initially include all input data points in the candidate set and, at each iteration, eliminate the unpredicted maximum/minimum candidates. Consequently, once the candidate set is reduced to a single remaining data point, the final maximum/minimum value has been determined, and the protocol can stop early. Because the auxiliary data $C_i$ specifies whether the corresponding data point remains in the candidate set ($C_i=1$) or has been removed ($C_i=0$), the number of remaining candidates can be obtained by summing all $C_i$ values.

It should be noted, however, that the efficient version does not always provide a substantial performance advantage. In particular, when multiple identical maximum/minimum values exist in the input dataset, or when the distinguishing bit appears only at the least significant position, the runtime of the efficient version converges to that of the secure version. Thus, the efficient version yields a benefit only when the maximum/minimum value is determined before the l-th round, allowing the protocol to terminate early; if the value is determined only in the final round, its efficiency is similar to that of the secure version.

The efficient version also introduces limited information leakage through its termination bit, which reveals the bit position at which the maximum/minimum value is determined. This leakage means an upper bound on the difference between the maximum/minimum value and the second-largest/-smallest value, rather than directly revealing the magnitude of the maximum/minimum itself (If ipMAX terminates at the ($l-1$)-th bit, an adversary can infer that the maximum value exceeds $2^l-1$). Importantly, this does not reveal which data point is the maximum/minimum, nor the second-largest/-smallest value. More specifically, if ipMAX/ipMIN performs the checking step at every bit position and terminates at the t-th bit ($0\le t<l$), then an adversary can infer that the gap between the maximum/minimum value and the second-largest/-smallest value is at most $2^{t+1}-1$.

This leakage can be reduced by enlarging the bound on that difference. To improve privacy, the checking step need not be performed at every bit position; instead, it may be restricted to a selected subset of bits. More frequent checking improves efficiency but increases leakage, whereas less frequent checking offers stronger privacy at the cost of reduced efficiency. Hence, the proposed protocols provide a multi-level trade-off between security and efficiency, and the check bit set should be chosen according to the privacy and performance requirements of the target application. In addition, to further reduce result leakage, the check bit set should avoid including the first few most significant bits and the last few least significant bits. Further discussion can be found in [19].

3.2.1. Efficient Version of the ipMAX Protocol

Algorithm 3 describes the efficient variant of the ipMAX protocol, and 

Table 9. Example of an efficient version of the ipMAX Protocol (Algorithm 3).

j	${\left\{{\langle \mathit{E}\left({\mathit{d}}_{\mathit{i}}\right)\rangle }_{\mathit{B}}\right\}}_{\mathit{i}\in \left[5\right]}$	s	$\mathit{\rho }$	${\left\{\mathit{E}\left({\mathit{\gamma }}_{\mathit{k}}\right)\right\}}_{\mathit{k}\in 〚2〛}$	$\mathit{E}\left(\mathit{q}\right)$	${\left\{\mathit{E}\left({\mathit{C}}_{\mathit{i}}\right)\right\}}_{\mathit{i}\in \left[5\right]}$	$\mathit{ϵ}$
·	·	·	·	·	·	$\left\{E\right(1),E(1),E(1),E(1),E(1\left)\right\}$	·
7	$\left\{E\right(0),E(0),E(0),E(0),E(0\left)\right\}$	0	3	$\left\{E\right(0),E(1),E(1\left)\right\}$	$E\left(1\right)$	$\left\{E\right(1),E(1),E(1),E(1),E(1\left)\right\}$	r
6	$\left\{E\right(1),E(1),E(1),E(0),E(0\left)\right\}$	3	7	$\left\{E\right(0),E(1),E(0\left)\right\}$	$E\left(0\right)$	$\left\{E\right(1),E(1),E(1),E(0),E(0\left)\right\}$	r
5	$\left\{E\right(0),E(0),E(0),E(1),E(1\left)\right\}$	0	4	$\left\{E\right(1),E(0),E(0\left)\right\}$	$E\left(1\right)$	$\left\{E\right(1),E(1),E(1),E(0),E(0\left)\right\}$	r
4	$\left\{E\right(1),E(1),E(0),E(1),E(0\left)\right\}$	2	6	$\left\{E\right(0),E(0),E(0\left)\right\}$	$E\left(0\right)$	$\left\{E\right(1),E(1),E(0),E(0),E(0\left)\right\}$	r
3	$\left\{E\right(0),E(0),E(1),E(0),E(1\left)\right\}$	0	1	$\left\{E\right(0),E(0),E(1\left)\right\}$	$E\left(1\right)$	$\left\{E\right(1),E(1),E(0),E(0),E(0\left)\right\}$	r
2	$\left\{E\right(1),E(0),E(1),E(1),E(0\left)\right\}$	1	5	$\left\{E\right(1),E(1),E(0\left)\right\}$	$E\left(0\right)$	$\left\{E\right(1),E(0),E(0),E(0),E(0\left)\right\}$	0

The bit length of input data is $l=8$. The bit length of the number of the input data points is $\theta =3$. r is a random value. For the given input data, the efficient version terminates at the second bit; therefore, it reveals the information that the maximum value is determined at the second bit. On the other hand, the secure version terminates at the 0th bit for the same input data in Table 4. The secure version always runs all for-loops, regardless of the input data and terminates at the 0th bit. Thus, it reveals no information about the input data. - Input: ${\left\{{\langle E\left(d_i\right)\rangle }_B\right\}}_{i\in \left[5\right]}=\{{\langle E\left(85\right)\rangle }_B,{\langle E\left(82\right)\rangle }_B,{\langle E\left(79\right)\rangle }_B,{\langle E\left(54\right)\rangle }_B,{\langle E\left(41\right)\rangle }_B\}$. $V=\{l-1,\cdots ,2,1,0\}$ (indicating that the DH and CSP perform the checking step in all iterations). - Output: ${\left\{E\left(C_i\right)\right\}}_{i\in \left[5\right]}=\{E\left(1\right),E\left(0\right),E\left(0\right),E\left(0\right),E\left(0\right)\}$ (indicating that the maximum value is 85).

provides an illustrative example to facilitate understanding. In addition to the encrypted input dataset ${\left\{{\langle E\left(d_i\right)\rangle }_B\right\}}_{i\in \left[n\right]}$, this variant takes a public parameter called the checking bit set V. For each $v\in V$, the protocol performs a check step at bit position v (at the ($l-v$)-th iteration) to determine whether exactly one candidate data point remains. The output is identical to that of the secure version: an auxiliary dataset ${\left\{E\left(C_i\right)\right\}}_{i\in \left[n\right]}$, where the data point $d_i$ associated with $C_i=1$ is identified as the final maximum value. Recall that n is the number of input data points, l is the bit length of the data, and $\theta$ is the bit length of the number n.

We only explain the checking step (lines 22–36) that is different from that of the secure version (Algorithm 2).

• (Checking step: lines 22–36) privately comparing the number of candidate data points to one: First, the DH checks whether the current bit (iteration) corresponds to a checking bit in the set V (line 22). If it is in the checking bit set, the DH proceeds with the following computations. The DH computes the value $ϵ$ and sends it to the CSP (lines 23–25).

Algorithm 3 Efficient version of the ipMAX Protocol.
Input: ${\left\{{\langle E\left(d_i\right)\rangle }_B\right\}}_{i\in \left[n\right]}$ where ${\langle E\left(d_i\right)\rangle }_B=\{E\left(d_{i,l-1}\right),\cdots ,E\left(d_{i,1}\right),E\left(d_{i,0}\right)\}$, $d_i={\sum }_{j=0}^{l-1}{d}_{i,j}·2^j$ and $d_{i,j}\in \{0,1\}$ Checking bit set $V=\left\{v\right|$ DH and CSP check whether the number of candidate data points is one in the v-th bit (i.e., ($l-v$)-th iteration), $0\le v<l\}$ Output: ${\left\{E\left(C_i\right)\right\}}_{i\in \left[n\right]}$ where $C_i=1$ if the corresponding data $d_i$ is the maximum and otherwise, $C_i=0$.
DH: 1: $E\left(C_i\right)\leftarrow E\left(1\right)$	$(i\in \left[n\right])$
2: for $j=l-1$ to 0 do
3:    $E\left({\alpha }_i\right)\leftarrow E\left(C_i\right)\ast E\left(r_i\right)$	$(r_i{\in }_R{\mathbb{Z}}_N,i\in \left[n\right])$
4:    $E\left({\beta }_i\right)\leftarrow E\left(d_{i,j}\right)\ast E\left(t_i\right)$	$(t_i{\in }_R{\mathbb{Z}}_N,i\in \left[n\right])$
5:    $E\left(x_i\right)\leftarrow E{\left(C_i\right)}^{N-t_i}\ast E{\left(d_{i,j}\right)}^{N-r_i}\ast E(N-r_i{t}_i)$	$(i\in \left[n\right])$
6:    $E\left(\lambda \right)\leftarrow E\left(\rho \right)\ast {\prod }_{i=1}^{n}E\left(x_i\right)$	$\left(\rho {\in }_R{\mathbb{Z}}_N\right)$
7:    $DH\to CSP:{\left\{E\left({\alpha }_i\right)\right\}}_{i\in \left[n\right]},{\left\{E\left({\beta }_i\right)\right\}}_{i\in \left[n\right]},E\left(\lambda \right)$
CSP: 8:    Decrypt $E\left({\alpha }_i\right),E\left({\beta }_i\right),E\left(\lambda \right)$	$(i\in \left[n\right])$
9:    $w_i\leftarrow {\alpha }_i·{\beta }_i$	$(i\in \left[n\right])$
10:    $\gamma \leftarrow \lambda +{\sum }_{i=1}^n{w}_i$
11:    Encrypt ${\gamma }_k$	$(k\in 〚\theta -1〛)$
12:    $CSP\to DH:{\left\{E\left({\gamma }_k\right)\right\}}_{k\in 〚\theta -1〛}$
DH & CSP: 13:    $(E\left(q\right),\perp )\leftarrow F_{SEQ}({\{E\left({\gamma }_k\right),E\left({\rho }_k\right)\}}_{k\in 〚\theta -1〛},SK)$
DH: 14:    $E\left(\delta \right)\leftarrow E\left(q\right)\ast E\left(\tau \right)$	$\left(\tau {\in }_R{\mathbb{Z}}_N\right)$
15:    $DH\to CSP:E\left(\delta \right)$
CSP: 16:    Decrypt $E\left(\delta \right)$
17:    $y_i\leftarrow {\alpha }_i·\delta +w_i$	$(i\in \left[n\right])$
18:    Encrypt $y_i$	$(i\in \left[n\right])$
19:    $CSP\to DH:{\left\{E\left(y_i\right)\right\}}_{i\in \left[n\right]}$
DH: 20:    $E\left(z_i\right)\leftarrow E{\left(C_i\right)}^{N-\tau }\ast E{\left(q\right)}^{N-r_i}\ast E(N-r_i\tau )$	$(i\in \left[n\right])$
21:    $E\left(C_i\right)\leftarrow E\left(x_i\right)\ast E\left(y_i\right)\ast E\left(z_i\right)$	$(i\in \left[n\right])$
22:    if $j\in V$ then
23:      $E\left(p\right)\leftarrow E(N-1)\ast {\prod }_{i=1}^{n}E\left(C_i\right)$
24:      $E\left(ϵ\right)\leftarrow E{\left(p\right)}^{\eta }$	$(\eta \ne 0{\in }_R{\mathbb{Z}}_N)$
25:      $DH\to CSP:E\left(ϵ\right)$
CSP: 26:      Decrypt $E\left(ϵ\right)$ 27:      if $ϵ==0$ then 28:         $\varphi =1$ 29:      else 30:         $\varphi =0$ 31:      end if 32:      $CSP\to DH:\varphi$
DH: 33:      if $\varphi ==1$ then 34:          return ${\left\{E\left(C_i\right)\right\}}_{i\in \left[n\right]}$ 35:      end if 36:    end if 37: end for 38: return ${\left\{E\left(C_i\right)\right\}}_{i\in \left[n\right]}$

$$\begin{array}{cc}\hfill E\left(p\right)& \leftarrow E(-1+\sum _{i=1}^n{C}_i)\hfill \end{array}$$

(23)

$$\begin{array}{cccc}\hfill E\left(ϵ\right)& \leftarrow E\left(\eta p\right)\hfill & \hfill & (\eta \ne 0{\in }_R{\mathbb{Z}}_n)\hfill \end{array}$$

(24)

Once the CSP receives $ϵ$, it decrypts the ciphertext (line 26) and checks whether the resulting value is zero. If the decrypted value $ϵ=0$, the CSP sets $\varphi =1$; otherwise, if $ϵ\ne 0$ (i.e., a random value), the CSP sets $\varphi =0$ and returns this bit to DH in plaintext (i.e., without encryption) (lines 27–32). When only one candidate data point remains, the maximum value has already been determined, which implies $p=0$ and, therefore, yields $\varphi =1$. In this case, DH returns the auxiliary dataset ${\left\{E\left(C_i\right)\right\}}_{i\in \left[n\right]}$ as the output and halts the protocol (lines 33–35). By contrast, if $\varphi =0$, then $p\ne 0$, meaning that the maximum value has not yet been determined, and the protocol proceeds to the next iteration. We next analyze the efficiency of the efficient version. The security proof is omitted here, since it follows by essentially the same argument as that used for the secure version.

• Efficiency Evaluation: Because the efficient version can stop before reaching the l-th iteration when the maximum value is found early, it executes all l iterations only in the worst case. By contrast, the secure version always runs for exactly l iterations, regardless of the intermediate outcomes, where l denotes the bit length of the data. Consequently, the efficient version requires at most $4l$ communication rounds, and its communication-volume complexity is bounded by $\mathcal{O}\left(3nlC\right)$, including the communication cost of the SEQ protocol. Note that the round cost, which directly affects the execution time, is independent of the number n of input data points, as in the secure version.

  Table 10. The communication and computation costs for a single iteration (i.e., one bit) of the efficient version. These operations are repeated for at most l iterations, depending on an input dataset.

  (a) Communication costs
  Step	Rounds	Volume
  		DH		CSP
  Steps 1–3	3	$(2n+\theta +2)·C$		$(n+\theta +1)·C$
  Checking step	1	$1·C$		1
  Total	4	$(2n+\theta +3)·C$		$(n+\theta +1)·C+1$
  (b) Computation costs
  Case	Step	DH		CSP
  		Enc/Dec	Exp	Enc/Dec	Exp
  Normal case	Steps 1–3	$4n+2$	$4n+2\theta +1$	$3n+2\theta +3$	0
  	Checking step	0	1	1	0
  	Total	$4n+2$	$4n+2\theta +2$	$3n+2\theta +4$	0
  Precom- putation	Steps 1–3	0	$4n+2\theta +1$	$3n+2\theta +3$	0
  	Checking step	0	1	1	0
  	Total	0	$4n+2\theta +2$	$3n+2\theta +4$	0
  Parallel execution	Steps 1–3	2	5	6	0
  	Checking step	0	1	1	0
  	Total	2	6	7	0

  $Parallelexecution$ means the number of sequential batches, with sufficiently many parallel threads assumed.

  shows the communication costs (communication rounds and volume) and the computation costs (number of encryption/decryption and exponentiation operations) performed by the DH and CSP at each step of the protocol.

The checking step requires one round of communication: the DH sends value $ϵ$ to the CSP, which responds with 1-bit value $\varphi$. From a computational point of view, the DH performs one exponentiation operation and the CSP performs one decryption operation. Since the multiplication operations in line 23 are performed locally and have a negligible impact on performance as mentioned in Section 2.4, they are excluded from the efficiency evaluation.

3.2.2. Efficient Version of the ipMIN Protocol

The efficient version of the ipMIN protocol is derived from the same underlying idea as the efficient version of ipMAX. In particular, it terminates once the minimum-candidate set has been reduced to a single data point, and its checking step is identical to that of the efficient variant of the ipMAX protocol described above. As in the secure version, the ipMIN protocol is realized by running the corresponding ipMAX algorithm on the 1’s complement of the input dataset. Accordingly, the efficient version of the ipMIN protocol is obtained by running the efficient version of ipMAX on the 1’s complement of the input data, whereas running the efficient version of ipMAX protocol on the original dataset yields the maximum value. Because the efficient version of ipMIN shares the same efficiency and security characteristics as the efficient version of ipMAX, a separate detailed discussion is unnecessary.

4. Experimental Results

This section presents the experimental environment and dataset, followed by the experimental results for various parameters. In order to demonstrate the efficiency of the proposed protocols, we implemented the ipMAX protocol in C++ using Paillier cryptosystem as the underlying additively homomorphic encryption scheme and its library [32]. The machine used for the DH was equipped with an Intel Core i9-14900K CPU @ 1.4 GHz (24 cores) and 16 GB of RAM, while that for the CSP was equipped with an Intel Core i5-14400 @ 2.50 GHz (10 cores) and 8 GB of RAM. Both the DH and CSP systems ran Ubuntu 18.04 LTS. The two machines were physically separated and communicated over a 1 Gbps network connection.

The experimental dataset was “Facebook Live Sellers in Thailand” from the UCI machine learning repository, which contains 7050 data points (n = 7050) with 16 bits (l = 16) [33]. We measured the communication volume and the execution time for the secure and efficient versions. We then compared these results to those of the prior protocols [20]. We first ran the protocols using a 1024-bit key and 16 threads for parallel execution.

Table 11. Comparison of communication volume and execution time with the prior protocol.

Protocol	Communication Volume			Execution Time
	DH (MB)	CSP (MB)	Ratio (%)	Time (s)	Ratio (%)
Prior protocol [20]	110.21	55.11	100%	212	100%
Secure version	55.2	27.59	50%	166	78%

shows the experimental results along with a comparative analysis.

As shown in Table 11, the secure version reduces communication volume and execution time by 50% and 22%, respectively, compared to the prior protocol. In the experimental dataset, the maximum value is determined at the 7th iteration (i.e., the 9th bit of 16 bits), whereas the secure version consistently performs all 16 iterations. Due to this early termination, the efficient version reduces communication volume and execution time by 78% and 64%, respectively. Note that the efficiency gain results from revealing the bit position at which the maximum/minimum value is determined. To carry out a comprehensive experimental evaluation and performance analysis, we varied several key parameters, including the number of threads, the input size, the key size, and the bit length of the data. A separate evaluation of ipMIN is omitted because it has identical runtime and communication characteristics to ipMAX.

Figure 2a illustrates the reduction in execution time as the number of parallel threads increases. As mentioned in the previous section, the proposed protocols support the parallel computation of individual data, and therefore, doubling the number of threads halves the execution time. For example, in the secure version (solid red line), the execution times are 1026, 550, and 304 s for two, four, and eight threads, respectively. A similar pattern is observed in the efficient version (dashed green line). The prior protocol [20] takes an average of 30% longer than the secure version (dotted blue line). As the number of threads increases, the execution time initially decreases; however, once the degree of parallelism exceeds a certain point, the improvement diminishes, and the performance eventually reaches saturation. This pattern is commonly observed in practical deployments. The following model captures the practical limitation of execution-time scaling with increased parallelism:

$$\begin{array}{c}\hfill T=N_R{T}_{RT}+{\displaystyle \frac{V_C}{BW}}+{\displaystyle \frac{T_C}{N_P}}+T_O\end{array}$$

(25)

In the above equation, T is the total execution time, $N_R$ is the number of communication/synchronization rounds, $T_{RT}$ is the round-trip time between DH and CSP, and $V_C$ is the communication volume (total amount of data transmitted during execution).

$BW$ is the effective bandwidth, $T_C$ is the total computation time without parallelization, $N_P$ is the number of parallel threads, and $T_O$ is the time spent on parallel/coordination overhead. When the number of parallel threads, $N_P$, is small, the overall execution time T is dominated by the term ${\displaystyle \frac{T_C}{N_P}}$. In this setting, the round-trip time remains small, the reduction in the effective bandwidth is limited, and the additional overhead is relatively small; thus, these factors have little impact on the total runtime. Consequently, increasing $N_P$ reduces the execution time rapidly. However, beyond a certain level of parallelism, the decrease in ${\displaystyle \frac{T_C}{N_P}}$ becomes small, while the other terms become more significant: the effective round-trip time can increase, the effective bandwidth can decrease, and additional system overheads arise, increasing $T_O$. As a result, once $N_P$ exceeds a threshold, the runtime benefit from reducing ${\displaystyle \frac{T_C}{N_P}}$ is outweighed by the runtime penalties from $T_{RT}$, $BW$, and $T_O$, leading to saturation, in which increasing parallelism no longer reduces the overall execution time.

Figure 2b shows that the communication volume remains constant, regardless of the number of threads. In the figure, the solid color bars indicate the communication volume of the DH, and the hatched bars represent that of the CSP. Even if the number of threads increases, the protocol allocates the same computational tasks to the threads, and therefore, the overall amount of communication remains unchanged. Compared to the prior protocol, the communication volumes are reduced by 50% and 78% for the secure and efficient versions, respectively. For each protocol/version, the communication volume of the CSP accounts for approximately 50% of that of the DH.

Figure 2c,d show that both the execution time and communication volume increase linearly and consistently as the amount of input data grows. This is because an increase in input data leads to a proportional increase in the amount of data to be processed. For the secure version, an additional 1000 data points results in an increase of approximately 23 s in execution time and an additional 7.81 MB and 3.91 MB of data transmission by the DH and CSP, respectively. For the efficient version, an additional 1000 data points results in an increase of around 11 s in execution time and an additional 3.42 MB and 1.71 MB of data transmission by the DH and CSP, respectively.

Figure 2e,f show that both the execution time and communication volume increase as the key size increases. This is because the ciphertext size of the Paillier cryptosystem is twice the modulus size (i.e., the key size). For the proposed protocol, the execution time approximately doubles when the key size increases from 512 to 1024 bits. When the key size increases from 1024 to 2048 bits, the execution time increases by more than three times. Compared to the prior protocol, the secure and the efficient versions are reduced by around 50% and 77%, respectively, when using a 2048-bit key. In terms of communication volume, both the secure and efficient versions increase constantly and twice as much as the key size doubles. This is because the ciphertext size is double the key size and determines the communication volume.

Figure 2g,h show the execution time and communication volume for the bit length of the input data. Various data with different bit-lengths are generated by truncating or extending the least significant bits of the original data using bit-shift operations. As shown in the figures, the execution time and communication volume of the secure version increase linearly with the data length since the secure version performs one iteration per bit. For every 8-bit increase, an additional 80 s is required, and the DH and CSP transmit an additional 27.6 MB and 13.8 MB, respectively. However, the efficient version maintains a constant execution time and communication volume, regardless of the data length. This is because, in our experimental dataset, the maximum value is determined in the seventh iteration, causing the protocol to terminate early. In other words, even when the data length increases from 8 to 32 bits, the efficient version constantly terminates at the seventh iteration, resulting in no additional cost.

As demonstrated in Figure 2a, the overall performance of the proposed protocols is proportional to the number of parallel threads since the computations on each data point are independent and can be executed in parallel. Therefore, it is expected that the protocol will significantly improve runtime performance when deployed in a cloud computing environment that supports a large number of parallel executions.

5. Related Works

Most existing ppMAX/ppMIN protocols relied on costly comparison operations, which causes the execution time to increase rapidly as the amount of input data grows. Therefore, these protocols are unsuitable for large-scale data analytics. To overcome this inefficiency, some protocols provide approximate results or allow partial data leakage. In addition, other approaches, such as those based on quantum cryptography, are difficult to implement in practice and only provide simulation-based results without concrete results.

The authors of [18] focused on privacy-preserving reinforcement learning for patient treatment. They introduced cryptographic protocols that enable the secure computations, such as comparison, maximum selection, exponentiation, and division on encrypted data. Their protocol computes on encrypted health data without revealing sensitive information and is based on the CKKS approximate homomorphic encryption scheme [22] by Cheon et al. However, the results may contain small numerical errors since the protocol is based on an approximate scheme. Moreover, their maximum protocol performs costly comparison operations for each data point, making it inefficient and unsuitable for large-scale data applications. The authors of [21] tackled the problem of finding the maximum value and its index in data encrypted in the CKKS scheme [22]. Due to the difficulty of emulating comparison operations with polynomials using fully homomorphic encryption, the authors introduced a protocol that finds all data whose top k most significant bits match those of the true maximum. However, the protocol involves the limitation that it outputs only an approximate maximum value, and the accuracy of the result depends on the parameter k. Furthermore, it performs expensive comparison operations for each data point, making it inefficient and unsuitable for large-scale data applications.

The authors of [8] proposed a lightweight protocol for the Internet of Things (IoT) that enables maximum/minimum range queries (i.e., finding the maximum or minimum value within a dataset) without revealing sensitive information. Rather than using heavy cryptography, the protocol uses a probabilistic approach based on simple hashing and bitwise XOR operations. However, the protocol reveals the maximum value of the transmitted data to intermediate nodes (aggregators). Due to the probabilistic nature of the method, the results may contain errors. The authors of [9] proposed a sealed-bid auction that finds the maximum bid without exposing the bids of each bidder in an IoT environment. The protocol supports multiple authorities to overcome the limitations of a single authority (e.g., an excessive operational burden). It runs on simple operations since it is based on the protocol proposed in [8]. However, due to the protocol of [8], it inherits the same limitations as the previous work. In [34], the authors revisited the existing protocols [35,36] for securely computing the minimum and k-th minimum in privacy-sensitive mobile sensing applications and proposed improvements to enhance efficiency and accuracy. Their compressing min computation protocol (CMCP) reduces the total runtime by eliminating or parallelizing certain steps. However, since the protocol is probabilistic, it may produce approximate results with potential errors, similar to prior works [8,9,18,21]. In addition, the evaluation is limited to simulations, and the authors did not provide concrete experimental results to demonstrate real-world performance.

The authors of [37] explored a quantum cryptographic solution to the multi-party maximum problem. First, they defined a basic secure multi-party computation of the logical OR operation. Then, they implemented the computation using single photons (quantum states) to achieve information-theoretic security. However, the approach is theoretical and requires a quantum communication infrastructure, which is impractical for large networks. A simulation was conducted on a small scale, and scaling up to include more parties or larger bit lengths may present challenges related to quantum noise and error correction. The authors of [38] proposed a quantum cryptography-based approach to address privacy-preserving range maximum/minimum queries in edge-based Internet of Things (IoT) environments. They proposed a novel quantum protocol for range queries using an orthogonal social interaction distinguishability (OSID) quantum method. This scheme allows an edge IoT server to process encrypted quantum states from devices and determine the maximum sensor within a certain range without learning any individual sensor data. However, as with the method in [37], this protocol is highly dependent on quantum hardware, which poses practical limitations to real-world deployment. Thus, further advancements in quantum technologies are required before this approach is considered feasible.

The work in [19] introduced highly efficient privacy-preserving protocols, based on multiparty computation, for identifying the maximum/minimum value in large-scale datasets. The authors formally demonstrated that those protocols preserve the privacy of the input data, the computation outcomes, and the associated data-access patterns. Their protocols also include secure and efficient variants, such as the protocols proposed here. Nevertheless, compared with our protocols, their construction incurs approximately twice the communication and computation cost.

Table 12. Summary of existing ppMAX/ppMIN protocols.

Ref.	Privacy	Accuracy of Result	Practical Feasibility	Key Techniques	Limitations
[8]	Low	Approximate	Real Experiment	Hash, Probabilistic	Leaks Max value to aggregator, Potential false positives
[9]	Low	Approximate	Real Experiment	Hash, Probabilistic	Leaks Max value to aggregator, Potential false positives
[34]	Low-Moderate	Approximate	Simulation	Probabilistic, Optimization	Probabilistic errors, Lacks real-world evaluation
[18]	Moderate	Approximate	Simulation	Homomorphic encryption	Numerical errors, High computation cost for comparisons
[21]	Moderate	Approximate	Simulation	Homomorphic encryption	Accuracy depends on parameter k, High computation cost for comparisons
[37]	High	Exact	Simulation	Quantum	Requires unavailable quantum infrastructure
[38]	High	Exact	Simulation	Quantum, Bloom filter	Dependent on specialized quantum hardware
[19]	High	Exact	Real Experiment	Multiparty computation	High communication overhead
[Ours]	High	Exact	Real Experiment	Homomorphic encryption	The cost of the efficient version can converge to that of the secure version

compares and summarizes the aforementioned related works.

6. Conclusions

In big data analytics, data is a key factor that determines the accuracy and efficiency of models. This directly impacts the quality of the analysis results and learning performance. Outsourcing data to external parties can lead to the leakage of personal information or the loss of corporate intellectual property, which can result in severe privacy violations and economic or legal consequences. Therefore, it is important to study large-scale data analytics protocols that ensure privacy protection and maintain computational efficiency.

In this paper, we have proposed improved privacy-preserving protocols (ipMAX/ipMIN protocols) for securely finding the maximum or minimum value over encrypted large-scale data in outsourced cloud computing environments. The proposed protocols consist of a secure version specialized for security and an efficient version specialized for efficiency. Compared to the prior protocol [20], the secure version reduces the number of communication rounds by 25%, the communication volume by 50%, and the computational cost by 42%, while preserving privacy and accuracy. The efficient version can provide more efficient results. These efficiency improvements are achieved by integrating independent subprotocols, reusing intermediate computational results, and eliminating computations that scale with the number of input data points. While existing protocols perform costly comparison operations in proportion to the size of the input data, the proposed protocols perform more efficient equality operations in proportion to the length of the data. This property substantially increases the efficiency of the proposed protocols since data length is significantly smaller than the amount of the data in large-scale data. Our experiments demonstrated the theoretical analysis: the communication volume was reduced by half, and the execution time by 22%, compared to the prior protocol. Moreover, since the proposed protocols support fully parallel execution, it is expected that the performance will be significantly improved in cloud environments with massive parallel computing capabilities. The protocols enable even data owners with insufficient computing power for large-scale data analytics to participate without information exposure. Under the secure version, the cloud servers are unable to infer any information about either the input data or the final output. This makes the protocols well suited for efficient deployment on public cloud platforms operated by major IT providers. By contrast, the efficient version allows limited information leakage—specifically, the bit position at which the maximum/minimum value is determined—and can achieve higher efficiency by trading a small amount of privacy for improved performance.

Although privacy-preserving computations such as maximum/minimum, bit-decomposition and comparison have been proposed using multi-party computation (MPC) as the main privacy-preserving technique, they are inefficient for use in real-world environments. Because the characteristics of MPC is similar to homomorphic encryption in terms of the design of privacy-preserving protocols, the idea presented in this paper, which is the integration of independent subprotocols, will significantly contribute to enhancing the efficiency of computation protocols using MPC. In addition, future work includes extending the proposed ipMAX/ipMIN protocols to support more complex statistical queries, such as median and top-k selection, which could further improve overall performance. However, a key technical challenge will be to adapt the proposed protocols to the input/output requirements of these tasks without degrading efficiency.