Zero-Knowledge Architecture

Key terms and concepts behind the platform's zero-knowledge architecture — how sensitive data stays encrypted and private across storage, transit, and processing.

A derived, one-way value computed from plaintext on your device and sent to the server for lookup purposes. The server stores and matches blind index values without ever seeing the original data. This enables equality searches on encrypted fields — the server can find matches but cannot reverse the index to learn what was searched.

A variant of blind indexing is used for authentication: an Oblivious Pseudorandom Function (OPRF) derives a login bucket index from the email without the server ever seeing it — a blind index computed interactively rather than locally.

Analogy: A search index where every entry is a hash — you can check if a hash matches your search term by hashing it yourself, but the server cannot reverse the hash to learn what you actually searched for.

A technique where the platform routes requests using encrypted payloads and opaque tokens rather than plaintext identifiers. Sensitive content and key material are never exposed to routing logic. The server can fulfill operations without learning what content is being accessed, though operational metadata — such as resource identifiers, statuses, timestamps, and access patterns — remains visible.

On document, entity, and grant resource endpoints, the server returns an identical 404 for both missing and unauthorized resources — an anti-oracle pattern that prevents attackers from distinguishing whether a resource exists.

Analogy: A courier who delivers sealed packages to numbered lockers without knowing the sender, recipient, or contents — the locker number tells the courier where to deliver, but the sealed package remains opaque.

Document Lifecycle

The sequence of stages a document passes through — creation, encryption, storage, retrieval, update, and deletion — all while remaining encrypted. Document content is never stored or transmitted in plaintext. For operations that require processing the plaintext — such as OCR or verification — decryption occurs exclusively inside the secure enclave, not on the server's general compute layer.

Example: From the moment you upload a passport scan to the moment you delete it, the server only ever stores encrypted bytes. When OCR runs, decryption happens inside a hardware-isolated environment and the plaintext is zeroized immediately after processing.

Encrypted Search

The ability to search across encrypted data without decrypting it first. The platform uses privacy-preserving index structures that allow the server to return matching results while never learning the search query or the content of the documents. Only the requesting client can decrypt and read the results.

Analogy: Asking a librarian to find books by showing them a code word — they locate matching books without learning what you actually searched for, then hand you the encrypted results to decrypt on your device.

Entity Membership

A cryptographic mechanism that proves a user or device belongs to an organization or group without revealing their identity to the server. Membership is validated through tokens and proofs rather than by exposing user records, keeping organizational relationships private.

Three distinct blind tokens replace plaintext foreign keys for sensitive stored relationships: one identifying the entity, one identifying the member within the entity, and one identifying the user across all their memberships. Plaintext identifier columns have been selectively removed from database tables as part of an ongoing migration — some associations are fully tokenized while others retain operational identifiers.

Analogy: A club membership card that proves you belong without revealing your name to every doorman — the card is a proof of membership, not an identity card.

Entity Scope

The boundary that defines which encrypted resources a given entity (user, device, or organization) is permitted to access. Scopes are enforced cryptographically — the platform cannot grant access beyond what the client's keys allow, even if the server is compromised.

Analogy: A keycard that only opens the floors you're authorized for — building management cannot grant you access to floors your card doesn't cover, even if they wanted to.

Index Scoping

The practice of partitioning encrypted search indexes by entity or access boundary so that queries only touch the subset of data the requester is authorized to see. This limits both the blast radius of any single query and the information the server can infer from access patterns.

Analogy: Search results partitioned by security clearance level — a user with clearance level 2 cannot even see that clearance level 3 results exist, so they cannot infer what higher-level data is available.

Token-Based Identity

Users prove identity using cryptographic tokens instead of passwords or personal details.

Session token: After login, a short-lived token proves "I authenticated successfully." The server verifies the token's signature without learning who you are — just that the token is valid.

OPRF during login: The server evaluates your credentials without seeing them. Your device blinds your email, the server processes the blinded value, your device unblinds the result to derive a login bucket. The server authenticated you without ever seeing your email.

Analogy: A tamper-proof event ticket. The bouncer verifies the QR code is valid and unforged — you enter. The bouncer never learns your name, only "valid ticket." In the OPRF case, even the identity check is hidden: the bouncer cannot see you — they just process signals.

View Tag

A lightweight, privacy-preserving marker attached to encrypted records that allows the server to filter or sort results without decrypting them. View tags enable efficient query processing on encrypted data by exposing just enough information for routing — but not enough to reveal content.

Analogy: A single-letter sorting code on an envelope — the post office uses it to route to the right mailroom without reading the letter or identifying the recipient.

Zero-Knowledge Boundary

The architectural dividing line between components that can see plaintext (your device and the secure enclave) and components that cannot (the server's general compute layer). Everything beyond this boundary operates exclusively on ciphertext, tokens, and proofs. The boundary is enforced both in software design and through hardware isolation.

Analogy: A one-way mirror — the client can see everything happening on the server, but the server can only see its own reflection, never the plaintext on the client side.

Zero-Knowledge at Rest

A guarantee that all stored data — documents, indexes, metadata — remains encrypted on disk. The platform never holds decryption keys for stored content. Even with full access to the storage layer, an attacker cannot read document content or reconstruct sensitive associations from the database.

Example: Even with full database access, an operator cannot read any document content — they see only encrypted blobs, with no keys to decrypt them. Decryption keys exist in plaintext only inside the secure enclave, for the duration of a specific operation, and are zeroized immediately after use.

ZK-in-Transit

A guarantee that data remains encrypted while moving between systems — from your device to the server, between services, and back. The platform transports ciphertext only. Decryption of sensitive content happens on your device or, for server-side processing operations, inside the secure enclave.

Analogy: A document in a sealed, unbreakable tube traveling through the postal system — even if intercepted in transit, the contents remain inaccessible.