The short answer
Correctly implemented end-to-end encryption means message content is encrypted on the sender’s device and can be decrypted only by the intended receiving endpoints. The delivery service should handle ciphertext, not plaintext or conversation keys. But E2EE protects a path between endpoints—it does not make either endpoint, the recipient, every piece of metadata, or every backup trustworthy.
What “end to end” actually means
The endpoints are the devices or application instances that hold the keys needed to read a conversation. Encryption happens before the message leaves the sender’s endpoint; decryption happens after it reaches an authorized receiving endpoint.
That boundary matters. Transport encryption such as TLS protects a connection between a device and a server. End-to-end encryption adds a separate message-level boundary intended to keep the intermediary from receiving the plaintext keys. The IETF’s Messaging Layer Security standard describes the goal as making messages accessible to communicating endpoints rather than the servers delivering them.
A product label alone is not proof. Identity authentication, key management, group membership changes, old-key deletion, implementation quality, and the behavior of backups all affect the real security result.
What E2EE is designed to protect
The exact guarantees depend on the protocol and implementation, but modern authenticated E2EE is intended to address these risks:
Network interception
Someone observing Wi-Fi, an ISP, or an intermediate network should see encrypted traffic rather than readable message content.
A curious service provider
A delivery service that does not hold conversation keys should not be able to open ordinary message ciphertext.
Delivery-server compromise
Message-level encryption can preserve content confidentiality even if the infrastructure routing or temporarily queuing ciphertext is compromised.
Undetected message changes
Authenticated encryption can allow recipients to reject ciphertext that was altered or forged, subject to correct key authentication and implementation.
Some past-message exposure
Protocols with forward secrecy delete or advance old key material so a later key compromise does not automatically reveal all earlier messages. This is an additional protocol property, not a synonym for E2EE.
What E2EE does not automatically protect
Most security misunderstandings begin when protection of message content is treated as protection of the entire communication system.
A compromised or unlocked endpoint
Malware, an unlocked stolen device, notification previews, screenshots, keyboards, and accessibility services may encounter plaintext before encryption or after decryption.
The person receiving the message
An authorized recipient can copy, photograph, quote, or forward what they can legitimately read. Disappearing controls reduce retained history; they cannot make a hostile recipient forget.
All metadata
Delivery can expose timing, traffic volume, IP addresses, destinations, device tokens, or group operations. Protocols and architectures can minimize or shield parts of this metadata, but content encryption alone does not remove it.
Unencrypted backups and exports
If plaintext history or recoverable keys are copied into another system, that copy has its own security boundary. “The chat is E2EE” does not prove that every backup is.
Who is really at the other end
Encryption to the wrong or substituted key can create a perfectly encrypted conversation with the wrong party. Key verification and trustworthy identity binding remain important.
Availability and coercion
A service can still delay, block, rate-limit, or delete encrypted traffic. E2EE also cannot prevent a person from being compelled to unlock an endpoint or disclose what they know.
Threat model: does E2EE help?
A useful security question names the adversary instead of asking whether an app is simply “encrypted.”
| Scenario | Does E2EE protect content? | What else matters |
|---|---|---|
| Network observer intercepts traffic | Usually yes | Strong protocol, secure implementation, traffic-analysis limits |
| Delivery server is breached | Usually yes | Keys must remain on authorized endpoints; metadata may remain visible |
| Phone is stolen while unlocked | No | Device lock, local storage protection, notification policy, short retention |
| Recipient intentionally records the message | No | Trust, policy, watermarking, limited disclosure, legal controls |
| Attacker substitutes an identity key | Not by itself | Key verification, transparency, authentication, change warnings |
| Service refuses to deliver messages | No | Availability design, monitoring, alternate communication plan |
How City of Hats handles this boundary
City of Hats treats E2EE as one layer in a wider threat model. The statements below describe our published architecture and product behavior; they are not a claim that software can eliminate endpoint risk or recipient behavior.
Message-level encryption
City of Hats documents client-side E2EE for Hat-to-Hat messages, files, and calls, using hybrid X25519 and ML-KEM-768 key establishment with a Double Ratchet and AES-256-GCM. Conversation decryption keys are intended to remain on authorized devices.
Technical transparency →Less registration identity
A Hat can be created without a phone number or email. Phrase IDs, multiple Hats, and disposable Hats reduce the need to tie every communication context to one carrier or mailbox identity. They do not make a compromised device or network connection anonymous.
Disposable Hats →Relayed encrypted calls
City of Hats documents relayed voice and video so the other participant does not receive a direct peer-to-peer IP address. The relay handles encrypted media, while network-level metadata still requires a realistic threat model.
Encrypted calls →No conversation recovery path
The consumer messenger is designed without a provider-held message recovery vault. Losing the only authorized device can mean losing the message history. That improves resistance to server-side recovery demands but is a deliberate availability tradeoff.
Privacy and data handling →Controls after delivery
View Once, Recall, GeoLock, Certified Send, Channel Seal, and other security modes can limit normal access or retention. These controls reduce exposure; they cannot defeat an authorized recipient using a second camera or an already-compromised endpoint.
Security modes →Burnable communication contexts
Hats and channels can be burned or allowed to expire so a long-lived identity and unlimited conversation history are not mandatory. Destruction reduces what remains available later; it cannot retract information already captured outside the protected system.
Channel Seal →How to evaluate an encrypted messenger
Do not stop at the phrase “end-to-end encrypted.” Ask the provider or its documentation:
- Which communication types are E2EE by default—messages, groups, files, calls, and business interactions?
- Where are keys generated, stored, rotated, backed up, and deleted?
- How are identity keys verified, and what happens when a key changes?
- What content and metadata can the service observe or retain?
- What happens on a compromised, lost, or newly linked device?
- Can recipients export, forward, capture, or permanently retain content?
- Are protocol specifications, source code, audits, or reproducible technical evidence available?
- What security properties are independent of E2EE, such as forward secrecy, post-compromise security, metadata resistance, and availability?
The bottom line
End-to-end encryption is essential because it can remove the delivery service and the network from the set of parties trusted with message content. It is not the entire privacy system. Strong secure communication also depends on endpoints, identity, metadata, retention, recovery, recipient behavior, and honest documentation of tradeoffs.
Primary sources and further reading
Standards and first-party technical materials used for this article. Accessed 9 August 2026.
- IETF RFC 9420. The Messaging Layer Security (MLS) Protocol
- IETF RFC 9750. The Messaging Layer Security (MLS) Architecture
- NIST SP 800-124 Rev. 2. Guidelines for Managing the Security of Mobile Devices
- Signal. Sealed Sender: metadata and message delivery
- Signal. Disappearing messages and the hostile-recipient boundary
City of Hats product statements link to our own published documentation and should be evaluated as first-party claims until independently verified.
← Back to the Knowledge Center