Zero-Knowledge Model

In a zero-knowledge system, the server can store and deliver your data — but it can never read it.

What "zero-knowledge" means

This isn't a policy decision. It's a structural guarantee enforced by the architecture:

• Your encryption keys are created on your device and never leave it in unencrypted form.
• Cryptographic operations happen either on your device or inside a hardware-isolated secure enclave that server operators cannot access.
• The server stores only ciphertext and opaque tokens — it performs storage and routing, but cannot interpret what it handles.

What the server can see

The server is not completely blind. It needs certain pieces of information to function:

• Login bucket — authentication uses an OPRF so your email is never sent in plaintext. The server sees only a blind bucket index (login_bidx) derived from the blinded evaluation — a 13-bit non-unique value shared by many accounts.
• When actions happen — timestamps for uploads, shares, and searches are recorded for operational purposes.
• Coarse document size — a rough size bucket (not the exact size) is stored for storage management.
• Processing status — whether a document is uploading, processing, or ready. This reveals nothing about the document's content.
• Token equality — the server can observe that two requests produced the same blind index token within a scope, and how many results matched a search. It cannot reverse tokens to plaintext.
• Resource identifiers — path parameters use opaque UUIDs for routing. These are server-assigned identifiers that carry no sensitive meaning.
• Encrypted blobs — the server stores your encrypted documents and metadata, but cannot decrypt them.

What the server cannot see

• The content of any document
• Document titles, filenames, or any metadata
• What you're searching for
• Which document a grant is for, or who the grant is intended for
• The relationship between a grant and a specific person
• Which organization a user belongs to — membership records use cryptographic tokens, not plaintext foreign keys
• Your encryption keys in any form
• The contents of audit log entries — audit records are encrypted inside the secure enclave before leaving it

These guarantees are enforced at the database schema level — plaintext identifier columns have been physically removed from the relevant tables, not just obscured or deprecated. A database dump cannot reveal these associations because the columns no longer exist.

How this is enforced

Client-side encryption

Before a document ever leaves your device, it is encrypted with a key that only you possess. The server receives and stores only the encrypted result. Even if someone gained full access to the server's storage, they would see only meaningless ciphertext.

Hardware-isolated secure enclave

Some operations — like generating search indexes or processing documents for verification — require temporary access to decrypted data. These operations happen inside a secure enclave: a special hardware environment completely isolated from the rest of the server. The enclave has no general network access and communicates with the outside world only through a narrow, controlled channel. Server operators cannot inspect what happens inside it.

The enclave's identity is cryptographically verified through attestation. Before the enclave can access any encryption keys, it must prove to the key management service that:

• It is running the exact, unmodified software that was audited and approved.
• It has not been tampered with since it was built.
• It is executing inside a genuine hardware-isolated environment.

Only after this proof is verified will the key management service release keys to the enclave. A tampered, replaced, or impersonated enclave cannot pass attestation and therefore cannot access any keys. This is not a policy check — it is a cryptographic guarantee enforced by the hardware itself.

Cryptographic tokens replace sensitive foreign keys

Throughout the system, sensitive relationship identifiers — document ownership, grant associations, entity memberships — are replaced with one-way cryptographic tokens. The server can compare tokens for equality but cannot reverse-engineer the original identifier from the token. This prevents the server from building a map of who owns what or who is sharing with whom.

Tamper-evident audit trail

Every significant action in the platform — document uploads, shares, verifications — is recorded in an encrypted audit log. Each entry is encrypted inside the secure enclave before it leaves, and the entries are chained together cryptographically so that tampering with or deleting a single record would break the chain. The server stores these encrypted entries but cannot read them. Only the enclave, after passing attestation, can decrypt an entry for authorized review.

The Zero-Knowledge Boundary

The platform enforces zero-knowledge at rest — the database contains no plaintext associations between users, documents, and grants. A database dump reveals only ciphertext and opaque tokens.

Request routing uses some plaintext identifiers for technical reasons — path parameters carry server-assigned resource UUIDs. This is an accepted trade-off: the server is trusted to route requests correctly, but it cannot learn anything meaningful from the data it stores.

Post-Quantum Protection

The platform protects your data not just against today's threats, but against future quantum computers as well.

All key exchange and key wrapping operations use a hybrid approach: every operation is performed using both a modern classical scheme and a post-quantum scheme simultaneously. The result is protected by both — an attacker would need to break both the classical and the post-quantum layer to compromise a single key.

The hybrid scheme pairs X25519 (classical) with ML-KEM-1024 (post-quantum) for key encapsulation, and Ed25519 (classical) with ML-DSA-65 (post-quantum) for signatures. Both layers must verify for a signature or key exchange to be accepted.

This hybrid design means:

• If quantum computers arrive sooner than expected, the post-quantum layer protects your data.
• If the post-quantum scheme turns out to have a flaw, the classical layer still provides security.
• Documents encrypted today remain safe even if a quantum-capable attacker records and stores the ciphertext for future decryption.

Verification Seals

When the enclave processes a document, it produces a verification seal — a cryptographic proof signed with a platform key only the attested enclave possesses.

The seal proves three things:

1. Authenticity — processed by a genuine, attested enclave, not a fake
2. Integrity — the result has not been altered since creation
3. Specificity — bound to this document only; cannot be transferred or reused

The seal itself is encrypted and stored with the document. A commitment hash (SHA-256 of the seal payload) is also stored, so anyone can verify the seal exists and is authentic without reading its contents — you can prove a document was verified without revealing what it contains.

What's next

• Document Lifecycle — Follow a document's journey from upload to deletion.
• Key Hierarchy — Understand the types of keys that protect your data.
• Encrypted Search — How search works without revealing your queries.
• Entities & Memberships — How organizations and teams are managed.
• Grants & Sharing — How sharing works without the server knowing who's sharing with whom.
• Blind Routing — How sensitive relationships are tokenized to prevent relationship mapping.