Enhancing Efficiency and Security in Unbalanced PSI-CA Protocols through Cloud Computing and Homomorphic Encryption in Mobile Networks

Abstract

Private Set Intersection Cardinality (PSI-CA) is a cryptographic method in secure multi-party computation that allows entities to identify the cardinality of the intersection without revealing their private data. Traditional approaches assume similar-sized datasets and equal computational power, overlooking practical imbalances. In real-world applications, dataset sizes and computational capacities often vary, particularly in Internet of Things and mobile scenarios where device limitations restrict computational types. Traditional PSI-CA protocols are inefficient here, as computational and communication complexities correlate with the size of larger datasets. Thus, adapting PSI-CA protocols to these imbalances is crucial. This paper explores unbalanced scenarios where one party (the receiver) has a relatively small dataset and limited computational power, while the other party (the sender) has a large amount of data and strong computational capabilities.This paper, based on the concept of commutative encryption, introduces Cuckoo filter, cloud computing technology, and homomorphic encryption, among other technologies, to construct three novel solutions for unbalanced Private Set Intersection Cardinality (PSI-CA): an unbalanced PSI-CA protocol based on Cuckoo filter, an unbalanced PSI-CA protocol based on single-cloud assistance, and an unbalanced PSI-CA protocol based on dual-cloud assistance. Depending on performance and security requirements, different protocols can be employed for various applications.

1. Introduction

1.1. Background

In today’s digital age, data privacy and security have become critically important issues worldwide. With technological advancements and explosive growth in data volumes, individuals and institutions face unprecedented challenges in protecting their privacy. Privacy computing technologies have emerged in response to these challenges, enabling the secure computation and analysis of data without exposing the details of personal information. This is crucial for driving data-driven innovation and services while safeguarding personal privacy and data protection.

Private Set Intersection (PSI) technology is a key technique in the field of privacy computing. It allows two or more parties to identify the common elements in their datasets without revealing any other non-shared data. This technology is highly useful in multiple application scenarios, such as cross-institutional data cooperation, fraud detection, and private contact discovery, without compromising user privacy. It has been applied in various fields, including the genetic testing of fully sequenced human genomes [1], private contact discovery [2], and botnet detection [3]. This study investigates the cardinality of private dataset intersections between two parties, which is an essential aspect of two-party computation (2PC) tasks. Specifically, it involves a sender and a receiver who aim to collaboratively determine the number of common elements in their private datasets. Throughout this process, only the receiver obtains the cardinality of the set intersection, while the sender remains unaware of it. The topic of private-set intersection cardinality is widely researched due to its significant practical applications

1.2. Motivation

While the traditional Private Set Intersection Cardinality (PSI-CA) protocols have been extensively explored in research, real-world applications continue to present unique challenges. Traditional approaches assume similar-sized datasets and equal computational power, overlooking practical imbalances. In real-world applications, dataset sizes and computational capacities often vary, particularly in Internet of Things and mobile scenarios where device limitations restrict computational types. Traditional PSI-CA protocols are inefficient here, as computational and communication complexities correlate with the size of larger datasets. Thus, adapting PSI-CA protocols to these imbalances is crucial.

A compelling example is found in the collaboration between major medical institutions and small health app developers. In this scenario, a large medical institution with extensive patient data and robust computational capabilities collaborates with a small app developer who possesses minimal user data and limited computational resources. The primary goal is to analyze the coverage of health app users within the extensive patient database to assess market penetration and potential partnership opportunities. For instance, the medical institution might want to determine how many of its patients are using the health app to consider recommending it more broadly or collaborating on new features.

This article uses the above scenario as an example to conduct research, but our scenario is not limited to this, and the data types are also diverse. As long as one party has a large number of dataset elements and strong computing and storage capabilities, while the other party has a small number of dataset elements and weak computing and storage capabilities, and both parties want to perform PSI-CA operations, our solution is applicable.

To address the challenges outlined above, this paper delves into the unbalanced Private Set Intersection-Cardinality (PSI-CA) protocols and proposes three innovative unbalanced PSI-CA protocols. In practical applications, different solutions can be chosen based on varying performance and security requirements.

1.3. Main Work

• To address the performance shortcomings of traditional PSI-CA protocols in the face of significant differences in dataset sizes between participants, this paper introduces the first protocol, which is the unbalanced PSI-CA protocol based on Cuckoo filter. This protocol successfully constructs the first unbalanced private intersection cardinality protocol of this article by integrating exchange encryption technologies with Cuckoo filter functionalities for private information retrieval, followed by experimental analysis.
• To alleviate the computational and storage burden on the small health app developer in the first protocol, the paper further proposes an unbalanced PSI-CA protocol based on single-cloud assistance and conducts experimental analysis. This strategy effectively migrates computational and storage tasks to cloud services, significantly optimizing resource utilization efficiency.
• To safeguard against data leakage risks inherent in the unbalanced PSI-CA protocol based on single-cloud assistance, which cannot resist collusion attacks, the paper further designs an unbalanced PSI-CA protocol based on dual-cloud assistance. By employing homomorphic encryption and other security technologies, this scheme resolves potential data leakage risks in the single-cloud protocol while effectively preventing potential collusion attacks.
• Based on the unbalanced PSI-CA protocol based on dual-cloud assistance, this paper also designs the PSI-CA network and establishes corresponding data update strategies, significantly enhancing the practicality of the protocol.

2. Related Works

2.1. Design Framework of Private Set Intersection Protocol

2.1.1. Design Framework Based on Public Key Encryption

The basic idea behind early private-set intersection protocols is to encrypt data elements and then perform comparison operations on the encrypted data. The most widely used technique in this method is homomorphic encryption: The sender encrypts their dataset and sends it to the receiver. The receiver processes these ciphertexts using the properties of homomorphic encryption and returns the results to the sender. The sender then decrypts these results using their own private key to obtain the intersection of the datasets. This public-key-based method generally relies on three main security assumptions [4]:

• Based on Diffie–Hellman (DH) theory: Meadows [5] used the DH key-exchange mechanism, which is based on the discrete logarithm problem, to implement a PSI protocol. In contrast, Huberman et al. [6] explored the use of elliptic curve cryptography in PSI, noting its significant advantages in security and efficiency compared to traditional discrete logarithm-based PSI methods.
• Based on the RSA assumption: DeCristofaro et al. [7] developed a semi-honest PSI protocol using RSA blind signature technology based on the integer factorization problem. Another study [8] showed that PSI schemes based on discrete logarithm cryptography demonstrated higher efficiency compared to those based on integer factorization cryptography.
• Based on homomorphic encryption: Freedman et al. [9] innovatively represented elements as roots of polynomials and encrypted the coefficients of these polynomials using Paillier homomorphic encryption technology, combined with zero-knowledge proofs, to implement a two-party PSI protocol resistant to malicious attacks. In 2016, Freedman et al. [10] further improved computational efficiency through the ElGamal encryption mechanism and reduced the protocol’s computational complexity using Cuckoo Hash technology [4]. Abadi et al. [11] introduced a set representation method based on point-value pairs of d-degree polynomials, implemented through the Paillier encryption scheme, reducing the multiplication complexity from O($d^2$) to O(d) [4]. Kissner et al. [12] adopted different polynomial representation methods, significantly reducing computational costs to be linearly proportional to the number of participants. Jarecki et al. [13] used additive homomorphic encryption and zero-knowledge proofs to implement pseudorandom functions (PRF). Hazay et al. [14] developed an additive homomorphic encryption scheme that supports threshold decryption for implementing multi-party semi-honest PSI protocols. Dou Jiawei et al. [15] combined Paillier encryption to propose a PSI protocol based on the formula for calculating the area of triangles and rational number encoding.

Public key encryption-based Private Set Intersection (PSI) schemes typically feature fewer communication rounds and are suitable for environments with strong computational capabilities. However, in practice, communication bandwidth and time complexity often pose significant constraints [4].

2.1.2. Design Framework Based on Garbled Circuits

Garbled circuit technology can transform any function into a Boolean circuit, thereby securely computing the function. Early methods based on universal circuits, like the DPSZ scheme [16], demonstrated how to use arithmetic circuits to solve the set intersection problem: the circuit builder encrypts the circuit gates using a symmetric key, then creates a garbled circuit and sends it to the circuit evaluator. The evaluator decrypts specific paths in the garbled circuit to obtain the intersection results, while being unable to access other paths in the circuit. As the circuit depth increases, its construction complexity also increases. Additionally, PSI protocols based on this circuit design can also perform various symmetric function operations, such as calculating the threshold intersection, the number of intersection elements, and their sum. For adversaries under semi-honest conditions, there are two types of garbled circuits: the Yao [17] protocol and the GMW [18] protocol. Pinkas et al. [19,20,21] and Chandran et al., based on hash storage structures and GMW circuits, implemented a more efficient OPRF circuit PSI scheme through private membership tests, reducing the number of comparisons and the depth of circuit equivalence comparisons. Meanwhile, Huang et al. [22] created a semi-honest secure disordered circuit PSI scheme through the combination of Yao circuits, performing equivalence tests and specific sorting on adjacent elements. Despite these advantages, these methods still require additional key calculations and communication processes, such as key exchanges between participants.

2.1.3. Design Framework Based on Oblivious Transfer

Oblivious Transfer (OT) [23] is a cryptographic protocol that allows a sender to transmit information to a receiver without revealing any private information. In the OT protocol, the sender has two options, but the receiver can only obtain information about one of them without access to the other, and the sender does not know which option the receiver has chosen. OT is widely used in many secure areas due to its cryptographic robustness and privacy features. Its applications include secure protocol negotiation, secure online auction systems, and secure voting systems. In 2013, Dong et al. [24] proposed a new data structure—the Garbled Bloom Filter (GBF)—and based on the GBF and OT extension, they introduced a PSI protocol. This protocol utilized efficient symmetric encryption operations and could handle billions of elements. However, this protocol faced two issues: one is that the malicious sender might send incorrect shared information, and the other is that the input datasets are not independent. To address these problems, in 2016, Rindal and Rosulek [25] proposed a new randomized garbled Bloom filter using the “cut-and-choose” technique. They successfully implemented a two-party malicious model PSI protocol. Subsequently, Zhang et al. [26], based on this scheme, further proposed and implemented a multi-party PSI protocol, ensuring malicious security in the presence of two non-colluding servers, with computational and communication costs depending on the number of participants. Pinkas et al. [27], based on the OOS17-OT [28] protocol, built a maliciously secure PSI protocol. Rindal et al. [29], based on the semi-honest secure Schoppmann et al. [30] protocol and the maliciously secure Weng et al. [31] protocol, respectively, proposed maliciously secure and semi-honest secure PSI protocols. Overall, PSI protocols based on oblivious transfer typically feature lower computational and communication overhead.

2.2. PSI-CA

In the research of set intersection cardinality, Ref. [32] put forward a two-party protocol based on the Bloom filter and ElGamal encryption scheme; the trick here is to count how many common zero-bits were in their Bloom filters. Thus, the cardinality of set intersection can be quickly figured out by a formula provided in [33]. The proposal in [34] was analogous to [32], which employed the Goldwasser–Micali encryption algorithm [25] to encrypt the Bloom filter entries.Cristofaro et al. [35] designed the first PSI-CA protocol with linear complexity $O(n_y+n_x)$ based on the Decisional Diffie–Hellman (DDH) assumption in the Random Oracle Model (ROM) [36]. However, for the computation cost, both the sender and the receiver need to compute two exponentiations for each item.

3. Related Theories and Technologies

3.1. Multi-Party Secure Computation Security Model

The mathematical concept of Multi-Party Computation (MPC) involves several participants (such as $P_1,P_2,\dots ,P_n$), each holding private input data ($x_i$). These participants collaboratively execute a computation of the function $f(x_1,x_2,\dots ,x_n)$ with the goal of ensuring that each participant can only access their own computational results, while being unable to ascertain the inputs and results of others. There are generally two security models employed in secure multi-party computation protocols [37,38]:

• Semi-honest model: In this model, participants adhere to the protocol’s execution rules but may attempt to gather other participants’ inputs, outputs, and any accessible information during the execution of the protocol. This model assumes that the participants do not deviate from the established procedural rules but will use all available information to deduce the private data of others.
• Malicious adversary model: Unlike the semi-honest model, the malicious adversary model accounts for the possibility that attackers may manipulate a subset of the participants to perform illicit actions, such as submitting incorrect input data or maliciously altering data to steal the private information of honest participants. Malicious adversaries might also disrupt the protocol by intentionally terminating its execution or by refusing to participate, thus preventing the protocol’s completion.

The security model considered in this paper is the semi-honest security model.

3.2. Cuckoo Filter

Determining whether a particular element belongs to a given set is a common problem in computer science, with widespread applications in bioinformatics, machine learning, computer networks, the Internet of Things, and database systems [39]. Filter data structures such as Bloom filters and Cuckoo filters can approximately determine if an element is part of a specified set and have been extensively applied in network routing [40], information retrieval, file merging [41], spam detection [42], and distributed systems [43].

Filter data structures are used to approximately ascertain if an element belongs to a specific set. In essence, for a given set S and a query element x, the filter can approximately inform the query whether “x is in S”. “Approximately” here implies that if x is actually not in S, the filter has a small error probability p of wrongly indicating that “x is in S”; however, if x is indeed in S, the filter will always correctly return that “x is in S”. Filter data structures sacrifice some query accuracy to enhance space and time efficiency. Unlike data structures that require storing the complete information of each element for precise queries, filters approximate the presence of an element solely through partial information such as hash values or “fingerprints”. Based on this principle, existing filter data structures are mainly categorized into two types: one type uses bit arrays as in Bloom filters; the other type, exemplified by Cuckoo filters, is based on element “fingerprints”.

The Cuckoo filter [44] is an advanced retrieval structure made up of multiple buckets, each capable of containing several bits. Compared to Bloom filters, Cuckoo filters offer the significant advantage of supporting deletion of elements and having higher space efficiency. With equal storage space, Cuckoo filters can achieve more accurate search results and shorter search times. When querying an element, the time complexity for Cuckoo filters is $O\left(1\right)$, meaning constant time complexity. This indicates that the execution time for query operations does not increase with the number of elements in the filter, an important performance feature of the Cuckoo filter design. In this paper, Cuckoo filters are used to store data at a large medical institution.

3.3. Paillier Homomorphic Encryption

Homomorphic encryption is an encryption technology that allows computations to be performed on encrypted data and to obtain encrypted results, which, when decrypted, are consistent with the results obtained by performing the same computations directly on the original data. This means that homomorphic encryption enables data to be processed and analyzed without revealing any content. It is an important technology for protecting online privacy, allowing cloud computing services to perform complex data processing tasks on users’ encrypted data without accessing the actual data.

Paillier homomorphic encryption is a public-key cryptosystem that specifically supports homomorphic addition operations on encrypted data. The applications of the Paillier encryption scheme are extensive, and it can be used to protect the privacy and security of data. For example, in distributed computing, the Paillier encryption scheme can be used to encrypt data and transmit it to various nodes for processing, ensuring the security and privacy of the data. Furthermore, the Paillier encryption scheme can also be used to implement homomorphic secret sharing, private-set intersection, and other application scenarios. Overall, the Paillier encryption scheme is an efficient homomorphic encryption scheme with a wide range of application prospects. This paper uses the Paillier cryptosystem in its final scheme. The homomorphic properties utilized in this paper are as follows:

• Additive Homomorphism: If $c_1=\mathrm{Enc}\left(m_1\right)$ and $c_2=\mathrm{Enc}\left(m_2\right)$, then $\mathrm{Dec}(c_1·c_{2}mod{n}^2)=m_1+m_2$. This allows for performing addition operations on ciphertexts without needing to decrypt them first.
• Scalar Multiplication Homomorphism: If $c=\mathrm{Enc}\left(m\right)$, then $\mathrm{Dec}(c^{k}mod{n}^2)=k·m$. This means that it is possible to perform multiplication operations between a ciphertext and a plaintext scalar without decryption.

This paper will utilize homomorphic encryption technology to construct the third protocol of this paper: Unbalanced PSI-CA Protocol Based on Dual-Cloud Assistance.

4. PSI-CA Protocol Constructed Based on DH Key Exchange Mechanism

Before proposing the first unbalanced PSI-CA protocol of this paper, we introduce Cristofaro’s PSI-CA protocol, constructed based on the DH key-exchange mechanism [35]. As shown in Figure 1, the specific process is as follows, where $\alpha$ is the private key of a large medical institution, $\beta$ is the private key of a small health app developer, and H is the hash function negotiated by both parties.

4.1. Protocol Process

4.1.1. Exchange and Computation Stage

• Receiver Data Encryption: The receiver encrypts $H\left(y_j\right)$ with its private key $\beta$, obtaining $H{\left(y_j\right)}^{\beta }$, and sends it to the sender.
• Sender Computation: Upon receiving $H{\left(y_j\right)}^{\beta }$, the sender applies their private key $\alpha$ to compute ${\left(H{\left(y_j\right)}^{\beta }\right)}^{\alpha }$ and shuffles it before sending it back to the receiver.
• Sender Data Encryption: The sender encrypts $H\left(x_i\right)$ with its private key $\alpha$, resulting in $H{\left(x_i\right)}^{\alpha }$, and sends it to the receiver to facilitate the computation of the intersection cardinality.

4.1.2. Cardinality Calculation Stage

• Receiver Decryption and Computation: The receiver uses the inverse of $\beta$ to decrypt ${\left(H{\left(y_j\right)}^{\beta }\right)}^{\alpha }$ to retrieve $H{\left(y_j\right)}^{\alpha }$. By comparing $H{\left(x_i\right)}^{\alpha }$ with $H{\left(y_j\right)}^{\alpha }$, the receiver can calculate the cardinality of the intersection between the two sets.

4.2. Experimental Analysis

For this protocol, experiments were conducted and the runtime was recorded for various combinations of dataset sizes, as shown in

Table 1. Runtime of the PSI-CA protocol constructed based on the DH key-exchange mechanism.

Cardinality of Dataset from Participant One	Cardinality of Dataset from Participant Two	Protocol Runtime (Seconds)
$2^{10}$	$2^{15}$	1.8095
$2^{10}$	$2^{17}$	7.3003
$2^{10}$	$2^{20}$	56.1277
$2^{10}$	$2^{25}$	1859.9520
$2^{15}$	$2^{15}$	5.2207
$2^{15}$	$2^{17}$	10.0672
$2^{15}$	$2^{20}$	63.4835
$2^{15}$	$2^{25}$	1886.3966
$2^{17}$	$2^{17}$	20.7044
$2^{17}$	$2^{20}$	71.9252
$2^{17}$	$2^{25}$	1977.5657
$2^{20}$	$2^{20}$	170.3074
$2^{20}$	$2^{25}$	2054.2694

. Cardinality here refers to the number of elements in the participant’s dataset. For example, $2^{10}$ means that the dataset has $2^{10}$ elements. The cardinalities mentioned in the following tables all have the same meaning.

Through the experimental data, an important phenomenon can be observed. Table 1 shows the estimated runtime of the above protocol under different data volume levels. For example: Initially, when the number of elements in Participant One’s dataset is $2^{10}$ and Participant Two’s dataset is $2^{15}$, the runtime of the protocol is 1.8095 s. In this case, there is a noticeable imbalance between the smaller side (Participant One) and the larger side (Participant Two). Now, if we expand the number of elements in Participant One’s dataset (originally the side with fewer elements) to $2^{15}$, while keeping Participant Two’s dataset size constant at $2^{15}$, the runtime increases to 5.2207 s, approximately three times the original. This indicates that although the runtime increases when the datasets are balanced, the increase is limited. However, if we keep Participant One’s dataset size at $2^{10}$ and increase Participant Two’s dataset size to $2^{20}$ (the same scale of change), the runtime dramatically increases to 56.1277 s, approximately 31 times the initial condition. This phenomenon shows that, in unbalanced dataset conditions, increasing the number of elements in the larger dataset significantly affects the efficiency of the protocol.

These results reveal the importance of dataset balance in maintaining efficiency during the implementation of this protocol. Unbalanced datasets not only lead to extended runtimes but can also cause low resource utilization and delays in processing. However, in practical applications, when two parties want to obtain the private-set intersection’s cardinality, their sets are often unequal and have a significant gap. Therefore, the current situation requires the design of a new protocol to eliminate the impact of dataset size imbalance on protocol efficiency.

4.3. Summary of This Chapter

This chapter explores the PSI-CA Protocol built on the Diffie–Hellman (DH) key-exchange mechanism, detailing its processes and experimental analysis. Initially, the protocol employs a DH mechanism for securing data exchanges between two parties, outlined in specific stages: data encryption by the receiver, computation and further encryption by the sender, followed by decryption and intersection cardinality computation by the receiver.

The experimental analysis section provides a practical examination of the protocol’s runtime across varying dataset sizes, demonstrating that imbalances significantly affect efficiency. As the dataset sizes diverge, particularly when a smaller dataset is compared with a rapidly increasing larger dataset, the protocol’s runtime escalates dramatically.

Therefore, there is an urgent need to design a new protocol to alleviate the adverse effects of dataset size imbalance on the performance of the PSI-CA protocol.

5. Unbalanced PSI-CA Protocol Based on Cuckoo Filter

Although Cristofaro’s PSI-CA protocol [35], constructed based on the DH key-exchange mechanism, provides an effective way to compute the intersection’s cardinality of two datasets, especially under the premise of protecting participants’ data privacy, this paper observes that its efficiency is significantly impacted when dataset sizes are extremely unbalanced. In particular, as shown in Table 1, the runtime increases significantly as the size of the larger dataset increases, reflecting the performance limitations of Cristofaro’s PSI protocol when dealing with unbalanced datasets.

In order to overcome these limitations, the first protocol proposed in this paper adopts a different technical strategy, which effectively reduces the computational burden under unbalanced conditions by introducing Cuckoo filter. This not only optimizes the data processing process, but also improves the overall operational efficiency. In the new protocol, the increase in run time is not as dramatic as that in the Cristofaro PSI-CA protocol [35], based on DH key exchange; even with unbalanced dataset sizes, this allows for more efficient and balanced data processing. This improvement is particularly important for datasets of different sizes frequently encountered in practical applications.

Therefore, based on the above introduction, as shown in Figure 2, this paper first proposes a PSI-CA protocol based on the discrete logarithm problem difficulty and the correctness (high false positive rate) of Cuckoo filter. This protocol is divided into two phases; the specific details are as follows.

5.1. Definition of Main Participants and Related Symbols

• Large medical institution represents the party with a larger dataset and greater computational and storage capabilities.
• Small health app developer represents the party with a smaller dataset and lesser computational and storage capabilities.
• X and Y represent the dataset of the large medical institution and the small health app developer, respectively.
• $\alpha$ represents the private key of the large medical institution in the Diffie–Hellman encryption algorithm.
• ${\beta }_j$ represents the random number generated by the small health app developer for the Diffie–Hellman encryption algorithm.
• H represents the hash function negotiated by the small health app developer and large medical institution for use.
• $CF$ represents Cuckoo filter, $CF.insert$ represents the operation of adding an element to the Cuckoo filter, $CF.check$ represents the operation of checking whether a specific element exists in the filter.
• $X_i$ represents the i-th element of set X. Similarly, $Y_i$, $C_i$, etc., also represent similar meanings.
• $C=\{c_1,c_2,\dots ,c_n\}$ represents the set containing $n_2$ ciphertexts sent by the small health app developer to the large medical institution.
• $C^{\prime }$ represents the set containing $n_2$ ciphertexts sent by the large medical institution to the small health app developer.
• $ite{m}_j$ represents the result obtained through a series of exchange and decryption operations, used to retrieve the filter.
• $sum$ represents the cardinality of the intersection between the two parties.

5.2. Protocol Process

The protocol is divided into two phases, the preprocessing phase and the intersection phase, with specific details as follows.

5.2.1. Preprocessing

In the preprocessing phase, the small health app developer and the large medical institution need to perform a series of preparatory works to ensure the security and efficiency of subsequent interactions. The specific steps are as follows:

• Security parameter negotiation: The small health app developer and the large medical institution agree on the large prime number q used in the DH encryption algorithm and the hash function H used.
• Large Medical Institution Generates Private Key: The large medical institution generates its own private key $\alpha$, used for the Diffie–Hellman (DH) encryption algorithm.
• Data Scrambling: The small health app developer and the large medical institution scramble their own datasets Y and X for randomization, enhancing data privacy and security.
• Small Health App Developer Data Preprocessing: The small health app developer calculates $h_j=H\left(y_j\right)$ and generates $n_2$ random numbers ${\beta }_j$, used for the Diffie–Hellman (DH) encryption algorithm.
• Creation of Cuckoo Filter: The large medical institution generates a Cuckoo filter $CF$ by using the operation $CF.insert\left({\left(H\left(x_i\right)\right)}^{\alpha }\right)$ and sends the filter $CF$ to the small health app developer for private-set intersection queries with privacy protection.

5.2.2. Cardinality Calculation

In the cardinality calculation phase, the small health app developer and the large medical institution perform a series of carefully designed encryption and decryption operations to blind the small health app developer’s elements securely and compute the intersection cardinality of the two sets. The specific operations are as follows:

• Element Blinding and Interactive Encryption Operations: The small health app developer and the large medical institution interact through a series of asymmetric encryption and decryption operations to blind the small health app developer’s elements. Specifically, the small health app developer calculates $C_j=h_j^{{\beta }_j}$ and sends C to the large medical institution. The large medical institution uses its private key $\alpha$ to compute $C_j^{\prime }=C_j^{\alpha }$ and sends $C^{\prime }$ back to the small health app developer.
• Cardinality Computation: After receiving $C^{\prime }$, the small health app developer checks whether they belong to the filter $CF$ through the check operation $CF.check$, thereby calculating the cardinality of the intersection of the sets. Specifically, after receiving $H{\left(X\right)}^{r\alpha }$ sent by the large medical institution, the small health app developer computes $ite{m}_j={C_j^{\prime }}^{1/{\beta }_j}$ and uses the result to query the filter $CF$ to obtain the intersection’s cardinality $sum$.

5.3. Correctness Analysis

If $x_i=y_j$, then $H\left(x_i\right)=H\left(y_j\right)$, then (please see the fifth step in Figure 2) $ite{m}_j={C_j^{\prime }}^{1/{\beta }_j}=$ (Step 4 in Figure 2) ${C_j^{\alpha }}^{\ast 1/{\beta }_j}=$ (Step 3 in Figure 2) ${\left(h_j^{{\beta }_j}\right)}^{1/{\beta }_j\ast \alpha }=$ $h_j^{\alpha }=H{\left(x_i\right)}^{\alpha }=H{\left(y_j\right)}^{\alpha }$.

Thus, through this scheme, the small health app developer can accurately obtain the cardinality of the intersection of both parties.

5.4. Security Analysis

This section will analyze the security of the protocol in detail, mainly its ability to protect the privacy of both parties. Here, the large medical institution is called the sender and the small health app developer is called the receiver.

5.4.1. Definition

$f=\left(f_S,f_R\right)$ denotes the deterministic function of $\pi$ where S denotes the sender and R denotes the receiver. We say that the protocol $\pi$ is secure under the semi-honest model, if the probabilistic polynomial-time algorithms ${\mathcal{L}}_S$ and ${\mathcal{L}}_R$ can be presented as:

• ${\left\{{\mathcal{L}}_S\left(X,f_S(X,Y)\right)\right\}}_{X,Y}\stackrel{c}{\equiv }{\left\{{view}_S^{\pi }(X,Y)\right\}}_{X,Y}$
• ${\left\{{\mathcal{L}}_R\left(X,f_R(X,Y)\right)\right\}}_{X,Y}\stackrel{c}{\equiv }{\left\{{view}_R^{\pi }(X,Y)\right\}}_{X,Y}$

where ${view}_S^{\pi }(X,Y)$ and ${view}_R^{\pi }(X,Y)$ denote all the information, which an adversary can obtain from party S and party R, respectively. The information includes the input of the party, the output from function f, and the other information that it receives.

5.4.2. Theorem

Let X, Y be two sets from a predefined universe; the set intersection functionality f is defined as: $f(X,Y)=\left(f_s(X,Y),f_R(X,Y)\right)=\left(\right|X\cap Y|,\perp )$. Given the commutative encryption system, our protocol in Section 5 can compute f securely in the presence of semi-honest adversaries.

5.4.3. Proof

If the Hellman encryption scheme is secure, then the simulators for sender and receiver are guaranteed to exist; we can use them as subroutines when constructing our simulators.

• Sender’s View: We start from the case where the sender is corrupted. We construct a simulator $Si{m}_S$, which receives the sender’s private input and output and generates the view of the sender S in the protocol. We want to show that this view is indistinguishable from the view of S in an execution of the unbalanced PSI-CA protocol based on Cuckoo filter. That is, ${\left\{{Sim}_S\left(S,f_S(X,Y)\right)\right\}}_{S,R}\stackrel{c}{\equiv }{\left\{{view}_S^{\pi CC}(X,Y)\right\}}_{S,R}.$
  We first sketch the algorithm of $Si{m}_S$. In the pre-process step, $Si{m}_S$ determines a prime number q and chooses a public key with the same security parameter. It constructs a Cuckoo filter in the presence of the ciphertexts, which is all the same as the real execution. Then, $Si{m}_S$ fills a set $Y_R$ with the same size as Y randomly and determines a key to encrypt each element in $Y_R$ utilizing the Hellman encryption scheme randomly. We denote the encryption set result as Y. Last but not least, $Si{m}_S$ attempts to obtain the cardinality of the set intersection by querying the Cuckoo filter.
  From the view of the sender, given the secure Hellman encryption scheme, the distribution of $Y_R$ produced by $Si{m}_S$ is indistinguishable from the one produced by the real execution. Thus, we can conclude that the simulated view is indistinguishable from the real view.
• Receiver’s View: In this case, the receiver is corrupted. We construct a simulator $Si{m}_R$ that is given the private input Y and the output $|X\cap Y|$. Similarly, we will prove this view is indistinguishable from the view of the receiver R in the real execution. That is, ${\left\{{Sim}_R\left(R,f_R(X,Y)\right)\right\}}_{S,R}\stackrel{c}{\equiv }{\left\{{view}_R^{{\pi }_{CC}}(X,Y)\right\}}_{R,S}$.
  We first sketch the algorithm of $Si{m}_R$. In the pre-process step, $Si{m}_R$ determines a prime number q and chooses a public key with the same security parameter to encrypt its own set Y. Then, $Si{m}_R$ randomly chooses $\left|X\right|$$-|X\cap Y|$ elements from a predefined universe and $|X\cap Y|$ elements from Y. We denote the new dataset as $X_{new}$. Afterward, $Si{m}_R$ determines a sender’s key to encrypt the dataset and constructs the Cuckoo filter in the presence of the new dataset’s ciphertext using the parameters determined in the pre-process step. Since the distribution of $X_{new}$ produced by $Si{m}_R$ is indistinguishable from the distribution of X produced by the real execution, we conclude the simulated view is indistinguishable from a real view.

Combining both of the above, we finish our proof.

5.5. Experimental Analysis

For this protocol, experiments were conducted, and the runtime was recorded for various combinations of data volumes, as shown in

Table 2. Comparison of running time of PSI-CA protocol based on DH key-exchange mechanism and Cuckoo Filter based.

Cardinality of Dataset from Participant One	Cardinality of Dataset from Participant Two	Original Protocol Runtime (Seconds)	New Protocol Runtime (Seconds)
$2^{10}$	$2^{15}$	1.8095	0.1685
$2^{10}$	$2^{17}$	7.3003	0.1663
$2^{10}$	$2^{20}$	56.1277	0.1641
$2^{10}$	$2^{25}$	1859.9520	0.1840
$2^{15}$	$2^{15}$	5.2207	5.2725
$2^{15}$	$2^{17}$	10.0672	5.5104
$2^{15}$	$2^{20}$	63.4835	5.2807
$2^{15}$	$2^{25}$	1886.3966	5.5166
$2^{17}$	$2^{17}$	20.7044	21.1474
$2^{17}$	$2^{20}$	71.9252	21.2865
$2^{17}$	$2^{25}$	1977.5657	21.9713
$2^{20}$	$2^{20}$	170.3074	171.5354
$2^{20}$	$2^{25}$	2054.2694	186.9644

. The table also compares the runtime of Cristofaro’s PSI-CA protocol constructed based on the DH key-exchange mechanism [35]. Since preprocessing can be completed offline, the runtime of the unbalanced PSI-CA protocol based on Cuckoo filter refers to the total time of the the cardinality calculation process. The original protocol refers to the PSI-CA protocol constructed based on the DH key-exchange mechanism, and the new protocol refers to the unbalanced PSI protocol based on Cuckoo filter.

Through the experimental data, this paper can observe several key phenomena. First, when the cardinality of the smaller dataset (number of elements) remains constant while the number of elements in the larger dataset increases rapidly, it is observed that the runtime of the protocol does not change much, remaining consistent. This indicates that, although the size of the large dataset increases dramatically, the efficiency of the protocol is not significantly affected, thereby proving that the design of this protocol can effectively mitigate the negative impact of dataset size imbalance on protocol efficiency. In particular, the overall runtime of the protocol is more related to the cardinality of the smaller dataset and has very low relevance to the cardinality of the larger dataset.

At the same time, this experiment also found that, under balanced dataset conditions, the runtime of the PSI-CA protocol based on the DH key-exchange mechanism and the unbalanced PSI-CA protocol based on Cuckoo filter does not differ significantly. This indicates that, when the sizes of the sets are similar, both protocols can exhibit comparable performance, providing an efficient solution.

5.6. Summary of This Chapter

This chapter presents the development and analysis of an unbalanced PSI-CA protocol that utilizes Cuckoo filter to efficiently handle datasets with significant size disparities. The protocol is designed to overcome the limitations observed in traditional PSI-CA protocols such as Cristofaro’s, which struggles with efficiency under unbalanced conditions.

Experimental analyses demonstrate the protocol’s robustness, showing minimal runtime increases even as dataset sizes grow significantly, which marks a substantial improvement over traditional methods. The protocol proves particularly effective in real-world scenarios where dataset imbalances are common, providing a reliable solution that ensures privacy and efficiency.

In essence, this chapter confirms the efficacy of integrating Cuckoo filter into PSI-CA protocols, offering enhanced performance and security, making it a valuable addition to the field of data privacy and secure computation.

However, in this protocol, the receiver still has to bear the burden of complex cryptographic computations and storing the Cuckoo filter. The next chapter will focus on optimizing this aspect.

6. Unbalanced PSI-CA Protocol Based on Single-Cloud Assistance

The previous chapter has proven that the unbalanced PSI-CA protocol based on Cuckoo filter is more suitable for practical scenarios, especially under unbalanced conditions, this protocol effectively resolves the performance limitations of the PSI protocol constructed using the DH key-exchange mechanism in handling unbalanced datasets. However, there is still room for improvement in this protocol. It is observed that, in this protocol, the small health app developer (receiver) need to store the filter and perform complex cryptographic operations, which can be a significant burden for mobile devices with limited computing power and storage space. A series of encryption operations and the storing filter received from the other party becomes a heavy load. To address this issue, it is considered to transfer most of the receiver’s computational and storage tasks to cloud servers. By delegating tasks to cloud servers, the receiver can significantly reduce computational and storage pressure, especially for a small health app developer with limited capabilities.

This section will introduce cloud computing technology, which allows a small health app developer with limited computing power and storage space to outsource their private data and request cloud platforms to perform related computations. Currently, whether for individual users or large enterprises, entrusting data storage and computation tasks to cloud services has become a common practice. Based on the introduction above, as shown in Figure 3, this chapter proposes a second unbalanced PSI-CA protocol.

6.1. Definition of Main Participants and Related Symbols

• Large medical institution represents the party with a larger dataset and greater computational and storage capabilities.
• Small health app developer represents the party with a smaller dataset and lesser computational and storage capabilities.
• Cloud server represents an auxiliary server that assists the receiver in obtaining the intersection’s cardinality operations, undertaking most of the computational and storage pressures.
• X and Y represent the dataset of the large medical institution and the small health app developer, respectively.
• $Y^{\prime }$ represents the obfuscated dataset sent by the small health app developer to the large medical institution, used to confuse the cloud server and prevent it from obtaining the accurate cardinality of the intersection. k represents the cardinality of the set $Y^{\prime }$.
• $\alpha$ represents the private key of the large medical institution in the Diffie–Hellman encryption algorithm.
• $r_1$ represents the random number generated by the small health app developer, used to blind the data.
• ${\beta }_j$ represents the random number generated by the small health app developer for the Diffie–Hellman encryption algorithm.
• H represents the hash function negotiated for use by the small health app developer and large medical institution.
• $CF$ represents the Cuckoo Filter, $CF.insert$ represents the operation to add an element to the Cuckoo filter, $CF.check$ represents the operation to check if a specified element exists in the filter.
• $X_i$ represents the i-th element of the set X. Similarly, $Y_i$, $C_i$, etc., also represent similar meanings.
• $C=\{c_1,c_2,\dots ,c_n\}$ represents the set of $n_2$ ciphertexts sent by the small health app developer to the large medical institution.
• $C^{\prime }$ represents the set of $n_2$ ciphertexts sent by the large medical institution to the small health app developer
• $ite{m}_j$ represents the result obtained through a series of exchange and decryption operations, used to retrieve the filter to obtain the cardinality of intersection.
• $sum$ represents the variable used to help the small health app developer obtain the cardinality of the intersection, where $sum-k$ represents the cardinality of the intersection.

6.2. Protocol Process

6.2.1. Preprocessing

• Security parameter negotiation: Each role discusses the necessary security parameters; all parties share the large prime q used in the DH cryptographic algorithm. The small health app developer and the large medical institution negotiate to generate $r_1$ and the hash function H.
• The small health app developer negotiates with the large medical institution to create an obfuscated dataset $Y^{\prime }$; this dataset is completely useless data, which means that its elements cannot belong to either the small health app developer or the large medical institution collection.
• Large medical institution generates a private key: The large medical institution generates its own private key $\alpha$, for use in the Diffie–Hellman encryption algorithm.
• Data scrambling: The small health app developer and the large medical institution each scramble their own datasets X and Y.
• Small health app developer data preprocessing: The small health app developer calculates $h_j=H\left(y_j\right)$, generates $n_2$ random numbers ${\beta }_j$, and calculates $h_j\times r_1$.

6.2.2. Outsourcing

• Large medical institution sends data to the cloud server: The large medical institution uses its private key $\alpha$ to perform the operation $CF.insert({\left(H\left(x_i\right)\right)}^{\alpha }\times r_1^{\alpha })$, creates a Cuckoo filter $CF$, and sends it to the cloud server.
• Small health app developer sends data to the cloud server: The small health app developer sends the random numbers ${\beta }_j$ and $h_j\times r_1$ to the cloud server. After receiving the data sent by the small health app developer, the cloud server calculates $C_j=r_1^{{\beta }_j}\times h_j^{{\beta }_j}$. At this point, the cloud server has saved the small health app developer’s blinded data.

6.2.3. Cardinality Calculation

• Cloud server sends data: The cloud server sends the blinded data $C_j$ to the large medical institution.
• Large medical institution processes data: Upon receiving $C_j$, the large medical institution uses its private key $\alpha$ to calculate $C_j^{\prime }=C_j^{\alpha }$ and sends the result back to the cloud server.
• Cloud server processes data: After receiving $C_j^{\prime }$ from the large medical institution, the cloud server calculates $ite{m}_j=C_j^{1/{\beta }_j}$ and uses the result to search $CF$. If $ite{m}_j$ exists in $CF$, then sum is incremented by 1 (initial value of sum is 0).
• Obtaining the intersection cardinality: The small health app developer obtains the cardinality of the intersection by calculating $sum-k$, where k is the cardinality of the set $Y^{\prime }$.

6.3. Correctness Analysis

If $x_i$ = $y_j$, then $H\left(x_i\right)$ = $H\left(y_j\right)$, so (please see the seventh step in Figure 3) $ite{m}_j={C_j^{\prime }}^{1/{\beta }_j}=$ (Step 5 and Step 6 in Figure 3) ${C_j^{\alpha }}^{\ast 1/{\beta }_j}={\left({r_1}^{{\beta }_j}\ast h_j^{{\beta }_j}\right)}^{1/{\beta }_j\ast \alpha }={r_1}^{\alpha }\ast h_j^{\alpha }={r_1}^{\alpha }\ast H{\left(x_i\right)}^{\alpha }={r_1}^{\alpha }\ast H{\left(y_j\right)}^{\alpha }$.

Thus, through this scheme, the small health app developer can accurately obtain the cardinality of the intersection of both parties.

6.4. Security Analysis

In the design of this protocol, the primary security objective is to ensure that, even in a partially trusted cloud environment, neither the small health app developer’s data nor the large medical institution’s data can be accessed or inferred by unauthorized entities. Overall, this protocol, compared to the previous one, merely outsources the tasks, thus inheriting the security of the previous protocol. Specifically, since other participating parties are unaware of the large medical institution’s private key $\alpha$, they cannot deduce the data held by the large medical institution. Similarly, since other parties do not know the small health app developer’s private random number $r_1$, they cannot deduce the small health app developer’s data.

However, this scheme has inherent security risks, primarily because it does not withstand collusion attacks. If the large medical institution and the cloud server collude, they can jointly deduce the small health app developer’s data. This is possible because the cloud server possesses the blinded data $h_j\times r_1$, and if the large medical institution leaks the private key $r_1$ to the cloud server, then both the cloud server and the large medical institution could deduce the small health app developer’s original data $h_j$. Collusion attacks are a security threat where two or more distinct entities (for example, users, systems, or service providers) secretly cooperate to undermine or circumvent security mechanisms and privacy measures. In cloud computing environments, cloud service providers and cloud users may collude to steal or infer other users’ sensitive data stored on the cloud. In the medical scenario of this article, the intersection represents the patient’s sensitive data, and leaking this information will cause very serious damage.

6.5. Experimental Analysis

6.5.1. Data Storage Volume

In the research of this paper, the experimental analysis of the unbalanced PSI-CA protocol based on single-cloud assistance revealed a key issue: when the small health app developer needs to receive a Cuckoo filter from the large medical institution, this poses a significant challenge for receivers with limited storage capacity. This challenge is magnified when facing large datasets.

To understand this issue deeply, a series of experiments were conducted to measure the volume of the Cuckoo filter needed by the small health app developer under different data sizes. The input data size for the experiments was provided by the large medical institution, reflecting the various data volumes that might be encountered in actual application scenarios. As shown in

Table 3. Size of Cuckoo filter at different data volumes.

Data Set Count	Size of Cuckoo Filter (MB)
$2^{15}$	0.535
$2^{17}$	2.363
$2^{20}$	21.678
$2^{22}$	93.645
$2^{23}$	194.436
$2^{24}$	403.201
$2^{27}$	3571.206
$2^{28}$	7372.835
$2^{29}$	15,206.421

, the paper meticulously recorded the specific sizes of Cuckoo filter under different input data volumes, revealing the intrinsic relationship between data volume and filter size. Through experiments, it was discovered that, as the data volume in the large medical institution increased, the storage burden on the small health app developer under the original protocol also increased accordingly, with the size of the Cuckoo filter directly impacted by the input data volume. Especially in the context of the large medical institution containing extensive patient data, this storage pressure is particularly evident.

Therefore, based on the above analysis and experimental results, it is clear that when the data volume in the large medical institution is excessively large, in other words, when the number of users reaches a certain level, the feasibility of a simple unassisted unbalanced PSI-CA protocol based on Cuckoo filter significantly decreases. This is because the unbalanced PSI-CA protocol based on Cuckoo filter requires small health app developers to directly receive and process a massive Cuckoo filter, which poses a significant challenge for small health app developers with limited storage resources, particularly mobile devices. Small health app developer devices often do not have enough storage space to accommodate these large-volume filter data, let alone process these data to complete PSI-CA operations.

In this context, the introduction of a cloud server scheme shows its unique advantages. By transferring the storage of the filter to the cloud server, the burden on the small health app developer is greatly reduced. By this means, even in situations with a massive number of users and large data volumes, the scheme can still maintain efficient operations and ensure the smooth completion of PSI-CA operations.

In summary, through experimental and theoretical analysis, this section concludes that, in scenarios with large-scale users and massive data volumes, the introduction of a cloud server scheme is more feasible and efficient than the unbalanced PSI-CA protocol based on Cuckoo filter.

6.5.2. Protocol Running Time

For this protocol, as shown in

Table 4. Running times of Protocol 1 and Protocol 2 under different data volume combinations.

Small Health App Developer Dataset Size	Large Medical Institution Dataset Size	Protocol 1 Running Time (Seconds)	Protocol 2 Running Time (Seconds)
$2^{10}$	$2^{15}$	0.1685	0.1658
$2^{10}$	$2^{17}$	0.1663	0.1693
$2^{10}$	$2^{20}$	0.1641	0.1658
$2^{10}$	$2^{25}$	0.1840	0.1731
$2^{15}$	$2^{15}$	5.2725	4.0627
$2^{15}$	$2^{17}$	5.5104	4.2464
$2^{15}$	$2^{20}$	5.2807	4.3202
$2^{15}$	$2^{25}$	5.5166	4.6118
$2^{17}$	$2^{17}$	21.1474	17.056
$2^{17}$	$2^{20}$	21.2865	16.731
$2^{17}$	$2^{25}$	21.9713	18.5417
$2^{20}$	$2^{20}$	171.5354	130.0498
$2^{20}$	$2^{25}$	186.9644	140.0193

, the paper conducted experiments and recorded the running time of the protocol under various data volume combinations. Because preprocessing can be completed offline, the running time of the protocol refers to the total time of the outsourcing process and the intersection process. Table 4 also compares the running times of the unbalanced PSI-CA protocol based on Cuckoo filter and the unbalanced PSI-CA protocol based on single-cloud assistance. Here, Protocol 1 refers to the unbalanced PSI-CA protocol based on Cuckoo filter, and Protocol 2 refers to unbalanced PSI-CA protocol based on single-cloud assistance.

From the experimental analysis, the following conclusions can be drawn: In cases of smaller data volumes, the performance differences between the two protocols are not significant. However, as the data volume increases, the running time differences between different protocols gradually become apparent. This is because, at certain specific levels, the proportion of communication time is relatively high when the data volume is small, significantly impacting the results. For larger data volumes, where computation time dominates, Protocol 2, by placing computational tasks on the more powerful cloud server, gradually widens the running time difference from Protocol 1. Overall, the use of cloud resources in the unbalanced PSI-CA protocol based on single-cloud assistance significantly reduces running times, especially when dealing with large-scale datasets.

6.6. Summary of This Chapter

This chapter introduces an unbalanced PSI-CA protocol based on single-cloud assistance, which utilizes cloud computing to reduce the computing and storage pressure of the small health app developer compared with previous protocols. Additionally, in the absence of collusion between the large medical institution and the cloud server, the protocol effectively protects data from unauthorized access, ensuring the confidentiality of the data and the privacy of the small health app developer, making it highly suitable for scenarios where the cloud server is fully trusted.

However, it cannot be denied that, although this scheme significantly reduces the computational and storage burden on the small health app developer, its security against collusion attacks is insufficient. In the medical scenario of this article, the intersection represents the patient’s sensitive data, and leaking this information will cause very serious damage. When the possibility of collusion between the cloud server and large medical institution cannot be completely ruled out, the protocol faces security risks and will require further security enhancement measures. Therefore, the next chapter will introduce a more secure solution to address the security deficiencies of the current scheme, ensuring the security and privacy of small health app developer data and large medical institution data in environments where not all parties are fully trustworthy. In other words, the new scheme can resist collusion attacks.

7. Unbalanced PSI-CA Protocol Based on Dual-Cloud Assistance

The previous single-server solution, which efficiently delegated computationally intensive encryption operations such as exponentiation and storage-intensive Cuckoo filter to the cloud server, has indeed alleviated the computational and storage burdens on the small health app developer to a certain extent. This is particularly advantageous for small health app developers with limited computing and storage capabilities, allowing them to operate beyond their hardware constraints. However, security analysis reveals that the unbalanced PSI-CA protocol based on single-cloud assistance has inherent security risks, specifically when collusion between the cloud server and large medical institution is possible, thus compromising its adequacy in protecting small health app developer data privacy.

As shown in Figure 4, to preserve the advantages of the previous scheme—namely reducing computational and storage pressures on the small health app developer—while addressing these security issues, this chapter proposes a new solution. This design aims to enhance the security during data processing, especially against potential collusion attacks.

7.1. Definition of Main Participants and Related Symbols

• Large medical institution represents the party with a larger dataset and greater computational and storage capabilities.
• Small health app developer represents the party with a smaller dataset and lesser computational and storage capabilities.
• Cloud server $H_1$: Acts as an auxiliary server for the small health app developer, handling the majority of computation and storage pressures.
• cloud server $H_2$: Another auxiliary server handling substantial computational and storage demands.
• X and Y represent the dataset of the large medical institution and the small health app developer, respectively.
• $Y^{\prime }$ represents the obfuscated dataset sent by the small health app developer to the large medical institution, used to confuse the cloud server and prevent it from obtaining the accurate cardinality of the intersection. k represents the cardinality of the set $Y^{\prime }$.
• $\alpha$ represents the private key of the large medical institution used in the Diffie–Hellman encryption algorithm.
• H: The hash function agreed upon by the small health app developer and the large medical institution for use.
• $CF$ represents the Cuckoo Filter, where $CF.insert$ denotes the operation to add elements, and $CF.check$ checks for the presence of specific elements.
• ${\omega }_j$: Random exponentials generated by the small health app developer for cloud server $H_1$, ${\beta }_j$ for cloud server $H_2$.
• a: A secret value held by the small health app developer.
• $r_{1,j}$: Random numbers used by the small health app developer for sending obfuscated data to cloud server $H_1$, and $r_{2,j}$ for $H_2$ where $r_{1,j}+r_{2,j}=a$.
• $C_1$: The ciphertext collection sent from cloud server $H_1$ to the large medical institution, and $C_2$ from $H_2$; $C_{1,j}$ and $C_{2,j}$ are specific elements within these collections.
• $C_1^{\prime }$ and $C_2^{\prime }$: Processed ciphertext collections returned to $H_1$ and $H_2$ from the large medical institution; $C_{1,j}^{\prime }$ and $C_{2,j}^{\prime }$ are specific elements within these collections.
• $C_1^{″}$ and $C_2^{″}$: Final processed ciphertext collections at $H_1$ and $H_2$ after receiving data from the large medical institution; $C_{1,j}^{″}$ and $C_{2,j}^{″}$ are specific elements within these collections.
• $ite{m}_j$ represents the result of multiplying $C_{1,j}^{″}$ and $C_{2,j}^{″}$ used to query the filter.
• $sum$ represents the variable used to help the small health app developer obtain the cardinality of the intersection, where $sum-k$ represents the cardinality of the intersection.

7.2. Protocol Process

7.2.1. Preprocessing

• Discuss security parameters: Each party discusses the necessary security parameters—the large prime q used in DH encryption and the small health app developer’s public key $p{k}_c$ required for the Paillier encryption system. The small health app developer and the large medical institution negotiate the creation of hash function H.
• The small health app developer negotiates with the large medical institution to create an obfuscated dataset $Y^{\prime }$. This dataset is completely useless data, which means that its elements cannot belong to either the small health app developer or the large medical institution collection.
• Small health app developer sends $E_{p{k}_c}\left(a\right)$: The small health app developer generates its private secret number a and sends $E_{p{k}_c}\left(a\right)$ to the large medical institution.
• Large medical institution generates private key: The large medical institution creates its private key $\alpha$, used for the DH encryption algorithm.
• Data scrambling: The small health app developer and the large medical institution each shuffle their respective datasets.
• Small health app developer calculates hashes and generates random numbers: The small health app developer computes $h_j=H\left(y_j\right)$ and generates $n_2$ random numbers, ${\beta }_j$, ${\omega }_j$, $r_{1j}$, $r_{2j}$, and computes $r_{1j}{h}_j$, $r_{2j}{h}_j$, where $r_{1j}+r_{2j}=a$.

7.2.2. Outsourcing

• Small health app developer sends data to cloud servers: The small health app developer sends $r_{1j}{h}_j$, ${\omega }_j$ to cloud server $H_1$ and $r_{2j}{h}_j$, ${\beta }_j$ to cloud server $H_2$. $H_1$ computes $C_{1,j}=E_{p{k}_c}\left(r_{1j}{h}_j{\omega }_j\right)$, and $H_2$ computes $C_{2,j}=E_{p{k}_c}\left(r_{2j}{h}_j{\beta }_j\right)$. At this point, $H_1$ and $H_2$ hold the small health app developer’s obfuscated data.
• Large medical institution sends data to cloud servers: Using $E_{p{k}_c}\left(a\right)$, the large medical institution performs the filter insertion operation $\mathrm{CF}.\mathrm{insert}\left(E_{p{k}_c}{\left(a\right)}^{\alpha \ast H\left(x_i\right)}\right)$ to generate a Cuckoo filter and sends it to cloud server $H_2$. $H_2$ stores the filter sent by the large medical institution.

7.2.3. Intersection

• $H_1$ and $H_2$ send data: $H_1$ and $H_2$ each send their respective collections $C_1$ and $C_2$ to the large medical institution.
• Large medical institution processes data: Upon receiving the data, the large medical institution uses its private key $\alpha$ to compute $C_{1,j}^{\prime }=C_{1,j}^{\alpha }=E_{p{k}_c}{\left(r_{1j}{h}_j{\omega }_j\right)}^{\alpha }$ and sends the results back to $H_1$. It also processes $C_{2,j}^{\prime }=C_{2,j}^{\alpha }=E_{p{k}_c}{\left(r_{2j}{h}_j{\beta }_j\right)}^{\alpha }$ and sends the results back to $H_2$.
• $H_1$ processes data: After receiving data from the large medical institution, $H_1$ uses the random number ${\omega }_j$ to calculate $C_{1,j}^{″}=C_{1,j}^{\prime 1/{\omega }_j}=E_{p{k}_c}{\left(r_{1j}{h}_j{\omega }_j\right)}^{\alpha \ast 1/{\omega }_j}$ and sends the results to $H_2$.
• $H_2$ processes data: Upon receiving data from $H_1$ and the large medical institution, $H_2$ calculates $C_{2,j}^{″}=C_{2,j}^{\prime 1/{\beta }_j}=E_{p{k}_c}{\left(r_{2j}{h}_j{\beta }_j\right)}^{\alpha \ast 1/{\beta }_j}$. $H_2$ checks if $ite{m}_j=C_{1,j}^{″}\ast C_{2,j}^{″}$ exists in $CF$. If $ite{m}_j$ exists in $CF$, then sum is incremented by 1 (initial value of sum is 0).
• Obtaining the intersection cardinality: The small health app developer obtains the cardinality of the intersection by calculating $sum-k$, where k is the cardinality of the set $Y^{\prime }$.

7.3. Correctness Analysis

If $x_i=y_j$, then $H\left(x_i\right)=H\left(y_j\right)$, which implies that (please see the ninth step in Figure 4) $C_{1,j}^{″}\ast C_{2,j}^{″}=$ (Step 7 and Step 8 in Figure 4) $C_{1,j}^{\prime 1/{\omega }_j}\ast C_{2,j}^{\prime 1/{\beta }_j}=$ (Step 6 in Figure 4) $E_{p{k}_c}{\left(r_{1j}{h}_j{\omega }_j\right)}^{\alpha \ast 1/{\omega }_j}\ast E_{p{k}_c}{\left(r_{2j}{h}_j{\beta }_j\right)}^{\alpha \ast 1/{\beta }_j}=$ (Step 5 in Figure 4) $E_{p{k}_c}\left(r_{1j}{h}_j\alpha \right)\ast E_{p{k}_c}\left(r_{2j}{h}_j\alpha \right)=$ (Step 1 in Figure 4) $E_{p{k}_c}\left[\alpha h_j(r_{1j}+r_{2j})\right]=E_{p{k}_c}\left(\alpha h_{j}a\right)=E_{p{k}_c}{\left(a\right)}^{\{\alpha \ast H\left(x_i\right)\}}$.

Thus, through this scheme, the small health app developer can accurately obtain the cardinality of the intersection of both parties.

7.4. Security Analysis

Firstly, we consider the security of the small health app developer’s data in the set. In considering security against collusion attacks, it is generally assumed that there is an adversary who possesses the perspective and information of all participating parties except for the protected entity. This means the adversary can access, control, or receive information and resources from all participants except for the small health app developer. In this scenario, the adversary attempts to compromise the system’s security or privacy by aggregating these insights, such as revealing the sensitive data of the small health app developer. If, in this context, the adversary still cannot learn or infer the small health app developer’s data, then it is proven that the data and privacy of the small health app developer are sufficiently secured against collusion attacks.

This section defines a game where the security objective is to maintain confidentiality of the data within the set under semi-honest and collusion conditions. The game for securing the small health app developer’s dataset is as follows:

• The small health app developer runs the preprocessing algorithm, sharing the cryptographic hash function H and the large prime q used in the protocol with the adversary.
• The small health app developer simulates the outsourcing algorithm and sends their (encrypted) input to the adversary.
• The small health app developer and the adversary simulate the intersection algorithm and discard any output.
• The adversary is asked to output a guess $\widehat{y}$ of the small health app developer’s input y.

The game is analogized to a deterministic one-way function, such as a public key encryption scheme. Let S be the simulated messages of the small health app developer during the game. Let a one-way function adversary $A^{\prime }$ be given the information (public key) $pk$ and function (ciphertext) c (encrypted y). The advantage of the adversary $Ad{v}_A$ is defined as the difference between the successful guesses of A and $A^{\prime }$. If this advantage is negligible in the security parameter $\lambda$, then the outsourced private-set intersection is considered secure. That is, let $Ad{v}_A=Pr[A\left(S\right)=y]-Pr[A^{\prime }(pk,c)=y]$. If $Ad{v}_A<\frac{1}{poly\left(\lambda \right)}$, then the protocol is said to be secure.

Specifically, after the steps mentioned above, $H_1$, $H_2$, and the large medical institution have a complete view of the process. However, under the two-server architecture, as illustrated in Figure 4:

• In step four of Figure 4, since $r_{1j}$ and $r_{2j}$ are unknown to the adversary, $h_j$ cannot be derived. The adversary can only attempt exhaustive guessing, thus making ${\mathrm{Adv}}_A$ negligible.
• In subsequent steps, as A does not know the small health app developer’s private key for the Paillier encryption system, it is impractical to decrypt the ciphertexts, making it even more challenging to derive $h_j$. For instance, $ite{m}_j=C_{1,j}^{″}\ast C_{2,j}^{″}={C_{1,j}^{\prime }}^{1/{\omega }_j}\ast {C_{2,j}^{\prime }}^{1/{\beta }_j}=E_{p{k}_c}{\left(r_{1j}{h}_j{\omega }_j\right)}^{\alpha \ast 1/{\omega }_j}\ast E_{p{k}_c}{\left(r_{2j}{h}_j{\beta }_j\right)}^{\alpha \ast 1/{\beta }_j}$, and since the private key used in Paillier’s system by the small health app developer is unknown, decrypting this compound is complex and hence $h_j$ remains secure.

From the analysis above, it is evident that the advantage of ${\mathrm{Adv}}_A$ is negligible. Therefore, if both cloud servers collude with the large medical institution, they cannot deduce the small health app developer’s original data.

Next, consider the security of the data in the large medical institution’s set. Obviously, apart from the large medical institution itself, none of the parties know the large medical institution’s private key $\alpha$; hence, even if both cloud servers colluded with the small health app developer, they cannot derive the original data from $CF$.

It is particularly noted that, due to the prevalence of attacks on hash functions, further security enhancements are recommended by protecting the hashed data as the raw data.

In addition, due to the existence of obfuscated dataset $Y^{\prime }$, two cloud servers cannot know the set cardinality of the large medical institution and the small health app developer.

In conclusion, the dual-server scheme successfully resists collusion attacks under semi-honest conditions. By thoroughly integrating considerations for security and privacy into the protocol design, both the small health app developer’s and the large medical institution’s data are assured of robust protection. This solution not only provides an effective mechanism for private-set intersection but also demonstrates resilience against potential collusion threats.

7.5. Experimental Analysis

7.5.1. Data Computation Volume

When evaluating the performance of these protocols, the computational load borne by the small health app developer is undoubtedly a critical factor. Since all three protocols have been introduced, this section specifically focuses on the computational volume of the small health app developer to accurately gauge and compare the efficiency of the three distinct protocols in operation. Specifically, this section will conduct a detailed analysis and comparison of the main computational tasks that the small health app developer must execute across these protocols to fully assess each protocol’s demand on the small health app developer’s computational resources. This analysis will primarily focus on the types of operations involved, aiming to clarify which protocol demonstrates relative advantages in reducing the small health app developer’s computational burden, thus providing a solid basis for selecting the most appropriate protocol. Below is an analysis of the main types of operations involved in each protocol, focusing primarily on the outsourcing and intersection processes, as the preprocessing can be completed offline.

• Unbalanced PSI-CA protocol based on Cuckoo filter: Two rounds of modular exponentiation operations and filter retrieval.
• Unbalanced PSI-CA protocol based on single-cloud assistance: A single round of multiplication operations.
• Unbalanced PSI-CA protocol based on dual-cloud assistance: Two rounds of multiplication operations.

An analysis of the single-instance time consumption for these four operations offers a practical insight into the computational volume differences:

• Modular Exponentiation Operation: Representing computation-intensive operations, modular exponentiation becomes particularly time-consuming. On a standard hardware setup, the time required for a single modular exponentiation operation depends primarily on the size of the numbers involved and the efficiency of the algorithm.
• Multiplication Operation: Compared to modular exponentiation, multiplication operations execute much faster on modern computing systems, even when involving large numbers. Therefore, whether it is a single round of multiplication in the single-cloud protocol or two rounds in the dual-cloud protocol, the processing times are relatively short.
• Cuckoo Filter Retrieval: Although relatively quick, the retrieval operation for a Cuckoo filter involves memory access, which may make it slightly slower than simple arithmetic operations. The exact time required for this operation depends on the size of the filter and the efficiency of the implementation.

After a detailed analysis and comparison, this section has conducted a thorough exploration of the key computational tasks executed by the small health app developer across the three different protocols. These tasks include modular exponentiation, multiplication operations, and Cuckoo filter retrieval By assessing these types of computations and their specific time consumptions, the following conclusions can be drawn:

• Unbalanced PSI-CA Protocol Based On Cuckoo Filter: Primarily relies on two rounds of modular exponentiation, which are computation-intensive, especially when dealing with large numbers, making it the most time-consuming of all the operations reviewed. Additionally, the filter retrieval operation is also involved.
• Unbalanced PSI-CA Protocol Based On Single-Cloud Assistance: By executing a single round of multiplication, it significantly alleviates the computational burden on the small health app developer. Multiplication operations, even for large numbers, can be done quickly.
• Unbalanced PSI-CA Protocol Based On Dual-Cloud Assistance: Includes two rounds of multiplication operations, also aiming to distribute the computational pressure on the small health app developer. Although it involves two rounds of multiplication, due to the inherent efficiency of the operation, the total processing time remains within an acceptable range.

Through the meticulous assessment of each protocol’s computational types and their time consumptions, it is evident that both the unbalanced PSI-CA protocol based on single-cloud assistance and unbalanced PSI-CA protocol based on dual-cloud assistance exhibit excellent performance in reducing the small health app developer’s computational burden, particularly in the efficient execution of multiplication operations. In contrast, the unbalanced PSI-CA protocol based on Cuckoo filter, while potentially offering stronger security provisions, shows some deficiencies in efficiency and timeliness. Therefore, when choosing an appropriate protocol, a balance should be struck based on actual performance requirements and security needs.

7.5.2. Protocol Running Time

After introducing all three protocols, this section primarily discusses the running times of the protocols. The running time of a protocol is an important benchmark for evaluation in this paper because it directly reflects the protocol’s efficiency in practical operations. The factors affecting the running time of the protocol include computational time and communication time. As shown in

Table 5. Running times of the three protocols under different data volume combinations.

Data Volume	Protocol I Running Time (s)	Protocol II Running Time (s)	Protocol III Running Time (s)
$2^{10}|2^{15}$	0.1539	0.1543	0.1612
$2^{10}|2^{17}$	0.1569	0.1573	0.1742
$2^{10}|2^{20}$	0.1616	0.1611	0.1736
$2^{10}|2^{25}$	0.1693	0.1683	0.1868
$2^{15}|2^{15}$	4.9239	3.8223	4.3904
$2^{15}|2^{17}$	5.0232	3.9145	4.9128
$2^{15}|2^{20}$	5.1709	4.0267	4.6099
$2^{15}|2^{25}$	5.4172	4.2233	4.8281
$2^{17}|2^{17}$	20.0930	15.6768	18.2058
$2^{17}|2^{20}$	20.6841	16.1281	20.2155
$2^{17}|2^{25}$	21.6690	16.8939	20.0528
$2^{20}|2^{20}$	165.4731	129.0516	148.7145
$2^{20}|2^{25}$	173.3531	135.2534	165.9464

, experiments were conducted to record the running times of the protocols under various data volume combinations. Table 5 also places the running times of the unbalanced PSI -CA protocol based on Cuckoo filter, unbalanced PSI-CA protocol based on single-cloud assistance, and unbalanced PSI-CA protocol based on dual-cloud assistance side by side for comparative analysis. Here, Protocol I refers to the unbalanced PSI-CA protocol based on Cuckoo filter, Protocol II refers to the unbalanced PS-CAI protocol based on single-cloud assistance, and Protocol III refers to the unbalanced PSI-CA protocol based on dual-cloud assistance.

It is noteworthy that the preprocessing stages of all three protocols can be completed offline, meaning they do not directly contribute to online operation delays. Therefore, the recorded running times in this paper refer to the total time of all processes, excluding preprocessing. Specifically, in Protocol I this primarily refers to the total duration of the intersection process; in Protocols II and III, it refers to the total duration of both the outsourcing and intersection processes.

Through experimental analysis, the paper draws the following conclusions: At smaller data volumes, the performance differences between the three protocols are not significant. However, as the data volume increases, the differences in running times between the protocols become apparent. Generally, the unbalanced PSI-CA protocol based on Cuckoo filter tends to have the longest running time, while the unbalanced PSI-CA protocol based on single-cloud assistance has the shortest running time, and the performance of the unbalanced PSI-CA protocol based on dual-cloud assistance is in the middle. This phenomenon can be explained by the complexity of data handling and the differences in communication overhead among the protocols. The unbalanced PSI-CA protocol based on Cuckoo filter, due to its direct and unoptimized calculations, is less efficient when handling large volumes of data. Nevertheless, at very small data volumes, where the proportion of communication time is relatively high, the impact of data transmission costs on total running time becomes significant. In such cases, the unbalanced PSI-CA protocol based on Cuckoo filter does not necessarily appear inefficient because other protocols might be even less efficient in data transmission. Especially in environments with poor network conditions or limited data transfer rates, the lower communication demands of the unbalanced PSI-CA protocol based on Cuckoo filter might, in some cases, lead to better performance.

Moreover, the running times of the unbalanced PSI-CA protocol based on single-cloud assistance and the unbalanced PSI-CA protocol based on dual-cloud assistance are significantly reduced through distributed computing and the use of cloud resources, especially when dealing with large-scale datasets. In summary, choosing the appropriate protocol requires a comprehensive consideration of factors such as data volume, computational resources, and network environment. In practical applications, understanding the performance characteristics and suitable scenarios of each protocol is crucial for optimizing data processing workflows and enhancing efficiency.

7.6. Summary of This Chapter

The protocol leverages the computational and storage resources of two cloud servers, significantly reducing the burden on the small health app developer by lowering its computational and storage requirements and enhancing the system’s efficiency and availability. Through distributed computing and security measures such as homomorphic encryption, it ensures the privacy of data during transmission and processing, adequately protecting the sensitive information of both the small health app developer and the large medical institution. This solution not only improves the operational efficiency of devices with limited resources but also effectively prevents collusion attacks. Consequently, the unbalanced PSI-CA protocol based on dual-cloud assistance excels in private-set intersection operations, demonstrating both high efficiency and security.

7.7. Extensions

To enhance the practicality of the scheme, this section will explore two key aspects from an engineering practice perspective: the design of the PSI-CA network and the design of the data update mechanism.

First, the design of the PSI-CA network focuses on building an efficient, secure, and scalable network architecture to support large-scale PSI-CA computations.

Second, the design of the data update mechanism involves how to update the datasets stored on the cloud servers without interrupting the service. This is particularly crucial for PSI-CA computation scenarios that require frequent data updates.

7.7.1. PSI-CA Network

As previously described, the small health app developer delegates PSI-CA computations to two cloud servers. In practice, a vast network of cloud servers can be built to support this delegation. The basic system description is as follows.

• Access and Authentication of Cloud Servers: Any server can apply to become a cloud server, also known as a server assistant. These servers must undergo a series of certification processes (including hardware performance verification, security vulnerability scanning, and compliance checks) to ensure they meet security and performance standards. Servers that pass the certification but later violate regulations will be blacklisted and removed. The system maintains platform security and trust through mechanisms such as regular security scans and real-time monitoring, with any violations leading to immediate removal and further investigation of the server.
• Mechanism for Selecting Server Assistants: When needing to perform PSI-CA, small health app developers choose two cloud servers based on their performance (such as processing power, storage capacity, and network bandwidth), stability, security capabilities, and compliance with regulations, among other hard and soft factors. Cloud servers with high availability promises are preferred to minimize the risk of failures.
• Execution Mechanism for PSI-CA Operations: The PSI-CA network supports small health app developer flexibility and system scalability; small health app developers can execute PSI-CA on different large medical institutions by merely changing $E_{pk}\left(a\right)$ and obfuscated dataset $Y^{\prime }$, without needing to redesign the entire system. This design enhances small health app developer flexibility and the system’s efficiency, reliability, and security.

This system design not only achieves the delegation of PSI-CA computations but also introduces multiple cloud servers into the network, thereby enhancing the system’s flexibility and stability. Additionally, by implementing authentication and maintaining a blacklist for cloud servers, the system can better guarantee the credibility of the cloud servers, enhancing overall security. This flexible yet secure system design provides small health app developers with more options and makes PSI-CA operations more adaptable to various practical requirements.

In summary, under the existing framework, small health app developers can delegate computing and storage tasks to different cloud servers and perform PSI-CA operations on various large medical institutions by using different random numbers, $E_{pk}\left(a\right)$, and obfuscated dataset $Y^{\prime }$. This method allows small health app developers to more flexibly use multiple resource nodes and optimize task distribution, thereby further enhancing the overall performance and security of the privacy protection scheme.

7.7.2. Data Updates

To further enhance the practicality of the scheme, this paper also designs a data update mode compatible with the scheme, making the overall scheme more practical and reliable.

• Data Updates on the Large Medical Institution’s Side:
  As shown in Figure 5, the update details of the large medical institution are as follows:
  Definition of main participants and related symbols:
  • Large medical institution: Represents the large medical institution that wants to encrypt and upload updated data to cloud server $H_2$.
  • Cloud server $H_2$: Represents the cloud-assisted server $H_2$ that assists the large medical institution in completing update operations.
  • Z represents the set of data to be updated; $z_k$ represents the k-th element of Z.
  • $\omega$ represents the load factor of the filter.
  • $z_k^{\prime }$ represents the data $z_k$ after encryption processing.
  • ${\mathrm{update}}_k$ represents the operation index, used to determine whether the update operation is an insertion or deletion.
  • U represents the set of data sent by the large medical institution to the cloud-assisted server $H_2$; $u_k$ represents the k-th element of U.
  Update process:
  • The large medical institution has a set of elements Z it wants to insert or delete. These elements are blinded before being sent to cloud server $H_2$. Specifically, $z_k^{\prime }=E_{p{k}_c}{\left(a\right)}^{\alpha \ast H\left(z_k\right)}$.
  • In addition to sending the blinded elements, the large medical institution also sends an identifier variable ${\mathrm{update}}_k$ to inform the small health app developer whether the operation is an insertion or a deletion.
  • During an insertion operation, $H_2$ first checks whether the current filter’s load factor $\omega$ exceeds 0.95.
  • If the load factor $\omega$ is greater than 0.95, then $H_2$ must request the large medical institution to generate a new filter using all elements to maintain high spatial and lookup efficiency of the filter.
  • If the load factor $\omega$ is less than or equal to 0.95, then $H_2$ can directly insert the element into the current filter $CF$.
  • In a deletion operation, $H_2$ removes the specified element from the filter $CF$, a process that does not require generating a new filter.
• Data Updates on the Small Health App Developer’s Side:
  As shown in Figure 6, the update details of the small health app developer are as follows:
  Definition of main participants and related symbols:
  • Small health app developer: Represents the small health app developer who wants to perform data updates.
  • Cloud server $H_1$ represents the cloud-assisted server $H_1$ that assists the small health app developer in completing update operations.
  • Cloud server $H_2$ represents the cloud-assisted server $H_2$ that assists the small health app developer in completing update operations.
  • Z represents the set of data to be updated; $z_k$ represents the k-th element of Z.
  • $z_k^{\prime }$ represents the data after being processed by the hash function H.
  • k represents the data index, used to determine the type of update, either insertion or deletion, and to retrieve the updated data based on the index.
  • When adding data, ${\mathrm{date}}_k$ represents the data processed through the dual-cloud scheme and sent to the two cloud-assisted servers. When deleting, ${\mathrm{date}}_k$ is null.
  • V represents the set of data sent by the small health app developer to the cloud-assisted server $H_1$; $v_k$ represents the k-th element of V.
  • $V^{\prime }$ represents the set of data sent by the small health app developer to the cloud-assisted server $H_2$; $v_k^{\prime }$ represents the k-th element of $V^{\prime }$.
  Update process:
  • The small health app developer has a set of elements Z it wants to insert or delete. In both cases, the small health app developer blinds each element and sends them to $H_1$ and $H_2$, respectively.
  • The small health app developer sends a data index K to inform the cloud servers about the type of update, whether it is an insertion or a deletion. If the index is less than $n_2$, it indicates a deletion operation. In this case, ${\mathrm{data}}_k$ is null, and $H_1$ and $H_2$ delete the corresponding data based on the index.
  • If the index is greater than $n_2$, it indicates an addition operation, and the corresponding calculation results and index are saved.
  • After completing a batch of deletion and addition operations, the relative order of the indices also needs to be adjusted. The update process is illustrated in Figure 5.

8. Conclusions and Future Work

8.1. Work Summary

Privacy computing is a technology framework aimed at protecting individual privacy during the process of data use and sharing. It ensures that data can still be effectively utilized without disclosing specific content through various algorithms and protocols. Among many applications of privacy computing, Privacy Set Intersection (PSI-CA) is a common requirement, which allows two or more parties to compute the cardinality of the intersection without revealing their private data.

Traditional PSI-CA protocols are primarily designed for cases where datasets are relatively balanced in size, which often does not apply in real scenarios. In many practical situations, the size disparity between participants’ datasets is significant, necessitating the use of unbalanced PSI-CA protocols. These protocols are specifically designed to handle such disparities, optimizing computational efficiency and privacy protection to cater to a wider range of practical needs. By adopting unbalanced PSI-CA protocols, not only is the processing efficiency improved, but more precise control over data protection is also offered, thus finding broader application in various data-sensitive industries. This paper proposes three protocols: the unbalanced PSI-CA protocol based on Cuckoo filter, the unbalanced PSI-CA protocol based on single-cloud assistance, and the unbalanced PSI-CA protocol based on dual-cloud assistance. Here, the unbalanced PSI-CA protocol based on Cuckoo filter addresses the performance issues of traditional PSI-CA protocols in handling unbalanced datasets. On this basis, the unbalanced PSI-CA protocol based on single-cloud assistance transfers most of the computational and storage burdens from the small health app developer to the cloud, enhancing practicality. Faced with the possibility of collusion attacks, the unbalanced PSI-CA protocol based on dual-cloud assistance employs security mechanisms such as homomorphic encryption to effectively resist these attacks. The main contributions of this paper are summarized as follows:

• Addressing the shortcomings of traditional PSI-CA protocols when dealing with significant data size disparities among participants, this paper proposes the first protocol, namely the unbalanced PSI-CA protocol based on Cuckoo filter.
• Given the complexities of cryptographic operations and storage demands of the small health app developer in the unbalanced PSI-CA protocol based on Cuckoo filter, this paper introduces an unbalanced PSI-CA protocol based on single-cloud assistance. This protocol effectively transfers the majority of computational and storage burdens from the small health app developer to the cloud.
• In response to potential collusion between the cloud and large medical institution in the unbalanced PSI-CA protocol based on single-cloud assistance, this paper proposes a unbalanced PSI-CA protocol based on dual-cloud assistance with security mechanisms like homomorphic encryption, which effectively prevents collusion attacks while offloading computational and storage burdens.
• In view of the practical problems of the unbalanced PSI-CA protocol based on dual-cloud assistance, this paper also designs a PSI-CA network and a data update mode tailored for the unbalanced PSI-CA protocol based on dual-cloud assistance.

8.2. Three Protocols

As shown in

Table 6. Overall performance summary of the three protocols.

Protocol	Security	Client Storage & Computational Burden	Runtime
Unbalanced PSI-CA Protocol based on Cuckoo Filter	High Security (no collusion attacks)	Requires storing Cuckoo filter and intensive computation	Longest
Unbalanced PSI-CA Protocol based on Single-Cloud Assistance	Security Risks (cannot resist collusion attacks)	Shifted to cloud server	Fastest
Unbalanced PSI-CA Protocol based on Dual-Cloud Assistance	High Security (can resist collusion attacks)	Shifted to cloud server	Moderate

, this section provides a comprehensive summary and recommendations for the three protocols discussed in this paper. The unbalanced PSI-CA protocol based on Cuckoo filter offers high security but involves significant computational and storage demands, making it suitable for clients with strong computational and storage resources. The unbalanced PSI-CA protocol based on single-cloud assistance, while being the fastest and offloading computational burdens to the cloud, poses security risks as it cannot withstand collusion attacks, making it appropriate for scenarios where the cloud is fully trusted. The unbalanced PSI-CA protocol based on dual-cloud assistance offers an ideal balance of runtime, security, and efficiency, making it the most versatile and practical option.

8.3. Future Outlook

Although the protocols proposed in this document are applicable in most scenarios, there are still several aspects that could be optimized for future development:

• All protocols are designed for two-party unbalanced PSI-CA. Extending these protocols to multi-party scenarios is an important future direction, given the practical needs for multi-party computations.
• The protocols are developed under a semi-honest security model. Extending their robustness to malicious models, where adversaries may actively attempt to undermine the protocols, represents a crucial area for further research.
• The current protocols are focused exclusively on PSI-CA. In practical applications, there may be a need to carry out other types of computations, such as PSI-SUM, etc. Expanding the protocols to support a variety of computational types is another significant direction for future work.