Blind Routing

Sensitive relationships — document ownership, grant associations, and entity memberships — are stored as blind cryptographic tokens rather than plaintext foreign keys. The application server can compare tokens for authorized lookups, but a database read does not reveal the underlying relationship graph.

The Problem With Traditional Identifiers

In typical applications, databases use straightforward identifiers — user IDs, document IDs, grant IDs. These make it trivial for anyone with database access to answer questions like:

• "Which documents does this user own?"
• "Who shared this document with whom?"
• "Which organization does this person belong to?"

Even with document content encrypted, these associations are themselves sensitive information. Knowing that User A shared Document B with User C reveals a relationship — without reading the document.

How Blind Routing Works

Instead of storing plaintext foreign keys, persistent records store blind tokens — one-way cryptographic values derived from scoped key material and the underlying relationship identifiers. The application server can match tokens for equality but cannot reverse them to recover the original identifiers or reconstruct the relationship graph.

Design Boundary

Blind routing primarily protects data at rest. Persistent storage avoids plaintext relationship columns for sensitive relationships.

It does not mean every request is anonymous. API path parameters may use server-assigned UUIDs for routing, and the application server may observe authenticated sessions, timing, request paths, statuses, and token equality.

The goal is narrower and important: a database dump should not reconstruct who owns which documents, who shared with whom, or which people belong to which organizations.

Relationships Protected By Blind Routing

Document Ownership

Documents are stored against blind ownership and document tokens rather than plaintext user-document foreign keys. The server can match tokens to authorize an owner-scoped operation, but cannot reconstruct an owner-to-documents map by reading the table.

Grant Relationships

Grants reference grantor and document via blind tokens, and each claimed grant carries a per-grant claim token derived from the grantee’s own key material. Because the claim token is unique per grant, the server cannot link multiple claims back to the same plaintext recipient.

Search Indexes

Search rows store blind index tokens scoped by key material rather than plaintext field values or document identifiers. The application server can match query tokens against stored tokens for equality, but cannot recover the plaintext value that produced either side. Organization-scoped search uses entity-scoped key material, so personal and organization tokens for the same plaintext value do not match.

Entity Membership

Membership rows reference the entity, the membership, and the user via blind tokens, alongside an encrypted member identifier sealed inside the enclave and bound to the specific entity. The server can match tokens to route an authorized membership operation, but a database read does not reveal which people belong to which organizations.

Anti-Oracle Behavior

Blind routing also affects API behavior. Sensitive lookup routes avoid distinguishing “missing” from “not authorized,” because different responses would let attackers probe for valid tokens.

For route-specific behavior, see Error Handling.

What A Database Breach Reveals

With blind routing, a database breach reveals ciphertext, opaque tokens, timestamps, and token equality, but not plaintext user-document, grantor-grantee, or member-organization relationships.

Related Concepts

• Zero-Knowledge Model — the trust-boundary foundation blind routing lives inside.
• Key Hierarchy — the keys used to derive blind tokens.
• Grants & Sharing — how blind tokens enable consent-based document sharing.
• Encrypted Search — how blind indexes support search without revealing terms.
• Account Recovery — how blind tokens are rotated when key material changes.

Last updated on