End-to-end encryption, explained for non-developers

If you've heard of "end-to-end encryption" and want to know what it actually means without a CS degree, here it is.

End-to-end encryption (E2EE) is the property that only the two people in a conversation can read it. The platform — Signal, WhatsApp, Are We Friends? — sees only ciphertext, gibberish, never the actual message content. Even the platform's engineers, with full database access, can't read your messages. Even a court order can't make them produce your messages, because the messages don't exist in readable form anywhere on their servers.

That's the property. Now let's unpack what makes it work.

The three weaker alternatives

To understand E2EE, it helps to compare it to what most apps do instead.

Encryption in transit (TLS). Every reputable app uses this. When you send a message, it's encrypted between your phone and the platform's server. An eavesdropper on your wifi can't read it. But the server reads it. All of Slack, Discord, Twitter, Instagram, default Gmail — these use encryption in transit but the server sees plaintext.

Encryption at rest. The server encrypts the database. So if someone steals the disk, the data is unreadable. But the running server has the keys. Anyone with access to the server (employees, lawful subpoenas, hackers who compromise the server's running process) can read the data. This is what most "encrypted" enterprise tools mean.

End-to-end encryption. The encryption happens on YOUR device, with a key that NEVER leaves your device. The server only ever sees ciphertext. There's no way for the platform to read messages, even if it wanted to. Even if it's served a search warrant, the most it can produce is encrypted blobs.

Signal, WhatsApp (default for new chats), iMessage (when both ends are iPhones), and Are We Friends? are E2EE. Most other messaging is not.

The three pieces that make E2EE work

E2EE has three cryptographic pieces. Each does a different job.

### 1. Symmetric encryption — the message itself

The actual message content is encrypted with a symmetric algorithm — same key encrypts and decrypts. Modern apps use either AES-GCM or ChaCha20-Poly1305. Both are "AEAD" algorithms — they produce ciphertext + an authentication tag, so the recipient can verify the message wasn't tampered with in transit.

Are We Friends? uses XChaCha20-Poly1305, an extended-nonce variant of ChaCha20-Poly1305. The "extended nonce" lets us safely choose a fresh random value for every message without worrying about collisions, which simplifies the protocol significantly. Same algorithm Signal uses for payload encryption.

### 2. Key exchange — how both ends get the same key

The hard problem: how do the two phones agree on a symmetric key without ever sending the key over the wire? If they sent the key, the server would see it and could decrypt everything.

The solution is Diffie-Hellman key exchange, specifically using the elliptic curve Curve25519. The math: each phone generates a private/public keypair. They exchange public keys (which are safe to send — public). Each phone combines its own private key with the other's public key to derive an identical shared secret. The shared secret never travels over the wire — both ends compute it independently from values that were never both visible to the server.

Are We Friends? uses X25519 (the standard Diffie-Hellman variant on Curve25519) in "sealed-box" mode. The same primitive Signal, WireGuard, and modern TLS use.

### 3. Key derivation — turning your password into a key

The last piece: where do the long-lived private keys live? On your phone. Encrypted. Encrypted with what? A key derived from your password.

But human passwords are weak — most are 8-12 characters of moderate entropy, well within the brute-force range of a determined attacker. To make a password-derived key strong enough to protect a private key, we run the password through a key derivation function (KDF) that's intentionally slow and memory-hard.

Are We Friends? uses Argon2id, the IETF-recommended modern KDF. It takes ~64 MB of RAM and ~250ms of CPU time to derive your master key from your passphrase. That's fast enough to be invisible to you on login but slow enough to make brute-force attacks on the encrypted private key prohibitively expensive even on specialized hardware.

Why E2EE for friendship messaging?

The case for E2EE is stronger for dating and intimate relationships than for friendships, in most people's intuition. So why bother for a friendship app?

A few reasons.

Friendships get personal too. Two-year-old friendships routinely include conversations about mental health, family situations, work crises, financial stress, medical news. The premise that "friend chats" are casual and don't need encryption falls apart the moment you actually look at what people send to close friends.

The platform shouldn't have eyes into your social graph. Even without reading the messages, knowing WHO talks to WHOM produces a lot of information. Are We Friends? doesn't need that information to operate, so we deliberately don't keep it.

It's good security hygiene by default. The day after you build a non-E2EE messaging system at scale, your team starts arguing about whether to monetize the message data, build NLP-based "smart features," "improve safety" with content scanning, etc. The argument always lands somewhere uncomfortable. The way to never have the argument is to make it technically impossible from day one.

Subpoena resistance is real. A court order against a non-E2EE platform produces messages. A court order against an E2EE platform produces ciphertext blobs. We've thought about this carefully and we think it's an important property to give to our users — the property that we genuinely cannot betray them, even if we wanted to.

What E2EE costs

The honest tradeoff. E2EE has real operational costs:

• No server-side search. We can't search through your DMs because we can't read them. Search is client-side only, which limits historical-message lookup to what's on your current device.
• No content moderation. We can't scan messages for abuse, spam, or illegal content. This is a real risk vector. Are We Friends? mitigates it through pre-DM friction (you have to friend-request, the recipient has to accept) and per-thread reporting that lets either party flag abuse without exposing message content to us.
• No automatic message recovery. If you lose your device and forget your passphrase, your messages are gone. Permanently. No customer-service escape hatch. We can't help even if we want to, because by design we don't have your keys.
• Notifications need a separate channel. Push notifications can't include message content (we can't decrypt to compose them), so they say things like "you have a new message" without the body.

These costs are real. We think they're worth it. Reasonable people can disagree.

What "Bry_NFET_SX" means on our pages

Are We Friends? labels the encryption stack "Bry_NFET_SX" in some technical pages. That's our internal name for the specific composition: XChaCha20-Poly1305 for symmetric encryption + X25519 sealed boxes for key exchange + Argon2id for key derivation. The "NFET" part refers to the founder's research framework (Non-Equilibrium Field Theory) — a naming convention more than a technical one.

The actual cryptography is exactly what Signal, WireGuard, and modern TLS use. It is not novel cryptography, on purpose. New cryptography is dangerous. Standard primitives composed correctly is the safe play.

The bottom line

E2EE means: only the two parties in a conversation can read it. The platform sees ciphertext. Even with a court order, the platform can't produce readable messages, because they don't exist in readable form anywhere on their servers.

It costs the platform some features (no server-side search, no content moderation, harder customer service). It gives you genuine privacy in exchange.

We chose to ship it on Are We Friends? because we think friendship conversations are personal too, and because the property "the platform genuinely cannot betray you" is one of the few digital trust signals that's actually verifiable.

The full crypto stack is documented at /end-to-end-encrypted-messaging and /glossary/bry-nfet-sx.