What "zero-knowledge" means here, exactly

Every password manager claims this. Here is the actual derivation Kanical Vault runs, so you can judge for yourself instead of taking our word for it.

master password+client salt
PBKDF2, SHA-256 · 600,000 rounds
master key
HKDFHKDF
encKey

AES-256-GCM · stays in your browser, in memory only

authKey

re-hashed with scrypt, then the only thing that reaches the server

Two keys, one password

When you set or enter your master password, your browser combines it with a per-account salt and runs it through PBKDF2 at 600,000 rounds — deliberately slow, so guessing it by brute force is expensive even if someone got hold of the encrypted database. That produces a master key that never leaves memory.

The master key is then split with HKDF into two independent keys, each with a different purpose baked into its derivation label, so a bug that mixed them up would produce a key that fails to decrypt anything rather than one that silently works: encKey, which encrypts and decrypts every item in your vault with AES-256-GCM, and authKey, which proves to the server that you know the password — without proving anything about what it is.

Only authKey is ever sent over the network, and only once, at unlock. The server re-hashes it again with scrypt before storing it, so even a full database compromise doesn't hand over anything usable to derive encKey from. Every item is stored as ciphertext and an initialization vector — the server has no schema for what's inside, no idea if it's a login or a credit card.

What hosting does and doesn't buy you

Kanical Vault runs as a hosted service — we run the Worker and the database. What we don't run is the part that matters: this derivation happens in your browser, before your account has ever touched our infrastructure. The server only ever receives authKey and ciphertext, the same as it would no matter who operated it. Paying for Kanical Vault buys convenience. It doesn't buy access to your data — that was never for sale.