The Problem with Traditional Search
Search is one of the most fundamental operations in computing. Every healthcare system that looks up a patient record, every law firm that queries a document repository, every financial institution that scans transactions for fraud — all of them depend on search. And in every case, the standard approach requires data to be decrypted before it can be searched.
This creates a structural vulnerability that no amount of perimeter security can solve. You can encrypt data at rest with AES-256. You can encrypt it in transit with TLS 1.3. But the moment a server needs to find a matching record, it decrypts the data into memory, runs the comparison in plaintext, and returns results. During that window — however brief — the data is exposed. The search query itself is exposed. A compromised server, a rogue administrator, or a memory-scraping attack can capture everything.
Traditional database encryption protects data at rest and in transit. But search requires decryption. If an attacker compromises the server during a query, they see both the search terms and every record scanned to produce results. Encrypting the disk doesn't help — the computation itself is the exposure point.
This isn't a theoretical concern. Data breaches increasingly target data in use — the brief period when information must be unencrypted for processing. According to the Verizon Data Breach Investigations Report, compromised servers and insider threats account for the majority of healthcare and financial services breaches. The common thread: data had to be decrypted so the system could do something useful with it.
What Is Encrypted Search?
Encrypted search is the ability to query data without ever decrypting it. The search query is encrypted on the client. The data being searched is encrypted on the server. The matching, comparison, and ranking operations all happen on ciphertext — encrypted data — using fully homomorphic encryption (FHE). The server performs the search computation without learning what was queried, what was matched, or what the underlying data contains.
FHE is the enabling technology. Unlike traditional encryption where ciphertext is opaque and inert, homomorphic encryption preserves algebraic structure. You can add encrypted values and get the encryption of the sum. You can multiply encrypted values and get the encryption of the product. These two operations — addition and multiplication — are computationally complete. Any function that can be expressed as a combination of additions and multiplications can be evaluated on encrypted data without decryption.
Search, at its core, is a sequence of comparisons. Does this encrypted field match this encrypted query? Is this encrypted vector similar to this encrypted vector? These comparisons can be constructed from the addition and multiplication primitives that FHE provides. The result is a search system where the server is mathematically incapable of seeing the data it processes.
How It Works: Three Stages
H33's encrypted search pipeline operates in three stages. Each stage maintains end-to-end encryption. At no point in the pipeline does plaintext data exist on the search server.
Stage 1: Encrypt and Index
Before any data reaches the search infrastructure, it is encrypted on the client using either BFV or CKKS — two FHE schemes optimized for different workloads. BFV (Brakerski/Fan-Vercauteren) operates on exact integers and is used for keyword matching, field comparisons, and boolean logic. CKKS (Cheon-Kim-Kim-Song) operates on approximate real numbers and is used for similarity search, vector embeddings, and nearest-neighbor queries.
The encrypted data is then indexed server-side. The server builds inverted indexes, B-tree structures, and hash maps — but all operating on ciphertext. The server organizes the data for efficient retrieval without ever seeing what the data represents. An encrypted inverted index maps encrypted terms to encrypted document IDs. An encrypted B-tree orders encrypted values for range queries. The index structures are identical in design to traditional database indexes; the difference is that every value they contain is a ciphertext.
Stage 2: Encrypted Query Execution
When a user searches, the query is encrypted client-side using the same FHE parameters as the indexed data. The encrypted query is sent to the server, which performs FHE operations to match the encrypted query against the encrypted index.
For keyword search, the server evaluates an encrypted equality function: does this encrypted query term match this encrypted index entry? The comparison is performed using FHE multiplication and addition — the server computes the result in ciphertext without knowing what the query term is or what the index entries contain. Boolean operators (AND, OR, NOT) are composed from the same FHE primitives, enabling compound queries like "encrypted term A AND encrypted term B NOT encrypted term C" — all evaluated without decryption.
For similarity search, the server computes encrypted cosine similarity between the encrypted query vector and encrypted document vectors using CKKS approximate arithmetic. The server can rank results by similarity score without ever seeing the vectors themselves. This enables semantic search, recommendation systems, and nearest-neighbor retrieval — all operating on data the server cannot read.
Stage 3: Encrypted Results
The search results are returned as ciphertexts. The server knows which encrypted records matched (by position in the encrypted index), but cannot read the content of those records or the relevance scores it computed. Only the data owner, holding the secret key, can decrypt the results on their client device.
The entire round trip — encrypted query in, encrypted results out — means the search server operates as a pure computation engine. It stores encrypted data, executes encrypted logic, and returns encrypted answers. The privacy guarantee is not based on access controls, network segmentation, or trust assumptions. It is based on the mathematical hardness of the Ring Learning With Errors (RLWE) problem — the same lattice problem that secures post-quantum cryptography.
Why This Matters for Privacy
The implications of encrypted search extend far beyond technical architecture. It fundamentally changes the trust model between data owners and the systems that process their data.
Healthcare: HIPAA Without the Exposure Window
Healthcare systems process billions of searches annually against patient records, lab results, imaging data, and prescription histories. Under HIPAA, this data must be protected — but "protected" has historically meant encrypted at rest and encrypted in transit, with a decrypt-in-memory exception for processing. Encrypted search removes the exception. A hospital system can search patient records for drug interactions, query lab results for abnormal values, and scan imaging metadata for diagnostic patterns — without the server ever holding plaintext patient data. The compliance burden shrinks because the exposure surface shrinks to zero.
Legal and E-Discovery: Privileged Data Stays Privileged
Legal discovery requires searching through millions of documents to find relevant evidence. The documents frequently contain attorney-client privileged communications, trade secrets, and sealed court records. Today, e-discovery platforms decrypt these documents into memory to run keyword searches and relevance scoring. Encrypted search allows the same queries to run on ciphertext. A litigation support team can search for specific terms across a document repository without the hosting provider having access to either the search terms or the documents. Privilege is maintained cryptographically, not procedurally.
Financial Services: Search Without Surveillance
Banks and financial institutions are required to monitor transactions for fraud, money laundering, and sanctions violations. These monitoring systems scan every transaction against watchlists, behavioral models, and historical patterns. With encrypted search, a compliance system can query encrypted transaction logs against encrypted watchlists — flagging matches without exposing the underlying transaction data or the watchlist entries to the server infrastructure. This reduces insider threat risk and limits the blast radius of any server compromise to zero usable data.
The Broader Principle: Computation Without Knowledge
The philosophical shift is significant. For decades, the assumption has been that a computer must "see" data to process it. Encrypted search proves that assumption wrong. A server can search, sort, compare, and rank data it cannot read. This has immediate practical consequences for any organization subject to GDPR, CCPA, HIPAA, SOX, or ITAR — because encrypted search means data processors can process data without becoming data viewers. The regulatory distinction between processing and accessing collapses when the processor is mathematically unable to access the underlying values.
Traditional Search vs. Encrypted Search
| Property | Traditional Search | Encrypted Search (FHE) |
|---|---|---|
| Data at rest | Encrypted (AES) | Encrypted (BFV/CKKS) |
| Data during search | Decrypted in memory | Never decrypted |
| Search query visibility | Server sees query | Server sees ciphertext |
| Results visibility | Server reads results | Server returns ciphertext |
| Insider threat surface | Full plaintext access | Zero plaintext access |
| Breach exposure | All queried records | Ciphertext only |
| Regulatory model | Trust-based access controls | Mathematically enforced privacy |
Where Encrypted Search Goes from Here
Five years ago, FHE was a theoretical curiosity — functional but orders of magnitude too slow for production workloads. That gap has closed dramatically. Hardware acceleration, algorithmic improvements like NTT-domain optimizations and batched operations, and purpose-built parameter selection have brought FHE computation to practical latencies. H33's FHE engine processes encrypted operations at microsecond-scale on commodity hardware — no specialized chips required.
The trajectory is clear. As FHE performance continues to improve and as regulatory pressure around data privacy intensifies globally, encrypted search will transition from a differentiating capability to a baseline expectation. Organizations that adopt it early gain both the security advantage and the compliance advantage. Organizations that wait will eventually be forced to adopt it — the same way TLS went from optional to mandatory over the last decade.
The question is no longer whether you can afford to search over encrypted data. It's whether you can afford not to.