Encrypted Search

How Literal matches encrypted search tokens without exposing plaintext search terms or document contents.

Encrypted search lets the application server match opaque search tokens without learning the underlying search terms or document plaintext.

The Problem With Traditional Search

Traditional KYC systems often need to search, filter, or reprocess sensitive document data. In most systems, that means the application server can read document metadata, extracted fields, or OCR text.

Literal separates search from plaintext access. The server can match encrypted search tokens, but it does not receive the underlying search terms or document contents.

How Encrypted Search Works

Search uses blind indexing: searchable values and queries are transformed into one-way blind index tokens before reaching the server. The server compares tokens for equality but cannot reverse a token to see what it represents.

Loading diagram…

Encrypted search summary

Search uses blind index tokens. Clients and enclaves generate opaque tokens from searchable values. The application server stores and compares those tokens for equality, then returns encrypted matching records. It can see that tokens match, but not what plaintext value produced them.

How Tokens Are Created

Blind index tokens are generated in two paths.

Personal Indexes

Personal indexes are generated by the document holder’s client. The client normalizes the text, derives tokens using personal search key material, and submits them to the application server. Plaintext never leaves the client. The API may refer to these as consumer indexes (POST /v1/documents/consumer-indexes).

Organization Indexes

Organization indexes are generated inside the secure enclave when a document enters an organization-scoped context. The enclave derives tokens using organization-scoped search key material and returns only the opaque token values. Plaintext never leaves the enclave.

Both paths produce the same token format. The application server stores them and can compare them for equality, but cannot reverse them to recover the original text.

Search Time

When a client searches:

The client transforms the search query into a token using the same search key and normalization step.
The token is sent to the application server.
The server compares the query token against stored tokens for equality.
Matching documents are returned — still encrypted.

The application server sees only opaque tokens moving in both directions. It cannot determine what plaintext value produced a given token.

Search Scopes

Search tokens are scoped by key material.

Personal Search

Personal search uses the document holder’s personal search key. Only a client with that key can generate matching query tokens.

Organization Search

Organization search uses organization-scoped key material derived inside the secure enclave. Members with authorized access can search the organization’s shared document pool.

The same plaintext value produces different tokens in different scopes, which prevents the application server from correlating personal and organization searches by token value.

A document is searchable within a scope once blind index tokens exist for that scope — processing status alone does not guarantee it.

What Can Be Indexed

Literal can create search tokens for several categories of document information:

Document type — the kind of document (for example, a passport or a driver’s license).
Document fields — specific pieces of information extracted from the document, such as a name or date of birth.
Dates — date-based values attached to the document.
Tags — labels applied to organize documents.
Text content — words and phrases extracted from the document itself.

Each category is tokenized independently. A search request can target a specific category or search across all of them.

What The Application Server Learns

That a search was performed (it receives the request).
How many results matched the query token.
Which encrypted documents correspond to the matching tokens.
Repeated use of the same token within a scope — the server can observe that two requests produced the same token, but it cannot determine the plaintext value behind that token.

What The Application Server Does Not Learn

What plaintext value was searched.
What the matching documents contain.
Why those particular documents matched.
Whether two different plaintext values are semantically related.
The plaintext identity represented by search-scope tokens; membership and ownership are represented through opaque tokens rather than plaintext foreign keys.

Token Properties

Blind index tokens have several important properties:

Deterministic — the same input always produces the same token, which is what makes matching work.
One-way — a token cannot be reversed to recover the input.
Key-bound — tokens generated with different search keys do not match, even for the same input. Personal tokens and organization tokens are independent.
Normalized — text is processed through a consistent normalization step before token generation, so searches are case-insensitive and handle common text variations.

Anonymous Document References

Search indexes do not store plaintext document identifiers. They store blind document tokens that let the application server connect a matching search token to an encrypted document record without storing sensitive relationship identifiers.

See Blind Routing for the broader relationship-tokenization model.

Zero-Knowledge Model — the trust-boundary foundation that encrypted search lives inside.
Key Hierarchy — the search keys used for token generation.
Document Lifecycle — how documents move from upload through processing to becoming searchable.
Blind Routing — how sensitive relationships are tokenized to prevent relationship mapping.

Last updated on

On this page