Why End-to-End Encryption Actually Matters (and Why Most Apps Get It Wrong)

Every week another breach makes headlines. A database dumped, a cloud bucket left open, a rogue employee exfiltrating millions of records. The company's post-mortem always mentions encryption. "All data is encrypted at rest and in transit."

And yet — the breach happened.

Here's the uncomfortable truth: most "encrypted" apps aren't actually protecting users from the one threat that matters most. Let's break down why.

The three layers most apps encrypt

Modern SaaS apps typically encrypt at three levels:

1. TLS in transit — HTTPS between the browser and your server. Good. Table stakes. Doesn't protect data once it arrives.
2. Encryption at rest — Your database or cloud provider encrypts the disk. This protects against physical theft of hardware. Not against SQL injection, insider threats, or a compromised AWS account.
3. Application-level secrets — Hashing passwords, wrapping API keys in secrets managers. Still server-side. Your server can decrypt anything it stores.

All three of these share a fatal flaw: your server holds the keys.

What "your server holds the keys" really means

When your server encrypts data, it also holds the ability to decrypt it. That means:

• A SQL injection attack that reaches your DB can read any field your app can read
• A malicious employee with DB access can read any user's data
• A law enforcement subpoena compels you to hand over plaintext records
• A breach of your cloud provider's API exposes everything

The math is simple: encryption only protects data from parties who don't have the key. If your server has the key, you've only protected against hardware theft.

What real E2E encryption looks like

In a genuine end-to-end encrypted system:

Alice's device                     Your server                     Bob's device
─────────────                      ──────────                      ────────────
generates keypair                  stores public keys only         generates keypair
encrypts with Bob's public key ──► receives ciphertext ─────────► decrypts with Bob's private key
                                   (cannot decrypt)

The server is a blind relay. It moves encrypted blobs from A to B without ever having the ability to read them. Not even under subpoena — because cryptographically, it cannot.

This is how Signal works. It's how WhatsApp's messages work (despite Meta's other data practices). And it's the same protocol Encra implements.

The Double Ratchet: why E2E is hard to build yourself

The basic ECDH key exchange above protects the initial message. But real-world E2E messaging needs more:

• Forward secrecy: If a device is compromised today, past messages should still be safe
• Break-in recovery: After compromise, future messages should recover security
• Out-of-order delivery: Messages arriving out of sequence should still decrypt correctly

The Double Ratchet algorithm — developed by Signal — solves all three. It derives a new encryption key for every single message, then deletes the previous key. You can't decrypt last week's messages even if you have this week's key.

This is genuinely complex cryptography. Getting it wrong breaks all security guarantees silently. This is why rolling your own is dangerous even for experienced engineers.

What Encra does

Encra implements the full Double Ratchet protocol using libsodium — the most widely-audited cryptographic library for the web. The key server stores only public keys. Private keys never leave the device. The relay routes ciphertext blobs it cannot read.

The entire SDK surface area:

const { messages, isReady, sendMessage } = useE2EChat({
  apiKey: process.env.NEXT_PUBLIC_ENCRA_API_KEY,
  userId: currentUser.id,
})

That's it. Signal-level security in one hook. No cryptography degree required.

Who should care

If your app handles any of the following, you should be thinking about real E2E:

• Healthcare / HIPAA — Patient messages to providers, therapy session notes
• Legal — Attorney-client privileged communications
• Finance — Sensitive deal discussions, personal financial data
• HR — Whistleblower channels, performance reviews
• Consumer trust — Any messaging app where users expect privacy

The era of "we encrypt at rest" being sufficient is over. Users and regulators are starting to understand the difference — and they'll favor products that take it seriously.

Encra is free during beta. Get a key at encra.dev/signup — no credit card required.