Why we chose local-first encryption for Dotvault

Most cloud-based tools ask you to trust them with your data. You create an account, set a password, and hope the company never gets breached, never misuses access, and never hands data over under legal pressure.

We built Dotvault the other way around: your device does the encryption, and our servers — if you use sync at all — only store ciphertext we cannot read.

What zero-knowledge actually means

A true zero-knowledge vault has three properties:

  1. Your master password never leaves your device. It is not hashed and stored on a server for login. It lives only in memory while you use the app.
  2. Your encryption key is derived locally. Dotvault uses Argon2id to turn your master password and a random salt into a 32-byte AES key on your machine.
  3. Synced data is an opaque blob. If you enable Pro sync, the server stores your encrypted vault. Without your master password, it is mathematically infeasible to decrypt.

The encryption stack

  • AES-256-GCM encrypts each project as a JSON blob. GCM adds authenticated encryption, so tampering is detected.
  • Argon2id derives the key. It is memory-hard and resistant to GPU cracking.
  • Fresh nonces. Every encrypted project gets a new 12-byte nonce, so reusing the same password does not produce predictable ciphertext.

What we cannot do — by design

Because of this architecture, Dotvault cannot:

  • Reset your master password.
  • Recover your vault if you forget it.
  • Hand readable data to anyone, because we never have the key.

That is a feature, not a bug. It removes us from the trust chain entirely.

When cloud sync still makes sense

Local-first does not mean offline-only. With Dotvault Pro, you can sync the encrypted vault between the desktop app and the web app. The sync server sees only encrypted bytes. You keep the convenience of multi-device access while keeping the keys yourself.

Why “we encrypt your data” is not enough

Plenty of products claim encryption without being zero-knowledge. The distinction matters: if a company can decrypt your data on their servers — even just to generate a preview, index it for search, or comply with a support request — then a breach, a subpoena, or a rogue employee can expose it too. Encryption “at rest” on a server you do not control only protects against someone stealing the hard drive. It does nothing against the operator itself.

A zero-knowledge design removes that entire category of risk by construction. There is no “trust us” step, because there is nothing on the server worth trusting anyone with.

What this means if we get breached

Assume, for a moment, that an attacker gets full read access to Dotvault’s database. What do they get? Rows of ciphertext, each encrypted with a key derived from a master password we never had. Without that password, AES-256-GCM ciphertext is not just “hard” to break — it is computationally infeasible with any technology that exists today. The breach becomes a non-event for user data, because there was never any plaintext to steal.

This is the actual test of a zero-knowledge claim: not “do you encrypt data,” but “what happens to my data in the worst-case breach scenario.” If the honest answer is “attackers get unreadable bytes,” the architecture is doing its job.

The trade-off, honestly

Zero-knowledge is not free. It means:

  • No “forgot password” email reset — because a reset would require someone else to be able to re-encrypt your data, which would mean they could read it.
  • No server-side search across plaintext values — search has to happen after decryption, on your device.
  • No account recovery via support ticket, ever.

We think this trade-off is the right one for credentials specifically. A forgotten social media password is an inconvenience. A vault holding your production API keys and SSH credentials is worth a stronger guarantee, even at the cost of losing a convenience feature.

Bottom line

If a service can reset your password, it can read your data. Dotvault cannot reset your password because it cannot read your data. That is the local-first promise — and it is a deliberate trade of convenience for a guarantee that matters more when what you are protecting is the keys to your production systems.