Delegated multi-party private set intersections from extendable output functions

Traditional private set intersection protocols

Traditional private set intersection (PSI) protocols enable clients to compute the intersection of their datasets while keeping their private data local and secure. These protocols typically involve direct client-to-client or client-to-server interaction, assuming all parties have sufficient computational resources. Since the introduction of PSI by Freedman, Nissim & Pinkas (2004), it has been a key focus in privacy-preserving computations. Their protocol utilizes homomorphic encryption and balanced hashing to compute set intersections securely.

Following this foundational work, various extensions have been developed with enhanced security models and functionalities. For instance, Kissner & Song (2005) implement multiparty intersection computation using the polynomial representation of sets combined with additive homomorphic encryption. Building on these advancements, (Hazay & Lindell, 2008) leverage oblivious pseudorandom functions in their PSI construction. To enhance security against malicious adversaries, Dachman-Soled et al. (2009) develop a robust PSI protocol using homomorphic encryption, enhanced Shamir secret sharing, cut-and-choose techniques, and zero-knowledge proofs. In a similar direction, Hazay & Nissim (2010) later develop a PSI protocol specifically designed for the malicious adversarial model, based on Freedman’s earlier work. Moreover, Camenisch & Zaverucha (2009) introduce a PSI protocol requiring signed input sets, which need verification from a trusted certifying authority. De Cristofaro, Kim & Tsudik (2010) also devise an efficient PSI protocol for malicious settings, employing public-key encryption and hash functions to improve performance. Ateniese, De Cristofaro & Tsudik (2011) design a protocol that conceals the size of the clients’ input set for added privacy.

In the semi-honest model, Huang, Evans & Katz (2012) propose a garbled circuit-based PSI protocol, achieving $O(n\log n)$ complexity for symmetric key operations, where $n$ represents the set size. Meanwhile, Many, Burkhart & Dimitropoulos (2012) introduce a PSI protocol using a Bloom filter, where parties query the filter to obtain the intersection. However, this method leaks information about the other party’s set, making it insecure.

Furthermore, Dong, Chen & Wen (2013) design two different PSI protocols: one for semi-honest adversaries and another for malicious adversaries, both relying on the garbled Bloom filter intersection and oblivious transfer, making them scalable for large dataset processing. Later the same year, Dong et al. (2013) propose a fair mutual PSI protocol relying on a trusted third party, allowing both parties to receive the output. However, this approach incurs high costs due to the dependence on zero-knowledge proofs and oblivious polynomial evaluation.

This line of work is further refined by Debnath & Dutta (2015), making Bloom filter-based PSI a viable solution for large-scale private set operations. Similarly, Bay et al. (2022), Vos et al. (2024) have extended these improvements with further optimizations based on Bloom filters. Moreover, Cuckoo filters (Pinkas et al., 2018; Jiang et al., 2023) have been widely adopted to reduce memory and computation costs.

In parallel, Pinkas, Schneider & Zohner (2014) propose PSI protocols utilizing IKNP-OT (Ishai et al., 2003), achieving notable improvements in computational efficiency at the cost of increased communication. Further efficiency gains are achieved by Kolesnikov et al. (2016), who leverage Oblivious Transfer Extension (OTE) to construct a batched oblivious pseudorandom function. Their method achieves two- to three-fold improvement in computational efficiency for two-party PSI, making it one of the fastest protocols in high-speed networks. Following these advancements, Rindal & Rosulek (2017) improve PSI efficiency by utilizing hashing schemes to reduce complexity and by employing the dual-execution technique from Mohassel & Franklin (2006). Subsequently, Kolesnikov et al. (2017) pioneer the oblivious programmable pseudorandom function technique, offering an efficient solution with symmetric-key operations and laying the foundation for later works like secret-shared PSI by Rindal & Schoppmann (2021).

Furthermore, bitset-based methods combined with homomorphic encryption (Ruan et al., 2019; Bay et al., 2021) have been proposed. Key agreement protocols such as those in Rosulek & Trieu (2021), Wei et al. (2024) have also facilitated secure PSI computations between multiple parties. Finally, the emergence of quantum computing has prompted researchers to explore quantum PSI protocols, which promise enhanced security against quantum attacks while reducing communication complexity (Shi et al., 2015; Liu, Zhang & Shi, 2020).

Overall, traditional PSI protocols rely on direct interaction between parties and do not support data outsourcing. Hence, each party needs to store its data locally, leading to significant storage overhead. Furthermore, these protocols require continuous online participation from all parties throughout the computation, increasing communication costs and limiting scalability, particularly in distributed or resource-constrained environments.

Outsourced PSI protocols

Outsourced/delegated private set intersection (OPSI) protocols address scenarios where clients have limited computational resources by introducing a third-party, typically a cloud server, to perform the intersection computation. In this model, clients delegate the computationally intensive set intersection task to the server, thus benefiting from its storage and processing capabilities.

In this section, we provide a structured overview of existing OPSI protocols, categorizing them based on their cryptographic foundations into symmetric-based and asymmetric-based protocols, highlighting their contributions and limitations. A detailed comparison is presented in Table 1.

XOR-sharing using XOFs

An XOF takes an input message and an output size $d$, and produces a cryptographically secure digest of $d$ bits. In our delegated PSI protocol, large masks are needed to ensure that only the intersection of sets is revealed. Consequently, XOFs are effective for this purpose because they can generate these large masks from secret values, and the masks have the property that their XOR combination results in zero. Specifically, if each pair of clients $({\mathcal{P}}_i,{\mathcal{P}}_{i^{\prime }})$ share a secret value $s_{i,i^{\prime }}=s_{i^{\prime },i}$ that only they know, where $i,i^{\prime }\in \{1,\dots ,n\}$, we can use XOFs to generate large masks M that combine to zero with high performance, relying on the self-inverse property of the XOR function:

(1) $$M_i\leftarrow \underset{i\ne i^{\prime }}{\oplus }{\mathrm{X}\mathrm{O}\mathrm{F}}_d(s_{i,i^{\prime }}).$$

Here, $\oplus$ denotes the bitwise XOR operation applied across all relevant terms, and ${\mathrm{X}\mathrm{O}\mathrm{F}}_d(s_{i,i^{\prime }})$ represents the output of the XOF applied to the secret $s_{i,i^{\prime }}$, producing a digest of $d$ bits.

This technique is essentially a non-interactive version of the dining cryptographer’s problem (Chaum, 1988), in which each party’s randomness is replaced by a keyed pseudo-random function in the form of an XOF.

Bloom filters for set intersections

Many previous works perform set intersections privately by first representing the sets as Bloom filters (Bay et al., 2022; Debnath et al., 2021; Miyaji, Nakasho & Nishida, 2017). A bloom filter is a data structure with $m$ bins that are either $0$ or $1$. It is indexed by $h$ hash functions, so that when queried, the result is only $1$ when all indexed bins are indeed $1$. This corresponds to an AND operation. To create a Bloom filter representing a set X, one iterates over all elements $x\in X$ and evaluates hashes ${\mathcal{H}}_j(x)\in \{0,\dots ,m-1\}$ for $j=1,\dots ,h$. The bins indicated by the hash functions are set to $1$.

To compute the Bloom filter representing the intersection, we only have to perform an AND operation between the respective bins of the input Bloom filters. To find the intersection from its Bloom filter representation, one must perform a query for each element in one of the original sets. Suppose the intermediate Bloom filter is leaked to any of the parties. In that case, they can learn the distribution of the elements contained in the original input sets when the number of hash functions $h>1$ (Vos, Conti & Erkin, 2022). We use cryptographic hash functions in this work to obfuscate the resulting Bloom filter from the server so that the server does not know the relationship between the $1$s in the Bloom filter and the elements in the universe $\mathcal{U}$. This does reveal information about the cardinality of the intersection to the server.

Membership queries in Bloom filters are approximate because they might return false positives. We denote the probability of false positives by $\epsilon$, which is the probability that a query gives the wrong result. Goel & Gupta (2010) provide an upper bound for $\epsilon$ when N elements have been inserted in a Bloom filter:

(2) $$\epsilon \le {\left(1-e^{-\frac{h(N+0.5)}{m-1}}\right)}^h.$$

In practice, we only tolerate a maximum probability of false positives $\epsilon$. So, we want to select the most compact Bloom filter to satisfy this constraint, which leads to a convex minimization problem (Vos, Conti & Erkin, 2022):

(3) $$\underset{h\ge 1}{min}\lceil -\frac{h(N+0.5)}{\ln 1-\sqrt[h]{\epsilon }}\rceil +1.$$

Setup of the protocol

Our protocol relies on private channels between each client and the server, which must be set up ahead of time. Next, we rely on the fact that there exists a shared random seed between each pair of clients $({\mathcal{P}}_i,{\mathcal{P}}_{i^{\prime }})$, which must stay secret. While it is possible to let a third party generate these seeds, the parties can also generate them collectively using a series of pairwise Diffie-Hellman key exchanges. As a consequence, the network topology would go from a star to a full mesh. In the setup, the clients must also agree on a set of hash functions ${\mathcal{H}}_j$ for $j=1,\dots ,h$, without the server learning them. One possibility is for the clients to engage in a random coin toss together and use the resulting randomness as a key for the cryptographic hash functions. Finally, all clients must agree on the size of the Bloom filter $m$, which is not secret.

Computing the intersection

Each client ${\mathcal{P}}_i$, $1\le i\le n$ has input set $X_i$ and collective hash functions ${\mathcal{H}}_1,\dots ,{\mathcal{H}}_h$, which are unknown to the server. The server ${\mathcal{P}}_{\mathrm{s}\mathrm{r}\mathrm{v}}$ has no inputs. Client ${\mathcal{P}}_q$ is the querying client, who receives the final intersection. See Fig. 1 for the depiction of the protocol; the steps of the protocol are enumerated as follows:

• 1.

  Each client ${\mathcal{P}}_i$ encodes their set $X_i$ as a Bloom filter ${\hat{X}}_i$.

• 2.

  Each client ${\mathcal{P}}_i$ transforms all zeroes in ${\hat{X}}_i$ to 40 bits of randomness and all ones to zeroes: $${\hat{Y}}_i[t{]}_{40}\leftarrow \{\begin{array}{cc}{r}_{i,x}\hfill & \mathrm{i}\mathrm{f}{\hat{X}}_i[t]=0\hfill \\ 0\dots 0\hfill & \mathrm{i}\mathrm{f}{\hat{X}}_i[t]=1\hfill \end{array}$$

• where $r_{i,x}\in \{0,1{\}}^{40}$ and $t=0,\dots ,m-1$.

• 3.

  Each client ${\mathcal{P}}_{\mathcal{i}}$ computes $M_i$ using Eq. (1), then computes the message: $$R_i\leftarrow \underset{40\mathrm{m}\mathrm{b}\mathrm{i}\mathrm{t}\mathrm{s}}{\underbrace{{\hat{Y}}_i\oplus M_i}}$$

• and sends $R_i$ to the server ${\mathcal{P}}_{\mathrm{s}\mathrm{r}\mathrm{v}}$.

• 4.

  The querying client ${\mathcal{P}}_q$ computes: $$H\leftarrow \{{\mathcal{H}}_1(x),\dots ,{\mathcal{H}}_h(x)\}\mathrm{\forall }x\in X_q$$

• and sends it to the server ${\mathcal{P}}_{\mathrm{s}\mathrm{r}\mathrm{v}}$.

• 5.

  The server ${\mathcal{P}}_{\mathrm{s}\mathrm{r}\mathrm{v}}$ aggregates all $R_i$ into $R\leftarrow {\oplus }_i{R}_i$. We refer to this XOR-based combination of masked Bloom filters as aggregated masking.

• 6.

  The server checks whether the 40-bit segments of R indicated by the querying client are all zero: $$I_x\leftarrow R[{\mathcal{H}}_1(x){]}_{40}=0\dots 0\wedge \dots \wedge R[{\mathcal{H}}_h(x){]}_{40}=0\dots 0$$

• for all $x\in X_q$, and sends the result to the querying client ${\mathcal{P}}_q$.

• 7.

  The querying client ${\mathcal{P}}_q$ outputs $Z\leftarrow \{x\in X_q\mid I_x=1\}$.

Notice that the output of XOFs plays a crucial role in concealing the 40-bit zeros present in ${\hat{Y}}_i[j]$, which indicate the presence of an element in the set. These 40-bit zeros will effectively disappear when the messages $R_i$’s from all parties are combined, as $M_1\oplus M_2\oplus \dots \oplus M_n=0$. In the protocol description, we chose to work over 40-bit secret shares. While it is possible to choose smaller shares, this would result in a higher probability of a $1$ in the Bloom filter accidentally turning into a $0$. Such a phenomenon would lead to false negatives, which makes studying the protocol’s correctness significantly harder. By choosing 40 bits, the probability of this occurring is negligible at $2^{-40}$.

This protocol is correct because the server ${\mathcal{P}}_{\mathrm{s}\mathrm{r}\mathrm{v}}$ only returns the index of $x$, a data set element of ${\mathcal{P}}_q$, when $R[{\mathcal{H}}_j(x){]}_{40}=0$ for all $j\in \{1,\dots ,h\}$, which reflects a Bloom filter query. This happens only when $x$ appears in every $X_i$ that is $x\in X_1\cap \dots \cap X_n$. Due to how we use Bloom filters in our protocol, $1$ s are replaced with 40 $0$ s, and $0$ s are replaced with 40-bit random bitstrings. This requires the value coming from all Bloom Filters to be 0 in that index for an element to exist in the intersected set. If even one is non-zero, a random number appears where that index is, thereby hiding the elements that are not in the intersection.

Updating the private sets

In Feather (Abadi et al., 2022), clients can update their inputs held by the server. We can use a similar trick to update inputs if the server has not yet revealed the intersection. For one client to update their private set, they must be able to turn a $0$ in the set representation to a $1$ or a $1$ to a $0$. They can do so for bin $j$ by knowing $r_{i,j}$. The client simply tells the server which segment $j$ to update and sends along $r_{i,j}$. The server XORs this value into the corresponding segment, flipping the encoded bit. This does reveal the access pattern to the server, as is also the case for Feather.

Efficiency

The computational effort for a client is dominated by the computation of the extendable output functions. The asymptotic run time of XOFs scales linearly with the number of bits in the output, which is $40\mathrm{m}$ in our case. As shown in “Concrete Communication Cost Analysis” of Vos, Conti & Erkin (2022), $m=O(k)$. Since each client must execute $n-1$ XOFs, the total asymptotic complexity is $O(nk)$. Communication-wise, each client only sends one message, which is exactly $40\mathrm{m}$ bits. So, in the same way, the asymptotic complexity is $O(k)$. The querying client sends another $hk$ elements of at most ${\log }_2(m)$ bits, so its complexity is $O(hk\log m)$.

In theory, the server only has to aggregate $h$ bins of the masked Bloom filters it received for each element. In other words, in the worst case, the server must perform $O(nkh)$ XOR operations. When it comes to communication, the server receives $n$ messages of length $40\mathrm{m}$, but it only sends one message back to the querying client, which has length $hk$ in the worst-case. So, asymptotically, the server sends $O(hk)$ bits.

Simulating a corrupted server

When $h=1$, the server does not learn any information from the protocol besides the size of the intersection $|X_1\cap \dots \cap X_n|$ and the size of the querier’s set $|X_q|$. We show that this is true by showing that a server with no access to the other client’s inputs can perfectly simulate the protocol’s execution.

Proof. The view of the server only contains the incoming messages $R_i$ for $i=1,\dots ,n$ and H. We construct simulator ${\mathcal{S}}_1$ as follows:

In step 3 of the protocol, ${\mathcal{P}}_{\mathrm{s}\mathrm{r}\mathrm{v}}$ receives $R_i$ for $i=1,\dots ,n$, which it must simulate. Knowing $|X_1\cap \dots \cap X_n|$, the simulator randomly samples $J\leftarrow \{0,\dots ,m-1{\}}^{|X_1\cap \dots \cap X_n|}$, which represent the Bloom filter indices that are set to $1$. It then generates $R{\in }_{\mathrm{R}}\{0,1{\}}^{40\mathrm{m}}$. For each $j\in J$, the simulator sets the 40-bit segment to zero: $R[j{]}_{40}\leftarrow 0\dots 0$. Finally, it generates $R_{i\prime }{\in }_{\mathrm{R}}\{0,1{\}}^{40\mathrm{m}}$ for $i^{\prime }=2,\dots ,n$, and $R_1\leftarrow R_2\oplus \dots \oplus R_n\oplus R$.

In step 4 of the protocol, ${\mathcal{P}}_{\mathrm{s}\mathrm{r}\mathrm{v}}$ receives H. The simulator first sets $H\leftarrow J$, and then insert random hashes ${\mathcal{H}}_1(x){\in }_{\mathrm{R}}\{0,\dots ,m-1\}$ into H until $|H|=|X_q|$.

We then show that these simulated incoming messages are indistinguishable from the actual messages:

From Lemma 1 we have that $\{M_2,\dots ,M_n\}\stackrel{\mathrm{s}}{\equiv }\{R_2,\dots ,R_n\}$ and that $M_1\stackrel{\mathrm{s}}{\equiv }{R}_2\oplus \dots \oplus R_n$. If we XOR some $x$ to any $M_i$ for $i=2,\dots ,n$ it still holds that the result is indistinguishable from randomness. If we do the same for $M_1$, it holds that $M_1\oplus x\stackrel{\mathrm{s}}{\equiv }{R}_2\oplus \dots \oplus R_n\oplus x$. In other words, so long as $R\stackrel{\mathrm{s}}{\equiv }{\hat{Y}}_1\cap \dots \cap {\hat{Y}}_n$, the simulated $R_1,\dots ,R_n$ are indistinguishable from those generated in the actual view.

Indeed, $R\stackrel{\mathrm{s}}{\equiv }{\hat{Y}}_1\cap \dots \cap {\hat{Y}}_n$ since for one hash function, the Bloom filter representing the intersection is identical to the Bloom filter that results from performing the inherent AND operation between the separately encoded Bloom filters. Since we replace the hash functions of the Bloom filter by random oracles that the server does not have access to, J is statistically indistinguishable from the set of actual ones in the Bloom filter.

H exactly corresponds to the hashes of the elements in the intersection. For the other elements $x\in X$, by replacing the hash function of the Bloom filter with a random oracle, ${\mathcal{H}}_1(x)$ are statistically indistinguishable from randomness by definition.

□

When $h>1$, the server cannot anymore simulate the protocol’s execution without knowledge of the distribution of the elements in the parties’ sets. At this point, a protocol where clients would simply send hashes of their set elements to the server would be sufficient, and significantly cheaper when it comes to communication. On the other hand, the Bloom filter does not fully leak this information, so one might trade-off the performance gain with increasing information leakage as $h$ increases.

Simulating corrupted clients

Finally, we show that $n-2$ colluding clients still learn no more information than they learn from each others’ inputs. Here, we only consider the case where the querying client colludes because the other case is trivial to simulate since the other parties do not receive any incoming messages. We show that a set of at most $n-2$ colluding clients, including the querying client, do not learn more information from the protocol than they learn from each others’ inputs, regardless of $h$.

Proof. The view of the corrupted parties is comprised of their inputs $X_i$ for $i\in C$, the messages $I_x$ for $x\in X_q$ received by the server ${\mathcal{P}}_{\mathrm{s}\mathrm{r}\mathrm{v}}$, and the output Z. Simulator ${\mathcal{S}}_3$ must therefore simulate all $I_x$, which it does as follows:

$$I_x\leftarrow \{\begin{array}{cc}0\hfill & \mathrm{i}\mathrm{f}x\notin Z\hfill \\ 1\hfill & \mathrm{i}\mathrm{f}x\in Z\hfill \end{array}.$$

It is trivial to see that this results in the correct output. Moreover, the simulated $I_x$ are statistically indistinguishable from the actual $I_x$; they are in fact identical, because any other $I_x$ would result in a different output. □

Validity and practical challenges of the non-colluding server setting

The non-colluding server setting is a fundamental assumption in the proposed protocol’s security framework. First, an important distinction must be made between this non-colluding server setting and the two non-colluding server model frequently used in secure multi-party computation (MPC). The first assumes that the server does not collude with any clients, while the latter only assumes that the two servers do not collude with each other. The crucial difference is that in the typical setting for outsourced MPSI, the scheme breaks if the server colludes with anyone, while in the setting commonly used in MPC, the scheme only breaks if the server colludes specifically with the other server. As such, the latter leads to a stronger notion of security.

The non-colluding server setting achieves unlinkability efficiently by using a single cryptographic hash function unknown to the server, avoiding the high computational costs of techniques like homomorphic encryption or mixnets. However, in our protocol, all clients must share the same hash function, necessitating a trusted or interactive setup.

Collusion could cause a significant risk in this setting. We analyze the level of breakage if even just one client ${\mathcal{P}}_c$ colludes with the server. In this case, the collective secret hash functions ${\mathcal{H}}_j$ for $j=1,\dots ,h$ are leaked to the server, as well as $X_c$ and the seeds $s_{c,i}$ for $i=1,\dots ,n$. Let the server compute $R^{\prime }\leftarrow R\oplus M_c$, which represents the Bloom filter of the intersection of all input sets excluding that of the colluding client. From Bloom filter R^′, the colluding parties learn $\bigcap _{i\ne c}{X}_c$. Moreover, when $h>1$, the colluding parties learn additional information about the elements contained in any of the other input sets (Vos, Conti & Erkin, 2022). For parties that collude, this means they can observe which bits are set and use that information to make inferences by comparing it with their own input sets. Because the colluding client ${\mathcal{P}}_c$ has access to the collective secret hash functions and the seeds used for hashing, they can reconstruct how elements are mapped and deduce with higher probability which elements belong to the other parties’ input sets. The larger $h$ is, the more bits are influenced per element, making it easier to infer missing elements through elimination. Additionally, because Bloom filters are merged using bit-wise AND operation, misaligned 1s from different input sets can accidentally indicate the presence of elements that are not actually in the intersection, leading to unintended information leakage. If a colluding client sees a certain pattern of bits in the Bloom filter, they can infer that a specific element must have originated from another client’s dataset.

In practical applications, ensuring that the server does not collude with any client poses considerable challenges. Economic or organizational incentives may drive collusion, jeopardizing the protocol’s integrity. To address these vulnerabilities, multi-server architectures that distribute trust across multiple servers under non-collusion assumptions can enhance resilience. Further improvements can be achieved by incorporating threshold models, where computations proceed only with agreement from a predefined subset of servers. This reduces the impact of a small number of colluding servers while retaining the benefits of distributed trust. Additionally, audit mechanisms, such as zero-knowledge proofs, enable clients to verify the server’s computations’ correctness without revealing additional information. However, these enhancements come at the cost of increased computational and communication complexity, which must be balanced against the protocol’s efficiency requirements.

Run time without communication delays

We provide an extensive analysis of our protocol, focusing on both breakdown and total computational costs. We fix the error rate at $\epsilon =0.1\mathrm{\%}$ for Bloom filters and evaluate the performance for both $h=1$ and $h>1$ cases. Table 3 summarizes the per-role breakdown for the server ${\mathcal{P}}_{\mathrm{s}\mathrm{r}\mathrm{v}}$, the querying client ${\mathcal{P}}_q$, and each ${\mathcal{P}}_i$, highlighting the linear scalability of our protocol with respect to set sizes, numbers of clients, and hash counts. In particular, the server computation remains minimal; it stays around 3 s even in the largest configuration, which involves $2^{16}$ elements and ten clients. The querying client incurs the highest cost due to its central role, but the increase in computation is predictable and scales linearly with input size and hash count.

Table 4 presents the total execution times in various settings. For example, when ten clients each hold $2^{14}$ elements and the hash count is $h=10$, the total computation time remains under 54 s. As expected, increasing set sizes impact all parties, especially the clients and querying client, whose runtime grows proportionally with the input. Similarly, more clients introduce additional overhead, though the impact remains smooth and predictable. This demonstrates that even in relatively large-scale scenarios, our protocol remains practical and efficient for real-world deployment.

Comparison with Feather. Feather performs well for two-client settings with small input sizes, completing a $2^{10}$-sized PSI in less than 1 s, as shown in Table 5. Figure 2 illustrates this scalability difference, comparing the total runtime of Feather and our protocol across varying clients and set sizes. However, it scales poorly when increasing the number of clients due to its pairwise intersection model and reliance on modular arithmetic and permutations.

Using lightweight XOFs and XOR operations, our protocol shows better scalability and comparable performance in many settings. In addition, our protocol exhibits superior scalability concerning the number of clients. For instance, at $k=2^{16}$ and $n=10$, our protocol completes in 212.72 s, compared to Feather’s 253.58 s. While the advantage is modest at this point, the performance gap continues to widen as $n$ increases, thanks to our aggregated masking approach, which avoids redundant computations and communications. Notice that while Feather has strong performance for $n=2$, our protocol offers more consistent scaling across all values of $n$ and $k$, maintaining competitive performance without sacrificing flexibility or simplicity.

We note that the Feather results may not exactly match those in its original publication, as we used different hardware and the original evaluation parameters were not fully disclosed.

Concrete communication cost analysis

Table 3 presents the per-client communication costs, distinguishing between the querying client ${\mathcal{P}}_q$ and the regular clients ${\mathcal{P}}_i$. In our protocol, the server ${\mathcal{P}}_{\mathrm{s}\mathrm{r}\mathrm{v}}$ sends a single message to ${\mathcal{P}}_q$, which is included in ${\mathcal{P}}_q$’s total communication. The cost for regular clients remains constant for a given set size and number of hash functions, whereas ${\mathcal{P}}_q$’s cost increases linearly with the number of hash functions due to element replication. For example, in the largest tested configuration ( $k=2^{16}$, $h=10$), ${\mathcal{P}}_q$ transmits approximately 5.18 MB, while each regular client transmits approximately 4.49 MB. This per-client overhead is independent of the total number of participants. However, as shown in Table 6, the overall communication increases linearly with the number of clients, demonstrating the protocol’s scalability and efficiency in bandwidth-constrained, multi-party scenarios.

Comparison with Feather. We further compare the communication efficiency of our protocol with Feather (Abadi et al., 2022), as summarized in Table 6 and illustrated in Fig. 3, using identical evaluation settings. Feather achieves low and stable communication overhead for small set sizes, but its cost increases sharply with larger datasets, even with a fixed number of clients. In contrast, our protocol incurs slightly higher per-client communication but scales linearly and predictably with both the number of clients and the set size. This makes it more suitable for large-scale deployments where bandwidth predictability and scalability are critical.

As shown in Table 3, increasing the number of hash functions $h$ does not consistently improve computational performance. In some smaller configurations, higher $h$ values show marginal improvements. However, for larger set sizes, computation time tends to increase or plateau. These observations suggest that while increasing $h$ may reduce false positives, it does not provide meaningful performance gains and may even introduce additional computational overhead in practice.

Run time with simulated communication delays

One often-overlooked aspect of outsourced private set intersection protocols is the impact of communication delays. To address this, we analyze the runtime of our protocol under varying download bandwidth and latency constraints, which are uniformly applied across all communication channels in the star topology. We conduct experiments with $n=10$ clients and a set size of $k=2^{14}$, fixing the Bloom filter error rate at $\epsilon =0.1\mathrm{\%}$ and focusing on cases where $h>1$. As shown in Fig. 4, bandwidth limitations significantly affect efficiency. For $h=10$, the resulting Bloom filter size is approximately $m=235,568$ bins, meaning each client sends about $40\mathrm{m}$ bits, or roughly 1.12 MB (see Table 3). Since we simulate download bandwidth, the server must process incoming data sequentially, introducing delays. In contrast, latency has minimal effect, as the protocol requires only a single round-trip interaction and thus incurs latency just twice. Detailed numerical results of these latency and bandwidth experiments are provided in Table A1 in the Appendix.

Performance evaluation of BLAKE3-XOF

All analyses in this study use the BLAKE3-XOF (O’Connor et al., 2021) function, which offers a modern cryptographic design characterized by strong security guarantees and a high potential for parallelization. As illustrated in Fig. 5, comparative runtime performance measurements reveal that BLAKE3-XOF consistently outperforms both SHAKE128-XOF and SHAKE256-XOF (National Institute of Standards and Technology (NIST), 2015) (see also Table A2) across a wide range of data set sizes and client numbers. While SHAKE-based XOFs offer strong cryptographic security and are well-established, the performance advantage of BLAKE3-XOF is evident even at small dataset sizes and low party counts. It becomes increasingly pronounced as both parameters grow. This suggests excellent scalability and low computational overhead, making it a highly efficient choice for large-scale or concurrent applications.

Although integrating BLAKE3’s SIMD-friendly design could have accelerated the protocol, we used the same setup of hash functions in Feather to ensure a fair comparison. Future work may explore BLAKE3-specific optimizations.