Private Information Retrieval

Let a client retrieve record i from a server-held database without revealing i to the server. PIR is a generic primitive: it applies wherever the index of a lookup is itself sensitive. Concrete cases in this map include fetching a Merkle inclusion path or an incoming note from a shielded-pool indexer, querying a market-data or order-book service for a specific instrument, and looking up a regulatory-directory entry whose identity would otherwise leak intent.

Works best when

  • The index of a lookup is itself sensitive (e.g., which note, which order book entry, which directory record).
  • The queried database is operated by a counterparty, a shared indexer, or any party that should not learn intent.
  • An integrity anchor exists alongside the database (on-chain state root, signed snapshot) so responses can be verified.

Avoid when

  • The client already replicates the database locally; running an own indexer closes the leak without PIR.
  • Network-layer metadata (timing, IP) is the dominant exposure; address that first with [pattern-network-anonymity](pattern-network-anonymity.md).

I2I vs I2U — context differences

Institution to institution

I2I

An institution uses PIR to query a counterparty- or third-party-held database (market data, order books, RFQ venues, regulatory directories) without revealing which records it cares about. For replicable public data such as Ethereum state, the institution can also sidestep PIR by hosting its own indexer; PIR is then defence-in-depth rather than the primary mitigation.

Institution to end user

I2U

End users depend on third-party RPC and indexers and cannot replicate large databases locally. PIR is the load-bearing mitigation whenever a lookup index would leak intent (the specific note about to be spent, the directory entry being scanned).

Post-quantum exposure

Risk · low
Vector
Classical DDH-based PIR schemes are broken by a CRQC; HNDL risk on any encrypted query payloads built from EC primitives.
Mitigation
Use lattice-based PIR (SimplePIR, DoublePIR, FrodoPIR, Respire, InsPIRe). See Post-Quantum Threats.

Components

  • Client query encoder, which produces an encrypted query for index i under a lattice scheme.
  • Server, which evaluates the query against the full database. Single-server schemes carry the entire compute cost; multi-server schemes split it across non-colluding parties.
  • Database snapshot or stream, indexed in a form the scheme expects (flat array, tree, sharded layout).
  • Integrity anchor appropriate to the database: an on-chain state root and light client for replicated chain data, a signed snapshot or transparency log for off-chain data.
  • Client-side application keys that govern which queries get issued (for example, the viewing key used to identify the leaf whose path is being retrieved).

Protocol

  1. server Publish or snapshot the indexed database; commit to it via the integrity anchor.
  2. user Identify the target index i from local state (note identifier, instrument identifier, directory key).
  3. user Encrypt a PIR query for i under the scheme's public parameters and send it to the server.
  4. server Compute the response over the entire database without learning i, and return it.
  5. user Decrypt the response to recover the record.
  6. user Verify the record against the integrity anchor (Merkle proof against the on-chain root, signature on the snapshot) before acting on it.

Guarantees & threat model

Guarantees:

  • The server learns that a query was issued, the time, and aggregate query rate, but not which record was retrieved.
  • Privacy reduces to a standard lattice assumption (LWE or RLWE) for modern schemes.
  • Composes with any integrity layer that can attest to the database contents.

Threat model:

  • Hardness of the underlying lattice problem.
  • Correctness of the integrity anchor. PIR alone does not authenticate the response; a malicious or buggy server can return arbitrary records unless verification is performed against the anchor.
  • Non-collusion between servers in multi-server schemes.
  • Network-layer metadata (IP, timing, query rate) is out of scope and requires pattern-network-anonymity.

Trade-offs

  • Server compute scales (sub)linearly with database size per query. PSE benchmarks of Respire against tree-shaped state on r7i.8xlarge report seconds at 2²¹ records and minutes at 2²⁵, before any application-level batching or sharding.
  • Single-server schemes concentrate cost on one operator and require trust that the operator runs the scheme honestly; multi-server schemes split cost but add a non-collusion assumption.
  • Client bandwidth and compute are modest with modern schemes (hundreds of bytes per query, milliseconds of work) and rarely the binding constraint.
  • PIR alone does not authenticate responses; designs must pair it with an integrity anchor.
  • Applicability sidestep: when the database is publicly replicable, an operator can host its own copy and skip PIR. For counterparty-held or external databases the sidestep does not apply; PIR remains the cryptographic option.
  • Adjacent primitives cover scenarios where the client does not know the index. Oblivious Message Retrieval (OMR) handles private message detection on a bulletin board; Fuzzy Message Detection (FMD) gives a probabilistic, cheaper variant. They are not interchangeable with PIR but solve a neighbouring problem.

Example

  • Recipient of a shielded note: the wallet fetches Merkle siblings for the recipient's leaf via PIR against the pool indexer. The indexer learns that a query happened but not which leaf. The wallet verifies the path against the on-chain pool root before constructing the spend proof.
  • Institutional market-data query: a desk fetches a quote or order-book level for a specific instrument from a shared venue without revealing which instrument it cares about, preventing the venue (or anyone able to read its query log) from inferring trading intent.

See also

Open-source implementations

Last reviewed 2026-05-15