Why Your Password Manager Should Know Nothing About Your Passwords

Here’s an uncomfortable question: When you store your passwords in a password manager, who else can see them?

If your answer is “nobody,” you’re hopefully right. But how do you know?

Most people trust their password manager because… well, because they have to. The company says they can’t see your data, and you believe them. But what if there’s a way to prove it—not with promises, but with mathematics?

That’s exactly what zero-knowledge architecture does.

I’m building Clefi, a password manager designed for French and EU users with compliance built in from day one. And the foundation of Clefi’s security is a simple principle:

The server should never—under any circumstances—be able to see your passwords.

Not if we wanted to. Not if a hacker broke in. Not if a government demanded it. Never.

Let me show you how that works.

Table of contents

The Problem: Trust Shouldn’t Be Required

Most password managers work like this:

1. You create an account and set a master password
2. You add your passwords to the vault
3. Everything gets encrypted and sent to the company’s servers
4. The company promises they can’t decrypt your data

That last step? It’s based on trust. You trust the company implemented encryption correctly. You trust they’re not keeping a copy of your master password. You trust their employees can’t peek at your data.

And most of the time, that trust is well-placed! But trust isn’t a security model—it’s a hope.

Zero-knowledge architecture removes the need for trust. It makes it cryptographically impossible for the service provider to access your data, even if they wanted to.

How Zero-Knowledge Architecture Works

The core idea is simple: All encryption and decryption happen on your device, not the server.

Here’s the step-by-step:

Step 1: Your Master Password Never Leaves Your Device

When you create your Clefi account and set a master password, that password never gets sent to our servers. Not in plain text, not encrypted, not hashed. It stays on your computer, in your browser, completely under your control.

Instead, we derive two things from your master password using a process called key derivation:

1. An authentication key - This proves you know your password (so you can log in)
2. An encryption key - This encrypts and decrypts your vault

Think of it like this: Your master password is the seed that grows two different trees. One tree (authentication) lets you prove who you are. The other tree (encryption) locks and unlocks your vault. The server only ever sees the authentication tree—never the encryption tree.

Step 2: Your Vault is Encrypted Locally

When you save a password in Clefi, here’s what happens:

1. Your browser uses your encryption key (which lives only on your device) to encrypt the password
2. The encrypted vault gets sent to our servers
3. Our servers store the encrypted blob—but have no way to decrypt it

It’s like putting your passwords in a safe, locking it, and then storing the locked safe in a warehouse. The warehouse (our servers) can store your safe, but they don’t have the key to open it. Only you do.

Step 3: Decryption Happens in Your Browser

When you need a password:

1. Your browser requests your encrypted vault from the server
2. The server sends the encrypted blob (still locked)
3. Your browser uses your encryption key (still on your device) to decrypt it
4. You see your passwords

The server never participates in decryption. It’s just a storage locker.

The Cryptography That Makes This Possible

Zero-knowledge architecture isn’t magic—it’s mathematics. Here’s what’s happening under the hood (in plain language):

Argon2id: Making Your Master Password Unbreakable

Your master password might be “correct horse battery staple”—strong, but still just a passphrase. We need to turn it into cryptographic keys.

We use Argon2id, a password hashing algorithm that’s specifically designed to be:

• Memory-hard: Requires lots of RAM, making it expensive to attack with specialized hardware
• Time-hard: Takes deliberate time to compute, slowing down brute-force attacks
• GPU-resistant: Can’t be sped up by throwing graphics cards at it

Think of Argon2id as intentionally making password cracking slow and expensive. It’s the winner of the Password Hashing Competition and the current gold standard.

HKDF-SHA256: Turning One Key Into Two

We use HKDF (HMAC-based Key Derivation Function) to split your master password into:

• The authentication key (for proving you’re you)
• The encryption key (for locking your vault)

This separation means that even if someone intercepted your authentication key (used for login), they still couldn’t decrypt your vault. The keys are mathematically related but computationally impossible to reverse.

XChaCha20-Poly1305: The Vault Lock

Your vault is encrypted using XChaCha20-Poly1305, an authenticated encryption algorithm that:

• Encrypts your data so it’s unreadable
• Authenticates your data so tampering is detectable
• Performs fast so your experience is smooth

“Authenticated encryption” means that if anyone tries to modify your encrypted vault (even without decrypting it), we’ll know. The math will show that something’s wrong, and we’ll reject it.

Why These Algorithms?

I didn’t invent these. Nobody should invent their own cryptography.

These algorithms are:

• ✅ Recommended by cryptography experts worldwide
• ✅ Audited and battle-tested in production systems
• ✅ Modern, avoiding older algorithms with known weaknesses
• ✅ Standard implementations (we’re using well-tested libraries, not custom code)

What This Means For You

Here’s what zero-knowledge architecture guarantees:

1. Your passwords are private—truly private Not “we promise not to look” private. Mathematically impossible to access private.

2. A data breach doesn’t expose your passwords If someone hacked Clefi’s servers tomorrow and stole everything, they’d get encrypted blobs they can’t decrypt. Your passwords would still be safe.

3. We can’t be forced to hand over your data Even if a government, court, or malicious actor demanded we decrypt a specific user’s vault—we literally cannot. We don’t have the keys.

4. You’re in control Your master password is the single point of trust. Keep it safe, and your vault is secure. Lose it, and we can’t help you recover it (because we never had access in the first place).

Where Clefi Development Stands Today

I’m sharing this deep dive because the cryptographic foundation of Clefi is now implemented and working.

Here’s where we are:

✅ Zero-knowledge architecture implemented - The core encryption/decryption flow is built and tested

✅ Backend vault storage complete - Secure API for storing and retrieving encrypted vaults

✅ Authentication system working - Login flow with Argon2id key derivation

🚧 Browser extension in development - Auto-fill and password capture coming soon

🚧 Web application UI refinement - Making the interface beautiful and intuitive

📅 Target launch: Q1-Q2 2026

The hard part—getting the security right—is done. Now it’s about building the user experience around that bulletproof foundation.

Want to Follow Along?

I’m building Clefi in public, and I’d love to have you along for the journey.

If you’re interested in:

• Getting notified when Clefi launches
• Early access to the beta
• Behind-the-scenes development updates
• Opportunities to shape features with feedback

👉 Join the mailing list at clefi.app

I send updates on major milestones, technical deep dives like this one, and the honest reality of building a security-first SaaS in France.

And if you have questions about zero-knowledge architecture, password security, or compliance for French SMEs—I want to hear them.

📧 [email protected] or [email protected] 💻 @andrea_nekolab on Twitter/X

Next up: I’ll be sharing how we’re building the browser extension with security and usability in mind, and the unique challenges of making cryptography fast enough for real-time auto-fill.

🔐 clefi.app - Sign up for launch updates