How encrypted search works

UniClipboard's privacy baseline is simple: clipboard history is encrypted at rest, and the search index is encrypted too.

There is no plaintext clipboard content saved anywhere on disk. For the storage details behind the index, see “Sync content — Local storage”.

That raises the practical question: if the content is encrypted, how can the search box still find words inside it?

How the index is built

UniClipboard uses a “tokenize → HMAC tokenization → inverted index” pipeline:

1. Content is normalized with NFKC, lowercased, and split by Unicode word boundaries.
2. Each token is transformed with HMAC-SHA256(SearchKey, token) into a 32-byte term tag.
3. The inverted index stores the term tags, not the original text.

SearchKey is derived from the space MasterKey with HKDF-SHA256. Each space has its own key. The MasterKey lives in the system keyring, so it does not leave the local machine.

That means even if someone copies the index file, all they see is a set of HMAC outputs. Those outputs are not reversible, so they cannot be used to recover the original tokens.

How matches work

A query goes through the same tokenization and HMAC pipeline. A result matches only when the complete term tag matches.

For hello world:

Query	Matches hello world
hello	✅
world	✅
hello world	✅ — both term tags must match
hel	❌
ello	❌

hel does not match hello because HMAC transforms the whole input. Change one character and the output changes completely. There is no prefix relationship between hel and hello in term-tag space.

The boundary: no arbitrary substring search in body text

For body text, substring search does not work; you need complete words.

That is the trade-off of encrypted search. If UniClipboard allowed arbitrary substring matching, the index would need to preserve plaintext-like “cracks” that can leak information — for example, indexing every n-gram or storing comparable plaintext prefixes. That would weaken the point of encrypting the index.

UniClipboard makes two targeted compromises so search remains usable:

Identifier fields support prefix expansion

For identifier-like fields such as filenames, URLs, and paths, UniClipboard indexes prefixes of each token with length ≥ 3. Each prefix still becomes its own term tag.

So searching uniclip can match the filename uniclipboard.dmg, and searching localh can match the URL localhost:3000.

This is only enabled for identifier fields. Large body text does not use prefix expansion because it would make the index too large.

Chinese text uses bigrams

Chinese text is indexed with overlapping two-character bigrams. 你好世界 becomes 你好 / 好世 / 世界, and each bigram is stored as a term tag.

So searching 好世 can match 你好世界, and 你好 works too. Single-character search inside Chinese phrases does not work because the index does not store single-character terms.

What this means in daily use

What you want to find	Recommended query
A command containing prod	Search prod, not pro
A filename containing report	Search report, or prefixes like rep / repo
A Chinese phrase	Use at least two consecutive characters, such as 合同, not 合
An English word you cannot spell exactly	Try a shorter but still complete token, then narrow by type or time

For more query options, see “Full-text search — Query syntax”.