Updatable Private Set Intersection with Low Communication Overhead

Abstract

Private set intersection (PSI) is a fundamental cryptographic task that allows two mutually distrusting parties, each holding a private set of elements, to jointly compute the intersection of their sets. It ensures a symmetric information structure where neither party gains any knowledge about the other’s elements beyond those in the shared intersection. Traditional PSI protocols are primarily designed for static settings, which limits their applicability and efficiency in dynamic scenarios where input sets continuously evolve. To address this challenge, the notion of updatable PSI (UPSI) was introduced, enabling repeated PSI computations over changing inputs while preserving the symmetric privacy guarantees between participants. Despite the numerous recent advancements in UPSI research, it still suffers from significant communication overhead. In this paper, we address this challenge by introducing LcUPSI (low-communication UPSI), a new updatable PSI protocol that achieves remarkably low communication overhead. We formally prove that LcUPSI is secure in the semi-honest model. Furthermore, we compare the LcUPSI protocol with the state-of-the-art UPSI protocol BMSTZ24 (ASIACRYPT). The results demonstrate that LcUPSI significantly reduces communication overhead, highlighting its advantages in low-bandwidth conditions.

1. Introduction

Private set intersection (PSI) is a fundamental cryptographic primitive that enables two mutually distrustful parties, each holding a private set, to jointly compute their intersection without revealing any other information. Its wide-ranging practical applications—spanning from online ad conversion measurement [1] and password breach alerts to private contact discovery [2] and privacy-preserving contact tracing during pandemics—have made it a central topic in applied cryptography. This practical demand has fueled decades of research, leading to a rich landscape of highly efficient PSI constructions built upon diverse cryptographic paradigms. Among these paradigms, approaches based on oblivious transfer (OT) [3,4,5,6,7], vector oblivious linear evaluation (VOLE) [8,9,10,11,12], RSA [13,14], Diffie–Hellman [1,15,16], circuit-based protocols [17,18,19,20], and fully homomorphic encryption (FHE) [21,22,23] have all been extensively studied. A more general variant, known as Circuit PSI [8,11,12,17,19,24], allows the parties to obtain secret shares of the intersection and then securely compute arbitrary functions over it using generic secure two-party computation protocols [25,26]. As a result of these extensive works, modern PSI protocols can achieve high efficiency under both the semi-honest and malicious security models [4,6,8,9,10,11,19,22,23,24,27] and preserve symmetric privacy guarantees between participants.

However, existing PSI protocols suffer from a critical limitation: when parties need to update their sets (e.g., by adding or removing elements), as in real-world applications such as advertising aggregation and privacy-preserving contact tracing, PSI must be performed repeatedly on periodically updated sets (e.g., on a daily basis). In many cases, these updates are significantly smaller than the entire dataset. Nevertheless, most existing protocols require both parties to re-execute the full PSI protocol for each update, leading to considerable computational and communication overhead in scenarios with frequent set modifications.

1.1. Related Work

Applying traditional static private set intersection (PSI) protocols to dynamic scenarios where the set content evolves continuously is a challenging research direction. The most straightforward approach is to completely re-execute the entire PSI protocol after each set update. However, in common scenarios where the update size is much smaller than the total set size, this “start-from-scratch” strategy incurs significant computational and communication overhead, leading to extremely low efficiency.

To address this challenge, researchers have begun exploring updatable PSI (UPSI) solutions. Early attempts, such as those proposed by Kiss et al. [28], introduced a baseline approach for incremental updates, leveraging technologies like RSA signatures, Diffie–Hellman, and other techniques for secure computation. Despite the progress, these solutions are limited by their inability to support dynamic updates (i.e., adding and deleting elements) efficiently. In particular, servers still require frequent full set recalculations, which significantly increases both computation and communication overhead.

Another approach is to introduce a third-party server for delegated computation. For example, Abadi et al. [29] constructed a multi-party delegated PSI protocol, where the client inserts elements into a hash table and uploads it to the server. During updates, only the corresponding buckets need to be downloaded and modified. Although this is an innovative model, it relies on an additional online server throughout the phases, including storage, update, and PSI computation. Therefore it falls outside the standard two-party online UPSI setting considered in this work.

The development of truly two-party UPSI protocols has also gone through an evolutionary process. The initial protocols [30] only supported “weak deletion,” where elements could only be deleted in bulk after being inserted for a fixed time window. This resembled a periodic old data cleanup mechanism rather than arbitrary deletion. Agarwal et al. [31] introduced a UPSI framework based on structured encryption, marking the first protocol to support both arbitrary insertions and deletions with complexities that scale only poly-logarithmically relative to the total set size. Later, Badrinarayanan et al. [32] achieved a UPSI protocol that supports arbitrary deletions and achieves per-round complexity that scales only with the size of the update set. Meanwhile, other studies have focused on enhancing the security of UPSI, such as the work by Wang et al. [33], which introduced the concept of “forward privacy” and proposed the FUPSI protocol based on keyword PIR. Informally, forward privacy in the UPSI setting means that information revealed in previous rounds should not enable an adversary to infer additional information about the other party’s current updates beyond the unavoidable leakage from the updated intersection itself.

Among the most closely related works, ALOS22 [34] provides the pairing-based encryption and witness verification framework that inspires our construction. However, ALOS22 is not an updatable PSI protocol and does not address repeated updates. The main contribution of LcUPSI is to extend this framework to the UPSI setting. More specifically, we introduce bucketization to reduce unnecessary computation and communication in update rounds, and we use OKVS to reduce $P_0$’s pairing-related complexity from quadratic to linear in the bucket size. In contrast, BMSTZ24 [32] is a state-of-the-art UPSI protocol that provides a more general construction without relying on a trusted third party. Relative to BMSTZ24, LcUPSI places greater emphasis on fewer interaction rounds, lower communication volume, and better support for computationally constrained parties such as $P_1$.

However, despite the breakthroughs in theoretical complexity achieved by state-of-the-art UPSI protocols [32], their practical application still faces a key bottleneck: high communication overhead. Although the communication volume is proportional to the size of the update set, the protocol requires multiple rounds of interaction, and each round involves large data packets, resulting in significant communication costs. This poses a severe practical challenge in applications with limited network bandwidth (such as mobile networks and the Internet of Things) or those sensitive to latency. Therefore, the core issue in current research is that existing solutions cannot simultaneously satisfy the flexibility of arbitrary updates and the need for extremely low communication overhead. In light of this, we raise the following question:

Can we design a UPSI protocol with minimal communication overhead?

1.2. Our Results

In this work, we consider a standard two-party setting involving two participants, denoted as $P_0$ (the Sender) and $P_1$ (the Receiver), holding private sets X and Y, respectively. We present LcUPSI, a two-party UPSI protocol designed to minimize communication overhead. Technically, LcUPSI does not introduce a new pairing verification mechanism from scratch; instead, it builds on the ALOS22-style accumulator and witness verification framework and extends it to the updatable setting. The main novelty lies in two aspects: first, bucketization is used to reduce unnecessary computation and communication in update rounds; second, OKVS is incorporated to reduce $P_0$’s pairing-related complexity from quadratic to linear in the bucket size. Compared with BMSTZ24 [32], LcUPSI further emphasizes fewer interaction rounds, lower communication cost, and practical friendliness to weaker participants such as $P_1$, whereas BMSTZ24 provides a more general UPSI construction without relying on a trusted third party. We analyze and compare LcUPSI with BMSTZ24, and the results demonstrate that our protocol offers the following advantages:

• LcUPSI requires only three rounds of communication with minimal communication overhead, whereas BMSTZ24 requires more than 14 rounds. This makes our protocol significantly more stable and efficient, particularly in low-bandwidth conditions.
• LcUPSI is particularly efficient for participant $P_1$, who only needs to perform simple operations with a minimal computational cost. Although $P_0$ incurs higher computational costs, the majority of its computation is performed offline and can be flexibly scheduled during idle periods, leading to a practical balance between online efficiency and overall system performance.

1.3. Overview

Section 2 introduces the notation and necessary preliminaries used throughout this paper. Section 3 presents the detailed construction of the LcUPSI protocol and provides analyses of its complexity, correctness and security. In Section 4, we compare its performance with the state-of-the-art UPSI protocol. Section 5 discusses an optimization for our protocol. In Section 6, we make a conclusion regarding our protocol as well as directions for future work.

Extending standard PSI protocols to the UPSI setting introduces new challenges, including increased computational and communication overhead, as well as potential privacy leakage. Reusing parameters across rounds can inadvertently expose additional information about participants’ input sets. Furthermore, existing UPSI adaptations of PSI protocols often face limitations such as increased communication rounds, high bandwidth requirements, and weakened security guarantees. While techniques like homomorphic encryption offer certain advantages, they often entail significant computational costs and poor scalability with frequent updates. To address these challenges, we adopt the following approach. We propose the LcUPSI protocol, a highly efficient updatable private set intersection (UPSI) solution that minimizes communication overhead while ensuring strong privacy guarantees. The protocol allows two participants to securely compute the intersection of their dynamic private sets with only three rounds of interaction. Initially, one participant constructs an accumulator over their set and sends it to the other participant, who computes and sends back encrypted pairing values. These values are verified in subsequent rounds to determine the intersection. This interaction remains concise and structured, resulting in an efficient communication process between the two parties. By using bilinear maps, accumulators, and Oblivious Key–Value Stores (OKVSs), our protocol reduces redundant computations and communication costs in update rounds, making it ideal for real-time, privacy-preserving applications. We formally prove its security in the semi-honest model, ensuring that only the intersection is revealed and no additional private information is exposed.

2. Preliminaries

In this section, we provide an overview of the symbols and notation used in this paper, as well as the underlying cryptographic primitives and definitions relevant to our protocol construction.

2.1. Notation

In this paper, we use $\mathrm{\Pi }$ to represent a protocol and use PPT to denote probabilistic polynomial time. The notation $a\stackrel{\$}{\leftarrow }A$ means that a is randomly chosen from the set A. The size of set A is denoted by $\left|A\right|$, and $A/B$ represents the set difference, i.e., $A-A\cap B$. The symbol $x\left|\right|y$ denotes the concatenation of x and y. We use $\lambda$ to refer to the statistical security parameter and $\kappa$ to the computational security parameter. A hash function is represented by H.

2.2. Updatable PSI

UPSI is a cryptographic protocol that allows two (or more) parties to repeatedly compute the intersection of their private sets when these sets are dynamically updated over time through additions and deletions, without revealing any information beyond the intersection itself. A key limitation of traditional static PSI protocols is that, whenever the sets change, it is necessary to re-run the entire PSI computation over the updated sets. This approach leads to significant computational and communication overhead, especially in scenarios where updates are frequent or where the size of each update is much smaller than the total set size. UPSI provides a dynamic extension to standard PSI, addressing many of the limitations of static PSI protocols in dynamic settings. Specifically, UPSI enables the repeated computation of the intersection between parties’ continually evolving private sets and allows for the reuse of previously generated data, rather than scaling proportionally with the total set size.

The two-party UPSI model is the most fundamental and widely used setting for updatable private set intersection. It applies to scenarios in which exactly two parties each possess private datasets that are dynamically updated over time. The two parties interact repeatedly, maintaining the protocol’s internal state across rounds. In each round (e.g., for daily updates), both parties input their sets to be updated or the updated sets themselves, and the ideal functionality computes the intersection of the current sets, delivering the result to the authorized party or parties.

In indexed settings such as PIR, a modification operation may require separate discussion because data items are associated with explicit positions or indices. In contrast, in the UPSI setting considered here, as well as in BMSTZ24 and related UPSI protocols, the protocol is defined over sets of elements rather than indexed records. Under this set-based formulation, an element modification is naturally interpreted as a deletion of the old element followed by an insertion of the updated element and thus does not introduce additional leakage beyond these two supported operations.

Here, arbitrary deletion means that a party may delete any chosen element in an update round without relying on a fixed expiration window or bulk cleanup mechanism as in weak deletion. In LcUPSI, when one party deletes an element while the other inserts the same element in the same update round, the protocol does not reveal any additional information about whether the deleting party held that element before the round beyond what is logically implied by the protocol output. On the other hand, if an element already appeared in the previous intersection and one party deletes it, then the other party may infer this deletion from the change between the previous and updated intersections. Such leakage is inherent in the functionality of UPSI itself and is therefore unavoidable.

UPSI inherits the security objectives of PSI and is typically defined with respect to the semi-honest adversary model; that is, apart from the intersection output (or related values depending on the application) in each round, the protocol reveals no other information about either party’s input set. Even after multiple rounds of updates, the existence or deletion of elements not present in the intersection output remains hidden from other parties and adversaries, thus ensuring consistent and symmetric privacy guarantees over time.

2.3. Oblivious Key–Value Store

An Oblivious Key–Value Store (OKVS) is a data structure that encodes a set of key–value pairs into a compact object S from which values can later be retrieved by key alone. Formally, let $\mathcal{K}$ be the key space and $\mathcal{V}$ the value space. Let ${\mathsf{Encode}}_H$ and ${\mathsf{Decode}}_H$ be the encoding and decoding algorithms, which may internally use a family of hash functions H. Given a set of distinct key–value pairs $A=\left\{(k_i,v_i)\right\}$, the encoding outputs $S\leftarrow {\mathsf{Encode}}_H\left(A\right)$ (or ⊥ with negligible probability); the decoding algorithm retrieves $v\leftarrow {\mathsf{Decode}}_H(S,k)$ for any key k. Correctness requires that, if $S\ne \perp$, then for all $(k,v)\in A$, ${\mathsf{Decode}}_H(S,k)=v$.

The oblivious property means that, when the values are random, S leaks no information about the underlying keys: for any two sets of distinct keys $\left\{k_i^0\right\}$ and $\left\{k_i^1\right\}$, as long as encoding does not fail, ${\mathsf{Encode}}_H\left(\left\{(k_i^b,v_i)\right\}\right)$ (for uniformly random $v_i\in \mathcal{V}$) is computationally indistinguishable for $b\in \{0,1\}$.

There exist a variety of OKVS constructions, such as those based on polynomials [10], cuckoo hashing [4,10,11], random band matrices [8], VOLE [11,35] and buckets [36]. The LcUPSI protocol proposed in this paper can be instantiated with any OKVS construction.

3. Our UPSI Protocol

At the outset of our protocol design, we considered constructing the scheme based on a bilinear map e, which has $e(g_1^a,g_2^b)=e{(g_1,g_2)}^{ab}$. Specifically, $P_0$ first computes the accumulated product $c=\prod _{x\in X}x$. It then independently samples a random blinding factor r and uses the exponent $cr$ to generate the ciphertext $C=g_1^{cr}$, which is then sent to $P_1$. Upon receiving this message, $P_1$ returns two values: the target $T=e(C,g_2^s)$ and $\widehat{y}=g_2^{ys}$, where s is a random value. In this manner, $P_0$ can locally construct a witness $W=C^{1/x_i}$ and verify whether $e(W,\widehat{y})=T$; if the equality holds, then $x_i=y$.

While this construction is simple, it suffers from an obvious security flaw: $P_0$ can locally construct a witness for some $z\notin X$ and, by passing the verification, can learn elements in $P_1$’s set. Inspired by ALOS22 [34], we introduce a trusted third party to distribute parameters, ensuring that $P_0$ must construct witnesses for its own set elements using polynomial-based techniques, thereby preventing the construction of witnesses for elements not in its set. We provide a brief overview of our protocol workflow in Figure 1.

In this section, we first present the protocol flow of both the initial and update rounds of the LcUPSI protocol and subsequently provide proofs of correctness and security.

3.1. Definition

The symbols used in the LcUPSI protocol are explained in

Table 1. The notations used in our LcUPSI protocol.

Notations	Comments
$X,Y$	$P_0$’s set and $P_1$’s set, $\left|X\right|=n,\left|Y\right|=m$
$X_i,Y_i$	$P_0$’s subset and $P_1$’s subset, $|X_i|=n_i,\left|Y_i\right|=m_i$
$x_{i,j}$	The j-th element of subset $X_i$
$W_{i,j}$	The witness of $x_{i,j}$
$X_{old},Y_{old}$	The sets of $P_0$ and $P_1$ in the last iteration
$X^{-},X^{+}$	$P_0$’s deleted and added sets, $|X^{+}|+|X^{-}|=N$
$Y^{-},Y^{+}$	$P_1$’s deleted and added sets, $|Y^{+}|+|Y^{-}|=M$
$X_i^{\prime },Y_i^{\prime }$	The updated sets of $P_0$ and $P_1$
$X/x_i$	A set that includes all elements of set X except for $x_i$
$I_{old}$	The intersection in the last round
$I_{upd}$	The updated intersection in the current update round
b	The number of their buckets (as well as subsets)
$T_i$	The OKVS table corresponding to $Y_i$

. We divide the LcUPSI protocol into two parts: the initial round protocol for the first intersection computation among the participants and the update round protocol for subsequent intersection computations. The two protocols are introduced as follows.

The initial round of LcUPSI works with $P_0$ and $P_1$. $P_0$ inputs its private set X, while $P_1$ inputs its private set Y. At the end of this round, $P_0$ and $P_1$ output the intersection $I_i=X\cap Y$. This is formally captured by the standard ideal functionality ${\mathcal{F}}_{LcUPSI}^{IR}$ in Figure 2.

In the update round of LcUPSI, $P_0$’s input consists of the previous intersection set $X_{\mathrm{old}}$, the subsets $X_i$, the computed ciphertexts and witnesses (see Section 3.3 for details) from the last iteration, and the addition set $X^{+}$ and deletion set $X^{-}$. $P_1$ inputs the set $Y_{\mathrm{old}}$, the subsets $Y_i$, the intersection $I_{\mathrm{old}}$ from the last iteration, and the addition set $Y^{+}$ and deletion set $Y^{-}$. $P_1$ learns the updated intersection $I_{\mathrm{upd}}=((X_{\mathrm{old}}/X^{-})\cup X^{+})\cap ((Y_{\mathrm{old}}/Y^{-})\cup Y^{+})$. This is formally captured by the standard ideal functionality ${\mathcal{F}}_{LcUPSI}^{UR}$ in Figure 3.

3.2. Construction of LcUPSI’s Initial Round

In the initial round of the LcUPSI protocol, $P_0$ and $P_1$ input their private sets X and Y respectively. At last they output the intersection $I=X\cap Y$. We provide a detailed explanation below.

3.2.1. Setup Phase

In the setup phase, $P_0$ and $P_1$ agree on the number b of their buckets, where $b>N$ and $N=\max \left(\right|X^{-}|+|X^{+}|,|Y^{-}|+|Y^{+}\left|\right)$ denotes the larger update set size in each update round. Here, b is fixed for the entire lifetime of the protocol and is not dynamically resized during later update rounds. Therefore, before executing the protocol, both parties should select b according to the approximate size of the update sets they expect to use in subsequent update rounds. The impact of this choice is further analyzed in Section 4.1. They should also agree on three hash functions $H_1, H_2, H_B$, where $H_1,H_2:{\{0,1\}}^{*}\to {\{0,1\}}^{\lambda }$ and $H_B$ is a hash function with sufficiently uniform output distribution, which is used for bucketing by the participants. A bilinear map $e:{\mathbb{G}}_1\times {\mathbb{G}}_2\to {\mathbb{G}}_T$ where the generators are $g_1,g_2,g_T=e(g_1,g_2)$ respectively is agreed upon by the participants. A random key $k\in {\mathbb{Z}}_q^{*}$ is sampled by a trusted third party trusted by $P_1$. $P_0$ decides the maximum bucket size L and sends L to the trusted third party. Then, the trusted third party computes and sends ${\mathrm{setup}}_0=(g_2^k,g_2^{k^2},\dots ,g_2^{k^L})$, ${\mathrm{setup}}_1=\left(g_1^k\right)$ to $P_0$ and $P_1$ respectively (a possible future direction is to replace the trusted third party with a distributed setup procedure, where multiple parties jointly generate the setup and the protocol remains secure as long as at least one of them is honest).

3.2.2. Compute Ciphertext

$P_0$ first puts X into b buckets $B=(B_1,B_2,\dots ,B_b)$ by computing $\left(H_B\left(x_i\right)\mathrm{mod}b\right)+1$. Every bucket $B_i(i\in \left[1,b\right])$ stores a subset $X_i$; let $n_i$ be the size of $X_i$. Then for every subset $X_i$, $P_0$ samples a random value $r_i$ and computes its ciphertext $C_i$, together with computing all the witnesses of elements in the subset. These processes are respectively presented formally as subroutine EncryptSet in Figure 4 and GetWitness in Figure 5. After computation, $P_0$ sends all the ciphertexts and the index of each ciphertext to $P_1$.

Note that all the computation above can be pre-computed locally by $P_0$ prior to the protocol execution. $P_0$ can also first compute and send ciphertexts to $P_1$ and execute the protocol in parallel with $P_1$ to compute the witnesses of all elements, thereby improving the overall efficiency of the protocol.

3.2.3. Sign Element

$P_1$ also uses a hash function $H_B$ to put its private set Y into b subsets $Y_i(i\in [1,b])$. For each subset $Y_i$, $P_1$ samples a random permutation $\pi$ over the indices of the elements in $Y_i$ before encoding, so that $P_0$ cannot infer the original ordering of $P_1$’s elements within the bucket from the resulting OKVS table. Then for every element $y_{i,j}\in Y_i$, $P_1$ samples a random value $s_{i,j}$ and computes $\widehat{y_{i,j}}={\left(g_1^k·g_1^{-y_{i,j}}\right)}^{s_{i,j}}$ and $V_{i,j}=H_1\left(e\left(g_1^{s_{i,j}},C_i\right)\right)$, where $j\in [1,m_i]$, with $m_i$ being the size of the subset $Y_i$. Next, $P_1$ encodes $\left\{\right(H_2\left(y_{i,1}\right),\widehat{y_{i,1}}\left|\right|V_{i,1})\cdots (H_2\left(y_{i,m_i}\right),\widehat{y_{i,m_i}}\left|\right|V_{i,m_i}\left)\right\}$ into an OKVS table $T_i$ and sends $T_i(\forall i\in [1,b])$ with its corresponding index i to $P_0$.

3.2.4. Evaluate Pairing

After receiving the OKVS tables from $P_1$, for each element $x_{i,j}$, $P_0$ computes $H_2\left(x_{i,j}\right)$ to decode the corresponding table $T_i$ and gets $\widehat{y_{i,j}^{\prime }},V_{i,j}^{\prime }$. Iff $H_1\left(e(W_{i,j},\widehat{y_{i,j}^{\prime }})\right)=V_{i,j}^{\prime }$, $H_2\left(x_{i,j}\right)$ is put into the set Z. Finally, sends Z to $P_1$; $P_1$ can easily get the intersection I by comparing the hash values of its own elements. The formal description of LcUPSI’s initial round protocol is given in Figure 6.

3.3. Construction of LcUPSI’s Update Rounds

In the subsequent update rounds, $P_0$ inputs an addition set $X^{+}$ and a deletion set $X^{-}$. $P_1$ also inputs an addition set $Y^{+}$ and a deletion set $Y^{-}$. At the end of the protocol, $P_1$ learns the updated intersection $I_{upd}=((X_{old}/X^{-})\cup X^{+})\cap ((Y_{old}/Y^{-})\cup Y^{+})$. To reduce the communication overhead in the second round of the update rounds in the LcUPSI protocol, we choose to let $P_1$ determine which elements require additional intersection computation based on the previously obtained intersection and the updated ciphertexts sent by $P_0$. During the evaluate pairing phase, $P_0$ can also learn part of the intersection; nevertheless, it still achieves symmetric privacy protection, ensuring that no information regarding elements outside the shared intersection is leaked, and all information learned by either party is confined to the intersection of their sets. Naturally, if it is necessary for $P_0$ to learn the entire intersection, $P_1$ can simply return the full result (or their corresponding hash values) after the computation completes. This approach incurs minimal additional computational and communication cost. The formal description of LcUPSI’s update round protocol is given in Figure 7. The update rounds in LcUPSI largely follow the same procedure as the initial round; we will describe the differences in the following.

$P_0$ first hashes its updated set into the original buckets using the same method as in the initial round, pushes out each element $x_i\in X^{-}$ from its corresponding subset, and pushes each element $x_i\in X^{+}$ into the corresponding subset, using a bit array $flag$ to mark the indices of the updated subsets. As a result, $P_0$ gets $N_B\le N$ updated subsets from $X_i$ to $X_i^{\prime }$. $P_0$ only needs to re-compute ciphertexts of these updated subsets and witnesses of the elements in them. For the subsets that have not been updated, it is sufficient to randomize their ciphertexts and the witnesses of the elements in them using the same random value, without the need for re-computation. This selective update strategy follows a consistent and structured transformation across subsets, ensuring that unchanged components are treated uniformly while minimizing redundant computation. All the computation above can be pre-computed locally by $P_0$. Later, $P_0$ sends the updated ciphertexts $C_i^{\prime }$ and the bit array $flag$ to $P_1$.

Elements that were part of the original intersection and whose corresponding subsets are not marked by the bit array $flag$ are stored in the set $I_1$, since they remain in the old intersection and have neither been deleted nor modified during the update process. For elements whose subsets are marked by the $flag$, their ciphertexts are computed and subsequently encoded into OKVS tables according to the subset encoding. For newly added elements $y_{i,j}\in Y^{+}$, their ciphertexts are computed, and the corresponding subset indices are bound to them before being transmitted to $P_0$ together with the encoded OKVS tables. After pairing, $P_1$ gets set Z from $P_0$, and $P_1$ can obtain $I_{upd}=((X_{old}/X^{-})\cup X^{+})\cap ((Y_{old}/Y^{-})\cup Y^{+})=I_1\cup I_2$, where $I_2$ is the corresponding set associated with Z. In the degenerate case where one party submits empty addition and deletion sets in a given round, that party’s set remains unchanged in this round. More specifically, if $X^{+}=X^{-}=\varnothing$, then $((X_{old}/X^{-})\cup X^{+})=X_{old}$ (if $Y^{+}=Y^{-}=\varnothing$, then $((Y_{old}/Y^{-})\cup Y^{+})=Y_{old}$). If both parties submit no updates, i.e., $X^{+}=X^{-}=Y^{+}=Y^{-}=\varnothing$, then the protocol handles this case gracefully and the output reduces to $I_{upd}=I_{old}$.

3.4. Complexity, Correctness and Security

3.4.1. Complexity

Assuming the original set sizes of $P_0$ and $P_1$ are n and m, respectively, and the sizes of the update sets are N and M, the computational and communication complexities of LcUPSI are both $O\left(N\left(n/b+m/b\right)+M\right)$.

3.4.2. Security

We state Theorem 1 below and defer its proof to Appendix A. The computational assumption on which the security of our protocol relies is a $(B_1,B_2)$-Strong Bilinear Decisional Diffie–Hellman ($(B_1,B_2)-SBDDH$) problem as follows: A challenger picks a random $k\in {\mathbb{Z}}_q^{*}$ and outputs a $(B_1+B_2+2)$-tuple of elements $(g_1,g_1^k\cdots g_1^{k^{B_1}},g_2,g_2^k\cdots g_2^{k^{B_2}})\in {\mathbb{G}}_1^{B_1+1}\times {\mathbb{G}}_2^{B_2+1}$. The adversary, on input this string, outputs $y\in {\mathbb{Z}}_q$. Then the challenger flips a random bit a and, if $a=0$, outputs $V=e{(g_1,g_2)}^{1/(y+k)}$, whereas if $a=1$ it samples V as a random element from the target group. The goal of the adversary is to guess the bit a given the V as input. This is given more formally as follows.

Definition 1.

(($B_1$, $B_2$)-Strong Bilinear Decisional Diffie–Hellman Problem (($B_1$, $B_2$)-SBDDH)). Let $G_{b,(B_1,B_2),\mathcal{A}}^{SBDDH}$ denote the game described above. We say that the $(B_1,B_2)$-SBDDH problem is hard if, for every PPT adversary $\mathcal{A}$, the advantage

$$Ad{v}_{(B_1,B_2),\mathcal{A}}^{SBDDH}\left(\kappa \right):=\left|\mathrm{Pr}\left(G_{0,(B_1,B_2),\mathcal{A}}^{SBDDH}\left(\kappa \right)=1\right)-\mathrm{Pr}\left(G_{1,(B_1,B_2),\mathcal{A}}^{SBDDH}\left(\kappa \right)=1\right)\right|$$

(1)

is negligible in the security parameter κ.

The $(B_1,B_2)$-SBDDH assumption holds if no PPT adversary can solve the $(B_1,B_2)$-SBDDH problem with more than negligible probability.

Theorem 1.

The protocols ${\mathrm{\Pi }}_{LcUPSI}^{IR}$ and ${\mathrm{\Pi }}_{LcUPSI}^{UR}$ securely implement ${\mathcal{F}}_{LcUPSI}^{IR}$ and ${\mathcal{F}}_{LcUPSI}^{UR}$ in the presence of a passively corrupted adversary, assuming the hardness of the $(1,B)$-SBDDH problem (Definition 1) and collision resistance of H.

3.4.3. Correctness

Let $x_{i,j}$ be an element in $P_0$’s subset $X_i$ and y be an element in $P_1$’s set Y, where $y=x_{i,j}$. Both parties share a common hash $H_B$ and a parameter b. As a result, the elements y will be put into the subset $Y_i$, which has the same index as $X_i$.

• $P_1$’s Computation:

$P_1$ computes $H_2\left(y\right)$, $\widehat{y}={\left(g_1^k·g_1^{-y}\right)}^s$, $V=H_1\left(e\left(g_1^s,C_i\right)\right)$. It then encodes $(H_2\left(y\right),\widehat{y}|\left|V\right)$ into OKVS table $T_i$.

• $P_0$’s Computation:

Upon receiving $T_i$, $P_0$ uses $H_2\left(x_{i,j}\right)$ to decode the OKVS table $T_i$ and obtains the corresponding value $\widehat{y}\left|\right|V$.

$P_0$ then computes the following pairing-based verification:

$$\begin{array}{cc}\hfill H_1(e(\widehat{y},W_{i,j}))& =H_1(e(g_1^{s(k-y)},g_2^{rP(X_i/x_{i,j},k)}))\hfill \\ \hfill & =H_1(e{(g_1,g_2)}^{rs(k-y){\prod }_{x\in X_i,x\ne x_{i,j}}(k-x)}).\hfill \end{array}$$

(2)

Because $y=x_{i,j}$,

$$\begin{array}{cc}\hfill H_1(e(\widehat{y},W_{i,j}))& =H_1(e{(g_1,g_2)}^{rs(k-y){\prod }_{x\in X_i,x\ne x_{i,j}}(k-x)})\hfill \\ \hfill & =H_1(e{(g_1,g_2)}^{rsP(X_i,k)}).\hfill \end{array}$$

(3)

And also

$$\begin{array}{cc}\hfill V& =H_1(e(g_1^s,C_i))\hfill \\ \hfill & =H_1(e(g_1^s,g_2^{r{\prod }_{x\in X_i}(k-x)}))\hfill \\ \hfill & =H_1(e{(g_1,g_2)}^{rsP(X_i,k)}).\hfill \end{array}$$

(4)

Therefore, when $x_{i,j}=y$, the equation $H_1\left(e(\widehat{y},W_{i,j})\right)=V$ holds, meaning that $P_0$ can successfully perform the pairing.

4. Experiment and Evaluation

We implemented our LcUPSI protocol in C++ (Standard C++17), utilizing the RELIC toolkit for the underlying cryptographic operations. We instantiate the Oblivious Key–Value Store (OKVS) based on the construction by Ling et al. [36]. Since this OKVS natively supports only 128-bit values, we introduce a multi-table chunking scheme to facilitate the encoding and decoding of larger payloads. More specifically, our implementation uses the semi-honest instantiation of Ling et al. with redundancy parameter $ϵ=0.13$. Under the recommended parameters of that construction, each bucket encoding succeeds with probability at least $1-2^{-\lambda }$; if an encoding failure occurs, we simply re-run the encoding for that bucket locally before proceeding.

All experiments were conducted on a single machine equipped with an Intel i5-13600KF (3.50 GHz) CPU, 32 GB RAM, and Windows 11. We selected parameters at the 128-bit security level for the experiment. All protocol participants were run as separate processes on the same host, communicating via local inter-process communication. No artificial network bandwidth or latency was imposed, and thus all reported running times primarily reflect the computational overhead and local communication cost, representing a best-case scenario.

4.1. The Impact of Parameter $\rho$ on Efficiency

In the experiment presented in Figure 8, we evaluate the impact of varying $\rho$ on the communication cost and $P_1$’s online computation time under the parameter settings: $P_0$’s set size is fixed at $n=2^{14}$, while both parties update their sets with size $N^d=2^4$ in each update round. For $P_1$’s set size, we consider two configurations, namely $m=2^{11}$ and $m=2^{13}$. Here, $\rho ={\log }_2(N^d/b)$, where b denotes the number of buckets. In Figure 8, we choose $\rho$ in the range $[-6,-2]$, which corresponds to $b\in [2^6,2^{10}]$. Since $n=2^{14}$, this means that the average bucket size $n/b$ varies from $2^4$ to $2^8$, covering a representative transition from relatively fine-grained bucketing to relatively coarse-grained bucketing and including the empirically favorable region observed in our experiments.

When $\rho$ decreases (i.e., b increases), fewer elements fall into each bucket. This reduces the amount of re-computation needed in the touched buckets and therefore lowers $P_1$’s online time. However, if $\rho$ is too small, then the number of buckets becomes excessively large, which increases the number of ciphertexts sent in the initial round and also enlarges the bucket-level bookkeeping overhead. Moreover, under the average-case assumption that the bucketing hash function is uniformly distributed, a fixed bucket on $P_0$’s side remains untouched after T update rounds with probability ${(1-1/b)}^{T{N}^d}\approx e^{-T{N}^d/b}=e^{-T{2}^{\rho }}$. Consequently, all buckets are expected to be touched only after roughly $O\left((b/N^d)\log b\right)=O\left(2^{-\rho }\log b\right)$ rounds. Thus, when b is too large, many buckets may remain unchanged for a long time, and the practical benefit of further increasing b diminishes.

On the other hand, if $\rho >-2$, then $b<64$ and the average bucket size exceeds $2^8$. In this regime, each touched bucket becomes too large, which significantly increases $P_0$’s encryption and witness generation cost and also increases $P_1$’s online workload because more elements in the touched buckets need to be processed. Therefore, we selected $\rho \in [-6,-2]$ to illustrate the main efficiency trade-off in a representative parameter region.

4.2. Comparison with State-of-the-Art Protocol

BMSTZ24 [32] is currently the latest and most efficient updatable PSI protocol, published in ASIACRYPT 2024. We conducted tests on LcUPSI and the ${\mathrm{\Pi }}_{\mathsf{UPSI}-{\mathsf{Del}}_{\mathsf{psi}}}$ protocol from BMSTZ24 under the same experimental setup (for simplicity, we hereafter use BMSTZ24 to refer to the ${\mathrm{\Pi }}_{\mathsf{UPSI}-{\mathsf{Del}}_{\mathsf{psi}}}$ protocol in BMSTZ24). In this experiment, we tested the total runtime (Total Time), $P_1$’s online runtime ($P_1$’s Time), and total communication overhead (Comm.) of the BMSTZ24 and LcUPSI protocols under the conditions where both $P_1$’s and $P_0$’s original sets are of size $2^{14}$, $2^{16}$, and $2^{18}$ and the update sets are of size $2^3$, $2^5$, and $2^7$, respectively. For the LcUPSI protocol, the reported Total Time includes $P_0$’s preprocessing cost, including ciphertext generation and witness generation. For the LcUPSI protocol, we set the parameter $b=n/2^7$. Each set of experiments was tested three times, and the median value was recorded for comparison. The detailed experimental data are shown in

Table 2. Performance comparison of BMSTZ24 and LcUPSI.

$\mathit{n},\mathit{m}$	${\mathit{N}}^{\mathit{d}}$	Protocol	Total Time (s)	${\mathit{P}}_1$’s Time (s)	Total Comm. (MB)
$2^{14}$	$2^3$	BMSTZ24	22.933	—	14.222
		LcUPSI	15.874	1.172	0.500
	$2^5$	BMSTZ24	80.428	—	60.280
		LcUPSI	42.726	3.485	1.518
	$2^7$	BMSTZ24	329.260	—	257.343
		LcUPSI	96.437	8.315	3.596
$2^{16}$	$2^3$	BMSTZ24	23.354	—	14.790
		LcUPSI	15.352	1.158	0.517
	$2^5$	BMSTZ24	76.000	—	59.533
		LcUPSI	52.451	4.487	1.931
	$2^7$	BMSTZ24	323.832	—	254.569
		LcUPSI	176.460	15.076	6.761
$2^{18}$	$2^3$	BMSTZ24	24.528	—	14.257
		LcUPSI	14.708	1.208	0.563
	$2^5$	BMSTZ24	85.629	—	60.954
		LcUPSI	55.700	4.629	2.066
	$2^7$	BMSTZ24	327.449	—	256.762
		LcUPSI	214.027	17.713	8.162

Note: “—” denotes that the data for this item was not tested.

. By comparison, we can draw the following conclusions:

• Total Running Time: Across all nine data points in Table 2, LcUPSI consistently outperforms BMSTZ24 in total runtime. The advantage becomes more pronounced as the update size grows, especially when $N^d=2^7$, where the runtime gap is particularly visible. This indicates that LcUPSI offers a clear practical benefit in total runtime across the tested parameter range.
• $P_1$’s Online Time: In this experiment, we did not directly measure the online time of individual participants in BMSTZ24. However, according to the protocol flow (see Figure 10 in BMSTZ24 [32]), a participant in BMSTZ24 remains engaged throughout almost the entire protocol execution. In contrast, in LcUPSI, most of the heavy preprocessing is carried out locally by $P_0$, and $P_1$ is involved only in a much shorter online phase. As shown in Table 2, $P_1$’s online runtime in LcUPSI remains small across all tested settings, which makes the protocol particularly attractive in scenarios where $P_1$ is the relatively weaker participant.
• Communication Overhead: In terms of communication overhead, LcUPSI consistently outperforms BMSTZ24 across all tested parameter settings. The gap is especially pronounced when the update size is small and remains substantial even for larger updates. This advantage is closely related to the round complexity: BMSTZ24 requires at least 14 rounds of interaction (depending on the implementation of ${\mathcal{F}}_{\mathrm{lookup}}$ in BMSTZ24), whereas LcUPSI requires only three rounds, with a significantly smaller communication volume per round. This makes LcUPSI particularly attractive in bandwidth-constrained settings and in scenarios where $P_1$ is the relatively weaker online participant.

Figure 9 further compares the communication cost of LcUPSI with that of the state-of-the-art static PSI protocol LTT+25 [36], which currently achieves the lowest communication overhead among static PSI protocols. Although LcUPSI incurs a relatively high one-time initialization cost, its per-update communication is substantially smaller when the update size is small, and it remains competitive for moderate updates, which is precisely the dynamic regime targeted by UPSI.

5. Optimizations

5.1. Strictly One-Sided Output

Upon reviewing our LcUPSI protocol, we note that $P_0$ can learn part of the intersection (see Appendix A for further details). While the protocol guarantees that no information about elements other than those in the intersection will be revealed, it still does not achieve strictly one-sided output. In certain application scenarios where it is essential that only $P_1$ obtains the intersection elements at the end of the protocol, while $P_0$ learns nothing about the intersection, this limitation may pose a challenge. To address this, our protocol (as presented in Section 3) can be adapted by incorporating a shuffled oblivious pseudo-random function (shuffled OPRF) protocol [37] at the beginning, ensuring that the output remains strictly one-sided while still preserving the privacy and security guarantees of the original protocol.

Shuffled OPRF

A shuffled OPRF allows $P_0$ with inputs $X=\langle x_1,x_2,\cdots ,x_n\rangle$ to learn shuffled outputs

$$X^{°}=\langle OPR{F}_{k_{\mathsf{oprf}}}\left(x_{\pi \left(1\right)}\right),OPR{F}_{k_{\mathsf{oprf}}}\left(x_{\pi \left(2\right)}\right),\cdots ,OPR{F}_{k_{\mathsf{oprf}}}\left(x_{\pi \left(n\right)}\right)\rangle ,$$

(5)

where $k_{\mathsf{oprf}}$ is $P_1$’s input key and $\pi \left(·\right)$ is $P_1$’s random input permutation. $P_1$ learns nothing from this functionality. $P_0$ cannot find the corresponding OPRF value for a specific input. The overall workflow of the shuffled OPRF is illustrated in Figure 10. Note that the key $k_{\mathsf{oprf}}$ referred to in this section is different from the key $k_{\mathsf{ttp}}$ randomly selected by the trusted third party during the preprocessing phase in previous sections.

Instead of generating ciphertexts and witnesses for X as in Section 3, here $P_0$ generates ciphertexts and witnesses from the elements of the set $X^{°}$.

Since $P_1$ knows the key $k_{\mathsf{oprf}}$, $P_1$ can trivially compute the OPRF outputs

$$Y^{°}=\langle OPR{F}_{k_{\mathsf{oprf}}}\left(y_1\right),OPR{F}_{k_{\mathsf{oprf}}}\left(y_2\right),\cdots ,OPR{F}_{k_{\mathsf{oprf}}}\left(y_m\right)\rangle$$

(6)

by inputting its items and then encodes

$$\left\{\right(OPR{F}_{k_{\mathsf{oprf}}}\left(y_{i,1}\right),\widehat{y_{i,1}}\left|\right|V_{i,1})\cdots (OPR{F}_{k_{\mathsf{oprf}}}\left(y_{i,m_i}\right),\widehat{y_{i,m_i}}\left|\right|V_{i,m_i}\left)\right\}.$$

(7)

into an OKVS table $T_i$, instead of using $H_2\left(y_{i,j}\right)$ as the key in the sign elements step of the protocol. In the subsequent evaluate pairing step of the protocol, $P_0$ can use elements in $X_i^{°}$ to decode $T_i$ and attempt the pairing operation (where $X_i^{°}$ denotes the shuffled OPRF value of $P_0$’s subset $X_i$) and then return the shuffled OPRF values that result in a successful pairing to $P_1$. It is important to note that, due to shuffling, $P_0$ does not know the correspondence between any shuffled OPRF value and the elements in $P_0$’s set; thus, $P_0$ learns nothing about the items in $X\cap Y$ even if $P_0$ knows $X^{°}\cap Y^{°}$. Finally, $P_1$ can determine $X\cap Y$ by matching the shuffled OPRF values of its own elements with those returned by $P_0$.

6. Conclusions

In this paper, we introduced the LcUPSI protocol, a novel updatable private set intersection (UPSI) solution that significantly reduces communication overhead and requires only three interaction rounds. This reduction in rounds not only improves robustness under low-bandwidth conditions, but also makes the protocol particularly advantageous when $P_1$ is the relatively weaker online participant. In terms of novelty, LcUPSI does not introduce a new pairing verification mechanism from scratch; rather, it builds on the pairing-based accumulator and witness verification framework of ALOS22 and extends it to the updatable PSI setting. Its main technical contribution is the integration of bucketization and OKVS, which reduces unnecessary computation and communication in update rounds and lowers $P_0$’s pairing-related complexity from quadratic to linear. Compared with BMSTZ24, which provides a more general UPSI construction without relying on a trusted third party, LcUPSI emphasizes substantially fewer interaction rounds and lower communication overhead in practical two-party settings.

Currently, there are no known updatable PSI protocols designed for the multi-party setting. We are actively working on constructing and implementing multi-party UPSI protocols as part of our future work. In addition, we aim to develop more secure UPSI protocols that achieve security against malicious adversaries.