Forem: Haven Messenger

What End-to-End Encryption Actually Protects (And What It Doesn'''t)

Haven Messenger — Sat, 25 Apr 2026 23:14:07 +0000

What end-to-end encryption protects — and what it misses — is one of the most important distinctions in practical security. This is a technical breakdown.

The Precise Definition

End-to-end encryption (E2EE) means a message is encrypted on the sender's device, travels encrypted through all intermediaries, and is decrypted only on the recipient's device. No server in the path — not the service provider's infrastructure, not your ISP — can read the content.

This is genuinely powerful. Even if Signal's servers are compromised, even if a government serves a lawful demand, even if your traffic is intercepted at a coffee shop — the message content is unreadable to anyone except the intended recipient.

What it does not mean: using an E2EE app makes you private. These are different claims with a significant gap between them.

How It Actually Works: The Signal Protocol

Key Exchange (X3DH)

Before two parties can exchange encrypted messages, they need to establish a shared secret without transmitting it. The Signal Protocol uses X3DH (Extended Triple Diffie-Hellman).

Each user generates several key pairs at registration:

# Each user generates at registration:
IK  = Identity Key       (long-term, never changes)
SPK = Signed PreKey      (rotated periodically, signed by IK)
OPK = One-Time PreKey    (consumed once per session, then discarded)

# The server holds public keys only.
# Private keys never leave your device.

When Alice wants to message Bob, she fetches Bob's public keys from the server and performs a series of Diffie-Hellman operations combining her private keys with his public keys. This produces a shared secret that Bob can derive independently — but that no third party who observed the exchange can compute.

The Double Ratchet: Forward Secrecy

Forward secrecy means compromising today's keys doesn't decrypt past messages. Signal achieves this by generating a new encryption key for every single message:

# Each message advances the ratchet
message_key_1 = KDF(chain_key_0)
message_key_2 = KDF(chain_key_1)
message_key_3 = KDF(chain_key_2)

# Each key is used once, then deleted.
# Compromise of message_key_3 reveals nothing
# about message_key_1 or message_key_2.

An attacker who stores your encrypted messages today cannot decrypt them even if they obtain your private key in the future — the keys that decrypted those messages have already been deleted.

Group Messaging: MLS (RFC 9420)

The Double Ratchet scales to two-party conversations. Group messaging is harder. Traditional approaches encrypt to each member individually — sender work scales linearly with group size.

RFC 9420, the Messaging Layer Security (MLS) protocol, solves this with a binary tree key structure:

# MLS tree structure — 4-member group
          root_secret
         /            \
    left_secret    right_secret
    /       \       /        \
 Alice    Bob    Carol      Dave

# Adding Eve: only the path from Eve's leaf to root updates.
# Everyone derives the new root from their existing subtree secret.
# O(log n) operations instead of O(n).

MLS also provides post-compromise security: if a member's device is compromised, they can be healed back to security through key rotation — the attacker cannot read future messages once the member rotates keys.

What E2EE Protects

✅ Server compromise — An attacker who breaches the service provider obtains ciphertext they cannot decrypt.

✅ Network interception — Traffic captured in transit is unreadable without the recipient's private key.

✅ Service provider access — The provider cannot read message content even under legal compulsion. There is nothing readable to hand over.

✅ Historical messages — With forward secrecy, past messages remain encrypted even after future key compromise.

What E2EE Does Not Protect

❌ Metadata — Who you communicate with, when, how often, and from where are visible to the service provider and the network. E2EE encrypts the payload, not the envelope. [General Michael Hayden, former NSA/CIA director, was not exaggerating when he said "we kill people based on metadata."]

❌ Endpoint compromise — If an attacker controls either device — malware, physical access, compromised OS — they read plaintext before encryption or after decryption. E2EE only protects data in transit.

❌ Key distribution attacks — A service provider who controls the key directory can substitute an attacker's key for your contact's. You would encrypt to the attacker thinking you're encrypting to your contact. This is why Signal has "safety numbers" and PGP has key fingerprints. In practice, almost no users verify them.

❌ Identity linkage — If your account requires a phone number, your encrypted communications are linked to your carrier identity. E2EE says nothing about who you are, only that what you said is private.

⚠️ Stored messages — E2EE applies to transmission. If messages are backed up to cloud storage without E2EE (pre-2022 iCloud backups of iMessage), the backup is the vulnerability.

The Key Distribution Problem

The most underappreciated weakness in E2EE deployments: you have to actually encrypt to the right key. How does your app know the key it fetched for alice@example.com belongs to Alice?

In practice, most users trust the key server. Signal's server tells Bob's client what your key is. If Signal's server were compromised or malicious, it could substitute an attacker's key — Bob's client would silently encrypt to the attacker.

The cryptographic solution is out-of-band key verification — comparing fingerprints in person or over a phone call. Signal calls these "safety numbers." PGP calls them key fingerprints. Almost no users do this.

This is not theoretical. Law enforcement and intelligence agencies have legal mechanisms to compel service providers to serve modified key material to specific targets. A well-designed E2EE system makes this detectable — key changes trigger alerts — but only if the user notices.

Zero-Knowledge Architecture Goes Further

E2EE protects messages in transit. Zero-knowledge architecture extends protection to stored data: your messages, email, and files are encrypted before leaving your device, using keys derived from your passphrase that the server never sees.

The difference matters: an E2EE app that stores encrypted history on its servers has protected messages in transit, but the server holds ciphertext it can hand to a third party. A zero-knowledge system means the server has ciphertext and no ability to derive the keys — even a lawful demand for the encrypted data produces data that cannot be decrypted without the user's passphrase.

The Practical Checklist

When evaluating a "secure" messaging or email product, the right questions are:

Is encryption on by default? Opt-in encryption (Telegram's Secret Chats) is not a privacy feature — it's a disclaimer.
Who controls the key directory? Can the server substitute keys without detection?
Is key verification available and surfaced to users?
What metadata does the provider collect? Who-to-whom, when, and how often are often more revealing than content.
Does it require a phone number? A phone number is a carrier-issued identifier that links your identity to billing records.
Is stored data zero-knowledge, or just transit-encrypted?

E2EE is necessary. It is not sufficient. The gap between "encrypted in transit" and "actually private" is where most practical attacks live.

Haven implements end-to-end encryption for chat (MLS/RFC 9420) and zero-knowledge encryption for stored email (client-side PGP). No phone number required. havenmessenger.com

Your Encrypted App Has a Leak. It's Called Metadata.

Haven Messenger — Fri, 24 Apr 2026 20:39:03 +0000

In 2014, General Michael Hayden — former director of both the NSA and the CIA — made a remark that should have ended the "I use an encrypted app so I'm fine" line of reasoning. "We kill people based on metadata," he said. He meant it literally: drone targeting decisions had been made on communication patterns alone, with no access to message content.

Most people's threat model is considerably less dramatic. But the principle scales all the way down: metadata is a surprisingly complete record of your life, and encrypting message content leaves it entirely intact.

What Metadata Actually Is

Every message you send produces two distinct categories of information. The first is content — the words, files, and images in the message itself. The second is everything else:

Who you communicated with
When — date, time, and duration
How often — frequency and rhythm of contact
From where — IP address, which resolves to city, ISP, and often precise location
On what device — hardware identifiers, OS version, app version
Network conditions — which cell tower, which Wi-Fi network

End-to-end encryption protects the first category. The second category is produced before encryption is applied and after it's removed — it exists at the transport layer, visible to every intermediary between you and the recipient.

What a Metadata Record Reveals

A 2016 Stanford research project called MetaPhone asked 800 volunteers for their phone call metadata — just the numbers called and the call times, nothing else. Researchers found they could accurately identify:

Participants calling a cardiac arrhythmia specialist, then a medical device manufacturer → inferred: heart condition requiring a pacemaker
Participants calling a gun shop, then a background check service → inferred: firearm purchase
Participants whose call patterns to a spouse dropped off while calls to a specific number increased → inferred: affair

These inferences came from phone call metadata alone, with no access to what was said. Messaging apps generate richer metadata than phone calls. The conclusions that can be drawn are correspondingly more precise.

The Phone Number Problem

Signal's cryptography is excellent. Its metadata handling is a different story.

Using Signal requires a phone number. That number ties your Signal account to your carrier's records. Your carrier knows every number you've ever called or texted, timestamped, with tower location data. In the US, law enforcement can obtain these records with a subpoena — a significantly lower legal bar than a search warrant.

Signal introduced usernames in 2024 partly to address this, allowing users to share a username instead of a phone number with contacts. But the phone number is still required to create an account, still held by Signal, and still the underlying identity. The username is a display layer over the same infrastructure.

More fundamentally: every time you send a Signal message, your device contacts Signal's servers to deliver it. Signal knows when you are active, at what times, and with what frequency. Signal has published strong statements about the limits of what they log, and their track record of responding to law enforcement demands is genuinely good. But "trust us, we don't log that" is a policy, not a cryptographic guarantee.

The Service Provider Problem

The same dynamic applies to encrypted email services. ProtonMail encrypts your message content — they genuinely cannot read your emails. But ProtonMail's servers receive your connection, process your session, and route your messages. They know:

Your IP address at login (unless you use a VPN or Tor)
Exactly when you send and receive messages
Who you correspond with (recipient addresses are metadata, not content)
The size of each message
Your login frequency and session duration

In 2021, ProtonMail received a Swiss court order requiring them to log the IP address of a French climate activist. They complied — they were transparent that Swiss law could require this. The activist had assumed "encrypted email" meant "anonymous." It does not.

The core distinction: encryption protects your content from ProtonMail reading your emails. It does not protect your metadata from ProtonMail's servers receiving it. These are fundamentally different problems.

What Metadata Minimization Actually Requires

Reducing your metadata exposure requires more than choosing an encrypted app:

An identity that isn't your phone number. A phone number is a permanent, carrier-issued identifier tied to your billing address. Using it as your messaging identity links every conversation to that record. Email addresses can be created pseudonymously, aliased, and separated from your real identity in ways phone numbers cannot.

Aliases for compartmentalization. Using a single identifier for all communication creates a single point of aggregation. Multiple aliases — one per relationship, purpose, or context — fragment the picture, making pattern aggregation dramatically harder.

IP address protection. Your IP address reveals your location and ISP. For high-sensitivity communication, routing through a trusted VPN or Tor is the only reliable mitigation. No messaging app can fix this on its own.

Technical controls over policy controls. "We don't log" is a promise. Zero-knowledge architecture — where the server literally cannot decrypt your data — is meaningfully stronger than a logging policy. The latter can change; the former is a cryptographic constraint.

The Honest Answer for Most People

If your threat model is "I don't want Facebook reading my messages," Signal or iMessage are fine. E2EE handles that adversary cleanly.

If your threat model is "I don't want someone with legal authority over my service provider to be able to map my communication patterns," the requirements are stricter. You need an identity not tied to a phone number, IP protection, and a provider operating under legal constraints that limit what they can be compelled to disclose.

If your threat model is "I need to be effectively anonymous," no consumer messaging app currently solves that — and most make it harder by requiring phone numbers.

Encryption is a necessary component of a private communication system. It is not sufficient. Understanding what metadata reveals — and what your tools actually protect against — is the difference between privacy and the feeling of privacy.

This article was originally published on the Haven Blog. Haven is an end-to-end encrypted email and chat app that uses email-based identity — no phone number required.

WhatsApp Alternatives in 2026: The Apps That Actually Respect Your Privacy

Haven Messenger — Wed, 22 Apr 2026 01:53:20 +0000

WhatsApp's end-to-end encryption is genuine — the Signal Protocol implementation is well-audited. The problem is everything around the encryption: who you talk to, how often, from which device, and what that data means to Meta's advertising business.

Two billion people use WhatsApp. That makes it the default option for most of the world outside the US and China — and the reason most people stay isn't comfort with Meta's privacy practices, it's that leaving means losing access to most of their contacts.

This is a real problem worth naming honestly: the best private messenger in the world is useless if no one you know uses it. Any realistic evaluation of WhatsApp alternatives has to grapple with the network effect problem, not just the technical properties of the encryption.

What WhatsApp Actually Collects

First, the correct framing. WhatsApp's message content is end-to-end encrypted using the Signal Protocol. Meta cannot read your messages. When someone claims otherwise, they're wrong.

What Meta can collect, and does collect, is metadata:

Who you communicate with, and how frequently
When you're active (last seen, online status)
Your device identifiers, IP address, and location data (coarse)
Your phone number and contact list (uploaded on first run)
Usage patterns: how often you open the app, for how long
Group memberships — who you're in a group with reveals your social graph

The 2021 privacy policy update that triggered mass migration to Signal and Telegram was primarily about business accounts and integrating WhatsApp data more tightly into Meta's advertising infrastructure. The metadata collection described above existed before that update and continues.

The metadata distinction: Intelligence agencies have historically argued that "metadata is more valuable than content." Knowing that you called a particular lawyer, a particular oncologist, and a particular journalist on the same day tells a story that the content of those calls might not. Metadata is not a minor privacy footnote.

The Alternatives, Honestly Evaluated

Signal

Signal is the most technically defensible private messenger available. The Signal Protocol is the gold standard for 1:1 and group message encryption. Sealed Sender hides who is messaging whom even from Signal's servers. The organization is a nonprofit; there's no advertising business model to monetize your data.

The limitation is identity: Signal requires a phone number. Your Signal identity is permanently linked to a phone number, which is linked to your carrier, which is linked to your real name in most jurisdictions. Signal has introduced usernames as a way to avoid sharing your number with contacts, but registration still requires a phone number at the SIM level.

Best for: Personal use where you're replacing SMS/iMessage. Migration is easier than any other alternative — the UX is closest to WhatsApp.

Limitation: Phone number identity requirement. Adoption is lower than WhatsApp in most non-US markets.

Telegram is frequently cited alongside Signal as a "private" messenger, which creates significant confusion. They are not equivalent.

Telegram's default chats — including all group chats — are not end-to-end encrypted. They are encrypted in transit (client to server and server to client), but Telegram holds the keys and can read the content. Only "Secret Chats" are end-to-end encrypted, and Secret Chats are not available in group settings.

Telegram's founder Pavel Durov was arrested in France in August 2024 and faced charges related to content hosted on the platform, which led to a significant shift in the company's content moderation policies.

If your reason for leaving WhatsApp is privacy, Telegram is not the answer for sensitive communications.

Best for: Large communities, public channels, file sharing. Not for private communications.

Limitation: Default chats are not end-to-end encrypted. Treat it like a semi-public forum.

iMessage (for Apple users)

iMessage provides end-to-end encryption between Apple devices. The main caveat: iCloud Backup can undermine iMessage encryption if enabled, because backup keys are held by Apple and accessible to law enforcement. Apple's "Advanced Data Protection" (opt-in) encrypts backups end-to-end, but requires deliberate configuration and is not on by default.

iMessage is also Apple-only. SMS fallback (green bubbles) is unencrypted.

Best for: All-Apple households or teams.

Limitation: Apple-only. iCloud Backup disabled or Advanced Data Protection required for full encryption benefit.

Matrix / Element

Matrix is a federated, open-source messaging protocol. Unlike Signal or WhatsApp, there's no single company running the servers — you can host your own Matrix server or use a public homeserver. End-to-end encryption is available (MLS support in development).

Best for: Technical teams, organizations that want to self-host, developers.

Limitation: UX complexity. Non-technical users will struggle.

Haven

Haven uses email as its identity layer — no phone number required. Real-time chat uses the MLS protocol (RFC 9420) — the same standard that major messaging platforms are converging toward for group encryption. Messages are end-to-end encrypted; Haven cannot read them.

The identity model has a meaningful privacy advantage over Signal: no phone number means no link to your carrier, no SIM, and no phone registration paper trail. You sign up with an email address and a passphrase.

Best for: Users who want email and chat under one identity, without a phone number requirement.

Limitation: Smaller network than Signal or WhatsApp.

Side-by-Side Comparison

App	E2E Encrypted	Phone Number Required	Metadata Collection	Open Source
WhatsApp	Yes (content)	Yes	Extensive	No
Signal	Yes	Yes	Minimal	Yes
Telegram	Secret Chats only	Yes	Moderate	Clients only
iMessage	Yes (Apple↔Apple)	Yes (Apple ID)	Moderate	No
Matrix	Yes (opt-in)	No	Minimal (self-host)	Yes
Haven	Yes	No	Minimal	Partial

The Network Effect Problem

The biggest factor in this decision isn't the comparison table above — it's who you need to reach. A few strategies that work:

Lead with a specific group. Instead of asking everyone to switch, start with the people you communicate with most. One group on Signal is more valuable than a vague intention to move eventually.
Don't delete WhatsApp. Keeping WhatsApp for contacts who won't switch doesn't undermine your privacy for the contacts who do. Compartmentalization is valid.
Point to specific incidents. The 2021 policy change and documented metadata sharing cases are concrete. Specific incidents sometimes move people; abstract privacy arguments rarely do.

What We'd Recommend

For most people: Signal. It has the best combination of strong encryption, usability, and adoption in privacy-conscious circles. The phone number requirement is a real limitation, but it's not a dealbreaker for most threat models.

If you specifically want email-based identity and don't want to link your messaging to a phone number, Haven solves that problem — and the unified email-and-chat model reduces the app fragmentation that makes "private communication" operationally exhausting.

Avoid Telegram as a private messenger. It's a good platform for communities and channels, but its default encryption model is not appropriate for sensitive communications — and conflating it with Signal has led to real privacy failures.

Whatever you choose: the fact that you're evaluating your options means you're already ahead of the vast majority of people still sending unencrypted SMS and letting Google read their email. Perfect is the enemy of good.

This post was originally published on the Haven Blog. Haven is an end-to-end encrypted messenger that uses email as your identity — no phone number required.