BRASP: Encrypted Boolean Range Queries
- BRASP is a searchable encryption scheme for Boolean range queries over encrypted spatial data that uses Hilbert-curve prefix encoding and encrypted inverted indexes.
- It employs a dual-server architecture with index shuffling and ID-field redistribution to hide both search and access patterns while supporting dynamic updates and forward security.
- Experimental results show that BRASP outperforms comparable systems in key phases by reducing CPU cost despite a modest increase in communication overhead.
BRASP is a searchable encryption scheme for Boolean range queries over encrypted spatial data. It is defined for an outsourced spatio-textual database in which the data owner holds , with , , and , and a Boolean range query asks for
The scheme targets the standard leakage problem in efficient searchable encryption: most practical constructions leak the search pattern and access pattern, which may allow an honest-but-curious cloud server to infer query contents, user interests, or returned records. BRASP addresses this setting by combining Hilbert-curve-based prefix encoding with encrypted prefix-ID and keyword-ID inverted indexes, and by using a dual-server design with index shuffling and ID-field redistribution to hide both search and access patterns while supporting dynamic updates and forward security (Zhang et al., 9 Apr 2026).
1. Problem formulation and threat model
The BRASP problem setting is explicitly spatio-textual. Each object couples a two-dimensional location with a keyword set, and query semantics are conjunctive across the spatial and textual dimensions: an object matches only if its location lies in the query range and the query keyword set is contained in the object’s keyword set.
The privacy objectives are stated in two distinct forms. Search-pattern privacy requires that an adversary should not learn whether two trapdoors correspond to the same . Access-pattern privacy requires that an adversary should not learn which encrypted objects match each query beyond what can be simulated from the mandatory leakage. These two goals are central because repeated searches and observable result behavior are precisely the channels through which efficient searchable encryption systems often become vulnerable.
The adversary model is a dual-server one. BRASP assumes two non-colluding honest-but-curious cloud servers, and 0. The data owner and authorized clients are trusted. 1 and 2 each observe their local encrypted indexes, shuffled states, received trapdoors, partial decryptions, and inter-server messages, but do not collude. This suggests that BRASP trades a stronger deployment assumption—non-collusion—for stronger privacy against single-server observation (Zhang et al., 9 Apr 2026).
2. System architecture and end-to-end workflow
BRASP involves four parties: the Data Owner (DO), an Authorized Client, and two cloud servers 3 and 4. The DO builds and encrypts indexes, holds master keys, and authorizes clients. The Authorized Client holds a client key 5, generates query and update tokens, recovers results, and triggers index redistribution. Each cloud server stores one share of the encrypted prefix-ID and keyword-ID indexes plus the encrypted object set.
| Party | Held or stored material | Role |
|---|---|---|
| Data Owner | master keys | builds and encrypts indexes; authorizes clients |
| Authorized Client | client key 6 | generates query/update tokens; recovers results; triggers index redistribution |
| 7 | one share of encrypted indexes and encrypted object set | search, partial decryption, shuffle participation |
| 8 | one share of encrypted indexes and encrypted object set | search, partial decryption, shuffle participation |
The system workflow is staged. In DO.Setup, the DO generates a TPF key 9, a TUR key pair 0, partial TUR keys 1, and shuffle-seeds 2. In DO.EncryptedIndexBuild, the DO builds two shared inverted indexes 3 on 4 and 5 on 6. Before any search and after each search or update, 7 re-randomizes and permutes both indexes. The client then runs TokenGeneration for a query 8, producing trapdoors 9 that are sent to both servers. During Search, the servers perform partial decryptions and bitmap intersections and return encrypted result shares to the client. The client recovers 0 and triggers IndexRedistribution to refresh ID-field shares. Updates are handled through client-generated 1, which 2 apply in a forward-secure way (Zhang et al., 9 Apr 2026).
A notable systems property is that the shuffle is not an occasional maintenance step; it is part of the privacy-preserving lifecycle. The index state is refreshed before any search and after each search or update, so the storage structure itself becomes stateful.
3. Hilbert-curve encoding and encrypted inverted indexes
BRASP reduces two-dimensional spatial filtering to prefix matching by means of a Hilbert mapping. For a fixed curve order 3, the unit square is divided into 4 cells, and
5
maps each point 6 to a single integer Hilbert value 7. Writing the 8-bit binary representation of 9 as 0, BRASP defines the prefix family
1
where 2 is a wildcard bit.
For a target Hilbert interval 3, BRASP computes the minimal set of prefixes 4 such that
5
A point with value 6 lies in the range iff
7
This is the scheme’s core geometric reduction: range membership is transformed into prefix-family overlap.
The plaintext indexing layer contains two bitmap-based inverted indexes. The prefix-ID index is
8
where 9 is a prefix string and 0 with 1 iff 2 matches 3. The keyword-ID index is
4
where 5 is a plaintext keyword and 6 iff keyword 7.
Encryption is split across labels and bitmaps. TPF, the Tailored Proxy PRF, is used for labels: 8, 9, and 0 moves 1 under a new key without touching 2. TUR, the Tailored Universal Re-encryption, is used for bitmaps: 3, 4, 5, 6, 7 a partial decryption, and 8.
In encrypted index construction, for each 9, BRASP computes 0 and 1, then stores 2 in 3; the keyword index is handled analogously. This decomposition separates searchable labels from encrypted bitmap payloads and enables later shuffling and re-randomization without reconstructing plaintext indexes (Zhang et al., 9 Apr 2026).
4. Query execution and dual-server pattern hiding
Query execution begins with prefix-cover computation. For a Boolean range query 4, the client computes 5. For each 6, the client computes
7
and performs the same procedure for each 8, yielding 9 and 0.
On the server side, 1 first transforms client trapdoors into master-key space. For each 2, it computes 3, finds the matching 4 entry by label equality, and applies 5 to the corresponding encrypted ID bitmap. It performs the same steps for keywords and sends the resulting partial decryptions to 6. 7 completes decryption of the bitmap shares, uses them to locate matching encrypted objects, unions prefix matches, intersects keyword matches, and returns the encrypted object-ID list. The final server-side result structure is
8
The client then recovers and decrypts the returned encrypted objects (Zhang et al., 9 Apr 2026).
Pattern hiding is reinforced by a separate index-shuffling protocol. Its purpose is twofold: the same 9 or 0 should lead to a fresh, unlinkable label after each shuffle, and ID bitmaps should be re-randomized and remapped so that the cloud cannot link which bitmap it saw before and after. On the 1 side, the high-level protocol takes its index shares 2 for 3, sends them to 4, and has 5 re-encrypt labels with 6, re-randomize the ID ciphertexts with TUR, increment the entry state, randomly permute all entries, and return the resulting structures. 7 then re-encrypts again with 8, re-randomizes the ciphertexts again, increments the state again, and applies a fresh permutation to obtain the new shuffled index shares.
No zero-knowledge proofs are used. Privacy relies on TPF for pseudorandom labels, TUR for re-rando Paillier, random shuffles, and split-bitmap secret sharing. This design choice is operationally significant because it places the privacy burden on re-encryption, permutation, and server separation rather than on proof-carrying query execution (Zhang et al., 9 Apr 2026).
5. Security properties and formal analyses
BRASP is formalized through confidentiality, shuffle indistinguishability, query unforgeability, and forward security. The confidentiality statement is given as Theorem 1: for any PPT adversary controlling one server, there exists a simulator 9 with only leakage 00 such that
01
The proof sketch is a hybrid argument replacing TPF outputs and TUR ciphertexts by truly random ones consistent with leakage.
Shuffle indistinguishability is formulated as a separate notion. After a shuffle, any adversary’s advantage in linking a post-shuffle entry 02 to its pre-shuffle origin 03 is negligible. The informal theorem states that if TPF and 04 are pseudorandom or unlinkable, then shuffle is indistinguishable. The proof sketch is correspondingly direct: 05 and 06 produce unlinkable outputs, and random permutation erases positional information.
Query unforgeability appears as Theorem 3. No PPT adversary can forge a valid trapdoor for an unissued query with non-negligible probability. The stated intuition is that a successful forgery would imply either a TPF collision or a break of pseudorandomness.
Forward security is captured in Theorem 4. After an update, previous transcripts do not help link the new entries to past queries. The proof sketch attributes this to state-dependent update tokens and new TUR ciphertexts that are re-randomized and therefore unlinkable from past observations (Zhang et al., 9 Apr 2026).
Taken together, these properties characterize BRASP not merely as an efficient encrypted search structure, but as a stateful dual-server SE system whose privacy guarantees are explicitly tied to re-randomization and non-collusion.
6. Experimental results, limitations, and acronym ambiguity
The experimental evaluation uses the Yelp business dataset with approximately 07K objects and an implementation in Python 3.12 on an AMD Ryzen 5 3500U with 16 GB RAM. The baselines are 08 and PPSKS, and the reported metrics are computation time and communication volume for Index Build, Token Generation, Search, and Update.
The reported results are phase-specific. For Index Build, BRASP is approximately 09–10 faster than the baselines. For Token Generation, BRASP scales linearly in query-size and has the lowest cost. For Search, BRASP reduces server-side computation by 11–12, while communication overhead is slightly higher due to shuffle. For Update, cost grows linearly with update size, and the overhead is dominated by TUR re-encryptions. The overall comparison states that BRASP outperforms 13 and PPSKS in all four phases, while trading a modest extra communication during search and shuffle for much lower CPU cost. The source code is publicly available at the repository specified by the authors, which is relevant for reproducibility and follow-on systems work (Zhang et al., 9 Apr 2026).
The stated limitations are also specific. Current schemes assume non-collusion, so extending to 14 servers or threshold collusion models is open. The Hilbert-curve prefix encoding imposes 15 fixed order, and adaptive multi-resolution indexing could improve locality or range overlap. There is no support yet for 16-nearest-neighbor or circular range queries. All cryptographic workloads rely on Paillier-based TUR, and exploring lighter-weight additively homomorphic primitives such as elliptic-curve ElGamal could reduce update cost. Integrating verifiability, in the sense of proofs of correct search, without destroying pattern privacy is identified as an important direction.
A separate source of ambiguity is terminological rather than cryptographic. In reliability-sampling literature, BRASP is also used to denote a Bayesian reliability acceptance sampling plan under adaptive accelerated testing with competing risks and type-II censoring (Das et al., 31 Jul 2025). Closely related work under adaptive SSSPALT with Type I censoring uses the term BSPAA rather than BRASP (Das et al., 2024). In the searchable-encryption context, however, BRASP refers specifically to Boolean range queries over encrypted spatial data under access and search pattern privacy.