SECURITY MODEL · PRIVATE ALPHA

Your device encrypts first.

File content, filenames, and basic file metadata are encrypted in the browser before upload. The server stores ciphertext plus the minimum operational metadata needed to account for storage and retrieve encrypted chunks. The Recovery Key is generated on the customer device and is not uploaded to THE VAULT.

V1 uses a random 256-bit root secret, HKDF-SHA-256 per-file key derivation, AES-256-GCM encryption, fresh 96-bit nonces for encrypted metadata and every encrypted chunk, and associated data binding ciphertext to its file identifier and chunk index.

Important limitation: this is a web application delivered by its operator. A malicious future frontend deployment could theoretically capture a Recovery Key entered into that frontend. The private alpha therefore must not be described as independently audited or absolutely operator-proof.

Protected Recovery V3: when enabled, the browser creates a separate random Recovery Master Secret, wraps the Vault root key locally, and splits the recovery secret into five cryptographic shares with a three-share threshold. Four shares are intended for the customer and trusted/offline locations; THE VAULT stores only one share. Server-assisted release of that one share additionally requires the authenticated account, two-of-three recovery-profile matches, rate limits, and a security delay. Recovery-profile answers are supporting factors, never encryption keys.

Private-alpha limitation: the recovery hold is intentionally shortened for owner testing. Production code enforces a minimum 72-hour hold and remains blocked behind independent recovery-security review. Passkeys and external recovery-alert delivery are not claimed as complete in this build.

Do not use this private alpha for passwords, cryptocurrency seed phrases, Social Security numbers, bank credentials, medical records, or other regulated/high-risk secrets. Keep independent backups.