True Zero-Knowledge Encryption in Personal Finance: What I Actually Built

Every fintech app says "bank-grade security." Then you read the terms and find a clause like "our employees may access your account for customer support." That sentence haunted me for months before I started Misto's Financial. I wanted to know what it felt like to build something where I literally cannot read your transactions—not because I'm trustworthy, but because the cryptography makes it impossible.

This post is about zero knowledge encryption in personal finance: what it actually is, why most apps don't do it, and the concrete tradeoffs I made to ship it.

What Zero Knowledge Encryption Actually Means

Here's the clearest way I can say it: your password never leaves your device. It is never sent to my servers. Instead, your password is run through a key derivation function—PBKDF2, salted—to create an encryption key. That key encrypts every transaction, every budget, every memo you enter, using AES-256-GCM before it is sent to me.

I store the ciphertext. I have no key. Your data sits on my servers as unreadable noise.

When you log in on a new device, you enter your password. That same key derivation happens. The ciphertext decrypts client-side, in your browser or in the Misto's app. The plaintext never touches my servers on the way down.

That is zero knowledge encryption in personal finance. It is not "encrypted in transit." It is not "encrypted at rest with a master key I hold." It is you holding the only key, cryptographically.

The Moment I Almost Shipped It Wrong

I was three weeks into building Misto's Financial when I realized I had made a mistake. I had sketched out the architecture using a standard backend pattern: JavaScript hashing the password, sending it over HTTPS to my servers, where a Node script would do the key derivation and hand back a token. Convenient. Wrong.

If the key derivation happens on my server, then I have the key. I can decrypt your data anytime. The bank cannot do that—they cannot derive your password. But I could. So I deleted that entire sketch and started over.

The new version: the client does the key derivation. My server never sees the password or the key. It only sees a username and a salted hash (for login verification). The ciphertext arrives encrypted, stays encrypted, and leaves encrypted.

This meant I had to learn WebCrypto—the native browser crypto API—deeply. It meant building a Capacitor wrapper so the Android app could do the same derivation in native code, bit-for-bit identical to the browser, so your key was the same whether you logged in on web or mobile. It meant accepting that I cannot recover your account if you forget your password. That tradeoff felt radical. It still does. It is also correct.

Why Most Apps Don't Do Zero Knowledge Encryption in Personal Finance

Because it breaks the business model of surveillance.

If I can read your transactions, I can sell insights to credit card companies, lenders, merchants. I can profile you. I can send you algorithmic nudges that serve my revenue, not your values. Zero knowledge encryption closes that door. By design.

But there are real technical costs, too:

• I cannot run server-side analytics. Every chart, every insight, every breakdown of your spending has to be calculated in your browser, using only the data you decrypted yourself. That is slower on older phones.
• I cannot send push notifications that say "you're approaching your grocery budget." The notification would have to be generic ("you have a new transaction") or I'd have to decrypt your data server-side to compose it (which defeats the point). I chose generic.
• Password recovery is gone. Forget your password, your data is lost. I mitigate this by offering optional, client-side backup exports—you can download an encrypted JSON file and store it wherever. But I cannot restore your account server-side.

These are the tradeoffs of zero knowledge encryption in personal finance. I made them on purpose.

How It Actually Works Under the Hood

When you sign up:

1. You create a password. It never leaves your device.
2. The browser runs PBKDF2 with 600,000 iterations (OWASP 2023 baseline) to derive a key and a salt-hash.
3. The salt-hash is sent to my server to create your account. The key stays in your browser's memory.
4. From that moment on, every transaction is encrypted with AES-256-GCM using that key before it's sent to Misto's servers.

When you log in on a new device:

1. You enter your username and password.
2. The server sends you the salt it stored during signup.
3. Your browser runs PBKDF2 again with the same password and salt. It derives the same key.
4. The ciphertext downloads and decrypts locally.
5. Your data appears in the Misto's dashboard—all on your device.

If my database is hacked, an attacker finds ciphertext and salts. Without your password, they cannot derive the key. Without the key, AES-256-GCM is computationally infeasible to break.

This is not theoretical. This is live in Misto's Financial today.

The Proof Is in the Code You Can Verify

I don't ask you to trust me. I have published the client-side crypto logic and made it auditable (links in the Misto's docs). You can inspect how the key is derived. You can see that your password is never sent. You can verify that AES-256-GCM is the cipher. You can hire a cryptographer to tear it apart.

That is the difference between zero knowledge encryption in personal finance and corporate privacy theater. Theater requires trust. Cryptography requires proof.

If You Want to See It in Action

Misto's Financial is live now—web, iOS, Android. The free-forever core includes everything: transactions, budgets, goals, the full dashboard. Zero knowledge encryption is built in from day one, not bolted on later. You can sign up, enter a few transactions, and see that the only place they're readable is in your browser or app.

If you'd like a quieter way to see your money—one where I literally cannot peek—the free core lives at https://mistosfinancial.com/.