Zero-knowledge is a claim anyone can make. We want to be specific about what it means in PassVault and exactly why our servers, even if fully compromised, cannot expose your vault contents.
Key derivation
When you set your master password, PassVault performs the following on your device only — nothing is transmitted to our servers during this process:
The critical detail: encKey is never sent to the server. Our server only ever sees a hash of the auth key — which cannot be reversed to derive the encryption key.
Vault item encryption
Each vault item (password, note, card) is individually encrypted using AES-256-GCM with a random per-item key. The per-item key is then encrypted with your derived encKey.
This means:
- Each item has a unique encryption key — key reuse attacks are impossible
- AES-256-GCM provides authenticated encryption — tampering is detected
- The per-item key wrapped in your encKey — changing your master password only requires re-wrapping the per-item keys, not re-encrypting all content
What our server stores
An attacker who fully compromises our database and infrastructure gets: encrypted blobs they cannot decrypt, and auth key hashes they cannot reverse. Your vault is mathematically inaccessible to us — by design.
All cryptographic operations use the Web Cryptography API (SubtleCrypto) — native browser implementations audited by browser vendors, not custom crypto code. The PassVault client is open source and auditable.
Why Argon2id, and what parameters we chose
The choice of KDF matters enormously. MD5 and SHA-1 are out of the question. Even bcrypt — still widely used — is CPU-only, and GPU farms can attack it at scale. Argon2id is the winner of the Password Hashing Competition (2015) and is now the OWASP recommended KDF for password hashing. The "id" variant combines Argon2i (resistant to side-channel attacks) and Argon2d (resistant to GPU/ASIC attacks).
Our current parameters: m=65536 (64MB memory), t=3 (3 iterations), p=4 (4 parallel lanes). On a modern laptop, this takes approximately 800ms–1.2s, which is imperceptible for login but makes brute-force attacks enormously expensive. An attacker trying to crack your master password must spend 64MB of memory and ~1s of CPU time per guess — even with a botnet this is impractical for anything beyond a trivially weak password.
We use your userId as the Argon2id salt rather than a random salt stored server-side. This is a deliberate design choice: a random server-side salt would require a round-trip to our servers before any crypto could begin, which would allow us to delay or vary the salt — a subtle but real attack vector. Using your userId (deterministic and known to you) means the entire key derivation can happen locally before any network contact.
The emergency access key handshake
Emergency access is one of the more cryptographically interesting features in PassVault v2.1. The problem: how do you allow a trusted person to access your vault in an emergency, without ever giving them your master password, and without us being able to perform the handshake ourselves?
The answer is an asymmetric key ceremony. When you add an emergency contact:
- A fresh RSA-4096 key pair is generated on their device
- Their public key is sent to our server
- Your
encKeyis encrypted with their RSA public key and stored server-side - Their RSA private key never leaves their device
If they need to access your vault: they submit a request, we notify you, and after the waiting period (if you haven't denied it), we release the RSA-encrypted encKey to them. They decrypt it with their private key — which only they have — and can now decrypt your vault. We never have both the RSA private key and the RSA-encrypted encKey at the same time, so we cannot perform this handshake ourselves.
What this architecture means in practice
The practical implications of zero-knowledge architecture are significant. A subpoena or court order compelling us to hand over your data gives the requesting party: encrypted blobs, auth key hashes, and RSA-encrypted emergency keys. None of these are useful without your master password. This is not a privacy promise on our part — it is a cryptographic property of the system.
It also means we cannot offer "forgot master password" recovery in the traditional sense. If you lose your master password and have no emergency access configured, your vault is permanently inaccessible. We believe this is the correct tradeoff: the guarantee that no one can access your data without your master password is worth the operational complexity of proper backup and emergency access setup.
We recommend: memorise a strong passphrase (use the Diceware method for something both strong and memorable), write it down and store it somewhere physically secure (a safe, a solicitor's envelope), and set up emergency access with a family member or trusted friend. The cryptography is sound — your operational security practices are what determines the overall security of your vault.
The PassVault client is fully open source. You can audit every cryptographic operation, verify our claims, and build your own client if you choose. Trust mathematics, not promises.