← Blog

Zero-Knowledge Architecture, Without the Jargon

Zero-Knowledge Architecture, Without the Jargon

"Zero-knowledge" is one of those terms that sounds like a marketing phrase even when it isn't. In cryptography it has a very specific meaning, and the apps that use it correctly are doing something genuinely different from "we encrypt your data."

This is a plain-English walkthrough of what zero-knowledge architecture is, what it can and can't do, and why — for a journaling or notes app — it's the right floor, not the ceiling.

The plain-language definition

Zero-knowledge architecture means the server can do its job — store your data, sync it across devices, authenticate you — without ever learning the contents of your data, or the keys that unlock it.

It's not magic. It's a deliberate set of design choices: where data is encrypted, where keys live, what the server is allowed to ask for, and what proofs replace passwords.

The three properties

A system is zero-knowledge in practice when:

1. Encryption happens on the user's device. Plaintext never reaches the server.
2. Keys live on the user's device. The server never sees the master key, recovery key, or anything that can derive them.
3. Authentication doesn't require the password. The server can verify that you're you without seeing your secret.

Property 3 is the one that surprises people. Most apps send your password (or its hash) over the network during sign-in. A zero-knowledge app uses a protocol (like SRP, OPAQUE, or a simpler challenge-response) where the server learns "this user proved they know the secret" but not the secret itself.

A worked example: how a zero-knowledge journal sync works

Imagine you write an entry: "Decided to quit job. Need to start saving more."

In a non-zero-knowledge app:

1. You type. The app sends the text to the server over HTTPS.
2. The server stores the text on disk, encrypted at rest with a key the server holds.
3. To sync to your phone, the server reads the text, encrypts it again over HTTPS, sends it.
4. The server can read the entry at any of these steps — and so can anyone with database access.

In a zero-knowledge app:

1. You type. The app encrypts the text on your device with a key only your device has.
2. The app sends the encrypted blob to the server. The server stores the blob and a few unavoidable metadata fields (entry ID, timestamp).
3. To sync to your phone, the server hands the blob to your phone. Your phone uses the same key (synced via a separate, secret-protected mechanism) to decrypt it.
4. The server cannot read the entry at any step. A database breach gives an attacker ciphertext, not your thoughts.

What zero-knowledge does not mean

The marketing departments of less rigorous apps blur the lines. Zero-knowledge does not mean:

• "No data is collected." Servers still need metadata. The architecture only protects content, not the existence of an entry.
• "You're invincible." A compromised device, a screenshot, a coerced unlock — none of these are within the threat model.
• "The company can't do anything." They can rate-limit, ban accounts, run aggregate analytics on metadata. They just can't read your entries.
• "The crypto can never be broken." Algorithms have lifecycles. Today's strong cipher might be weak in 2050. Good systems plan for rotation.

Honest zero-knowledge apps publish their threat model and what's outside it. Be skeptical of any that don't.

The ergonomic cost — and why it's worth paying

Zero-knowledge architecture forces some decisions that look like bugs to users:

• Recovery is harder. If you forget your password and lose your recovery phrase, the company genuinely cannot help. There's no "reset and recover everything." (If there were, the system wouldn't be zero-knowledge.)
• Server-side intelligence is limited. No "AI summarize my year" feature unless it runs on-device. No cross-account search.
• Sharing is harder. Sharing an entry with another user requires a key exchange, not just a permission flag.

Each of these limits the product. They're also exactly the limits that prove the architecture works.

How to verify a "zero-knowledge" claim

If an app calls itself zero-knowledge, look for:

1. A specific cipher named. Vague claims = no claims.
2. A documented key derivation flow. Argon2, PBKDF2, or scrypt; with parameters specified.
3. A statement on what the server stores in plaintext. It should be short — entry IDs, timestamps, account ID, maybe device info.
4. A recovery flow that does not involve a support reset. A recovery phrase that you, and only you, hold.
5. Ideally, a public security review or open-source client. Trustworthy code earns trust by being inspectable.

How Jottii implements it

Quickly, since this post is about the concept:

• Master key generated on-device with tweetnacl.randomBytes(32).
• Stored in iOS Keychain or Android Keystore via expo-secure-store. Never transmitted.
• Entries encrypted with NaCl secretbox (XSalsa20-Poly1305) before sync.
• Server stores: encrypted blob, entry ID, date, sort timestamps. Nothing else.
• Recovery is a base64-encoded copy of the master key the user saves at signup.

If you lose the recovery key, we can't restore your data. We say it loudly because it's the proof the model works. (For more, see What End-to-End Encryption Actually Means for Your Journal and Why We Chose NaCl Over WebCrypto.)

The bottom line

Zero-knowledge architecture isn't a marketing tier. It's a constraint a team accepts so that their users don't have to take privacy on faith. The apps that wear the label honestly are easy to spot — they tell you exactly what the server sees, what it doesn't, and what they can't do for you because of it.

For a journal app — where your raw, unedited thoughts live — zero-knowledge should be the floor, not a premium feature. Jottii is built that way from the start.

• #zero-knowledge
• #encryption
• #architecture
• #security