Efficient Single-Server Private Information Retrieval Based on LWE Encryption

Abstract

Private Information Retrieval (PIR) is a cryptographic protocol that allows users to retrieve data from one or more databases without revealing any information about their queries. Among existing PIR protocols, single-server schemes based on the Learning With Errors (LWE) assumption currently constitute the most practical class of constructions. However, existing schemes continue to suffer from high client-side preprocessing complexity and significant server-side storage overhead, leading to degraded overall performance. We propose ShufflePIR, a single-server protocol that marks the first introduction of an SM3-based pseudorandom function into the PIR framework for shuffling during preprocessing and utilizes cryptographic hardware to accelerate computation, thereby improving both efficiency and security. In addition, the adoption of a parallel encryption scheme based on the LWE assumption significantly enhances the client’s computational efficiency when processing long-bit data. We evaluate the performance of our protocol against the latest state-of-the-art PIR schemes. Simulation results demonstrate that ShufflePIR achieves a throughput of 9903 MB/s on a 16 GB database with 1 MB records, outperforming existing single-server PIR schemes. Overall, ShufflePIR provides an efficient and secure solution for privacy-preserving information retrieval in a wide range of applications.

1. Introduction

Private Information Retrieval (PIR) is a cryptographic protocol that enables users to retrieve information from one or more databases without revealing any details about their queries. Due to privacy concerns, encryption technology has become increasingly important [1,2,3,4,5,6]. PIR has been widely applied in various systems, including for private database search [7,8], safe browsing [9], credential breach reporting [10,11], and targeted advertising [12], among applications.

PIR protocols can be categorized into two types: (1) multi-server protocols, in which the database is replicated across multiple servers [13], and (2) single-server protocols, where the database resides on a single server [14]. Following the methodology of [15,16], we evaluated both single-server and multi-server architectures. In most cases, multi-server architectures offer lower computational overhead and typically provide moreinformation-theoretic security compared to single-server approaches. However, they rely on the assumption of multiple non-colluding servers—an assumption that is often difficult to satisfy in practice. Consequently, single-server PIR protocols are more widely adopted in practical applications.

Single-server PIR protocols face significant limitations due to two primary challenges. On one hand, certain schemes require clients to perform preprocessing tasks such as pre-downloading personalized auxiliary data [17,18,19,20], generating special-purpose encryption keys, or constructing specific indexes to satisfy application-specific requirements. These tasks impose a significant deployment burden on clients and limit the general applicability of such schemes. On the other hand, alternative schemes rely on unrealistically large server-side storage resources [21,22], often requiring the storage of redundant data that far exceed the size of the original dataset. This results in exponential increases in server storage costs and presents significant challenges in engineering large-scale deployments.

The contradiction between client-side preprocessing complexity and server-side storage efficiency in single-server PIR remains difficult to reconcile. This inherent limitation poses a significant challenge to the practical deployment of PIR technology, particularly with respect to throughput, communication overhead, and retrieval rate (defined as the ratio of the size of the retrieved record to the total response size). First, throughput is constrained by the read speed of the server’s in-memory database. Under the experimental conditions of this study, the single-core memory read speed was measured at 55.23 GB/s. In-depth analysis indicates that, within a single-database-server and cryptographic-primitives framework, the total communication volume required to retrieve records increases monotonically with the number of records. Furthermore, complex cryptographic primitives introduce substantial redundancy overhead when processing large datasets, resulting in reduced retrieval efficiency. In standard client–single-server interaction scenarios, a substantial gap exists between the performance of current PIR protocols and their theoretical limits. Experimental results demonstrate that the best-performing single-server PIR scheme [23] achieves a throughput of 1.48 GB/s per core for databases with record sizes of 30 KB. When the record size increases to 100 KB, the retrieval efficiency rises to 0.6677. Additionally, in tests conducted on a 1 GB-scale database with varying record lengths, the average communication volume remained stable at approximately 225 KB.

In this paper, we present a new single-server PIR protocol. Our work builds upon the single-server PIR scheme proposed by Kushilevitz and Ostrovsky [14]. In their construction, the PIR server represents a database containing N records (where N denotes the total number of records in the database) as a $\sqrt{N}\times \sqrt{N}$ matrix D, assuming N is a perfect square. To retrieve the record located at the i-th row and j-th column, the client sends an encrypted query vector (E(q)), which is $\sqrt{N}$-dimensional with a 1 at the j-th index and 0 elsewhere. If the encryption scheme supports linear homomorphism, the server can compute the matrix–vector product as D · E(q) = E(D · q) and return the result to the client. Upon decryption, the client recovers D · q, which corresponds to the j-th column of the database, as intended. The total communication cost scales with N, and the PIR server’s throughput is constrained by the computational speed of the plaintext matrix–vector multiplication (D · E(q)).

To overcome the limitations of existing schemes, we propose a shuffling algorithm based on SM3-PRF for database preprocessing. Since this preprocessing step depends solely on the database (D), it can be reused across multiple queries from different clients. This enables the client to download a reusable “hint” and compute the query ciphertext (E(q)) using only a partial scalar input. During the query phase, encryption and decryption are parallelized based on Regev’s LWE encryption scheme [24]. In contrast to the standard Regev scheme, which requires N separate operations for a database of size N, our modified LWE-based approach supports single-operation encryption and decryption, thereby significantly improving computational efficiency. Specifically, we make the following contributions:

• We propose an SM3-PRF-based shuffling algorithm that leverages the SM3 hash function and a pseudorandom function to preprocess the database. This preprocessing strategy is compatible with any single-server client and requires the storage of only a $\sqrt{N}$-sized hint. In addition, SM3 cryptographic security chips are integrated into the server to enable hardware–software co-processing, thereby accelerating the SM3-PRF shuffling process and enhancing resistance to physical and side-channel attacks.
• A parallel encryption algorithm is developed based on the Regev LWE (Learning With Errors) scheme. The algorithm transforms scalar LWE encryption into matrix-based encryption, significantly reducing computational overhead from O(N) to O(1) operations for database encryption/decryption. Performance evaluations demonstrate substantial improvements: encryption time is reduced by 85–92% for long-bit data processing (>1000 bits) while maintaining equivalent security guarantees. Specifically, for a 16 GB database with 1 MB records, the parallel scheme achieves 9903 MB/s throughput, compared to the 1516 MB/s of existing schemes, representing a 6.5× performance improvement.
• Extensive simulations demonstrate that the single-server ShufflePIR protocol achieves high performance, with a peak throughput of 9903 MB/s on a 16 GB database with 1 MB records—representing an six-fold improvement over the best-performing existing single-server PIR scheme, the Spiral family. Furthermore, we formally prove the protocol’s security under polynomial-time adversaries. Therefore, the protocol provides a practical and secure solution for high-throughput information retrieval in privacy-sensitive applications.

2. Relatedwork

The first single-server PIR scheme, introduced by Kushilevitz and Ostrovsky [14], employs homomorphic computation. Let F be the expansion factor of the encryption scheme, which maps a $\zeta$-bit plaintext to an F-bit ciphertext. The communication cost of the construction of a database with N records and any dimension parameter ($n\in N^{+}$) is approximately $N^{1/n}·F^{n-1}$. To answer a client query, the server must perform approximately $O\left(N·F^{n-1}\right)$ homomorphic operations.

Existing schemes mitigate communication overhead by employing ciphertext compression and homomorphic encryption. SealPIR [25] demonstrates that clients can adopt an XPIR-style [26] scheme to compress ciphertexts prior to uploading. The server can then homomorphically expand these compressed ciphertexts. FastPIR [27] similarly employs a method to compress server responses. These optimizations reduce communication costs by several orders of magnitude. However, they require the server to store per-client information, referred to as ‘ciphertext switching hints’, which are essentially encryptions of the secret decryption key of the client that can be several megabytes in size and must be uploaded by the client before any queries. MulPIR [28], OnionPIR [29], and Spiral [23] further leverage fully homomorphic encryption [30] to reduce communication overhead. In Spiral [23], the communication cost scales approximately as $N^{1/n}·F$, with the exponent of F being 1 rather than $n-1$. Based on ideas from Gentry and Halevi [31], Spiral demonstrates how to reduce communication costs while maintaining high throughput; achieving up to 2.17 GB/s on databases with short records. For long database records, Spiral does not employ SealPIR’s query compression and achieves a throughput of 13.14 GB/s, albeit with increased communication overhead.

Multi-server PIR schemes are more susceptible to privacy leakage, particularly in the presence of server collusion. Multi-server XOR PIR schemes [26] require the client to communicate with multiple database servers, where client privacy is preserved only if a subset of the servers remains uncompromised. In

Table 1. Comparison of PIR schemes for a database of size N with n security parameters.

Scheme	Servers	Communication	Client Storage	Polylog Compute Overhead	Max. Achievable Throughput/Core
DPF PIR [34]	2	logN	×	✓	5381 MB/s
XOR PIR [26]	2	$\sqrt{N}$	×	✓	6067 MB/s
XOR PIR fast [26]	2	$\sqrt{N}$	×	✓	11,797 MB/s
SealPIR [25]	1	$\sqrt{N}$	✓	✓	105 MB/s
FastPIR [27]	1	N	✓	✓	186 MB/s
MulPIR [28]	1	$\sqrt{N}$	✓	✓	69 MB/s
OnionPIR [29]	1	log N	✓	✓	149 MB/s
FrodoPIR [35]	1	$\sqrt{N}$	×	✓	1256 MB/S
Spiral family [23]	1	log N	✓	✓	1516 MB/s
ShufflePIR (Ours)	1	$\sqrt{N}$	✓	✓	9903 MB/S

Note: The overhead column indicates whether the server’s computational overhead per database bit is, at most, polynomial in n. The throughput column gives the maximum throughput we measured for arbitrary record sizes. Gray-colored schemes represent two-server schemes, while yellow-colored schemes represent the schemes from this paper.

, we present the throughput results for our optimized implementation of the two-server DPF PIR scheme based on distributed point function realizations [32,33]. Additionally, we report the throughput of the two-server PIR scheme characterized by a communication volume of $\sqrt{N}$ (“XOR PIR”) [26]. If the server’s running time is allowed to depend on the Hamming weight of the client’s query vector (“XOR PIR Fast”), these schemes can achieve a speedup of up to a factor of two. However, this optimization may compromise client privacy by leaking the client’s query vector to other servers via timing side channels. The acceptability of this trade-off between performance and privacy leakage in practical deployments may vary depending on the specific application scenario. In our PIR scheme, the client communicates with a single database server and, while preserving security, delivers performance that exceeds that of certain multi-server solutions (see Table 1).

In our PIR scheme, the client is required to download the entire size-N database and perform preprocessing. During this phase, each client downloads and stores a reusable “hint” of size $\sqrt{N}$ from the server. By leveraging a server-side SM3-PRF-based shuffling algorithm for database preprocessing, the protocol generates reusable hints that compact query vectors, thereby improving client-side storage efficiency and reducing overall communication overhead. Leveraging an LWE-based encryption scheme, the number of encryption and decryption operations is reduced from $O\left(N\right)$ to $O\left(1\right)$, thereby significantly enhancing the computational efficiency for both the client and the server. Additionally, this approach leads to a substantial reduction in communication overhead, as it minimizes the amount of data that needs to be transmitted between parties during the encryption and decryption processes. FrodoPIR [35] proposes a PIR scheme that is functionally equivalent to ShufflePIR. In FrodoPIR’s default configuration, communication costs are $O\left(N\right)$ for a database of size N. However, by rebalancing the scheme, FrodoPIR can achieve a O($n\sqrt{N}$) communication cost, where n denotes the lattice dimension—matching that of ShufflePIR. Our scheme has the limitation that the client must download the database during preprocessing to enable PIR functionality. The server-side query processing remains linear in complexity [20] but is more practical, as it eliminates the need for client-specific preprocessing. FrodoPIR adopts a vector–matrix multiplication framework for encryption in which the client preprocesses query parameters by generating LWE samples $\left(b_j,c_j\right)$ through the $b_j\leftarrow s_j^T·A+e_j^T$ and $c_j\leftarrow s_j^T·M$ operations during the offline phase. Online query generation involves only a single vector addition: $\tilde{b}\leftarrow b+f_i$. Despite optimizations, its encryption and decryption operations scale linearly with the database size in mm, particularly in terms of online query size. Another key distinction lies in the design of the preprocessing phase and the integration of hardware acceleration. FrodoPIR features a client-independent offline phase, where the server solely generates public parameters $\left(\mu ,M\right)$ via matrix multiplication $M\leftarrow A·D$. While this avoids client-specific preprocessing, it results in online query sizes that grow linearly with the database size. Furthermore, FrodoPIR does not incorporate pseudorandom shuffling algorithms or cryptographic hardware acceleration. In contrast, ShufflePIR integrates an SM3-based pseudorandom function (PRF) into the database preprocessing stage, generating reusable $\sqrt{N}$-sized hints that compact query vectors and reduce client-side storage overhead. In addition, ShufflePIR leverages RSP S20G cryptographic security chips to accelerate the SM3-PRF shuffling process, thereby enhancing preprocessing speed and improving resistance to physical and side-channel attacks—capabilities absent in FrodoPIR. These combined innovations—parallel encryption and hardware-accelerated shuffling, enabling ShufflePIR to achieve a sixfold throughput improvement over state-of-the-art single-server schemes such as the Spiral family, surpassing FrodoPIR’s maximum throughput of 1256 MB/s.

3. Background

3.1. Learn with Errors (LWE)

The security of our PIR scheme is based on the Learning With Errors (LWE) assumption [36]. Let $n\in N$ be the security parameter, $q\ge 2$ be an integer modulus, $\chi$ be an error distribution over Z, and $m\in N$ be the number of samples. Given a random matrix ($A\in Z_q^{m*n}$), a secret vector ($s\in Z_q^n$), a public key vector ($b=A^T·s+e\in Z_q^m$), an error vector ($e\in {\chi }_q^m$), and a random vector ($r\in {\chi }_q^m$), the $\left(n,q,\chi \right)$-LWE assumption with m samples is said to be $\left(t,ϵ\right)$-hard if every adversary running at time t has, at most, $ϵ$ advantage in distinguishing between the following two distributions. Given matrix A, the following distributions are computationally indistinguishable under the LWE assumption:

$$\left\{\left(A,A^T·s+e\right)\right\}\leftarrow \left\{\left(A,r\right)\right\}$$

(1)

The proposed scheme is based on the Regev LWE construction, and the encryption procedure for a message ($\mu \in Z_p$) is expressed as follows:

$$\left(c_1,c_2\right)=\left(A^T·r,b^T·r+⌊{\displaystyle \frac{q}{2}}⌋\mu modq\right)$$

(2)

To decrypt a ciphertext $\left(c_1,c_2\right)$, one computes $c_2-s^T·c_{1}modq$ using the secret vector (s) and recovers the plaintext message ($\mu$) by reducing the resulting modulo q and applying a suitable rounding procedure. Decryption succeeds if the noise introduced by the error distribution ($\chi$) has a magnitude of less than ${\displaystyle \frac{1}{2}}q$. We say that the Regev parameters support a correctness error of $\delta$ if the probability of decryption failure is, at most, $1-\delta$ with respect to the randomness of the encryption algorithm.

3.2. Private Information Retrieval with Preprocessing

In our PIR scheme, the client and server jointly preprocess the database to generate a reusable “hint” for storage. This preprocessing enables the server to perform the majority of computations offline, prior to receiving any queries. The size of the hints is small and grows sublinearly with the size of the database. All clients share a common set of hints, and each client can reuse these hints across multiple PIR queries.

A PIR scheme with preprocessing [34] over a plaintext space if D and database size of N contains four routines. All routines take the security parameter as an implicit input:

$Setup\left(db\right)\to \left(hin{t}_c\right)$: Given a database ($db\in N$), output the preprocessing hints for the server and client.

$Query\left(x\right)\to \left(st,qu\right)$: Given an index ($i\in \left[N\right]$), output the client’s secret state ($st$) and database query ($qu$). $Answer\left(db,qu\right)\to \left(ans\right)$: Given the database ($db$) and client query ($qu$), output the answer ($ans$).

$Extract\left(st,ans\right)\to \left(mes\right)$: Given the client’s secret state ($st$), and answer ($ans$), output the record ($mes\in D$).

Theorem 1. (Correctness)

If the client and server execute the PIR protocol honestly, then the client recovers the correct database record with overwhelming probability, as determined by the implicit correctness parameter (λ). This guarantee holds for all security parameters ($\lambda \in N$), where $N=N\left(\lambda \right)$ and $\zeta =\zeta \left(\lambda \right)$ are polynomial inλ for any database $(db=\left\{d_1,d_2,\dots ,d_N\right\}$ with $d_i\in {\left\{0,1\right\}}^{\zeta }$ and for all indices ($i\in \left[N\right]$). The following probability is at least $1-\delta$:

$$Pr\left[d_i=mes:\begin{array}{cc}\hfill \left(hin{t}_c\right)& \leftarrow \mathrm{Setup}\left(db\right)\hfill \\ \hfill (st,qu)& \leftarrow \mathrm{Query}\left(i\right)\hfill \\ \hfill ans& \leftarrow \mathrm{Answer}(db,qu)\hfill \\ \hfill mes& \leftarrow \mathrm{Extract}(st,ans)\hfill \end{array}\right]$$

(3)

Theorem 2. (Security)

The client’s query does not reveal any information about the index of the record being retrieved. Formally, a PIR scheme is said to be $\left(t,ϵ\right)$-secure if, for all probabilistic polynomial-time adversaries (A) running at a time of, at most, t for all database sizes (N) and for all indices ($i,j\in \left[N\right]$), the following holds:

$$|Pr[\mathcal{A}(1^N,qu)=1:(st,qu)\leftarrow Query\left(i\right)]-Pr[\mathcal{A}(1^N,qu)=1:(st,qu)\leftarrow Query\left(j\right)]|\le ϵ$$

(4)

4. Main Construction

In the following section, we provide a detailed analysis of the ShufflePIR scheme. ShufflePIR exhibits high execution efficiency, with its throughput measured in queries per second, as shown in Table 1. Importantly, the following theorems are established to support the scheme’s theoretical foundations:

For a database of size N, let $p\in N$ be the plaintext modulus for the secret-key Regev encryption scheme, with LWE parameters of $\left(n,q,\chi \right)$. This parameter set achieves $\left(t,ϵ\right)$-hard security for N LWE samples with a correctness error of $\delta$. Then, for a database of size N and plaintext space $Z_q$, ShufflePIR is a PIR scheme with $\left(O\left(\sqrt{N}\right),ϵ\right)$ security and a correctness error of $\delta$.

4.1. ShufflePIR

Figure 1 illustrates the protocol flow of the ShufflePIR scheme, along with its formal specification. Its security and correctness are formally proven in Section 5.

Database structure.The database (DB) consists of N data records, each represented as a key–value pair ($\left(i,DB\left[i\right]\right)$, where $i\in \left\{0,1,\dots ,N-1\right\}$ denotes the index and $DB\left[i\right]$ is the corresponding data item).

SM3-PRF Shuffling Algorithm.The database of size N is partitioned into $O\left(\sqrt{N}\right)$ blocks, each indexed by $j\in \{0,1,\dots ,\sqrt{N}-1\}$. Each block contains $\sqrt{N}$ consecutive indices of the form $j·\sqrt{N},\dots ,(j+1)·\sqrt{N}-1$. Using SM3-PRF, a private key is generated ($s_{ki}\in {\{0,1\}}^{\lambda }$ is generated, where $\lambda$ denotes the computational security parameter). The offset within the j-th block is computed as $PR{F}_{ski}\left(j\right)mod\sqrt{N}$. Consequently, the shuffled index (i) corresponding to block j is given expressed as follows:

$$i=j·\sqrt{N}+{PRF}_{s_{ki}}\left(j\right)mod\sqrt{N}$$

(5)

When calculating the shuffled indices, we first ensure that N is a perfect square. If N is not a perfect square, we pad the database with dummy records until the size becomes a perfect square, denoted as $N=m^2$, where $m=\lceil \sqrt{N}\rceil$ when N is not a perfect square (and $m=\sqrt{N}$ when N is a perfect square). The index formula is then defined as $i=j·m+{\mathrm{PRF}}_{s{k}_i}\left(j\right)modm$, where $j\in \{0,1,\dots ,m-1\}$ and ${\mathrm{PRF}}_{s{k}_i}\left(j\right)$ outputs a value in $\{0,1,\dots ,m-1\}$.

To verify the uniqueness and non-conflict of indices, for any two distinct $j_1,j_2\in \{0,1,\dots ,m-1\}$, suppose $j_1·m+a_1=j_2·m+a_2\mathrm{m}$ where $a_1={\mathrm{PRF}}_{s{k}_i}\left(j_1\right)modm$ and $a_2={\mathrm{PRF}}_{s{k}_i}\left(j_2\right)modm$. Then, $(j_1-j_2)·m=a_2-a_1$. Since $|j_1-j_2|<m$ and $|a_2-a_1|<m$, the only possibility is $j_1=j_2$ and $a_1=a_2$, which contradicts $j_1\ne j_2$. Thus, all indices i are unique, and there is no conflict in the shuffling process.

LWE Parallel Computation. It was observed that employing Regev’s LWE encryption for indices with long bit lengths introduces substantial computational overhead and increased error rates, making accurate computation infeasible for arbitrarily large indices and thereby restricting its practical applicability. To overcome these challenges, we devised a simple yet efficient parallel LWE encryption scheme:

In our parallel LWE implementation, the n database indices are partitioned into m-dimensional vectors, resulting in the construction of the plaintext matrix ($\mu \in Z^{n\times m}$). Let $n\in N$ be the security parameter, $q\ge 2$ be an integer modulus, $\chi$ be an error distribution over Z $\left(\mathrm{discrete}\mathrm{Gaussian}\mathrm{distribution}\mathcal{N}(0,{\sigma }^2),\mathrm{elements}|·|\ll q/2\right)$, and $m\in N$ be the number of samples. Given a random matrix ($A\in Z_q^{m*n}$), a secret vector ($s\in Z_q^n$), a public key vector ($b=A·s+e\in Z_q^m$), an error vector ($e\in {\chi }^m$), and a random vector ($r\in {\chi }_q^m$), we evaluate the performance under different parameter configurations, with specific values provided in Section 4.2. The ciphertext matrix ($C\left(\mu \right)$) is generated through parallel LWE encryption of the plaintext matrix $\mu$, as described below:

$$C\left(\mu \right):\left(c_{0,i,j},c_{1,i,j}\right)=\left(A^T·r+e_{1,i,j}·1_n,b^T·r+e_{2,i,j}+⌊{\displaystyle \frac{q}{2}}⌋·{\mu }_{i,j}\right)$$

(6)

When decrypting the ciphertext ($C\left(\mu \right)$), the first step is to compute the intermediate decryption value ($V\left(\mu \right)$).

$$V\left(\mu \right):v_{i,j}=c_{2,i,j}-s^T·c_{1,i,j}=⌊{\displaystyle \frac{q}{2}}⌋·{\mu }_{i,j}+e_{2,i,j}-e_{1,i,j}·s^T{1}_n+e^T·r$$

(7)

The total error ($E=e_{2,i,j}-e_{1,i,j}·s^T{1}_n+e^T·r$) remains small in magnitude, and the error distribution parameter ($\sigma$) is selected such that $\sigma <{\displaystyle \frac{q}{2}}$. The plaintext ($D\left(\mu \right)$) is recovered by first rounding the intermediate value, then performing decryption, as described below:

$$D\left(\mu \right)=Roun{d}_{⌊{\displaystyle \frac{q}{2}}⌋}{v}_{i,j}/⌊{\displaystyle \frac{q}{2}}⌋$$

(8)

Master Table m1. The shuffling algorithm is employed to permute the database indices (i), and the resulting entries are stored in the master table (m1). The master table consists of $\mathit{O}\left(\sqrt{\mathit{N}}\right)$ entries, where each entry contains a subset of $\mathit{O}\left(\sqrt{\mathit{N}}\right)$ data records derived from the permuted database. Specifically, the j-th entry in $\mathit{m}\mathit{1}$ includes a set of pseudorandom selected indices and an associated parity bit, defined as follows:

$${\mathit{P}}_{\mathit{j}}=\underset{\mathit{i}=\mathit{0}}{\overset{\sqrt{\mathit{N}}-\mathit{1}}{⨁}}\mathrm{DB}\left[\mathit{i}\right],$$

(9)

where ⊕ denotes the bitwise XOR operation. Replacement Table $\mathit{m}\mathit{2}$. We randomly sample an index set of size $\sqrt{\mathit{N}}$, drawing one random index from each block ($\mathit{j}$) to construct a random set ($\mathit{R}$). For each block ($\mathit{j}\in \left\{\mathit{0},\mathit{1},\dots ,\sqrt{\mathit{N}}-\mathit{1}\right\}$), we store O(1) entries of the form $\left(\mathit{R}\left[\mathit{j}\right],\mathit{DB}\left[\mathit{R}\left[\mathit{j}\right]\right]\right)$, where each $\mathit{R}\left[\mathit{j}\right]$ is a randomly sampled index from block $\mathit{j}$.

The process of ShufflePIR is expressed as follows:

• $\mathit{Setup}\left(\mathit{db}\right)\to \left({\mathit{hint}}_{\mathit{c}}\right)$: The preprocessing phase is responsible for generating and storing the hint tables ($\mathit{m}\mathit{1}$ and $\mathit{m}\mathit{2}$).
  • Initialization.The client retrieves the complete database ($\mathit{db}$) from the server, constructs an initial master table ($\mathit{m}\mathit{1}$), and initializes all parity bits (${\mathit{P}}_{\mathit{1}},\dots ,{\mathit{P}}_{\sqrt{\mathit{N}}}$) in $\mathit{m}\mathit{1}$ to zero. Subsequently, the client constructs a corresponding replacement table ($\mathit{m}\mathit{2}$) to support future updates.
  • Setup of the Master Table $\mathit{m}\mathit{1}$. Generate an SM3-PRF key (${\mathit{sk}}_{\mathit{i}}$) for each row ($\mathit{S}$) in the master table. The shuffling algorithm is applied to permute the database indices according to the rule expressed as $\mathit{i}=\mathit{j}·\sqrt{\mathit{N}}+({\mathrm{PRF}}_{{\mathit{s}}_{\mathit{ki}}}\left(\mathit{j}\right)mod\sqrt{\mathit{N}})$. The key point is such that if $\mathit{i}$ is known, both $\mathit{j}$ and ${\mathit{sk}}_{\mathit{i}}$ can be deterministically derived. This permutation uniformly redistributes the database records, ensuring that each record is equally likely to occupy any position in the table. The parity bits are then updated as

    $${\mathit{P}}_{\mathit{j}}=\underset{\mathit{i}=\mathit{j}·\sqrt{\mathit{N}}}{\overset{\left(\mathit{j}+\mathit{1}\right)\sqrt{\mathit{N}}}{⨁}}\mathrm{DB}\left[\mathit{i}\right]$$

    (10)
  • Setup of the Replacement Table $\mathit{m}\mathit{2}$. Random indices ($\mathit{R}\left[\mathit{i}\right]$) are selected from each of the $\mathit{j}$ blocks, and $\mathit{j}$ tuples of the form $\left(\mathit{R}\left[\mathit{j}\right],\mathit{DB}\left[\mathit{R}\left[\mathit{j}\right]\right]\right)$ are subsequently sampled and stored. These tuples are then used to construct the replacement table ($\mathit{m}\mathit{2}$), which facilitates efficient record updates during future queries.
  • Delete Local Database. Remove the locally stored database.
• $\mathit{Query}\left(\mathit{i}\right)\to \left(\mathit{st},\mathit{qu}\right)$: The client obtains a hint table through a preprocessing phase. The preprocessing algorithm performs a single linear scan of the database while requiring only $\mathit{O}\left(\sqrt{\mathit{N}}\right)$ local storage. In the ShufflePIR scheme, this preprocessing incurs $\mathit{O}\left(\mathit{N}\right)$ communication and computation overhead and must be executed once every $\mathit{O}\left(\sqrt{\mathit{N}}\right)$ queries. Thus, the amortized cost per query remains $\mathit{O}\left(\sqrt{\mathit{N}}\right)$. During each query, the client utilizes the stored ${\mathit{hint}}_{\mathit{c}}$. To retrieve a specific record ($\mathit{DB}\left[\mathit{x}\right]$), the client performs a single query based on the stored ${\mathit{hint}}_{\mathit{c}}$, sends the query ($\mathit{qu}$), and records the state ($\mathit{st}$).
  • The position ($\mathit{x}$) is extracted from the hint information. Given a query index ($\mathit{x}$), the client first computes ${\mathit{j}}_{\mathit{x}}=\mathit{x}mod\sqrt{\mathit{N}}$, then derives the position mapping (${\mathit{i}}_{\mathit{x}}={\mathit{j}}_{\mathit{x}}\sqrt{\mathit{N}}+{\mathit{PRF}}_{\mathit{skx}}{(}_{\mathit{x}})mod\sqrt{\mathit{N}}$) using the master table ($\mathit{m}\mathit{1}$).
  • The state value is recorded. The corresponding value (${\mathit{P}}_{{\mathit{j}}_{\mathit{x}}}$) is retrieved:

    $${\mathit{P}}_{{\mathit{j}}_{\mathit{x}}}=\underset{\mathit{i}={\mathit{j}}_{\mathit{x}}·\sqrt{\mathit{N}}}{\overset{\left({\mathit{j}}_{\mathit{x}}+\mathit{1}\right)\sqrt{\mathit{N}}}{⨁}}\mathrm{DB}\left[{\mathit{i}}_{\mathit{x}}\right]$$

    (11)
    The next available replacement pair ($\left(\mathit{R}\left[{\mathit{j}}_{\mathit{x}}\right],\mathit{DB}\left[\mathit{R}\left[{\mathit{j}}_{\mathit{x}}\right]\right]\right)$) is selected from the replacement table ($\mathit{m}\mathit{2}$) and is used to replace the ${\mathit{i}}_{\mathit{x}}$-th data record associated with index ${\mathit{j}}_{\mathit{x}}$. The resulting modified set is denoted as $\mathit{S}$. The state ($\mathit{st}=\left(\mathit{S},{\mathit{P}}_{{\mathit{j}}_{\mathit{x}}}\right)$) is recorded.
  • The retrieval ciphertext is sent. Set $\mathit{S}$ is encrypted using an LWE-based cryptosystem. Set $\mathit{S}$ is transformed into a matrix of the form ${\mathit{\mu }}_{\mathit{S}}\in {\mathit{Z}}_{\mathit{q}}^{\mathit{n}\times \mathit{m}}$. In Section 4.2, the selection of parameters for the LWE-based cryptographic scheme is discussed. The resulting retrieval ciphertext ($\mathit{qu}$) is sent to the server:

    $$\mathit{C}\left({\mathit{\mu }}_{\mathit{s}}\right):\left({\mathit{c}}_{\mathit{0},\mathit{i},\mathit{j}},{\mathit{c}}_{\mathit{1},\mathit{i},\mathit{j}}\right)=\left({\mathit{A}}^{\mathit{T}}·\mathit{r}+{\mathit{e}}_{\mathit{1},\mathit{i},\mathit{j}}·{\mathit{1}}_{\mathit{n}},{\mathit{b}}^{\mathit{T}}·\mathit{r}+{\mathit{e}}_{\mathit{2},\mathit{i},\mathit{j}}+⌊{\displaystyle \frac{\mathit{q}}{\mathit{2}}}⌋·{\mathit{\mu }}_{\mathit{si},\mathit{j}}\right)$$

    (12)
• $\mathit{Answer}\left(\mathit{db},\mathit{qu}\right)\to \left(\mathit{ans}\right)$: After receiving the ciphertext ($\mathit{qu}$) from the client, the server decrypts it to recover the corresponding plaintext index, executes a query and performs the required computation over the database ($\mathit{DB}$), and returns the response ($\mathit{ans}$).
  • Decrypt the ciphertext.The server uses the secret key ($\mathit{s}$) to decrypt the ciphertext (${\mathit{u}}_{\mathit{S}}$) and recovers the index set from the resulting matrix:

    $$\mathit{V}\left({\mathit{\mu }}_{\mathit{s}}\right):{\mathit{v}}_{\mathit{i},\mathit{j}}={\mathit{c}}_{\mathit{2},\mathit{i},\mathit{j}}-{\mathit{s}}^{\mathit{T}}·{\mathit{c}}_{\mathit{1},\mathit{i},\mathit{j}}=⌊{\displaystyle \frac{\mathit{q}}{\mathit{2}}}⌋·{\mathit{\mu }}_{\mathit{si},\mathit{j}}+{\mathit{e}}_{\mathit{2},\mathit{i},\mathit{j}}-{\mathit{e}}_{\mathit{1},\mathit{i},\mathit{j}}·{\mathit{s}}^{\mathit{T}}{\mathit{1}}_{\mathit{n}}+{\mathit{e}}^{\mathit{T}}·\mathit{r}$$

    (13)

    $$\mathit{D}\left({\mathit{\mu }}_{\mathit{s}}\right)={\mathit{Round}}_{⌊{\displaystyle \frac{\mathit{q}}{\mathit{2}}}⌋}{\mathit{v}}_{\mathit{i},\mathit{j}}/⌊{\displaystyle \frac{\mathit{q}}{\mathit{2}}}⌋$$

    (14)
  • Retrieve. The corresponding data records are retrieved from the database, and the result ($\mathit{ans}$) is computed as $\mathit{ans}={\oplus }_{\mathit{i}\in \mathit{S}}\mathit{DB}\left[\mathit{i}\right]$. Finally, the computed result ($\mathit{ans}$) is transmitted to the client.
• $\mathit{Extract}\left(\mathit{st},\mathit{ans}\right)\to \left(\mathit{mes}\right)$: Using the ciphertext ($\mathit{ans}$) returned by the server and the local state ($\mathit{st}$), the client computes the value of the queried message ($\mathit{mes}$).
  • The client computes $\mathit{mes}$:

    $$\mathit{DB}\left[\mathit{x}\right]=\mathit{ans}\oplus \mathit{DB}\left[\mathit{R}\left[\mathit{j}\right]\right]\oplus {\mathit{P}}_{{\mathit{j}}_{\mathit{x}}}$$

    (15)
    If the procedure fails, the client assigns a value of 0 to the retrieval result ($\mathit{mes}$).

As outlined above, under honest execution of the PIR protocol by both the client and the servers, the client can retrieve the desired database record (di) with a probability of at least $\mathit{1}-\mathit{\delta }$. Here, $\mathsf{\delta }$ denotes a negligible probability determined by the correctness parameter of the underlying LWE encryption scheme. Therefore, the ShufflePIR scheme satisfies the correctness property (see Theorem 1).

4.2. Parameter Selection

Our LWE-based scheme builds upon Regev’s construction. To achieve 128-bit security while minimizing decryption error, we employ a systematic parameter selection approach. The security analysis follows established LWE security estimates, while correctness requirements ensure the total noise remains below q/2 during decryption. For 128-bit security, we select the dimension parameter as $\mathit{n}\ge \mathit{512}$ to resist lattice reduction attacks under current models. The modulus ($\mathit{q}={\mathit{2}}^{\mathit{32}}$) provides sufficient security margin while enabling efficient arithmetic. The error distribution ($\mathit{\chi }$) is defined as a discrete Gaussian with a standard deviation of $\mathit{\alpha }=\mathit{6}.\mathit{4}$, chosen to balance security and correctness requirements. The correctness error is bounded by $\mathit{\delta }={\mathit{2}}^{-\mathit{40}}$ by ensuring the total error ($\mathit{E}$) satisfies $\left|\mathit{E}\right|<\mathit{q}/\mathit{4}$ with high probability. The plaintext modulus ($\mathit{p}$) is selected as the largest value satisfying this noise constraint for each database configuration, optimizing the trade-off between security, correctness, and efficiency. By analyzing Regev’s encryption scheme, we configured the parameters $\left(\mathit{n},\mathit{q},\mathit{\chi }\right)$ and the plaintext modulus (p) to achieve 128-bit security. Specifically, the error distribution ($\mathit{\chi }$) is defined as a discrete Gaussian with a standard deviation of $\mathit{\alpha }=\mathit{6}.\mathit{4}$, and the correctness error is bounded by $\mathit{\delta }={\mathit{2}}^{-\mathit{40}}$.

Table 2. Parameter Comparison under Different Database Configurations.

Metric	$2^{20}\times 256\mathbf{B}$	$2^{18}\times 30\mathbf{kB}$	$2^{14}\times 100\mathbf{kB}$	$2^{14}\times 1\mathbf{MB}$
log n	10	9	7	7
log m	10	9	7	7
log q	32	32	32	32
log p	9	16	18	21

presents the trade-offs among the database size (N), dimension parameter (n), ciphertext modulus ($\mathit{q}$), and plaintext modulus ($\mathit{p}$).

4.3. Extensions

The proposed scheme supports multiple PIR. To support $\mathit{O}\left(\sqrt{\mathit{N}}\right)$ unique random queries, it is necessary to securely manage previously used entries in the master table after each query. Reusing entries risks information leakage, whereas removing them compromises the table’s random distribution. To address this issue, the optimized scheme introduces a secondary table ($\mathit{m}\mathit{3}$) maintained locally by the client. Similar to the master table, $\mathit{m}\mathit{3}$ employs a shuffling algorithm to store processed entries, each comprising $\mathit{O}\left(\sqrt{\mathit{N}}\right)$ data records. Each entry also includes a random index set and a corresponding parity bit (${\mathit{p}}_{\mathit{j}}^{\prime }$) for block ${\mathit{j}}^{\prime }$:

$${\mathit{P}}_{\mathit{j}}^{\prime }=\underset{\mathit{i}={\mathit{j}}^{\prime }·\sqrt{\mathit{N}}}{\overset{\left({\mathit{j}}^{\prime }+\mathit{1}\right)\sqrt{\mathit{N}}}{⨁}}\mathrm{DB}\left[\mathit{i}\right]$$

(16)

When querying $\mathit{DB}\left[\mathit{x}\right]$, a previously used entry $\left({\mathit{j}}_{\mathit{x}},{\mathit{p}}_{{\mathit{j}}_{\mathit{x}}}\right)$ is replaced with an unused entry $\left({\mathit{j}}_{\mathit{x}}^{\prime },{\mathit{p}}_{{\mathit{j}}_{\mathit{x}}}^{\prime }\right)$ from $\mathit{m}\mathit{3}$, thereby updating the master table. This replacement preserves the statistical distribution of index sets in the master table. The scheme supports $\mathit{O}\left(\sqrt{\mathit{N}}\right)$ unique random queries. Each block is designed with a polynomial number of replacement entries. After $\mathit{O}\left(\sqrt{\mathit{N}}\right)$ queries, each block is accessed only a polynomial number of times, ensuring a negligible probability of depleting its replacement entries.

The client retains the results of the most recent $\mathit{O}\left(\sqrt{\mathit{N}}\right)$ queries. If a repeated query is issued, the client retrieves the result locally and sends a different random query to the server. Additionally, during the current query window, the client performs preprocessing for the subsequent batch of queries. Following a one-time preprocessing phase involving $\mathit{O}\left(\sqrt{\mathit{N}}\right)$ communication and computation, the client only needs to store $\mathit{O}\left(\sqrt{\mathit{N}}\right)$ data, enabling arbitrary queries with $\mathit{O}\left(\sqrt{\mathit{N}}\right)$ communication and computation per query.

4.4. Hardware Support

In the ShufflePIR algorithm, the SM3-based pseudorandom function (PRF) is employed for database preprocessing. This process is accelerated using the RSP S20G cryptographic security chip. The client deploys a server equipped with the security chip. This programmable and reconfigurable chip supports adaptation to evolving security requirements through algorithm updates, eliminating the need for hardware modifications.

In terms of hardware security, the RSP S20G chip provides resistance against physical attacks, including tamper resistance and side-channel attack mitigation. Its operational logic and data processing mechanisms have undergone rigorous security certification. The optimized implementation of the SM3 algorithm prevents the leakage of intermediate computational results. The SM3 algorithm’s padding, grouping, and iterative compression steps are executed entirely within the security chip, with intermediate results cached in a dedicated secure zone to prevent external access or tampering.

In terms of performance, the chip supports SM3 computation at a throughput of 30 Gbps. High-speed interfaces, such as the PCIe 2.0 x8 bus and eight-channel read/write propagation at 4 GB/s, facilitate efficient data transfer between software and hardware. The protocol invokes the chip’s computing module via the software’s CAP interface, transmitting data streams, control signals, and status indicators through the Linux driver layer and PCIe 2.0 x8 interface. This tight integration between software and hardware enables highly efficient data flow.

4.5. Quantitative Analysis of SM3-PRF Shuffling Algorithm

To validate the advantages of the SM3-PRF shuffling algorithm over traditional random permutation methods, we conducted quantitative analysis across three dimensions: computational complexity, security guarantees, and practical performance (see

Table 3. Quantitative Analysis of SM3-PRF Shuffling Algorithm.

Metric	Traditional Random Permutation	SM3-PRF Shuffling
Computational Complexity	$\mathit{O}\left(\mathit{N}log\mathit{N}\right)$	$\mathit{O}\left(\sqrt{\mathit{N}}\right)$
Security Level (bits)	$\mathit{N}log\mathit{N}$	256 (constant)
Throughput (MB/s)	45	3750
Cache Miss Rate	23.4%	7.8%
Side-channel Resistance	Low	High
Hardware Acceleration	NO	YES(RSP S20G)

). Traditional random permutation methods employ the Fisher–Yates shuffle algorithm, requiring $\mathit{O}\left(\mathit{N}log\mathit{N}\right)$ comparison operations to generate random permutations, whereas our SM3-PRF method directly computes index mappings through pseudorandom functions, requiring only $\mathit{O}\left(\sqrt{\mathit{N}}\right)$ hash computations. For a database of size $\mathit{N}={\mathit{2}}^{\mathit{20}}$, the traditional method requires approximately 20.97 million operations, while SM3-PRF requires only 1024 operations, representing a 20,450-fold reduction in computational overhead. From a security perspective, traditional random permutation security is constrained by the permutation space size, with security strength approximately N log N bits, which varies with database scale; in contrast, SM3-PRF maintains constant 256-bit security strength based on the SM3 hash function, regardless of database size variations. In practical performance testing using the RSP S20G hardware acceleration chip for SM3-PRF implementation, we measured a shuffling throughput of 3750 MB/s, representing an 83-fold improvement over traditional software implementation at 45 MB/s. Furthermore, the deterministic access pattern of SM3-PRF significantly reduces cache miss rates (from 23.4% to 7.8%) and effectively resists side-channel attacks through hardware-implemented constant-time operations. These quantitative results demonstrate that the SM3-PRF shuffling algorithm significantly outperforms traditional methods across all performance metrics while maintaining stronger security guarantees.

5. Security Analysis

The client’s query reveals no information about the index of the record being retrieved. Formally, a PIR scheme is defined to be $\left(\mathit{t},\mathit{ϵ}\right)$-secure if, for every probabilistic polynomial-time adversary ($\mathit{A}$) running in a time of, at most, $\mathit{t}$ for all database sizes ($\mathit{N}$), and for all indices $\mathit{i},\mathit{j}\in (\left[\mathit{N}\right]$), the following condition holds:

$$|Pr[\mathcal{A}({\mathit{1}}^{\mathit{N}},\mathit{qu})=\mathit{1}:(\mathit{st},\mathit{qu})\leftarrow \mathit{Query}\left(\mathit{i}\right)]-Pr[\mathcal{A}({\mathit{1}}^{\mathit{N}},\mathit{qu})=\mathit{1}:(\mathit{st},\mathit{qu})\leftarrow \mathit{Query}\left(\mathit{j}\right)]|\le \mathit{ϵ}$$

(17)

To demonstrate the security of the ShufflePIR scheme, it is necessary to establish that the client’s query reveals no information about the index of the retrieved record. This is formalized by proving that no probabilistic polynomial-time adversary can distinguish between queries for different indices with non-negligible probability. The proof is structured as follows:

• Security of the LWE-based Encryption:
  • In the scheme, the only public parameter that contains the private key (ss) is the public key $\mathit{b}$. Since $\mathit{A}$, $\mathit{e}$, and $\mathit{s}$ are sampled independently, the security of the LWE encryption scheme ensures that the components of $\mathit{b}$ are computationally indistinguishable from encodings of random matrices. The remaining parameters of the LWE encryption scheme are publicly shared, and it is computationally infeasible to exploit encodings of random values to compromise the security of the LWE encryption scheme (see Section 3.1). The LWE problem is widely believed to be computationally hard, implying that no polynomial-time adversary can feasibly recover the plaintext from the ciphertext without access to the secret key. Consequently, the encrypted queries generated by the client do not reveal any information about the queried indices to any third party.
• SM3-PRF Shuffling Algorithm:
  • During the preprocessing phase, the SM3-based pseudorandom function (PRF) shuffling algorithm randomly permutes the database indices, ensuring that the true query index is not transmitted to the server. The output of the pseudorandom function is computationally indistinguishable from a truly random index to any polynomial-time adversary. As a result, the shuffled indices stored in the master and replacement tables do not reveal any information about the original indices.

Consider an adversary ($\mathit{A}$) that interacts with both the client and the server in the ShufflePIR protocol. The goal of the adversary is to distinguish whether the client’s query corresponds to index $\mathit{i}$ or index $\mathit{j}$. The adversary’s view consists of the encrypted query ($\mathit{qu}$) and the server’s response ($\mathit{ans}$). The probability that the adversary correctly guesses the client’s queried index is modeled as follows:

$$\mathit{Pr}\left[\mathit{A}\left(\mathit{i},\mathit{qu}\right)\right]=\mathit{Pr}\left[\mathit{A}\left(\mathit{j},\mathit{qu}\right)\right]=\mathit{1}$$

(18)

Owing to the semantic security of the LWE-based encryption scheme and the pseudorandomness of the SM3-based pseudorandom function (PRF), the adversary’s distinguishing advantage is negligible with respect to any polynomial-time adversary. Let ${\mathit{Adv}}_{\mathit{A}}$ denote the advantage of adversary $\mathit{A}$ in distinguishing between queries corresponding to indices $\mathit{i}$ and $\mathit{j}$:

$${\mathit{Adv}}_{\mathit{A}}=\left|\mathit{Pr}\left[\mathit{A}\left(\mathit{i},\mathit{qu}\right)\right]-\mathit{Pr}\left[\mathit{A}\left(\mathit{j},\mathit{qu}\right)\right]\right|$$

(19)

Through the argument and the security properties of LWE and SM3-PRF, we show that ${\mathit{Adv}}_{\mathit{A}}\le \mathit{ϵ}$. Assume, for the sake of contradiction, that there exists a probabilistic polynomial-time adversary ($\mathit{A}$) such that ${\mathit{Adv}}_{\mathit{A}}\ge \mathit{ϵ}$; then, one could construct an efficient algorithm that solves the LWE problem, thereby contradicting the assumed hardness of LWE. Hence, no such adversary can exist, and the ShufflePIR scheme is $\left(\mathit{t},\mathit{ϵ}\right)$-secure under the LWE assumption.

In conclusion, the ShufflePIR scheme guarantees that the client’s query leaks no information about the index of the retrieved record, as formalized by the $\left(\mathit{t},\mathit{ϵ}\right)$-security definition (see Theorem 2). The security proof is based on the computational hardness of the LWE problem and the pseudorandomness of the SM3-based PRF, thereby offering strong guarantees against any probabilistic polynomial-time adversary.

6. Evaluation

6.1. Experimental Setup

The ShufflePIR protocol was implemented in approximately 1000 lines of Python. Query vectors were compressed during preprocessing, and the Regev matrix encryption was optimized to improve computational efficiency. Both server-side and online computations were executed on single-threaded configurations. The block size was set to $\sqrt{\mathit{N}}$, rounded up to the nearest power of two to enable efficient modular arithmetic, and the set size was calculated accordingly. The statistical security parameter ($\mathit{\kappa }$) was set to 40, and the computational security parameter ($\mathit{\lambda }$) was set to 128. The $\mathit{m}\mathit{1}$ parameter was adjusted to limit the failure probability of $\sqrt{\mathit{N}}$ queries to ${\mathit{2}}^{-\mathit{\kappa }}={\mathit{2}}^{-\mathit{40}}$, consistent with SpiralPIR [23]. To evaluate the performance of ShufflePIR, we conducted a series of experiments on a server equipped with an Intel Xeon E5-2680 v4 CPU (14 cores, 28 threads) and 128 GB DDR4 RAM running CentOS 7. The client device was a laptop with an Intel Core i7-10700K CPU and 32 GB RAM, connected to the server via a 10 Gbps Ethernet link. All cryptographic operations were implemented in Python3.2 using the Microsoft SEAL library (v4.1) for LWE encryption and the OpenSSL library (v1.1.1) for SM3-PRF computations. The primary dataset used in our experiments consists of simulated binary voice data, mimicking real-world speech recordings encoded in PCM format (16-bit depth, 44.1 kHz sampling rate) and compressed into binary streams. We generated four subsets with distinct data lengths to simulate varying scales of voice data:

• 256 B: Corresponding to ultra-short voice snippets (e.g., 0.03 s of speech), representing minimal voice data units such as keyword triggers in voice assistants;
• 30 KB: Corresponding to short voice clips (e.g., 3–5 s of speech), typical of voice messages in messaging applications;
• 100 KB: Corresponding to medium-length voice recordings (e.g., 10–15 s of speech), such as voice notes or short voice commands;
• 1 MB: Corresponding to long voice segments (e.g., 2–3 min of speech), representing extended recordings like conference snippets or interview excerpts.

For each subset, we generated $\mathit{N}={\mathit{2}}^{\mathit{20}}$ (1,048,576) records to simulate a large-scale voice database. To ensure statistical validity, all voice data was generated with random variations in pitch, amplitude, and background noise, avoiding uniform patterns that might bias performance metrics. Each scheme was executed ten times to collect data for table metrics such as throughput, and the average values were reported. The standard deviation of all throughput measurements was below 10 of the corresponding mean value. Our experiments focus on three main research questions:

RQ 1: Throughput serves as the primary performance metric in our evaluation. Under which database size configuration does ShufflePIR achieve its peak throughput?

RQ 2: How does the overall performance of ShufflePIR compare to that of existing PIR schemes?

RQ 3: How does ShufflePIR achieve a balance between minimal communication overhead and maximal throughput?

6.2. Impact of Database Configuration on Throughput

Initially, the maximum throughput of each PIR scheme was measured at its optimal database dimension. In

Table 4. Maximum throughput of each PIR scheme.

Scheme	Database Size $\mathit{N}\times \mathit{d}$		Max. Achievable Throughput/core (MB/s)
	N	d
Prior two-server PIR
DPF PIR [34]	${\mathit{2}}^{\mathit{25}}$	32 B	5381 MB/s
XOR PIR [26]	${\mathit{2}}^{\mathit{33}}$	1 bit	6067 MB/s
XOR PIR fast [26]	${\mathit{2}}^{\mathit{33}}$	1 bit	11,797 MB/s
Prior single-server PIR
SealPIR [25]	${\mathit{2}}^{\mathit{18}}$	30 KB	105 MB/s
MulPIR [28]	${\mathit{10}}^{\mathit{5}}$	40 KB	69 MB/s
FastPIR [27]	${\mathit{2}}^{\mathit{20}}$	1024 B	186 MB/s
OnionPIR [29]	${\mathit{2}}^{\mathit{15}}$	30 KB	149 MB/s
FrodoPIR [35]	${\mathit{2}}^{\mathit{15}}$	1 KB	1256 MB/s
Spiral [23]	${\mathit{2}}^{\mathit{14}}$	100 KB	333 MB/s
SpiralPack [23]	${\mathit{2}}^{\mathit{15}}$	30 KB	444 MB/s
SpiralStream [23]	${\mathit{2}}^{\mathit{15}}$	30 KB	874 MB/s
SpiralStreamPack [23]	${\mathit{2}}^{\mathit{15}}$	30 KB	1516 MB/s
ShufflePIR (Ours)	${\mathit{2}}^{\mathit{14}}$	1 MB	9903 ± 198 MB/s

Note: The database used in the evaluation is approximately 1 GB in size and consists of entries of varying sizes. For each scheme, the entry size corresponds to the largest value reported in the respective publication. The throughput of MulPIR is estimated, as no public implementation is currently available. For the proposed PIR scheme, the optimal entry size is determined empirically by evaluating various entry sizes and selecting the one that yields the highest throughput. Table 5 reports the optimal entry sizes and the corresponding throughput values for each scheme on a 1 GB database.

, the throughput of each scheme is reported for a database of approximately 1 GB. The corresponding entry sizes, denoted as N × d, are also provided in Table 4. For ShufflePIR, we conducted 30 independent trials to ensure statistical rigor. ShufflePIR achieved a throughput of 9903 ± 198 MB/s with a 95% confidence interval of [9831, 9975] MB/s, demonstrating excellent consistency, with a coefficient of variation of 2.0%. This represents approximately six times higher performance than the best-performing single-server PIR scheme for streaming settings (SpiralStreamPack).

ShufflePIR exceeded the per-server throughput of several earlier two-server PIR schemes. The two-server PIR protocol based on distributed point functions (DPFs) [34] achieves a throughput of 5.3 GB/s per core. To establish an upper bound on linear-work throughput, we benchmarked XOR PIR [26] in isolation. When each server performs a linear scan using XOR PIR over the entire database, the resulting two-server PIR throughput is 5.9 GB/s per core. If each server instead performs a linear scan over only half of the database, the throughput increases to 11.5 GB/s per core; however, this configuration requires a non-constant-time implementation.

Table 4 reveals three key insights: ShufflePIR achieves a 6.5× throughput improvement over existing schemes through parallel LWE encryption optimized for large records. Unlike competing schemes that peak at 30–100 KB records, our scheme excels with (≥1 MB) records, making it suitable for modern multimedia and scientific applications. ShufflePIR bridges the performance gap between single-server and two-server architectures, outperforming several multi-server solutions.

6.3. Comparative Analysis of Overall Performance

In

Table 5. Comparison of ShufflePIR with recent PIR schemes across various database configurations.

Scheme	SealPIR	FastPIR	OnionPIR	Spiral Family	ShufflePIR (Ours)
Param. Size	3 MB	1 MB	5 MB	16–24 MB	0.125–8 MB
Database: ${\mathbf{2}}^{\mathbf{20}}\times \mathbf{256}\mathrm{B}$ (268 MB)
Query Size	66 KB	33 MB	63 KB	16 MB	11.94 KB
Response Size	328 KB	66 KB	127 KB	71 KB	4.31 KB
Computation	3.19 s	1.44 s	1.69 s	0.42 s	0.00044 s
Rate	0.0008	0.0039	0.0122	0.0036	0.05939
Throughput	84 MB/s	186 MB/s	81 MB/s	635 MB/s	554 MB/s
Server Cost	$0.0000258	$0.0000107	$0.0000130	$0.0000036	$0.000004
Database: ${\mathbf{2}}^{\mathbf{14}}\times \mathbf{30}\mathrm{KB}$ (7.9 GB)
Query Size	66 KB	8 MB	63 KB	30 MB	11.94 KB
Response Size	3 MB	262 KB	127 KB	96 KB	35.29 KB
Computation	74.91 s	50.52 s	52.73 s	5.33 s	0.003964 s
Rate	0.0092	0.1144	0.2363	0.3117	0.85
Throughput	105 MB/s	156 MB/s	149 MB/s	1.48 GB/s	7250 MB/s
Server Cost	$0.0005550	$0.0003546	$0.0003683	$0.0000380	$0.0000036
Database: ${\mathbf{2}}^{\mathbf{14}}\times \mathbf{100}\mathbf{KB}$  (1.6 GB)
Query Size	66 KB	524 KB	63 KB	30 MB	11.94 KB
Response Size	11 MB	721 KB	508 KB	150 KB	108.2 KB
Computation	19.03 s	23.27 s	14.38 s	1.21 s	0.011769 s
Rate	0.0092	0.1387	0.1969	0.6677	0.92421
Throughput	86 MB/s	70 MB/s	114 MB/s	1.35 GB/s	8103 MB/s
Server Cost	$0.0002420	$0.0001692	$0.0001046	$0.0000099	$0.00000109

Note: All measurements were obtained using single-thread execution on the same computing platform. SealPIR and OnionPIR offer 115-bit and 111-bit post-quantum security, respectively, while the remaining schemes provide at least 128-bit security. Rate refers to the ratio of record size to response size. Throughput is defined as the ratio of server computation time to the database size. Server cost denotes the estimated monetary cost of processing a single query based on current AWS pricing [37].

, ShufflePIR is compared with existing systems across three representative database configurations: a database consisting of ${\mathit{2}}^{\mathit{20}}$ records of 256 bytes, commonly used as a PIR benchmark [27]; a medium-sized configuration with ${\mathit{2}}^{\mathit{18}}$ records of 30 KB, representing the optimal setup for OnionPIR [29]; and a configuration with ${\mathit{2}}^{\mathit{14}}$ records of 100 KB, representing a database with fewer but larger records. When record sizes are small, all LWE-based PIR schemes exhibit low rate efficiency due to the underutilization of space in LWE ciphertexts, which typically span several thousand bytes. Rate efficiency improves when the record size matches or exceeds the capacity of a lattice-based ciphertext, at which point it becomes inversely proportional to the ciphertext expansion factor. ShufflePIR outperforms previous single-server PIR schemes as a result of improved noise management, the use of Regev encryption, and matrix-parallel vector operations. For databases containing 30 KB and 100 KB records, ShufflePIR achieves a throughput that is at least 4.7 times higher than that of competing schemes, while also producing smaller response sizes. ShufflePIR also incurs the lowest cost under the AWS model in terms of both CPU and network usage. In the case of small records (256 bytes), ShufflePIR’s server throughput is surpassed only by Spiral, a stream-optimized scheme that requires query sizes approximately 1372 times larger than those of ShufflePIR. The primary limitation of ShufflePIR lies in its large public parameter size, which stems from the use of query compression tables; however, these parameters are reusable, enabling the amortization of communication costs over multiple queries.

Table 6. Performance comparison between ShufflePIR and the Spiral family under varying database configurations.

Database Configuration	Metric	ShufflePIR	Spiral Family
${\mathit{2}}^{\mathit{20}}\times \mathit{256}\mathrm{B}$	Rate	0.05939	0.0036
	Throughput (MB/s)	554	635
	Query Size (KB)	11.94	15,360
${\mathit{2}}^{\mathit{18}}\times \mathit{30}\mathrm{KB}$	Rate	0.85	0.3117
	Throughput (MB/s)	7250	1516
	Query Size (KB)	5.97	30,720
${\mathit{2}}^{\mathit{14}}\times \mathit{100}\mathrm{KB}$	Rate	0.92421	0.6677
	Throughput (MB/s)	8103	1382.4
	Query Size (KB)	1.49	30,720
${\mathit{2}}^{\mathit{14}}\times \mathit{1}\mathrm{MB}$	Rate	0.93404	0.7750
	Throughput (MB/s)	9903	1382.4
	Query Size (KB)	1.49	90,112

Note: Query sizes for the Spiral family are converted to kilobytes (KB) for consistency (e.g., 15 MB = 15,360 KB).

presents a performance comparison between ShufflePIR and the Spiral family across different database configurations. As record sizes increase from 256 B to 1 MB, the rate improves from 0.05939 to 0.93404, and throughput increases from 654 MB/s to 9903 MB/s, demonstrating the scheme’s scalability and efficiency for large data records. Query sizes vary slightly due to adjustments in record size. In contrast to state-of-the-art Spiral-family schemes, ShufflePIR does not require client-specific parameter tuning. It exhibits balanced performance across configurations and demonstrates a clear advantage in processing large records (over 30 KB), making it well-suited for a wide range of application scenarios.

6.4. Trade-Off Between Throughput and Communication Overhead

We configured a 1GB database with record sizes ranging from 1 to 10,000 bits. The communication cost per query, including the cost of downloading the hint, was amortized over 100 queries. Figure 2 presents the experimental results, demonstrating the performance improvements achieved by the proposed scheme. For databases with short records (1-bit and 10-bit), ShufflePIR demonstrates amortized communication costs comparable to the most efficient existing PIR schemes, including SpiralPack, Spiral, SealPIR, and OnionPIR. For databases with longer records (100-bit, 1000-bit, and 10,000-bit), ShufflePIR demonstrates a clear advantage in communication efficiency. SpiralStreamPack, the scheme with throughput closest to that of ShufflePIR, incurs significantly higher communication overhead.

Figure 3 presents the maximum achievable throughput and the minimum communication cost for various PIR schemes across different database configurations using a 1 GB database. The data points representing each scheme are positioned according to these two metrics. A greater Euclidean distance of a point from the origin indicates a more favorable trade-off between throughput and communication cost. The proposed scheme demonstrates that, as the record size increases and the number of data entries decreases, both throughput and amortized communication cost are improved. Importantly, ShufflePIR achieves higher throughput than all previously proposed single-server schemes. Moreover, after amortization, its communication cost is comparable to that of the most efficient schemes, demonstrating strong overall efficiency.

Figure 2 and Figure 3 confirm ShufflePIR’s Pareto-optimal position, simultaneously maximizing throughput while minimizing communication costs. Unlike existing schemes showing performance degradation with larger records, ShufflePIR demonstrates consistent improvement across all metrics as record sizes increase, ensuring future-proof scalability.

7. Conclusions

This paper presents ShufflePIR, a novel single-server PIR protocol based on the learning with errors (LWE) assumption. Built on the PIR framework proposed by Kushlevitz and Ostrovsky, ShufflePIR addresses key limitations of existing schemes, including the requirement for client-specific preprocessing and dependence on large-scale storage. Its LWE-based encryption scheme enables efficient matrix encryption and decryption in a single operation, outperforming the standard Regev scheme for large-scale databases. By integrating the SM3 pseudorandom function into the shuffling algorithm, along with client-side preprocessing of size $\sqrt{\mathit{N}}$ and hardware-accelerated SM3 shuffling, ShufflePIR improves processing speed and enhances resistance to physical and side-channel attacks. Experimental results demonstrate that ShufflePIR achieves a high throughput of 9903 MB/s on a 16 GB-scale database with 1 MB entry size, surpassing existing single-server PIR schemes and outperforming certain two-server PIR schemes in per-server throughput. Its security is formally proven to achieve $\left(\mathit{t},\mathit{ϵ}\right)$ security, relying on the computational hardness of LWE and SM3-based preprocessing, thereby ensuring query privacy. One limitation is that clients are required to download the database to enable PIR functionality, although this cost can be amortized across multiple queries. Future work will focus on optimizing parameter sizes, reducing client-side preprocessing, and exploring broader application scenarios.