Zero-knowledge encryption: what it actually means when we can't see your data
We literally cannot read your notes. Here's what that implies for you and for us.
When we say zero-knowledge, we mean it: the server never has your password or the key that decrypts your note. Everything is encrypted in your browser before it hits the wire. That's not marketing—it's the only way we could sleep at night running a note-taking product.
What the server actually stores
We store ciphertext, a salt, an IV, and key-derivation metadata. No plaintext, no password hashes we could crack. If someone stole our database, they'd get a pile of random-looking bytes. Without your password, those bytes are useless.
Tip
Use a strong, unique password for each note. The server never sees it—only your browser uses it to derive the encryption key.
Why it matters for you
You don't have to trust us with the content. You only need to trust that we don't mess with the crypto (we use the Web Crypto API and standard algorithms) and that we don't log or exfiltrate your key. We don't have your key to begin with—it's derived in your browser and never sent.
Summary
Zero-knowledge means we never see your password or decryption key. Encryption happens in your browser; we only store ciphertext and public parameters like salt and IV.
What you can do
- Use a password manager for important notes.
- Share the link and password through different channels (e.g. link by email, password by phone).
- Treat the URL as public and the password as the real secret.
Fact
With AES-256-GCM and PBKDF2, even if our database is leaked, your note stays unreadable without your password.
FAQ: Zero-knowledge encryption
Q1. What does “zero-knowledge” actually mean for my notes?
It means we never see your password or decryption key and cannot decrypt your notes on the server. Encryption and decryption happen in your browser using the Web Crypto API; we only ever store ciphertext plus public parameters like salt and IV.
Q2. How is this different from “encrypted at rest” on a server?
“Encrypted at rest” usually means the provider holds the keys and can decrypt data whenever they need to. In a zero-knowledge model like Inkrypt’s, keys are derived from your password client-side (with PBKDF2 and 310k iterations) and never leave your device, so we cannot decrypt stored data even if we want to.
Q3. Why can’t you recover my note if I forget the password?
Because we never store anything that would let us reconstruct your key. Without your password, PBKDF2 and AES-256-GCM leave us with only ciphertext, salt, IV, and parameters, none of which are reversible into plaintext.
Q4. What do I need to do to make zero-knowledge work for me?
Choose strong, unique passwords, store them in a password manager, and avoid sharing them in the same channel as note URLs. Zero-knowledge removes the provider from your trust chain, but endpoint and password hygiene are still your responsibility.
Q5. How can I verify that encryption really happens in the browser?
You can open https://www.inkrypt.online, create a note, and inspect network requests: you’ll see ciphertext, salt, IV, and metadata—but never your password or derived key. Our other technical articles describe the exact algorithms and parameters we use.
Where to go next
If you want to understand how zero-knowledge fits into the rest of the design:
- Read “Why we encrypt in the browser (and what happens to your password)”.
- Read “AES-256-GCM in the browser: a quick tour of our crypto stack”.
- Try Inkrypt at https://www.inkrypt.online and see how zero-knowledge, client-side encrypted notes behave in practice.