End-to-end encryption vs encryption at rest: who can actually read your messages

In transit (TLS). When your phone sends a direct message, it travels over Wi-Fi, a mobile network and the internet before it reaches the service. TLS encrypts that journey, so the person running the café Wi-Fi or anyone watching the network sees scrambled traffic. But TLS ends at the server. The server decrypts the message to process it, which means the service sees the plain text.

At rest. Once the server has the message, it has to store it somewhere — a database, a disk, a backup. Encryption at rest scrambles it in storage using a key the service controls. If someone walks off with a hard drive or gets hold of a leaked database dump without the key, they get unreadable data. The service itself can still decrypt, because its application needs to show you your chat history.

End to end. With E2EE, your device encrypts the message using keys that exist only on the devices of the people in the conversation. The server stores and forwards ciphertext it has no way to open. The Signal Protocol, used by Signal and WhatsApp, is the best-known example; Telegram offers E2EE in its optional Secret Chats, while its default cloud chats use client–server encryption.

The last row matters more than people expect. Encryption protects data in places you can't see; it does nothing once the message is on a screen. A shared tablet, a friend's screenshot or a phone left unlocked defeats every model equally.

Encryption at rest gets undersold because it isn't end-to-end. It still closes real gaps. Cloud providers retire disks, backups get copied to other systems, and databases are sometimes exposed by misconfiguration. In each case, data encrypted at rest with a separately held key is useless to whoever finds it.

• Protects against: stolen or discarded storage, leaked backups and database dumps, and staff or contractors who can reach the database but not the keys.
• Does not protect against: the service reading messages through its own application, a compromise of the running application server, or a legal order served on the service.
• Depends on: how the keys are stored. At-rest encryption with the key sitting next to the data in the same database is mostly theater.

E2EE protects the content of a message. It doesn't make you invisible, and it helps to know its edges before you rely on it.

• Metadata. The service generally still knows your account, who you talk to, when, how often and from which IP address. Some apps work hard to minimize this; many don't.
• The other person. E2EE stops the service reading your message. It does not stop the recipient forwarding, screenshotting or showing it to someone.
• Backups. If your chat history is backed up to a cloud drive without its own end-to-end protection, the backup can be the weak point. Check whether your app offers encrypted backups and whether they are switched on.
• Notifications. Message previews on a lock screen are visible to anyone nearby, and notification text is handled by your phone's system software.
• The app itself. You are trusting the app on your device to encrypt properly and not leak keys. Open-source clients and published security reviews make that trust easier to check.

If E2EE is stronger, why do so many services choose encryption at rest? Because a server that can't read messages also can't do things people expect from it. These are real engineering trade-offs, not excuses.

1. 1

   Search

   Server-side search across years of messages needs readable text. E2EE apps search on your device instead, which only covers what that device has downloaded.

2. 2

   Moderation of reported messages

   On an at-rest service, a moderator can open a reported conversation and see what happened. On an E2EE service, the report has to include the messages from the reporter's own device, because the server can't decrypt anything.

3. 3

   Multi-device sync and history

   With at-rest encryption, you log in on a new browser and your full history is there. With E2EE, every device needs its own keys, and history on a new device depends on a transfer or an encrypted backup. Lose your only device without one and your history can be gone for good.

4. 4

   Account recovery

   A password reset on an at-rest service restores everything, because the service holds the keys. With E2EE, the service often can't restore what it never could read.

5. 5

   Large groups and web access

   Encrypting for every member's devices gets more complex as groups grow, and web clients have to handle keys carefully. Many E2EE apps solve this well today, but it is more work.

None of this makes E2EE optional for high-risk conversations. It explains why a community app and a secure messenger can reasonably make different choices, and why you should know which one you're using.

Asyncbit's messaging is a clear example of the at-rest model, and it says so. Messages are encrypted at rest on the server with Fernet, a standard scheme that combines AES-128 in CBC mode with an HMAC-SHA256 signature, so stored messages are both scrambled and tamper-evident. Messages are not end-to-end encrypted.

What that means in practice: a leaked copy of the message store without the key is unreadable, but the service itself can decrypt. That is what lets moderators review a message someone has reported, which matters on a social network where content moderation depends on seeing what was actually said. Push previews stay generic — “New message” — so the text of a chat is not placed in a push notification that passes through your phone's notification system.

1. Read the exact wording. “Messages are encrypted” with no qualifier usually means in transit, at rest, or both. Services that offer E2EE say “end-to-end” explicitly, and say which chats it covers.
2. Check whether it's on by default. Some apps offer E2EE only in a special chat mode you have to start deliberately.
3. Look for security codes. E2EE apps usually let you compare a safety number or QR code with a contact to confirm no one is sitting in the middle.
4. Think about recovery. If you can reset your password on a brand-new device and see your full history with no backup step, the service very likely holds the keys.
5. Read the moderation policy. If staff can review reported messages from the server, those messages aren't end-to-end encrypted.

For the wider picture beyond messages — profiles, posts and who can find you — see our guide on protecting your privacy on social media, and the plain-language definitions of end-to-end encryption and encryption at rest.

Whatever you choose, the basics still carry most of the weight: a strong unique password, a locked phone, and thinking twice before sending something you'd hate to see screenshotted.