VMkCwPIR: A Single-Round Scalable Multi-Keyword PIR Protocol Supporting Non-Primary Key Queries

Abstract

Keyword Private Information Retrieval (Keyword PIR) enables private querying over keyword-based databases, which are typically sparse, as opposed to the dense arrays used in standard Index PIR. However, existing Keyword PIR schemes are limited to single-keyword queries and generally assume that keywords serve as unique identifiers, making them inadequate for practical scenarios where keywords are non-unique attributes and clients need to retrieve records matching multiple keywords simultaneously. To bridge this gap, we propose MkCwPIR, the first single-round, exact-match multi-keyword PIR protocol that supports conjunctive keyword queries while preserving strict keyword privacy against the server. Our construction employs Constant-weight codes and Newton–Girard identities to encode multi-keyword selection into a compact algebraic representation, representing a functional extension of CwPIR (Usenix Security ’22). While this functional expansion introduces additional computational overhead due to the processing of multiple keywords, we further introduce VMkCwPIR—an optimized variant leveraging BFV vectorized homomorphic encryption. Experimental results demonstrate that although the base MkCwPIR incurs higher latency due to its enhanced logical capabilities, the vectorized optimizations in VMkCwPIR effectively close this performance gap. Consequently, VMkCwPIR achieves a performance level comparable to the single-keyword CwPIR. Experimental results demonstrate that when processing a query with eight keywords, VMkCwPIR achieves a server-side execution time comparable to executing only four independent single-keyword queries in CwPIR, while maintaining constant communication overhead for up to 16 keywords.

1. Introduction

Private Information Retrieval (PIR) [1] serves as a critical cryptographic primitive, enabling a user to fetch a specific entry from a remote database while ensuring the server remains oblivious to the identity of the retrieved item. Historically, the literature categorizes PIR frameworks into two primary architectures: multi-server [2,3,4,5,6,7,8] and single-server [9,10,11,12,13] configurations. Although multi-server systems achieve robust privacy through secret sharing across non-colluding entities, the stringent requirement for server independence often proves impractical in real-world deployments. Consequently, computationally secure single-server PIR has gained significant traction as a more feasible alternative. This study contributes to this domain by introducing a novel multi-keyword PIR protocol specifically optimized for single-server environments, effectively surmounting the structural bottlenecks of prior works. It is worth noting that the notion of efficiency in PIR varies across research communities. In the cryptographic community, particularly in works focusing on computational PIR (CPIR) or single-server models, the primary metric is often the total communication cost (the sum of query and response sizes), aiming to minimize the overall bandwidth overhead relative to the trivial solution of downloading the entire database. Conversely, the information-theoretic community, which frequently studies multi-server settings, has historically placed greater emphasis on minimizing the download cost (response size) and characterizing the PIR capacity, sometimes treating upload costs or server-side computation as secondary optimization targets [14].

Depending on how queries are structured, contemporary PIR research generally follows two distinct trajectories: Index PIR and Keyword PIR. Index PIR methodologies [15,16,17,18,19,20] are built on the assumption that the client possesses prior knowledge of the target record’s precise location (e.g., its physical offset). Within this paradigm, researchers prioritize minimizing communication and computational latency, often leveraging homomorphic encryption (HE) and vectorized query processing. In contrast, Keyword PIR [21,22,23,24] addresses more pragmatic scenarios where data is organized as associative key-value pairs. In these settings, the client retrieves information based on unique identifiers (keywords) rather than numerical indices, aligning more closely with the sparse data structures prevalent in modern database applications.

However, both classical Index and Keyword PIR paradigms are characterized by a fundamental architectural limitation: the absence of native support for multi-keyword queries. This constraint significantly impedes their practical utility in document retrieval systems, necessitating complex conjunctive queries, as well as in specialized domains such as legal e-discovery and sensor data filtering—all of which require the private retrieval of records satisfying multiple concurrent identifiers. The challenge can be defined as follows:

How to realize multi-keyword private information retrieval (PIR) that enables the client to retrieve multiple matching records from a database without maintaining any prior metadata or auxiliary information locally.

Focusing on a data model of $\left\{Index,Value,Keywords\right\}$, we introduce MkCwPIR to enable the private retrieval of records that match a specific collection of keywords. Distinct from existing methods, MkCwPIR allows for queries over non-primary-key fields, thus expanding the scope of searchable attributes within the database. The scheme is characterized by its zero-offline-cost for clients—requiring no pre-downloaded hints—and its robust support for dynamic server-side data updates, thereby achieving high practical availability. These capabilities directly address critical privacy needs in real-world scenarios. For instance, in healthcare applications, a patient can privately retrieve information about diseases associated with a specific set of symptoms without revealing their potential health conditions to the database server. Similarly, in e-commerce, consumers can search for sensitive products (e.g., medical supplies or specialized books) based on multiple attributes without leaving any trace of their browsing history or interests, thus preventing profiling and ensuring anonymity.

1.1. Our Contributions

For the case where keywords are non-unique attributes rather than primary keys, we introduce multi-keyword PIR construction. In summary, we make the following contributions:

• Theoretical Novelty in Retrieval Functionality: We propose MkCwPIR, the first single-round multi-keyword PIR protocol. Distinct from existing schemes limited to single-identifier retrieval, our core theoretical contribution lies in a novel algebraic construction that leverages constant-weight codes. Crucially, we transform the challenge of conjunctive multi-keyword queries into a solvable framework based on Newton power sums and primitive root extraction. This mathematical approach enables complex logical filtering in a single interaction while strictly preserving keyword privacy against the server.
• Structural Optimization via Vectorized HE: To reduce the inherent computational overhead in multi-keyword matching, we design a specialized optimization strategy rather than a generic implementation tweak. By adapting BFV vectorized homomorphic encryption, we restructure the protocol’s workflow to parallelize the generation of the matching vector. This approach ensures high computational efficiency while minimizing communication overhead, effectively bridging the performance gap between complex multi-keyword queries and standard single-keyword retrievals.
• Simulation-Based Performance Benchmarking: We implemented both the baseline MkCwPIR and our optimized variant, VMkCwPIR, and conducted simulation experiments to measure the server-side computational costs at each step of the online phase. The results quantitatively demonstrate that the proposed vectorized workflow yields significant efficiency gains, validating the scalability of our algebraic construction for practical application scenarios.
• State-of-the-Art Comparative Analysis: We performed comparative evaluations between VMkCwPIR and the leading single-keyword scheme, CwPIR [22]. These experiments confirm that our protocol achieves comparable end-to-end latency to state-of-the-art single-keyword systems while supporting significantly richer query semantics.

1.2. Related Work

Keyword PIR: Unlike previous keyword PIR methods prone to false positives, Mahdavi et al. proposed CW-PIR [22], a scheme that utilizes Constant Weight Codes (CWC) to encode keywords. This approach establishes a one-to-one mapping between keywords and CWCs and employs an equality operator to determine matches. The operator outputs 1 if the codes match and 0 otherwise; the resulting decision vector is then multiplied by the data vector to yield the final query result. However, CW-PIR only supports a bijective (one-to-one) relationship between keywords and data. In contrast, our scheme enables many-to-many mappings, serving as a functional extension of the CW-PIR framework.

CWC in Index PIR: Liu et al. proposed PIRANA [20], which applies the mapping of CWCs to indices in Index PIR to reduce the number of transmitted ciphertexts. By leveraging SIMD (Single Instruction, Multiple Data) properties and integrating the batching techniques proposed by Angel et al. [15], they constructed an efficient batch Index PIR system. While both PIRANA and our work utilize CWCs and SIMD technology, two critical distinctions must be noted. Application Context: PIRANA is designed for Index-PIR, representing the database as a two-dimensional matrix where CWCs are used to compress information across dimensions (rows or columns). In our work, CWCs serve as an alternative representation of keywords used directly within equality operator computations. Query Logic: The multi-query functionality in PIRANA is a batching technique, which is essentially the parallelization of multiple one-to-one queries. Conversely, our multi-keyword query performs a logical AND operation across multiple keywords—requiring all keywords to be satisfied simultaneously for a successful match. This constitutes a true many-to-many query capability. In summary, while we employ similar underlying primitives, PIRANA focuses on optimizing efficiency in traditional Index PIR, whereas this paper focuses on further extending the functional scope of Keyword PIR.

2. Preliminaries

2.1. Notations

Table 1. Summary of Notations.

Notation	Description
m	Number of client’s query keywords
n	Number of indices in the server database
t	Total number of distinct keywords in the database
$p_i$	The i-th power sum
$(pk,sk)$	The client’s public and secret key pair
D	The server-side database
${\mathrm{idx}}_i,i\in \left[n\right]$	The i-th index in database D
${\mathrm{val}}_i,i\in \left[n\right]$	The value associated with index ${\mathrm{idx}}_i$
$S_i^{\mathrm{kw}}$	The set of keywords corresponding to ${\mathrm{idx}}_i$ and ${\mathrm{val}}_i$
$S_{\mathrm{ck}}={\left\{{\mathrm{ck}}_j\right\}}_{j\in \left[m\right]}$	The set of keywords queried by the client
$\lambda$	Statistical and computational security parameters
$\mathcal{K}$	The keyword domain defined by the server
k	The maximum match count

summarizes the primary notations and parameters used throughout this paper.

2.2. Constant-Weight Code

A constant-weight code (CWC) is defined as an error-correcting scheme where every codeword is characterized by a uniform Hamming weight, ensuring an identical count of non-zero elements across the codebook. Within the binary domain, such codewords consist of bitstrings with a fixed density of ones; typical examples include one-hot encodings and balanced codes, where the latter maintains an equivalent distribution of zeros and ones. For any two codewords $(x,y)\in CW(c,w)$ with length c and Hamming weight w, the equality operator $f_{PCW}$ [22] can be formulated as:

$$f_{PCW}(x,y)=\prod _{y\left[i\right]=1}x\left[i\right],$$

(1)

In this construction, the operation is independent of the explicit values of the first operand x (maintaining obliviousness) while its execution logic is dictated by the structure of the second operand y.

2.3. Newton–Girard Identities

The Newton–Girard identities provide a fundamental recursive relationship between the elementary symmetric polynomials and the power sum symmetric polynomials. These identities are indispensable in various fields, ranging from Galois theory to numerical linear algebra and coding theory.

Let $x_1,x_2,\dots ,x_a$ be a set of variables that can be viewed as the roots of a monic polynomial $P\left(x\right)\in \mathbb{F}\left[x\right]$. These coefficients relate to the polynomial expansion:

$$P\left(x\right)=\prod _{i=1}^a(x-x_i)=\sum _{b=0}^a{(-1)}^b{e}_b{x}^{a-b}$$

where $e_b$ is the coefficient of the b-th term in the polynomial and $e_0=1$. The symmetric polynomial b-th power sum, denoted by $p_b$, is defined as:

$$p_b=\sum _{i=1}^a{x}_i^b=x_1^b+\cdots +x_a^b$$

The relationship between $e_b$ and $p_b$ is governed by the following recursive formula for any $b\ge 1$:

$$b{e}_b=\sum _{i=1}^b{(-1)}^{i-1}{e}_{b-i}{p}_i$$

Consequently, the set of elementary symmetric polynomials $\left\{e_k\right\}$ is computed recursively from the given power sums. This procedure enables the formulation of the locator polynomial $P\left(x\right)$, whose roots, representing the original values, are then recovered using standard algebraic solvers.

2.4. Fully Homomorphic Encryption (FHE)

Fully homomorphic encryption enables ciphertext computations, but faces noise accumulation challenges during operations. Current solutions employ bootstrapping [25,26,27] or leveled designs [28,29,30] to control noise growth and maintain decryption capability. The current study employs a Fully Homomorphic Encryption (FHE) construction grounded in the hardness of the Ring Learning With Errors (RLWE) problem. To distinguish our notation from the parameters listed in Table 1, we explicitly define N as the polynomial degree of the RLWE ring, Q as the ciphertext modulus, and T as the plaintext modulus. This cryptographic framework is formally established through a triplet of fundamental algorithms:

• $\mathsf{FHE}.\mathsf{KeyGen}\left(1^{\lambda }\right)$: Let $R_Q={\mathbb{Z}}_Q\left[X\right]/(X^N+1)$. Sample $a\leftarrow R_Q$, secret key $s\leftarrow {\{-1,0,1\}}^N$, and error $e\leftarrow \chi$ (where $\chi$ is a discrete Gaussian distribution over $R_Q$). Output the public key $pk=(p{k}_0,p{k}_1)=(a,-(as+e))$ and the private key $sk=s$.
• $\mathsf{FHE}.\mathsf{Enc}(m,pk)$: Sample $u,e_0,e_1\leftarrow \chi$; compute $\mathrm{\Delta }=\lfloor Q/T\rfloor$ and output $c=(c_0,c_1)=(p{k}_0·u+e_0,p{k}_1·u+e_1+\mathrm{\Delta }m)$.
• $\mathsf{FHE}.\mathsf{Dec}(c,sk)$: Compute $m^{\prime }=(s·c_0+c_1)modQ$; output $m=\lfloor (T·m^{\prime })/Q\rceil modT$.

Fully Homomorphic Encryption (FHE) facilitates both additive and multiplicative operations in the encrypted domain, supporting computations between two ciphertexts or between a ciphertext and a plaintext. A critical side effect of these evaluations is the cumulative expansion of internal noise. Should this noise surpass a predefined threshold, the integrity of the decryption process is compromised. Consequently, judicious parameter selection and rigorous management of noise growth during homomorphic processing are essential for maintaining protocol correctness.

To enhance efficiency, RLWE-based FHE schemes often leverage Single Instruction Multiple Data (SIMD) techniques, enabling the parallel processing of multiple data points within a single operation. By packing data into discrete ciphertext slots, this paradigm allows for vectorized computation [31,32], provided that the plaintext modulus T and the polynomial degree N satisfy the congruence $T\equiv 1\left(mod2N\right)$. The specific SIMD-supported homomorphic procedures are outlined below:

• $CtAddCt(c_1,c_2)$: This operation inputs two ciphertexts $c_1,c_2\in R_Q^2$ and outputs the homomorphic addition results of the two ciphertexts, in which the ciphertexts in each corresponding slot are parallelized homomorphic addition.
• $CtMulPt(c,p)$: This operation inputs a ciphertext $c\in R_Q^2$ and a plaintext $p\in R_T$, and outputs the ciphertext result after homomorphic multiplication of the two. The plaintext and ciphertext in the corresponding slot are calculated in parallel with homomorphic multiplication.
• $CtMulCt(c_1,c_2)$: This operation inputs two ciphertexts $c_1,c_2\in R_Q^2$ and outputs the homomorphic multiplication results of the two ciphertexts, in which the ciphertexts in each corresponding slot are parallelized homomorphic multiplication.
• $CtRotate(c,a)$: This operation inputs a ciphertext $c\in R_Q^2$ and an integer constant $a\in [1,N-1]$, and outputs the ciphertext result that all slots are shifted to the left a times. If the ciphertext starts with the encryption of $[x_0,x_1,x_2,\dots ,x_{n-1}]$, it will eventually be the encryption of $[x_a,x_{a+1},x_{a+2},\dots ,x_{n-1},x_0,x_1,\dots ,x_{a-1}]$.

2.5. Threat Model

The MkCwPIRprotocol adopts a passive-adversary (also known as honest-but-curious)threat model to ensure both query privacy and computational correctness. Under this model, the adversary—typically the cloud server hosting the database—is assumed to follow the protocol execution honestly but attempts to infer sensitive information from the available data.

Specifically, the adversary can access the entire content of the database, monitor and persist all incoming encrypted queries and outgoing responses, and perform arbitrary offline analysis on these transcripts. The adversary is also capable of observing the server’s internal operations, including memory access patterns and CPU execution traces, and may attempt side-channel attacks (e.g., noise analysis or timing attacks) to bypass encryption. Furthermore, we assume the adversary can intercept, log, and analyze all network traffic between the client and the server.

We assume the adversary is not actively malicious, meaning it does not intentionally corrupt the stored data, tamper with the homomorphic evaluation logic, or modify network packets to disrupt the protocol. Consequently, while an active adversary could theoretically generate incorrect results to violate integrity, MkCwPIR focuses on guaranteeing privacy against the defined honest-but-curious behavior.

In our system setup, the parameters $m,n,c,$ and w are considered public knowledge. This implies that the adversary is fully aware of these system configurations, including the dimensions of the underlying algebraic structures and any bounds related to the keywords or ciphertexts. The security of the protocol relies not on the secrecy of these parameters, but on the computational hardness of the underlying cryptographic problems.

Finally, we assume the adversary cannot compromise the client’s local environment or perform side-channel attacks on the client’s hardware, as such access would render query privacy trivial. We also rely on standard cryptographic assumptions, primarily the computational hardness of the RLWE problem, which ensures the semantic security of the underlying BFV encryption scheme.

3. MkCwPIR Design

In this section, we present the complete design of the entire protocol. We first introduce the privacy subset determination (PSD) method we have devised. Its function within our protocol is to precisely match the server’s data items while safeguarding client privacy.

3.1. Design Intuition of PSD

The PSD protocol is designed to verify whether a client’s keyword set $S_{\mathsf{ck}}$ is a subset of any record’s keyword collection $S_i^{\mathsf{kw}}$ within the server-held database ${\left\{({\mathsf{idx}}_i,{\mathsf{val}}_i,S_i^{\mathsf{kw}})\right\}}_{i\in \left[n\right]}$. Specifically, the output is defined as 1 for a successful match ($S_{\mathsf{ck}}\subseteq S_i^{\mathsf{kw}}$) and 0 for an exclusion. To facilitate this, the server maps all keywords to Constant-weight code representations. Drawing upon the equality comparison logic introduced in Equation (1), we develop an optimized technique to ascertain the subset relationship between two sets $S_x$ and $S_y$. This set inclusion logic is formally characterized by:

$$f_{PSD}(S_x,S_y)=\prod _{i=1}^{\left|S_x\right|}\left(\sum _{j=1}^{\left|S_y\right|}{f}_{PCW}(x_i,y_j)\right),$$

(2)

yielding a binary result:

$$f_{PSD}(S_x,S_y)=\left\{\begin{array}{ccc}1,\hfill & \mathrm{i}\mathrm{f}\hfill & S_x\subseteq S_y\hfill \\ 0,\hfill & \mathrm{e}\mathrm{l}\mathrm{s}\mathrm{e}\hfill & \end{array}\right..$$

(3)

The correctness of this approach can be readily verified through its underlying algebraic properties. Since the equality operator $f_{PCW}$ is designed to produce a binary 1 for identical constant-weight codewords and 0 for mismatches, it serves as a robust foundation for set inclusion testing. Specifically, the inclusion of an element $x\in S_x$ within the target set $S_y$ is determined by the summation of equality outputs; this inner sum results in 1 if a match exists and 0 otherwise. By taking the product of these individual membership results, we achieve a logical conjunction: the final output $f_{PSD}$ remains 1 if and only if every element in $S_x$ has a corresponding counterpart in $S_y$. Formally, the condition $S_x\subseteq S_y$ ensures that each $\sum f_{PCW}$ term equals 1, leading to a total product of 1. Conversely, the absence of any $x\in S_x$ from $S_y$ causes at least one summation to vanish, thereby nullifying the entire $f_{PSD}$ output.

In the practical execution of the PSD protocol, the client initiates the process by generating homomorphic encodings of the keyword set $S_{\mathsf{ck}}$ and transmitting them to the server. Subsequently, the server performs a series of homomorphic evaluations to determine the containment of the encrypted $S_{\mathsf{ck}}$ within each $S_i^{\mathsf{kw}}$ across the database indices $i\in \left[n\right]$. This secure computation of $f_{PSD}$ results in an n-dimensional indicator vector, where each component is a ciphertext representing a binary match (0 or 1). A pivotal departure from traditional PIR—which typically relies on a “one-hot” query vector containing a single ‘1’—is that our PSD mechanism frequently produces multiple positive indicators. This structural difference introduces a non-trivial challenge: an conventional inner product would aggregate several records into a single ciphertext, preventing the client from successfully isolating or disambiguating individual matches upon decryption.

3.2. Decomposition Method

The homomorphic inner product between one-hot ciphertext vectors and plaintext vectors in a database forms the underlying method for most PIR protocols, as it compresses n responses into one to enhance communication efficiency. However, when extended to the inner product between multi-hot ciphertext vectors and plaintext vectors, the client cannot uniquely decompose the final answer because it consists of the sum of multiple values. We introduce the Newton–Girard formula to address this issue.

Assuming the maximum number of matches is k, the server can perform power operations on the database’s plaintext during the offline phase. The original database ${\left\{({\mathsf{idx}}_i,{\mathsf{val}}_i,S_i^{\mathsf{kw}})\right\}}_{i\in \left[n\right]}$ is transformed into the form ${\left\{({\mathsf{idx}}_i,({\mathsf{val}}_i,{\mathsf{val}}_i^2,\dots ,{\mathsf{val}}_i^k),S_i^{\mathsf{kw}})\right\}}_{i\in \left[n\right]}$ through exponentiation.

Considering that homomorphic computations based on RLWE are performed within the plaintext domain T, all power operations must be reduced modulo T. Accordingly, the database is transformed into: ${\left\{({\mathsf{idx}}_i,({\mathsf{val}}_i,v_i^2,\dots ,v_i^k),S_i^{\mathsf{kw}})\right\}}_{i\in \left[n\right]}$ where $v_i^j={\mathsf{val}}_i^j\hspace{0.33em}(\mathrm{mod}\hspace{0.33em}T)$. Accordingly, the recursive construction of the polynomial must also be conducted within the finite field T. The recurrence identities are defined as follows:

$$k{e}_k=\sum _{i=1}^k{(-1)}^{i-1}{e}_{k-i}{p}_i(\mathrm{mod}\hspace{0.33em}T)$$

(4)

After computing $f_{\mathrm{PSD}}(·,·)$, the server obtains a multi-hot vector $vm$ containing at most k ones, where k denotes the maximum number of matches. Subsequently, the server homomorphically computes the power sums:

$$p_j=\sum _{i=1}^n{v}_i^j\times vm\left[i\right],\mathrm{for}j=1,\dots ,k$$

The server returns the k homomorphic power-sum result ciphertexts to the client. After obtaining k ciphertext results, the client performs decryption to derive k power-sum results ${\left\{p_i\right\}}_{i\in \left[k\right]}$. These power-sum results are then processed through recursive computation using Equation (4), ultimately constructing a univariate k-degree equation. Solving this equation yields the value corresponding to each matched data point.

It should be noted that this method can recover at most k values. Specifically, when the number of matches $x\le k$, the recovered output consists of the x original data values and $k-x$ zeros, a property dictated by Newton–Girard identities. Consequently, if $x>k$, the recovery process will fail. This poses a challenge: since the server must remain oblivious to the client’s query (as per PIR privacy requirements), it cannot determine the actual number of matches. To accommodate any potential query, the server must assume the worst-case scenario and set the maximum match capacity to k, leading to significant overhead in both storage and computation. Although transforming this into a coloring problem and partitioning the database into blocks—where each block recovers k values—can mitigate the computational burden to some extent, the worst-case scenario remains unavoidable. Theoretically, if every item in the database matches, all data must be returned. To ensure privacy, the response size must be invariant regardless of the actual number of matches; however, returning the entire database would violate the communication efficiency assumptions of PIR. Therefore, it is necessary to assume that the maximum number of matches is bounded by k, where $k\ll n$. In practice, the server can proactively satisfy this assumption by partitioning the database into smaller segments.

3.3. MkCwPIR Protocol

After introducing how to generate matching vectors and recover the original numerical data when the matching vector is multi-hot, we now present the complete protocol for MkCwPIR without SIMD technology. All optimizations involving SIMD techniques will be detailed in the next section.

3.3.1. MkCwPIR Setup Phase

The algorithm implementation is as described in Algorithm 1.

Mahdavi [22] introduced the $\mathsf{PerfectMapping}$ algorithm, which establishes a bijective mapping between elements in $\left[n\right]$ and constant-weight codes. In our scheme, the server maintains the database $D={({\mathsf{idx}}_i,{\mathsf{val}}_i,S_i^{\mathsf{kw}})}_{i\in \left[n\right]}$ and applies $\mathsf{PerfectMapping}$ to encode all keywords. In addition to mapping all keywords to constant weight codes, the server must also perform exponentiation calculations on all data items. The resulting parameters $parm$ are subsequently transmitted to the client for query preparation.

Algorithm 1 $\mathsf{MkCwPIR}.\mathsf{Setup}$ algorithm.

Input: $\mathcal{K}$ and ${\{S_i^{\mathrm{kw}},{\mathsf{val}}_i\}}_{i\in \left[n\right]}$ Output: encoded keywords $S_{CW}$, exponent V, and parameter $parm$   1: Select $parm=(c,w)$ and $\left({\displaystyle \genfrac{}{}{0pt}{}{c}{w}}\right)\ge \left|\mathcal{K}\right|$     ▷c is the codeword length, w is the number of 1.   2: initialize $S_{CW}=\mathsf{\varnothing }$   3: Parse $({\mathsf{kw}}_1,{\mathsf{kw}}_2,\dots ,{\mathsf{kw}}_t)={\bigcup }_{i=1}^n{S}_i^{\mathsf{kw}}$   4: for $i=1$ to t do   5:       $c{w}_i\leftarrow \mathsf{PerfectMapping}({\mathsf{kw}}_i,c,w)$   6: end for   7: $S_{CW}=(c{w}_1,\dots ,c{w}_t)$   8: for $i=1$ to k do   9:       for $j=1$ to n do 10:             compute ${\mathsf{val}}_j$ exponentiation to ${\mathsf{val}}_j^i$ 11:       end for 12:       $v_i=({\mathsf{val}}_1^i,{\mathsf{val}}_2^i,\dots ,{\mathsf{val}}_n^i)$ 13: end for 14: $V=(v_1,v_2,\dots ,v_k)$ 15: return$(S_{CW},V,parm)$

3.3.2. MkCwPIR Query Phase

The algorithm implementation is as described in Algorithm 2.

Algorithm 2 $\mathsf{MkCwPIR}.\mathsf{GenQuery}$ algorithm.

Input: a set of keywords $S_{\mathsf{ck}}=\{{\mathsf{ck}}_1,{\mathsf{ck}}_2,\dots ,{\mathsf{ck}}_m\}$, parameter $parm$ from setup phase and public-key $pk$ Output: the query of keywords q   1: Parse $parm=(c,w)$   2: for $i=1$ to m do   3:       $c_i\leftarrow \mathsf{PerfectMapping}({\mathsf{ck}}_i,c,w)$   4: end for   5: $c=(c_1,c_2,\dots ,c_m)$   6: $q\leftarrow \mathsf{FHE}.\mathsf{Enc}(c,pk)$   7: return q

The client maintains a keyword set $S_{\mathsf{ck}}=\{{\mathsf{ck}}_1,{\mathsf{ck}}_2,\cdots ,{\mathsf{ck}}_m\}$ and a public-private key pair $(pk,sk)$. After receiving the parameters $parm$ from the server, the client performs the following operations: first, it encodes $S_{\mathsf{ck}}$ using the $\mathsf{PerfectMapping}$ algorithm to obtain the constant-weight code representation $c=(c_1,c_2,\cdots ,c_m)$; then, it encrypts this coded vector c using the BFV homomorphic encryption scheme under the public key $pk$.

To enhance privacy against access pattern leakage, we introduce a robust padding strategy. More generally, let $S_{\mathsf{ck}}^{\prime }$ denote the actual set of keywords queried by the client. When the cardinality of the queried set, $|S_{\mathsf{ck}}^{\prime }|$, is less than the system parameter m, a padding mechanism is employed to ensure that the number of ciphertexts sent depends solely on m. The padding process proceeds as follows:

Firstly, the client maps all keywords in the queried set $S_{\mathsf{ck}}^{\prime }$ into their corresponding constant-weight codes using the $\mathsf{PerfectMapping}$ algorithm, obtaining an initial code sequence of length $|S_{\mathsf{ck}}^{\prime }|$. Secondly, if $|S_{\mathsf{ck}}^{\prime }| <m$, the client pads this sequence by repeating the constant-weight codes already generated from $S_{\mathsf{ck}}^{\prime }$ until the total number of codes reaches m.

This design guarantees that the server cannot derive any information regarding the actual query size from the ciphertext count, learning nothing beyond the public parameter m. From a computational logic perspective, since the multi-keyword search relies on conjunctive operations (logical AND), the insertion of duplicate keywords does not affect the correctness of the result. This is due to the idempotent property of the conjunction operation, where $A\wedge A\equiv A$; thus, repeating a keyword condition in the homomorphic evaluation yields the same intersection result as querying it once.

3.3.3. MkCwPIR Answer Phase

The algorithm implementation is as described in Algorithm 3. Upon receiving the query q from the client, the server performs the following operations: First, it decomposes q into its components $(q_1,q_2,\cdots ,q_m)$. Then, for each $i\in \left[m\right]$ and $j\in \left[t\right]$, the server executes the comparison function $f_{PCW}(q_i,c{w}_j)$ to evaluate the relationship between the client’s query terms and the server’s coded keywords. To optimize communication efficiency, the server performs vector compression by first forming a ciphertext vector v of length n, where each entry $vm\left[i\right]$ is the ciphertext of 1 if $S_{\mathsf{ck}}\subseteq S_i^{\mathsf{kw}}$ and the ciphertext of 0 otherwise. The server then computes the inner product between the $vm$ and data items of different powers, generating a total of k ciphertext responses.

Algorithm 3 $\mathsf{MkCwPIR}.\mathsf{Answer}$ algorithm.

Input: the query q from query phase and $S_{CW},V$ from setup phase Output: the answer A   1: Decomposition q into $q_1,q_2,\dots ,q_m$   2: Parse $S_{CW}=(c{w}_1,\dots ,c{w}_t)$   3: for $i=1$ to m do   4:       for $j=1$ to t do   5:             $e{q}_{ij}\leftarrow f_{PCW}(q_i,c{w}_j)$                                          ▷ Homomorphic multiplication   6:       end for   7: end for   8: Initialize the vector $vm$ of length n   9: for $i=1$ to n do 10:       $vm\left[i\right]:={\prod }_{j=1}^m({\sum }_{k=1}^{\left|S_i^{\mathsf{kw}}\right|}e{q}_{jk})$     ▷$e{q}_{jk}\leftarrow f_{PCW}(q_j,c{w}_k)$, where $c{w}_k$ is the codeword of the element in $S_i^{\mathsf{kw}}$ 11: end for 12: for $i=1$ to k do 13:       $a_i=vm·V\left[i\right]$         ▷ Homomorphic inner product of ciphertext and plaintext vectors 14: end for 15: $A=(a_1,a_2,\dots ,a_k)$ 16: return A

Crucially, throughout this phase, the server exclusively performs homomorphic equality operator computations between the constant-weight code ciphertexts uploaded by the client and the locally stored plaintexts. These computation outputs are then utilized to construct a ciphertext match vector, which subsequently drives the inner product calculations with the pre-processed data items from the setup phase. A fundamental strength of this design is that the server’s computational procedure is entirely decoupled from the underlying plaintext content of the client’s ciphertexts. Specifically, the sequence of arithmetic operations, memory access patterns, and execution time remain strictly invariant, regardless of whether the received ciphertexts correspond to valid encryptions of the actual keyword set $S_{\mathsf{ck}}$, encryptions of all-zero vectors, or encryptions of randomly selected codewords. By executing an identical trace of homomorphic operations irrespective of the plaintext values, this mechanism effectively eliminates information leakage via timing or access-pattern side channels. This data-oblivious property ensures that no information regarding the query content can be inferred from the server’s execution behavior. We formalize this security guarantee in the following proof:

Let us define a security game ${\mathcal{G}}_0$ between a challenger $\mathcal{C}$ and an adversary $\mathcal{A}$ (representing the honest-but-curious server) as defined in the standard indistinguishability framework.

The adversary $\mathcal{A}$ supplies two distinct keyword sets $S_0$ and $S_1$ of the same size $|S^{\prime }| \le m$. The challenger $\mathcal{C}$ randomly selects a bit $b\in \{0,1\}$ and constructs the query corresponding to $S_b$. Following our padding mechanism, $\mathcal{C}$ maps the keywords in $S_b$ to constant-weight codes, pads the sequence to length m by repetition, and encrypts the resulting vector using the FHE scheme to generate the query ciphertext $q_b$. The challenger sends $q_b$ to $\mathcal{A}$. The adversary $\mathcal{A}$ executes the MkCwPIR.Answer Algorithm 3 on $q_b$ and outputs its guess $b^{\prime }\in \{0,1\}$.

The adversary wins the game if its guess is correct, i.e., $b^{\prime }=b$. Let $W_0$ be the event that $b^{\prime }=b$ in ${\mathcal{G}}_0$. Let us also consider another game ${\mathcal{G}}_1$, which is identical to ${\mathcal{G}}_0$ except for the construction of the query ciphertext. In ${\mathcal{G}}_1$, instead of encrypting the padded constant-weight codes derived from $S_b$, the challenger constructs a vector $v_{rand}$ consisting of encryptions of random values (or alternatively, encryptions of all-zero vectors) of the same dimension m. The challenger sends the encryption of $v_{rand}$ to $\mathcal{A}$. Let $W_1$ be the event that $b^{\prime }=b$ in ${\mathcal{G}}_1$.

Evidently, $Pr\left[W_1\right]=1/2$. This is because the ciphertext provided to the adversary in ${\mathcal{G}}_1$ is statistically or computationally independent of the bit b chosen by the challenger (since the plaintext content is either random or fixed to zero regardless of b). Consequently, the adversary can do no better than a random guess.

Now, consider the transition from ${\mathcal{G}}_0$ to ${\mathcal{G}}_1$. In ${\mathcal{G}}_0$, the query $q_b$ consists of valid FHE encryptions of the padded keyword codes. In ${\mathcal{G}}_1$, the query consists of FHE encryptions of random/zero values. The only difference observable by the adversary lies in the plaintext content encrypted within the ciphertexts. Crucially, as described in the Answer Phase, the server’s algorithm performs a fixed sequence of homomorphic equality operator computations and inner products. The control flow, memory access patterns, and number of arithmetic operations are strictly invariant regardless of the underlying plaintext values. Therefore, any advantage the adversary gains in distinguishing ${\mathcal{G}}_0$ from ${\mathcal{G}}_1$ relies solely on its ability to distinguish the FHE encryptions of the real keyword codes from the FHE encryptions of random/zero values.

By the semantic security (IND-CPA) of the underlying FHE scheme, the advantage of any probabilistic polynomial-time (PPT) adversary in distinguishing these two distributions is negligible, denoted as ${ϵ}_{\mathrm{FHE}}$. Thus, we have:

$$|Pr\left[W_0\right]-Pr\left[W_1\right]|\le {ϵ}_{\mathrm{FHE}}.$$

Substituting the value of $Pr\left[W_1\right]=1/2$, we get:

$$\left|Pr\left[W_0\right]-{\displaystyle \frac{1}{2}}\right|\le {ϵ}_{\mathrm{FHE}}.$$

Since ${ϵ}_{\mathrm{FHE}}$ is negligible, the adversary cannot win the game ${\mathcal{G}}_0$ with non-negligible advantage. This implies that the server cannot distinguish between queries generated from different keyword sets $S_0$ and $S_1$, nor can it distinguish a real query from a dummy (random/zero) query. Consequently, the server learns nothing about the client’s actual keywords or the number of queried items (due to the padding), proving the query privacy of MkCwPIR.

3.3.4. MkCwPIR Reconstruction Phase

The algorithm implementation is as described in Algorithm 4. In the final phase, the client decrypts the server’s answer A to obtain the k power sums of distinct degrees. By applying Equation (4), the coefficients $e_i$ are computed recursively. These coefficients are then utilized to construct the polynomial P. Finally, the roots of P are solved, which correspond precisely to the matched data items.

Algorithm 4 $\mathsf{MkCwPIR}.\mathsf{Reconstruct}$ algorithm.

Input: the answer A from answer phase and private-key $sk$ Output: a set of indices $S_{\mathsf{idx}}$   1: $(p_1,p_2,\dots ,p_k)\leftarrow \mathsf{FHE}.\mathsf{Dec}(A,sk)$   2: initialize $e_0=1$   3: for $j=1$ to k do   4:       $e_j={\displaystyle \frac{1}{j}}{\sum }_{i=1}^j{(-1)}^{i-1}{e}_{j-i}{p}_i$   5: end for   6: $P\left(x\right)={\sum }_{i=0}^k{(-1)}^{k-i}{e}_i{x}^i$.   7: Solve the equation $P\left(x\right)=0$ for its roots $(x_1,x_2,\dots ,x_k)$   8: return$(x_1,x_2,\dots ,x_k)$

It is worth noting that solving a polynomial with k integer roots over the finite field T is computationally efficient, with a worst-case complexity of only $O\left(kT\right)$. Given that the plaintext modulus T in the BFV scheme is typically chosen as a prime smaller than $2^{20}$, the computational overhead for the client to retrieve these roots remains negligible. Since the server pre-processes the data by raising it to successive powers and the client obtains the power sums through querying, this mechanism essentially reverses the process of constructing a polynomial from its known roots. Correct reconstruction is guaranteed as long as the number of aggregated data items in the power sums does not exceed k. Given that the maximum match threshold k is a necessary assumption to balance PIR performance and privacy requirements, the application of Newton–Girard identities to recover the original roots from the power sums is inherently robust and guaranteed to succeed under this framework.

4. Vectorized MkCwPIR

In the preceding section, we introduced the underlying computational principles of MKCWPIR, focusing primarily on functional realization without addressing the optimization of computation and communication. In this section, we present an enhanced protocol that leverages ciphertext vectorization to improve efficiency.

4.1. Communication and Computational Complexity of MkCwPIR

The baseline MkCwPIR involves the uploading of m ciphertexts and the retrieval of k ciphertexts. During the server-side computation phase, the total computational load for $f_{PCW}$ consists of $(w-1)mt$ homomorphic multiplications. In the $f_{PSD}$ phase, the complexity entails $amn$ homomorphic additions (where a denotes the average number of keywords per data item) and $(m-1)n$ homomorphic multiplications. The final inner product computation (homomorphic power sums) requires $kn$ homomorphic ciphertext–plaintext multiplications and homomorphic additions. Notably, in the $f_{PCW}$ phase, a single ciphertext CWC cannot simultaneously perform equality operator computations with multiple plaintext CWCs; this is because the computation involves selecting specific ciphertexts corresponding to the positions of ‘1’s in a given plaintext CWC. Conversely, multiple ciphertext CWCs can be computed against a single plaintext CWC simultaneously, as the selected positions remain fixed for that specific plaintext CWC. This observation reveals a potential for parallelism. Furthermore, the additions and multiplications within $f_{PSD}$ can be efficiently parallelized using SIMD techniques. Detailed implementations are provided in the subsequent sections.

4.2. Packing Query Ciphertexts

Since vectorized encryption supports slot-wise data placement and each constant weight code has a length c, the m codes produced by the mapping algorithm can be aggregated into $\lceil cm/N\rceil$ ciphertexts through SIMD batching, where N represents the number of available slots.

To illustrate our approach, we begin with a simplified example. Suppose the database contains six keywords, each mapped to a Constant-weight code with a length of 4 and a weight of 2. These are denoted as: $c{w}_1=1100$, $c{w}_2=1010$, $c{w}_3=1001$, $c{w}_4=0110$, $c{w}_5=0101$, $c{w}_6=0011$. The client holds two query keywords, whose corresponding CWCs are mapped as: $c_1=1010,c_2=1001$.

Without vectorized encryption, each of the eight bits would need to be encrypted individually. Alternatively, one could employ the oblivious ciphertext expansion proposed by Angel [15]; however, since this expansion method is incompatible with subsequent vectorized operations, we opt for vectorized encryption instead. For clarity in this representation, we assume the number of available slots in the vectorized ciphertext is 8. In practical implementations of existing BFV schemes, the number of slots equals the degree of the polynomial—typically $2^N$ where $N\in [10,15]$. We have scaled this down here for ease of demonstration.

After the client transmits the vectorized ciphertext to the server, the server performs ciphertext–plaintext multiplication using the plaintext vectors to isolate the values in the corresponding slots, as illustrated in Figure 1. It is important to note that these vectors refer to plaintext polynomials encoded with multiple plaintext data elements. During operations between plaintext and ciphertext polynomials, the slots are processed in parallel; thus, the i-th slot of the resulting ciphertext represents the computation result of the i-th plaintext slot and the i-th ciphertext slot. In this approach, we utilize masking plaintexts—defined as plaintext polynomials with ‘1’ at the target positions and ‘0’ elsewhere—to perform homomorphic multiplication with the ciphertext. Subsequently, each isolated value is shifted to the first slot through rotation operations. Importantly, as the server only performs homomorphic computations, it remains unable to access the information within the slots.

In summary, the adoption of vectorized encryption technology effectively reduces the communication overhead associated with codeword transmission. Additionally, the specific algorithms for ciphertext packing and ciphertext expansion are detailed in Algorithms 5 and 6.

Algorithm 5 $\mathsf{VMkCwPIR}.\mathsf{GenQuery}$ algorithm.

Input: a set of keywords $S_{\mathsf{ck}}=\{{\mathsf{ck}}_1,{\mathsf{ck}}_2,\cdots ,{\mathsf{ck}}_m\}$, parameter $parm$ from setup phase and public-key $pk$ Output: the query of keywords q   1: Parse $parm=(c,w)$   2: for $i=1$ to m do   3:       $c_i\leftarrow \mathsf{PerfectMapping}({\mathsf{ck}}_i,c,w)$   4: end for   5: for $i=1$ to $⌈cm/N⌉$ do   6:       $c=\left(c_i\right|\left|c_{i+1}\right||\dots |\left|c_{⌊N/c⌋}\right)$   7:       $q_i\leftarrow \mathsf{FHE}.\mathsf{Enc}(c,pk)$   8: end for   9: $q=(q_1,q_2,\dots ,q_{⌈cm/N⌉})$ 10: return q

Algorithm 6 $\mathsf{VMkCwPIR}.\mathsf{Expand}$ algorithm.

Input: the query q from query phase Output: the expanded ciphertexts C   1: Initialize the vector pt of length N   2: for $i=1$ to $⌈cm/N⌉$ do   3:       $pt=0^{*}$   4:       for $j=1$ to c do   5:             $pt\left[j\right],pt[j+c],\dots ,pt[j+\left(⌊N/c⌋\right]-1)c]=1$   6:             $q_i^j=CtMulPt(q_i,pt)$   7:             $q_i^j=CtRotate(q_i^j,j)$   8:       end for   9: end for 10: $C=\left[\begin{array}{cccc}{q}_1^1& q_1^2& \cdots & q_1^c\\ q_2^1& q_2^2& \cdots & q_2^c\\ \cdots & \cdots & \cdots & \cdots \\ q_{⌈cm/N⌉}^1& q_{⌈cm/N⌉}^2& \cdots & q_{⌈cm/N⌉}^c\end{array}\right]$ 11: return  C

4.3. Vectorization to Reduce Computation

Subsequently, the server computes the values of $f_{PCW}(·,·)$ by performing multiplications on the corresponding ciphertexts. Since homomorphic multiplication consumes significantly more computational time and noise budget than other homomorphic operations, subsequent computations will reuse these results to avoid performing homomorphic multiplication. As shown in Figure 1, the six constant weight codes in the database are computed against one of the constant weight codes sent by the client, yielding six results. Among these, a result of 1 indicates a successful match, while a result of 0 signifies a mismatch.

Next, we describe the computation process of $f_{PSD}$ under vectorized ciphertexts. First, the server selects the corresponding $f_{PCW}(·,·)$ values row by row, as illustrated in Figure 1. Within each row, each constant weight code selects the result of the equality operator that corresponds to its own input. For instance, in the first row, $c{w}_2$ selects the second equality operator value, $c{w}_3$ selects the third, and $c{w}_4$ selects the fourth, following this pattern for each subsequent row. Once the corresponding ciphertexts for a row are selected, a homomorphic addition is performed across all selected ciphertexts within that row. As shown in Figure 1, the resulting four ciphertexts represent the matching results between the query q and each row. Specifically, the yellow slots (1, 1, 0, 1) in the ciphertext represent the matching results for $q_1$ across each row (i.e., whether $q_1$ exists among the keywords of that row), where ‘1’ indicates a match and ‘0’ indicates otherwise. Similarly, the green slots (1, 0, 1, 1) represent the matching results for $q_2$.

To obtain the final multi-keyword match, it is necessary to perform homomorphic multiplication on the matching results of the different query keywords $q_i$. To avoid a large number of ciphertext–ciphertext multiplications, we first construct vectorized single-keyword matching ciphertexts through rotation and accumulation. These vectorized ciphertexts are then masked and multiplied homomorphically, which effectively reduces the number of ciphertext–ciphertext multiplications from n to $\lceil n/N\rceil$. In the provided example (Figure 1), the four ciphertexts containing single-keyword match results are rotated by strides of 0, 1, 2, and 3, respectively, and then summed homomorphically to produce a vectorized result. By multiplying this result with a masking plaintext polynomial (e.g., 00001111) and performing a rotation by a stride of 4, the match results are separated into two distinct vectorized ciphertexts. Finally, a single homomorphic multiplication between these two ciphertexts yields the final matching vector (1001). The general computation procedures are provided in Algorithms 7 and 8.

Algorithm 7 $\mathsf{VMkCwPIR}.\mathsf{PCW}$ algorithm.

Input: the expanded ciphertexts C and $S_{CW}$ Output: result of the equality operator E   1: Parse $S_{CW}=(c{w}_1,\dots ,c{w}_t)$   2: for $i=1$ to t do   3:       Initialize the vector $e{q}_i$ of length t   4:       for $j=1$ to $⌈cm/N⌉$ do   5:             $e{q}_i^j={\prod }_{c{w}_i\left[z\right]=1}{q}_j^z$                                            ▷ Homomorphic multiplication   6:       end for   7: end for   8: return  E

Algorithm 8 $\mathsf{VMkCwPIR}.\mathsf{PSD}$ Algorithm.

Input: Equality set E; Keyword sets ${\left\{S_i^{\mathrm{kw}}\right\}}_{i=1}^n$. Output: Final matching vector ciphertext $vm$.   1: Initialize $\mathbf{a}$   2: for $i=1$ to n do   3:      ${\mathbf{a}}_i=0$   4:      for $j=1$ to $|S_i^{\mathrm{kw}}|$ do   5:            select $e_j$ from E to denote the equality of keywords $k_j$ and q   6:            ${\mathbf{a}}_i={\mathbf{a}}_i\oplus e_j$   7:      end for   8: end for   9: Initialize $\mathbf{b},\mathbf{d}$ 10: for $i=1$ to $n/c$ do 11:      ${\mathbf{b}}_i=0$ 12:      for $j=1$ to c do 13:            ${\mathbf{b}}_i={\mathbf{b}}_i\oplus CtRotate({\mathbf{a}}_{j+(i-1)c},j-1)$ 14:      end for 15:      Initialize $pt=0^{*}$ 16:      for $j=1$ to $N/c$ do 17:            $pt\left[\right(j-1)c+1,jc]=1$ 18:            ${\mathbf{d}}_i^j=CtMulPt({\mathbf{b}}_i,pt)$ 19:            ${\mathbf{d}}_i^j=CtRotate({\mathbf{d}}_i^j,(j-1)c)$ 20:      end for 21: end for 22: Initialize $\mathbf{h}$ 23: for $i=1$ to $N/c$ do 24:      for $j=1$ to $n/N$ do 25:           ${\mathbf{h}}_i^j={\sum }_{x=(j-1)c+1}^{jc}CtRotate({\mathbf{d}}_x^i,(i-1)c)$ 26:      end for 27: end for 28: for $i=1$ to $n/N$ do 29:      $vm\left[i\right]={\prod }_{j=1}^{N/c}{\mathbf{h}}_j^i$ 30: end for 31: return  $vm$

The multiplication here allows for the simultaneous processing of values across n slots. In contrast, non-vectorized ciphertexts would require n separate multiplication operations. Aside from the $f_{PCW}(·,·)$ computation common to both approaches, the preceding operations for generating this vectorized ciphertext consist solely of additions and rotations, the computational cost of which is significantly lower than that of ciphertext multiplication.

4.4. Vectorized Inner Product and Merging Response Ciphertext

After computing the final matching vector, the server needs to calculate multiple power sums for the corresponding data items, which is equivalent to the inner product of the vectorized matching ciphertext and the plaintext vector. While a non-vectorized inner product necessitates n ciphertext–plaintext multiplications and n ciphertext additions, the vectorized approach allows for parallel multiplications across all slots within a single ciphertext–plaintext operation. As shown in Figure 2, the resulting vectorized ciphertext then undergoes a series of rotations and additions with itself: the rotation offset starts at 1 and doubles in each subsequent step until $logn$ iterations are completed. Consequently, the inner product of a vectorized ciphertext and a plaintext vector requires only one ciphertext–plaintext multiplication and $logn$ rotation–addition operations.

Upon completion of the power sum computations, every slot in the resulting ciphertext vector is populated with the inner product value. The server then applies plaintext masking to these vectorized ciphertexts to isolate the values at specific indices. By summing these masked results, the server produces a consolidated ciphertext where each slot holds a distinct power sum, effectively packing the results for efficient transmission. Algorithm  9 presents the the details of power sum and packing, while Algorithm  10 outlines the overall Answer algorithm.

Algorithm 9 $\mathsf{VMkCwPIR}.\mathsf{PowSum}$ algorithm.

Input: $vm$ and V Output: the answer A   1: $pt=0$   2: for $i=1$ to k do   3:       for $j=1$ to $n/N$ do   4:             $a_j=vm\left[j\right]\otimes V\left[i\right][1+(j-1)N,jN]$   5:             for $z=1$ to $logN$ do   6:                   $b=CtRotate(a_j,2^z)$   7:                   $a_j=b\oplus a_j$   8:             end for   9:             $a=a\oplus a_j$ 10:       end for 11:       $c_i=CtMulPt(a,pt)$ 12: end for 13: $A=\sum c$ 14: return A

Algorithm 10 $\mathsf{VMkCwPIR}.\mathsf{Answer}$ algorithm.

Input: the query q from query phase and $S_{CW},V,{\left\{S_k^{\mathrm{kw}}\right\}}_{k=1}^n$ from setup phase Output: the answer A   1: C ← VMkCwPIR.Expand(q)   2: E ← VMkCwPIR.PCW($C,S_{CW}$)   3: $vm$ ← VMkCwPIR.PSD($E,{\left\{S_k^{\mathrm{kw}}\right\}}_{k=1}^n$)   4: A ← VMkCwPIR.PowSum($vm,V$)   5: return A

4.5. Efficiency Analysis

Communication between client and the server: First, we determine the number of ciphertexts that the client must transmit to the server. The client possesses m keywords, which are mapped to m constant weight codes. Since each constant weight code has a length of c, the total number of bits is $cm$. By utilizing vectorized encryption, a single ciphertext can accommodate N data slots, meaning that the client needs to send a total of $\lceil cm/N\rceil$ ciphertexts. Next, we analyze the number of ciphertexts returned by the server. The server computes k power sums, and the response consists of $\lceil k/N\rceil$ ciphertexts.

Server computational cost: We now analyze the computational overhead required by the server. Upon receiving the ciphertext, the server must extract the corresponding bits using a plaintext vector, requiring a total of $cm$ ciphertext–plaintext multiplications and rotations. The server then computes the $f_{PCW}(·,·)$ values, where each $f_{PCW}(·,·)$ involves $w-1$ ciphertext multiplications; for every constant-weight code mapped from the server’s keywords, an $f_{PCW}(·,·)$ value is generated in conjunction with each CWC sent by the client, totaling $(w-1)t$ ciphertext–ciphertext multiplications when accounting for vectorized multiplication. Next, the server computes the $f_{PSD}$ matching vector, which involves a additions which $a={\sum }_{i=1}^n\left|S_i^{\mathsf{kw}}\right|$ followed by n rotations and additions. The corresponding results are then extracted and processed via ciphertext multiplications to compute a cumulative product, totaling m operations. Finally, power sum calculations and packing are performed; considering sharding, this requires k ciphertext–plaintext multiplications, as well as $[klog(n\left)\right]$ rotations and additions. The complexity analysis of communication and computation is presented in

Table 2. Theoretical Analysis of Computational and Communication Complexity.

Scheme	Communication	$\mathit{ct}\times \mathit{ct}$	$\mathit{ct}\times \mathit{pt}$	$\mathit{ct}+\mathit{ct}$	Rotation
MkCwPIR	$O(cm+k)$	$O\left(mwn\right)$	$O\left(kn\right)$	$O(amn+kn)$	–
VMkCwPIR	$O\left(\right(cm+k)/N)$	$O\left(\right(w-1\left)n\right)$	$O(m+k)$	$O(an+klogn)$	$O(m+n+k)$

.

In summary, the total number of ciphertext–plaintext multiplications is $[m+k]$, the total number of ciphertext rotations is $[m+n+k]$, the total number of ciphertext–ciphertext additions is $[an+klog(n\left)\right]$, and the total number of ciphertext–ciphertext multiplications is $\left[\right(w-1)t+m]$.

4.6. Privacy and Correctness Analysis

Privacy: The privacy guarantees of MkCwPIR and its vectorized variant VMkCwPIR rely on the synergy between the semantic security of the underlying homomorphic encryption and the data-oblivious nature of our protocol design.First, as formally established in the security games ${\mathcal{G}}_0$ and ${\mathcal{G}}_1$ above, the indistinguishability of client queries reduces directly to the IND-CPA security of the underlying FHE scheme (specifically BFV). Since the server only processes ciphertexts and the plaintext distribution is hidden by the encryption, the server cannot distinguish between queries for different keyword sets $S_0$ and $S_1$, nor can it differentiate real queries from dummy padded entries. Second, the data-oblivious execution described previously ensures that no side-channel information is leaked via timing or access patterns. The server’s computational trace depends solely on the public system parameters (m and database size), remaining strictly invariant regardless of the specific keywords or the actual query cardinality (thanks to the padding strategy).

Correctness: The correctness of CWC-based subset determination and power-sum-based recovery holds inherently in plaintext. For homomorphic implementation, one must only ensure that the initial data does not exceed the plaintext space and the noise budget is sufficient. We address these by employing data fragmentation and selecting optimal homomorphic parameters, respectively. Consequently, these measures collectively ensure the overall correctness of the protocol.

4.7. Additional Optimization and Extensions

Query ciphertext halving: Building on the work in [21], the client’s request size can be reduced by 50% through the use of pseudorandom seeds. This is achieved by exploiting the fact that the first component $c_0$ of a fresh RLWE ciphertext is uniformly random. Instead of transmitting the entire component, the client only sends a short seed to generate it.

Modulus Switching for Response Compression: To minimize the communication overhead of the response, we employ the modulus switching technique during the final stage of the protocol. Since the response ciphertexts are solely intended for client-side decryption and involve no further homomorphic operations, the large ciphertext modulus Q is no longer necessary. By transforming the ciphertexts from $R_Q^2$ to a smaller modulus space $R_{Q^{\prime }}^2$, the server can significantly reduce the data size. This technique is also adopted in [21,33].

5. Implementation and Experiment

5.1. Implementation Environment

Hardware and Software Environment: The proposed protocol was implemented in C++ using the Microsoft SEAL [34] library (ver 4.1). We utilized the BFV scheme and enabled SIMD batching to achieve vectorized encryption and operations. All experiments were conducted on a machine equipped with an AMD Ryzen 7 7840HS processor running Windows 11 and with a 32 GB memory capacity. Both client-side and server-side functionalities were deployed on this single workstation to simulate their interaction and computational processes. All experimental evaluations were performed on a single thread, as no multi-threading techniques were used for speed-up.

BFV Parameters: The operational efficiency of the protocol is primarily governed by the selection of encryption parameters. After evaluating various configurations, we set the polynomial degree to N = 16,384 to accommodate the required computational depth. The plaintext modulus is configured at 20 bits; during database partitioning, bit-level headroom is reserved for homomorphic additions. The initial ciphertext modulus is chosen as 438 bits, which conforms to the 128-bit security standard. Ultimately, modulus switching reduces the ciphertext modulus to 49 bits, achieving a compression ratio of over eight-fold for the response ciphertext.

5.2. Experiment

Baseline: Due to the lack of publicly available protocols for multi-keyword Private Information Retrieval, no direct external baseline was available for comparison. To evaluate the effectiveness of our optimizations, we established a non-vectorized version of our MkCwPIR protocol as the baseline. By comparing this with our vectorized variant, we demonstrate the performance improvements achieved through our vectorized encryption approach. Finally, we compare the optimized protocol with CwPIR [22] to demonstrate both the overhead introduced by the additional operations and the effectiveness of our optimizations.

Comparison between MkCwPIR and VMkCwPIR:During the comparison phase, we analyze the server-side runtime and communication overhead across four distinct stages: oblivious expansion, the computation of $f_{PCW}(·,·)$, the computation of $f_{PSD}(·,·)$, and the power sums and packing process.

During the expansion phase, the conventional MkCwPIR utilizes the oblivious expansion mechanism from SealPIR, which primarily consists of Galois transformations and ciphertext additions. In contrast, Vectorized MkCwPIR employs plaintext masking and rotations. Benchmarks of individual operations show that the execution time of a Galois transformation is comparable to that of the masking-and-rotation procedure. However, the latter can directly process multiple codewords transmitted by the client, whereas the former must recursively decompose all codewords.

Table 3. Expansion time (s) evaluation of MkCwPIR and VMkCwPIR.

Method	m	c
		512	1024	2048	4096
MkCwPIR	2	9.6	19.4	39.5	80.2
VMkCwPIR		10.3	20.8	41.3	83.2
MkCwPIR	4	19.4	39.5	80.2	161.3
VMkCwPIR		10.3	20.8	41.3	83.2
MkCwPIR	8	39.5	80.2	161.3	322.6
VMkCwPIR		10.3	20.8	41.3	163.2

presents the time expenditure of both protocols during this phase.

It can be observed that when the codeword length c is small and the number of codewords m is large, vectorized ciphertext expansion exhibits a significant advantage over oblivious ciphertext expansion; conversely, the advantage becomes less pronounced.

During the $f_{PCW}(·,·)$ computation stage, the conventional MkCwPIR calculates the $f_{PCW}(·,·)$ values for each client codeword and each server codeword individually. In contrast, Vectorized MkCwPIR simultaneously computes the values for multiple client codewords against each server codeword. This parallel computation of equality operators yields a speedup factor approaching $N/c$, which is consistent with our experimental results and analysis.

Table 4. Execution time (s) of the $f_{\mathrm{PCW}}\left(\right)$ stage for MkCwPIR and VMkCwPIR with $c=2048$.

Method	m	t
		512	1024	2048	4096
MkCwPIR	2	57.4	114.8	229.6	459.2
VMkCwPIR		28.7	57.4	114.8	229.6
MkCwPIR	4	114.8	229.6	459.2	918.4
VMkCwPIR		28.7	57.4	114.8	229.6
MkCwPIR	8	229.6	459.2	918.4	1836.8
VMkCwPIR		28.7	57.4	114.8	229.6

summarizes the time consumption of both protocols during this stage.

Taking the number of keywords $t=2048$ as an example, as m increases from 2 to 8, the execution time of VMkCwPIR in the $f_{PCW}(·,·)$ stage remains constant at 114.8 s. In contrast, the time for MkCwPIR increases linearly from 229.6 s to 918.4 s. This demonstrates that VMkCwPIR achieves an 8× speedup over the conventional MkCwPIR when $m=8$.

During the $f_{PSD}(·,·)$ computation stage, the conventional MkCwPIR first sums the corresponding $f_{PCW}(·,·)$ values for each client’s codeword within each data row, followed by cumulative multiplications across the rows. In contrast, after completing the summation, Vectorized MkCwPIR employs rotations to align the partial sums and performs vectorized ciphertext multiplications, thereby minimizing the multiplication overhead. This parallel multiplication reduces the number of multiplications required for keyword accumulation by a factor of N. Since operations such as plaintext–ciphertext multiplication for truncation, rotation, and addition incur significantly lower latency than ciphertext multiplication, it is highly beneficial to replace expensive ciphertext multiplications with these additional lightweight operations during optimization.

Table 5. Execution time (s) of the $f_{\mathrm{PSD}}\left(\right)$ stage for MkCwPIR and VMkCwPIR with $c=2048$.

Method	m	n
		512	1024	2048	4096
MkCwPIR	2	29.7	59.5	120.8	242.6
VMkCwPIR		2.9	5.8	10.6	21.2
MkCwPIR	4	89.6	179.0	362.9	728.3
VMkCwPIR		3.1	6.0	10.8	21.4
MkCwPIR	8	208.9	417.5	846.6	1699.2
VMkCwPIR		3.5	6.4	11.2	21.8

summarizes the execution times of both protocols during this phase.

Focusing on the case where $n=4096$, the experimental results in Table 5 highlight the superior scalability of VMkCwPIR. Specifically, as the number of codewords m increases from 2 to 8, the execution time for the conventional MkCwPIR surges from 242.6 s to 1699.2 s, representing a nearly seven-fold increase in computational cost. In stark contrast, the execution time for VMkCwPIR remains nearly constant, shifting only slightly from 21.2 s to 21.8 s. Consequently, at $m=8$, VMkCwPIR achieves a remarkable 78× speedup over the standard protocol, effectively demonstrating its efficiency in minimizing multiplication overhead through vectorized operations and rotation-based alignment.

In the final power sum and packing phase, the conventional MkCwPIR performs plaintext-ciphertext multiplications between each row of data and the corresponding $f_{PSD}(·,·)$ values, followed by a homomorphic summation of the results from each row. Lacking vectorized encryption, it cannot execute ciphertext packing, which leads to the number of response ciphertexts scaling up to the maximum match count k. In contrast, the power sum computation in Vectorized MkCwPIR is efficiently achieved through a single ciphertext–plaintext multiplication followed by rotation-sum operations, as detailed in Section 4. The resulting k values are then packed into ciphertext slots.

Table 6. Execution time (s) and response ciphertext count of the power sum and packing phase ($c=2048$).

Method	k	n				Resp. Num
		512	1024	2048	4096
MkCwPIR	1	3.2	6.4	12.8	25.6	1
VMkCwPIR		0.14	0.15	0.16	0.18	1
MkCwPIR	4	12.8	25.6	51.2	102.4	4
VMkCwPIR		0.14	0.15	0.16	0.18	1
MkCwPIR	16	51.2	102.4	204.8	409.6	16
VMkCwPIR		0.14	0.15	0.32	0.64	1
MkCwPIR	64	204.8	409.6	819.2	1638.4	64
VMkCwPIR		0.32	0.64	1.2	2.5	1

summarizes the execution time and the number of response ciphertexts for both protocols during this stage.

A comparison of total server-side runtime is shown in

Table 7. Total execution time (s) comparison between MKCWPIR and VMKCWPIR.

Method	k	$\mathit{n}/\mathit{t}$
		512	1024	2048	4096
MKCWPIR	1	99.9	200.1	402.7	807.6
VMKCWPIR		42.04	84.15	166.86	334.18
MKCWPIR	4	236.6	473.7	953.5	1910.4
VMKCWPIR		42.24	84.35	167.06	334.38
MKCWPIR	16	529.2	1059.3	2131.1	4268.2
VMKCWPIR		42.64	84.75	167.62	415.24

(with $n=t$). The results indicate that by drastically reducing homomorphic ciphertext–ciphertext multiplications, the protocol runs nearly ten times faster, notwithstanding the overhead from additional ciphertext rotation and extraction.

Comparison Between with CwPIR [22]: Before proceeding with the comparison, we first analyze the differences between the two protocols. CwPIR only supports single-keyword queries based on primary keys, whereas our VMkCwPIR supports multi-keyword queries based on non-primary keys. During the server’s online computation phase, CwPIR only requires an $f_{PCW}(·,·)$ calculation followed by an inner product to obtain the results. In contrast, our protocol requires an additional subset decision step, followed by the computation of multiple power sums. Figure 3 illustrates the experimental results, comparing the server-side execution time and the communication overhead (comprising both upload and download costs) for the two protocols. The parameters are configured with a code length $c=2048$ and a code weight $w=2$. In this evaluation, VMkCwPIR executes a unified multi-keyword query with the maximum match threshold set to 64, whereas CwPIR performs an independent single-keyword query for each keyword. Given that CwPIR involves fewer computational operations, its polynomial degree parameter N is set to 8192.

As illustrated, the execution time of VMkCwPIR closely approximates that of CwPIR when performing four independent single-keyword queries. Notably, the communication overhead of VMkCwPIR remains constant, whereas that of CwPIR scales linearly with the number of keywords being queried.

6. Discussion

It can be observed that even though we optimized the protocol implementation using vectorized encryption, a significant performance gap remains compared to state-of-the-art PIR protocols. The primary reason is that our private subset inclusion functionality is constructed based on constant weight codes and equality operators, where the equality comparison for constant weight codes constitutes a computationally intensive operation. Consequently, we leave the task of enhancing the performance of multi-keyword PIR protocols as an open problem for future research.

7. Conclusions

We introduce the first single-round multi-keyword PIR protocol and utilize vectorized encryption to reduce its overhead. While it marks an advancement, its efficiency remains far from that of established high-performance PIR protocols; thus, optimizing the performance of multi-keyword PIR continues to be an important challenge for future work.