Threat model
What we protect, and what we don't
A clear boundary matters more than a list of promises.
Defended by construction
- Host operator reading stored fragments
- Theft or imaging of one host machine
- Full compromise of our database or storage
- A host returning altered shard bytes
- Loss of several shards per file
- Insider access to customer files
Out of scope
- Malware or keyloggers on your device
- Weak or reused passphrases
- Lost passphrases — there is no reset
- Metadata needed to route and bill
- Hostile browser extensions in your vault
- Network-wide traffic analysis
Primitives in use
Key derivationPBKDF2-HMAC-SHA256, 600,000 rounds, random salt
File encryptionAES-256-GCM with a unique key and IV per file
Key wrappingContent keys sealed under the master key
FragmentationReed-Solomon erasure coding, k-of-n recovery
IntegritySHA-256 per shard and manifest digest
TransportTLS 1.3; payloads are ciphertext
AuthorizationRow-level security scoped to owner or host
Metadata we necessarily hold
Zero-knowledge applies to content, not existence. We keep account identity, file names, sizes, shard counts, digests, node assignments, and timestamps to bill, route, and repair. Hosts see only a shard ID and byte length.