How Trezio protects vault credentials
What is actually encrypted, what the master password does and doesn’t do, and a plain statement of what "zero-knowledge" covers in Trezio and what it doesn’t.
Trezio stores login credentials — usernames and passwords attached to saved screenshots — behind a specific, narrow encryption system. It’s worth being precise about exactly what that system covers, because "encrypted" is a word that gets stretched to mean more than it does. This is the precise version.
What is encrypted
Credentials you explicitly save to the vault — a username and password pair attached to a login screenshot — are encrypted client-side with AES-256-GCM before they ever leave your device. The encryption key is derived from your master password using PBKDF2 with 600,000 iterations, which makes brute-forcing that key computationally expensive even with a stolen database. Each credential is encrypted with a fresh random IV, so encrypting the same password twice produces different ciphertext both times.
Your master password itself is never transmitted to Trezio’s servers and is never stored anywhere. The server only ever sees ciphertext — it has no way to recover a credential without your master password, because it was never given the means to.
What the master password actually unlocks
Setting a master password creates a random salt and a piece of verification data — a known string encrypted with your password — stored in your account settings. Unlocking the vault means Trezio attempts to decrypt that verification data with the password you just typed: success means the password is correct and the derived key is held in memory for your session; failure means it isn’t, and nothing is unlocked. After a configurable idle timeout (30 minutes by default in the main app), that derived key is cleared from memory automatically, and you’ll need to re-enter your master password to see credentials again.
Vault folders are a different lock
Vault folders — password-protected folders you can put any kind of item into — are a separate mechanism from the master password. A vault folder’s password is hashed with bcrypt and gates access to the folder itself. Your master password is what then decrypts any credentials stored inside items in that folder. The two locks serve different purposes: one restricts who can open a folder, the other protects what’s inside a credential specifically.
What is not encrypted this way — and this is the important part
This is the distinction worth being unambiguous about: AES-256-GCM client-side encryption applies to vault credentials specifically — the username/password pairs you store — not to your entire library. Your bookmarks, notes, screenshots, voice-note audio, folder names, and charms are not client-side encrypted the way a credential is.
That doesn’t mean the rest of your library is unprotected. It means it’s protected differently: through Row-Level Security enforced at the database level, which isolates every user’s data from every other user’s so that no one — including through a misconfigured query — can read data that isn’t theirs. That’s a real, meaningful protection against unauthorized access between accounts. It is not the same guarantee as zero-knowledge encryption, which would mean nobody but you could ever read the content even with direct database access. Trezio is not a zero-knowledge product across the whole library — it is zero-knowledge specifically for vault credentials, and RLS-isolated for everything else.
Why it’s scoped this way
Encrypting an entire library client-side the way a credential is encrypted would break most of what makes a bookmark manager useful day to day — full-text search across notes and transcripts, AI-assisted summaries and tag suggestions on demand, thumbnails, and fast list rendering all depend on the server being able to read that content. Credentials don’t need any of that: nothing needs to search inside your saved passwords, so nothing needs to read them either. Scoping the strongest protection to the one type of data that has zero legitimate reason to be server-readable is the tradeoff, made deliberately rather than left unexamined.