What makes messaging private: a look at Zyphr

"Private messaging" is on the home page of nearly every chat app, and it means very different things depending on who says it. We wanted to write down what actually makes secure messaging private, and what does not, using one app as a worked example. We picked Zyphr, a messenger we like and work near, mainly because it publishes an unusually plain description of its own architecture, including the parts that encryption does not fix.

Zyphr is made by Zyphr LLC, not by us. Everything we say about it below comes from its own public pages, the architecture notes and the security page. We have not audited it, and as its security page says, no formal third-party audit has been completed yet. Read this as an explanation of concepts, not a recommendation.

End-to-end encryption, and what it covers

End-to-end encryption (E2EE) means a message is encrypted on the sender's device and only decrypted on the recipient's device. The servers in between carry ciphertext. They can lose it, delay it or hand it to someone with a court order, but they cannot read it.

That is different from transport encryption, the TLS that protects nearly all traffic on the web. TLS protects the message between your phone and the server, and between the server and the other phone. The server itself sees plaintext. Plenty of chat products use only transport encryption for some or all conversations, and describe that as "encrypted," which is true and not very helpful.

Zyphr's architecture page makes the distinction explicitly: transport encryption and end-to-end encryption are separate layers, and the message is encrypted end to end before it takes any route at all. That is the property you want to check for first in any messenger.

Signal Protocol for one-to-one, MLS for groups

The hard part of E2EE is not encrypting a single message. It is managing keys across months of conversation, multiple devices and people who are offline half the time.

For one-to-one chats, the widely used answer is the Signal Protocol. It combines an initial key agreement, which lets you start an encrypted session with someone who is offline, with the Double Ratchet, which derives a fresh key for every message. The practical effect is forward secrecy: if a key leaks today, it does not expose messages from last month. Zyphr uses libsignal, the Signal Protocol library, in its Rust core for direct messages, and lists X3DH key agreement plus the Double Ratchet on its security page. It also uses safety numbers, a short code two people can compare to confirm they are talking to the right device and not to someone in the middle.

Groups are harder. Encrypting every group message separately to every member works for small groups but gets clumsy as people join, leave and add devices. Messaging Layer Security, standardised as RFC 9420, was designed for this. Members agree on a shared group key, and every membership change advances the group to a new epoch with new keys. Zyphr uses MLS through the mls-rs library: a new member receives a Welcome message, and membership changes are applied through a Commit that moves the group forward an epoch.

Zyphr adds a caution here that applies well beyond its own app. Properties like forward secrecy and post-compromise security come with assumptions and conditions. They are not a promise that a compromised device becomes safe again on its own.

Metadata: the part encryption leaves behind

Encryption hides what you said. It does not hide that you said something, to whom, when, how often, from which network, or how big the message was. That is metadata, and for many threats it matters more than content. Knowing that two people exchanged forty messages at 2am the night before a story broke can be enough.

Messengers reduce metadata in different ways. One is not tying accounts to phone numbers. Zyphr does not require a phone number. You sign up with an email address or supported Apple or Google sign-in, and find people by username or optional email-based discovery. Its comparison page adds a caveat we think is exactly right: no phone number does not mean anonymous, and hashing email addresses does not remove account metadata.

Another is sealed sender, where the envelope around a message hides who sent it from the server that delivers it. Zyphr uses sealed-sender envelopes from libsignal. Its security page lists what the operator would hold if asked: hashed emails, public keys and short-lived sealed envelopes. It also says clearly that it does not defend against traffic analysis by a global passive adversary, and that it is not a censorship-circumvention tool. That kind of statement is a good sign in any security product. Vague claims of total anonymity are not.

Peer to peer, relays and push

Zyphr prefers peer-to-peer (P2P) delivery. When both devices can connect, a message travels over a WebRTC data channel straight from one phone to the other, without sitting in a queue on a server. When a direct network path is not available, TURN can relay the encrypted traffic between the connected peers. When the recipient is offline, a sealed-message relay holds the encrypted envelope and delivers it later.

P2P sounds more private, and in one sense it is: fewer messages rest on a server. But it has its own cost. Direct peers can learn each other's network address, and E2EE does not hide that. Zyphr's architecture page says so, and adds that P2P-first does not mean serverless or always direct, since the service still handles accounts, discovery, connection setup and push notifications. Its comparison page puts it more bluntly: P2P alone does not establish superior privacy, and relay delivery can preserve E2EE. We agree. The route changes who sees the metadata. It does not change who can read the message.

Push notifications are the other unavoidable server. On iOS and Android, an app that is not running cannot listen for messages itself, so it relies on Apple Push Notification service (APNs) or Firebase Cloud Messaging (FCM) to wake it. Zyphr sends encrypted wake-ups through both. Apple and Google cannot read the content, but they can see the timing of those wake-ups. Every mobile messenger that uses system push shares this limit to some degree. It is one of the reasons metadata never quite reaches zero on a phone.

The endpoint is still the weak point

The strongest cryptography in the world ends at the screen. Zyphr's architecture page lists three things encryption does not solve, and they apply to every messenger we know of:

• A compromised endpoint. Someone who controls an unlocked device can read whatever that device can read. Malware on the phone sees messages after they are decrypted.
• Your recipient. They can copy, screenshot, photograph or forward anything you send. Encryption is not control over another person's device.
• All metadata. Delivery needs infrastructure, and infrastructure produces records of accounts, timing and routing.

On the device itself, Zyphr says sensitive fields are encrypted at rest with keys protected by the iOS Keychain, identity keys are generated on the device, and the server's trust root is pinned in the app so a forged sender certificate is refused. There is also an App Lock for chats. Those measures raise the bar for someone who picks up a locked phone or tampers with the server. They do not help against malware on an unlocked device, which Zyphr lists as out of scope.

What to look for in any messenger

If you are choosing a messenger, or building one, these are the questions we would ask, using Zyphr's published answers as a template for what a clear answer looks like:

• Is every conversation end-to-end encrypted by default, including groups?
• Which protocols, and which libraries implement them?
• What does the operator hold, and what would it hand over?
• Is a phone number required, and what identifies you instead?
• How are backups protected? Zyphr's are optional and passphrase-encrypted, which means losing the passphrase means losing the backup.
• What is explicitly out of scope, and has anyone independent checked the claims?

Zyphr is available on iOS, with Google Play marked as coming soon. Its comparison page sets it next to Signal, SimpleX, Threema, Telegram and WhatsApp with sources for each claim, and labels itself as published by Zyphr rather than an independent ranking. We would like more products to write their security pages this way, with a section on what they do not defend against sitting right next to the section on what they do. If you are thinking about the same trade-offs for an app of your own, our note on minimal app permissions covers the device side.