A vault that keeps its contents encrypted from the service.

The browser derives a vault key from a passphrase and encrypts each item before the ciphertext is sent to PostgreSQL.

AES-GCM 256-bit encryption in the browser; PBKDF2-SHA-256 with 310,000 iterations derives the key.

Client-side encryption flow

When you save a secret, the browser creates a random salt and nonce, derives a key from the passphrase, and encrypts the item with AES-GCM. The API stores the opaque encrypted payload associated with your account. The vault passphrase is not submitted to the API as part of this flow.

Use a unique, long vault passphrase
The service cannot reset or recover a lost vault passphrase
The server still processes account email, session and operational metadata

Unlocking and deletion

To read an item, the browser downloads its ciphertext and asks for the passphrase to decrypt locally. Deleting an item removes its database record; it does not prove that every external backup or storage layer has erased all copies. Backup and retention behavior must be reviewed in the final service policy.

Choose the right item before unlocking
Do not share an unlocked device session
A deleted item should not be treated as securely erased from all backups

Know the boundary

This is an application-encrypted personal vault, not a hardware security module, managed enterprise key vault, shared team vault or audited zero-knowledge claim. Browser extensions, malware, screen capture, clipboard monitors and weak passphrases remain relevant threats.

Keep the device and browser patched
Use device encryption and screen lock
Use hardware-backed custody for high-value signing keys

What the server still learns

Client-side encryption protects the saved payload from ordinary database inspection without the passphrase. The service still has to handle account email, session state, timestamps, item identifiers and ciphertext size. Hosting operators and infrastructure may also have access to operational metadata. The phrase 'zero knowledge' would overstate the assurances established by the current implementation and review status.

Encrypted content and account metadata are different things
TLS protects transport but does not eliminate endpoint risk
Read the privacy notice draft only as a draft until approved

Passphrase choice is the root of recovery

The vault derives a key from a passphrase rather than storing that passphrase with your account. This means there is no support reset that can restore decryption. A long, unique phrase stored in a separate trusted password manager is easier to preserve than a short improvised secret—and should not be the same as the account password.

Keep an offline recovery plan for critical items
Never send the vault passphrase to support
Try a small test item before placing important records in the vault

Saving is a deliberate trade

The browser must hold plaintext briefly to display or encrypt an item. Once encrypted, the ciphertext is uploaded over the authenticated session. Browser developer tools, malicious extensions, keyloggers, screen sharing and clipboard tools can observe a value while it is in use; application encryption cannot defend a compromised endpoint.

Use a patched, private browser profile
Close the session on a shared device
Consider a dedicated password manager for automatic filling and lifecycle features

Security is a workflow, not a label.

Review the implementation boundaries