What Is Zero-Knowledge Architecture? Password Security Explained

What zero-knowledge actually means

Zero-knowledge, in the context of password and data security, means that the service provider literally cannot access the data you've entrusted to them — not because they choose not to, but because the architecture makes it technically impossible without your encryption key.

This is distinct from "we don't look at your data" (a policy claim) or "we encrypt your data" (which might mean the provider holds the keys). True zero-knowledge means the provider receives only ciphertext — data that is meaningless without a key that only you possess. Even a malicious employee, a court order, or a data breach of the provider's servers cannot expose your data because the provider's infrastructure never had the plaintext.

How it works technically

The core mechanism in zero-knowledge systems is client-side encryption with keys derived from user-controlled secrets (typically a master password). The process for a zero-knowledge password manager:

1. You choose a master password that never leaves your device
2. The application derives an encryption key from your master password using a key derivation function (PBKDF2, Argon2id, or similar) — a computationally expensive one-way function that makes brute-force attacks slow
3. All your data is encrypted using that derived key, entirely on your device, before any data is sent to the provider's servers
4. The encrypted ciphertext is synced to the provider's servers — the provider stores data that looks like random noise
5. When you access your data on another device, the ciphertext is downloaded and decrypted locally using your master password
6. At no point does the provider's server have your master password, your derived encryption key, or the plaintext of your data

The security consequence: a breach of the provider's servers exposes only ciphertext. The attacker gets the equivalent of a hard drive full of random bytes. Without your master password, it is computationally infeasible to decrypt.

Client-side generation explained

Password generation is a specific and important zero-knowledge context. When you use a password generator, where the random number generation happens matters:

• Server-side generation: You click "generate," the server generates a random password and sends it back. The server has seen the plaintext password before you do. Logged? Possibly. Stored? Maybe. Exposed in a breach? If it was logged or cached, yes.
• Client-side generation: The random number generation happens entirely in your browser using the Web Cryptography API's crypto.getRandomValues(). The generated password never leaves your device before you copy it. The provider's servers never see it. Not logged. Not transmitted. Not stored.

Client-side generation is the stronger architecture for a password generator precisely because the generated credential is the thing you're trying to keep secret. Any system that transmits a generated password over a network — even over HTTPS — creates an exposure window that client-side generation eliminates entirely.

How to verify a zero-knowledge claim

Zero-knowledge is a verifiable technical claim, not just a marketing statement. Ways to verify it:

• Open source code: If the client-side application is open source, the encryption implementation can be audited. If it's closed source, you're trusting the claim.
• Network inspection: Use your browser's developer tools (Network tab) to inspect what is transmitted when you interact with the application. A genuine zero-knowledge password generator should show no outbound network requests containing your password when you generate or copy.
• Independent security audits: Reputable zero-knowledge services commission regular third-party cryptographic audits. Look for published audit reports from recognised security firms.
• Open cryptography protocols: Verify that the application uses well-established cryptographic algorithms (AES-256, ChaCha20, Argon2id) rather than proprietary ones. Proprietary cryptography is a red flag.

For PassGeni specifically: all password generation uses crypto.getRandomValues() directly in the browser. You can verify this by opening the browser's developer tools, navigating to the Sources tab, and searching the JavaScript for getRandomValues. The function call is there; no server request is made for the random seed.

What is NOT zero-knowledge

Many services use the term "zero-knowledge" loosely or incorrectly. Things that are not zero-knowledge despite sometimes being marketed as such:

• "We encrypt your data" — encryption alone is not zero-knowledge if the provider holds the keys. Encryption where the provider controls the keys is standard data protection, not zero-knowledge.
• "We can't access your password" — if this is a policy statement rather than a technical architecture, it is not zero-knowledge. Policies change; technical architecture is verifiable.
• Server-side password hashing — hashing your password before storing it is a standard security practice, but it is not zero-knowledge. The provider still has a record of your authentication credential.
• TLS/HTTPS encryption — this protects data in transit between your device and the server, but the server receives and can store the plaintext after decryption. HTTPS ≠ zero-knowledge.

Zero-knowledge proofs vs. zero-knowledge architecture

These are related but distinct concepts that are frequently confused:

Zero-knowledge architecture (this guide) refers to systems where the provider cannot access plaintext user data due to client-side encryption. It is a product design and architecture pattern.

Zero-knowledge proofs are a cryptographic primitive that allows one party to prove to another that they know something (a value, a fact) without revealing that something. For example: proving you know the password for an account without transmitting the password — the proof reveals that you know it, not what it is. The HIBP k-anonymity breach checker is a practical example: you prove you know the first five characters of a SHA-1 hash without revealing which hash you're checking.

Both are genuinely zero-knowledge in the cryptographic sense, but they apply at different layers of a system. Password managers use zero-knowledge architecture. Authentication protocols increasingly use zero-knowledge proofs.

Zero-knowledge in password managers

The major zero-knowledge password managers implement this architecture with some variation in the specific cryptographic details:

• 1Password: Uses 128-bit Secret Key combined with master password as the basis for encryption. Neither is ever transmitted to 1Password's servers in a form that allows decryption. AES-256-GCM encryption. Independent cryptographic audits by Cure53 and others.
• Bitwarden: Open-source. Master password never transmitted — only a derived authentication hash. AES-CBC-256 + HMAC SHA-256. Code audited by multiple independent security firms. Can be self-hosted.
• ProtonPass: From the makers of ProtonMail. Same architecture as ProtonMail's end-to-end encryption. Open source, audited.

What all three have in common: if their servers were breached tomorrow, the attacker would get encrypted blobs that require your master password to decrypt. The breach notification you'd receive would be "encrypted data was exposed" — not "your passwords were compromised."

How PassGeni implements it

PassGeni is a zero-knowledge password generator by design. The implementation:

• All password generation uses crypto.getRandomValues() — the Web Cryptography API's CSPRNG, seeded by the operating system's entropy pool, running entirely in the browser
• No generated password is transmitted to PassGeni's servers. The generation is local; the server never participates.
• No account required to generate passwords — there is no user profile that could be associated with generated credentials
• The breach checker uses k-anonymity: only the first 5 characters of the SHA-1 hash of the checked password are sent to the HIBP API, which returns matching hashes. The full hash and the plaintext password are never transmitted.
• The secure share feature uses AES-256-GCM encryption in the browser; the decryption key lives in the URL fragment, which is never sent to the server by design (browsers do not include the fragment in HTTP requests)