Security

Not “we take your privacy seriously.” Not “encrypted at rest.” Here is exactly what we store, exactly what we can read, and exactly what happens if everything goes wrong.

Threat Model

Protected Against

✓Server compromise (hacker gets DB access)
✓Government subpoena (legal request for data)
✓Insider threat (rogue employee)
✓Network interception (MITM attack)

NOT Protected Against

✗Compromised device (malware on your computer)
✗Password reuse (same password elsewhere)
✗Phishing (you give away your password)

We protect against server-side threats. We do not protect against client-side compromise. If your device has malware, no encryption can save you.

What We Store

Data	Format	Can We Read It?
File contents	AES-256-GCM ciphertext	No
File encryption keys (DEKs)	RSA-2048 OAEP wrapped	No
Your RSA private key	AES-GCM wrapped with your KEK	No
Your password	Argon2id hash of PBKDF2 hash	No
Session token	SHA-256 hash	No
Share link key	Never sent — stays in URL fragment	No

Key Architecture

1. Registration

Your browser generates two independent salts (auth_salt, kek_salt). Password + auth_salt → PBKDF2 → SHA-256 → auth verifier (sent to server). Password + kek_salt → PBKDF2 → AES-256-GCM key (KEK, stays in browser). RSA-2048 keypair generated in browser. Private key wrapped with KEK, sent to server. Server re-hashes auth verifier with Argon2id before storing.

2. Login

Client fetches salts from server. Re-derives auth verifier. Server verifies against Argon2id hash. Server generates random 32-byte session token, SHA-256 hashes it, stores in DB. Returns raw token + wrapped private key. Client derives KEK, unwraps private key in memory (non-extractable). Server never sees the password or the KEK.

3. File Upload

Browser generates random AES-256-GCM Data Encryption Key (DEK). Encrypts file with DEK. Wraps DEK with RSA public key. Sends ciphertext + wrapped DEK to server. Server stores on disk. Plaintext never leaves your device.

4. Share Links

Owner unwraps DEK with RSA private key. Generates random symmetric Link Key. Re-wraps DEK with Link Key. Link Key placed in URL fragment (#) — never sent to server. Recipient opens URL, browser extracts Link Key from fragment, unwraps DEK, decrypts file. Server cannot access the file even with full DB access.

Proof

Every line of code is open for inspection. No proprietary crypto. No “trust us.” Just standard Web Crypto API, standard Rust libraries, and a deliberately transparent architecture.

GitHub→

FAQ

What if your servers are hacked?

Attackers obtain AES-256-GCM ciphertext and RSA-wrapped keys. Without your password (which we never see) and your private key (which never leaves your browser), the data is unreadable.

What if a government subpoenas you?

We would produce encrypted ciphertext and wrapped keys. We cannot decrypt them. The architecture makes compliance impossible, not just difficult.

What if I lose my password?

Your data is permanently lost. There is no recovery mechanism. This is by design — any recovery mechanism is a backdoor. Use a password manager.

Create Your Vault