· · Daniel A
Client-Side Encryption: How We Protect Your Data
A deep dive into AES-GCM encryption and why your password never leaves your device.
"We take security seriously" is probably the most meaningless phrase in tech. Every company says it. Most of them just mean they use HTTPS and have a password field. That's table stakes, not security.
At SimplyBoard, we wanted to do something different. We wanted to build a system where even WE can't access your data. Not because we're trying to be difficult · but because if we can't read it, neither can anyone who might compromise our servers.
This post explains exactly how our encryption works, in plain English. No hand-waving, no trust-us-it's-secure. Just the actual implementation.
The Big Picture
Here's the core idea: your password is used to generate an encryption key, and that key never leaves your device. When you save an entry, it gets encrypted in your browser before being sent to our servers. When you load your entries, they come down encrypted and get decrypted locally.
Our database literally contains gibberish. Encrypted blobs that are meaningless without your password. We couldn't read your entries even if we wanted to, even if someone held a gun to our heads, even if law enforcement showed up with a warrant.
Zero-Knowledge Architecture
This approach is called "zero-knowledge" because the server has zero knowledge of your actual data. It just stores and syncs encrypted blobs without ever knowing what's inside them.
Step 1: Turning Your Password Into a Key
Your password isn't used directly for encryption. That would be insecure for a bunch of reasons · mainly that passwords are usually short and guessable. Instead, we use a process called key derivation.
Specifically, we use Argon2id, the winner of the Password Hashing Competition, with these parameters:
- 64 MB memory cost · Memory-hardness makes GPU and ASIC brute-force attacks impractical
- 3 passes, 4 lanes · The same class of parameters used by leading password managers
- A random salt · Unique to your account, stored on our servers
The salt is important. Without it, two users with the same password would have the same encryption key, which creates security problems. The salt ensures everyone gets a unique key, even with identical passwords.
The output of this process is a 256-bit encryption key. This happens entirely in your browser · the password itself is never transmitted anywhere.
Step 2: Encrypting Your Entries
Once we have the encryption key, we use AES-GCM (Advanced Encryption Standard in Galois/Counter Mode) to encrypt your entries. AES is the same encryption standard used by governments and banks worldwide. It's been analyzed by cryptographers for decades and remains unbroken.
GCM mode adds authentication to the encryption. This means if someone tampers with the encrypted data, we'll detect it when trying to decrypt. The ciphertext hasn't just been scrambled · it's been signed.
For Each Entry, We Generate:
- A random 12-byte IV (initialization vector)
- The encrypted content using AES-256-GCM
- A 16-byte authentication tag
The IV is generated fresh for every entry and every save. This means even if you save the exact same text twice, the encrypted output will be completely different. No patterns to analyze, no information leakage.
What Gets Encrypted
We encrypt the stuff that matters:
- Entry content · The actual text you're storing
- Tags · The labels you attach to entries
- Content type · Whether it's plaintext or markdown
We DON'T encrypt:
- Entry IDs · Random UUIDs, no information leakage
- Timestamps · When entries were created/updated
- Your email · Needed for authentication
The timestamps might seem like a privacy concern, but they're actually necessary for sync conflict resolution. And knowing WHEN someone saved something tells you nothing about WHAT they saved.
What We Can Still See
To be completely transparent about our trust model:
- Your email address
- When you created or updated entries (timestamps)
- Your IP address (in server logs)
- How many entries you have
We're a cloud service. Cross-device sync requires a server. That server sees some metadata. We're upfront about this because "zero-knowledge" can be misleading if interpreted as "we know literally nothing about you." If you require complete data sovereignty·where no third party sees any metadata whatsoever·you would need a self-hosted solution. We've prioritized convenience and reliability for users who want strong encryption without managing infrastructure.
The Tradeoffs
This approach isn't free. There are real downsides you should understand:
Password recovery is impossible. If you forget your password, your data is gone. We can reset your account, but we can't decrypt your entries. This is by design, but it means you need to remember your password or store it somewhere safe.
Server-side search is impossible. Because we can't read your data, we can't search it on the server. All search happens locally in your browser, which means your entries need to be downloaded and decrypted first. For most users with a few hundred entries, this is instant. For someone with tens of thousands... it might get slower.
Sharing is complicated. There's no "share this entry" button because sharing encrypted data requires sharing keys, which opens up a whole can of worms. For now, SimplyBoard is personal-only.
Why Not Just Use Signal/WhatsApp Encryption?
Good question. Signal uses the "Signal Protocol" which is designed for real-time messaging between multiple parties. It's brilliant for chat, but overkill for a personal knowledge base.
Our threat model is simpler: one user, multiple devices, and a server that shouldn't be trusted. AES-GCM with Argon2id key derivation is the modern standard for this scenario. Argon2id is what password managers like Bitwarden offer for key derivation, and it's been battle-tested since winning the Password Hashing Competition.
The Bottom Line
Your entries are encrypted with AES-256-GCM before leaving your device. The encryption key is derived from your password using Argon2id, a memory-hard key derivation function. We never see your password or your data in plaintext. If our servers got hacked tomorrow, the attackers would get encrypted garbage.
Got questions about our security implementation? Want to audit our approach? We're happy to nerd out about cryptography. Reach out at security@simplyboard.io.
· The SimplyBoard Team
