Client-Side Encryption Basics for Indie Hackers

Most tutorials on encryption start with heavy math. Asymmetric vs symmetric. Key derivation functions. Cipher modes. Attack vectors.

You lose your audience at "elliptic curve."

Here's the truth: you don't need the math. You need the intuition. Once you understand *why* encryption works, the implementation is simple (because smart people already built the libraries for you).

Encryption is not complicated. Explaining encryption without math is hard. This is the easy version.

What encryption actually is (the simple version)

Encryption is a scrambler. You have plaintext (readable message). You scramble it with a key. Out comes ciphertext (unreadable gibberish). Only someone with the right key can unscramble it back to plaintext.

That's it. Everything else is details.

The encryption process in three steps

Step 1: Start with a secret

You have plaintext: "My vault contains my fears and dreams." Your app has a key: "supersecurepassword123". Both stay on your device.

Step 2: Scramble with the key

Your app uses a cryptographic algorithm (we'll get to this) to scramble the plaintext with the key. Out comes: "aB7$@!dK#qL9%mN8pO2&xZ3*vY4+wU6-jI5~hG1"

Step 3: Send the scrambled version

The server receives the scrambled gibberish. Even if hacked, it's useless. Only your app (which has the key) can unscramble. When you want to read it, your app unscrambles using the same key.

The beauty: the server never sees the plaintext. Even if subpoenaed, it can't decrypt because it doesn't have the key.

The key (ha): Why the key matters more than the algorithm

Beginners think the algorithm is everything. "Should I use AES? RSA? Elliptic curve cryptography?"

Wrong question. The algorithm is just the scrambler. What matters is the *key*.

Think of it like a combination lock:

The algorithm is the lock mechanism (how it scrambles).
The key is the combination (what unscrambles it).

You can have the world's best lock mechanism, but if your combination is "1234", a child will open it.

Encryption security is 90% about the key strength, 10% about the algorithm. Use industry-standard algorithms (AES, ChaCha20). Spend your worry on key generation and storage.

A strong key with a weak algorithm is safer than a weak key with a strong algorithm.

Keys: How they're generated, stored, and used

There are three main ways indie hackers should think about keys:

🔑

Random key from the server

The server generates a random key and gives it to you. You use it to encrypt. Problem: you don't control the key. The server might have a copy.

Not recommended for privacy apps

🧠

Key derived from your password

Your password is transformed into a key using math. Every time you use the password, you get the same key. You control it (no one else has it). Password strength = key strength.

Best for privacy apps (CHRONOS uses this)

🎲

Random key generated locally, stored encrypted

Your device generates a random key. You can store it encrypted (protected by password). Decrypt when needed. Most secure but more complex.

Used by Signal, WhatsApp, Apple

Symmetric vs. asymmetric (the metaphor you'll actually understand)

There are two main types of encryption. Indie hackers usually only need to understand one, but here's both:

🔓 Symmetric Encryption (one key)

One key scrambles AND unscrambles

Same key on both sides = same secret to share

Metaphor: One key opens a box, one key closes it

Use case: Encrypting your own data (CHRONOS, note apps)

Examples: AES, ChaCha20

🔐 Asymmetric Encryption (two keys)

One key (public) scrambles, other key (private) unscrambles

You share public key, keep private key secret

Metaphor: Public mailbox (anyone can mail), private key to open it (only you have it)

Use case: Encrypting to someone else (email, messaging)

Examples: RSA, Elliptic Curve

For building privacy apps that protect *your own* data (like CHRONOS), use symmetric encryption. It's simpler and faster.

The three myths about encryption that trap indie hackers

Here are the misconceptions that stop you from building:

Myth vs Reality

❌ Myth: "I need to understand cryptography to use it"

You don't understand how TCP/IP works, but you use it. You don't understand how JPEG compression works, but you use it. Same with encryption. Use proven libraries (libsodium, Web Crypto API). Let cryptographers handle the hard parts.

❌ Myth: "Encryption makes my app slow"

Modern encryption (AES-256) is *fast*. Your browser can encrypt/decrypt hundreds of messages per second. The performance cost is negligible for 99% of apps.

❌ Myth: "If I encrypt, I'm done with security"

Encryption is one layer. You still need secure password storage, protection against malware, secure key generation. But encryption + strong password = pretty damn secure.

AES-256: The industry standard (and why you should use it)

If you Google "what encryption should I use?", you'll see AES-256 recommended everywhere. Here's why it's the default for indie hackers:

Proven: It's been analyzed by cryptographers for 25 years. No weaknesses found.
Fast: It's optimized in hardware on modern CPUs. Nearly free performance-wise.
Available: Every language, every platform has AES libraries. Web Crypto API in browsers. libsodium in Node.
Strong: AES-256 means 256-bit key. That's 2^256 possible keys. There's no computer in the universe that could brute-force this.

Use AES-256. Don't overthink it. Literally every privacy app uses it (Signal, WhatsApp, CHRONOS).

How to actually implement it (the indie hacker way)

Here's the pattern. No crypto degree required:

Choose a library (don't build crypto yourself)

Use libsodium (via Sodium.js) or Web Crypto API. These are battle-tested. You use them, not write them.

Derive a key from the user's password

Take the password "mypassword123", run it through a key derivation function (PBKDF2, Argon2). Out comes a strong 256-bit key. Always the same key for the same password.

Encrypt user data before sending to server

When user writes "My secret thought", use the key to encrypt it. Send the encrypted blob to the server. Keep plaintext local.

Decrypt on the client when retrieving

When user wants to read, fetch encrypted blob from server. Decrypt on the client (in the browser, on the device). Show plaintext only after decryption.

Never log plaintext server-side

The server sees only ciphertext. It never sees the plaintext. Make this the default: encrypt before sending, period.

That's the pattern. Every privacy app follows this. So can you.

The honest trade-offs of client-side encryption

Encryption isn't free. Here are the costs:

Forgotten password = lost data: If the user forgets their password, their data is gone. No "forgot password" recovery. Plan for this (recovery codes, backup devices).
No server-side search: The server can't search encrypted data. Search has to happen on the client. This limits UX.
Complexity: You have to think about encryption early. Retrofitting later is hard.
Key management is hard: Even with a library, keys can leak if you're careless. Review your code.

These are real constraints, not negatives. They're why encryption is valuable—it forces the server to be dumb about your data.

The complexity of encryption is worth it because the benefit is genuine privacy. The server cannot leak what it never had.

Building your first encrypted app: The checklist

Ready to add encryption to your indie app? Here's your minimum checklist:

✓

Pick a proven library

Web Crypto API (browser), Sodium.js, or libsodium. Don't invent your own encryption.

✓

Use AES-256

It's the default for a reason. Don't overthink algorithm selection.

✓

Derive keys from passwords (PBKDF2, Argon2)

Not random keys from the server. Use a key derivation function with high iteration count.

✓

Encrypt before sending

Make it the default. Plaintext never leaves the client except in the user's browser memory.

✓

Handle forgotten passwords gracefully

Maybe recovery codes, maybe multi-device backup. Don't just say "too bad."

✓

Test thoroughly

Encryption mistakes are catastrophic. Unit test your encryption, integration test your key derivation, manually verify encryption/decryption.

The shift in indie hacking: Privacy as a feature

Five years ago, encryption was a niche feature. Now it's table-stakes.

Users are waking up to the fact that cloud companies sell or leak data. Apps that offer genuine privacy—not marketing privacy, but architectural privacy—have an advantage.

This is the opportunity for indie hackers. You don't have a surveillance business to defend. You can actually build privacy.

Use encryption. Build privacy into your apps from day one. It's not as hard as you think, and it's more valuable than you imagine.

CHRONOS

Built with encryption
from the start.

Encryption is not a nice-to-have. It's the foundation. Here's how we did it.

Open CHRONOS