End-to-End Encryption Explained: Transport, At Rest and True E2E
What end-to-end encryption really means, how it differs from transport and at-rest encryption, and what it can and cannot protect. A clear guide.
Almost every app now says it is encrypted. Banks, email providers, cloud drives, social networks and messengers all use the word, and all of them are telling the truth in some sense. The problem is that "encrypted" describes at least three very different arrangements, and only one of them keeps the company running the service out of your conversations.
This guide explains the difference in plain language: encryption in transit, encryption at rest, and end-to-end encryption. It covers what each one protects, what it leaves exposed, and the questions worth asking before you trust any app with something private. It also explains how VOIDEX, an invite-only platform built around end-to-end encryption, draws those lines in practice.
A simple picture: the letter and the courier
Imagine sending a letter across a city. It passes through a courier, sits in a sorting office for a while, and is finally delivered.
- Transport encryption is an armoured van. The letter is safe on the road, but at the sorting office it comes out of the van and anyone working there can open it.
- Encryption at rest is a locked filing cabinet in the sorting office. Thieves who break in cannot read the letters, but the office itself holds the key and can open the cabinet whenever it likes.
- End-to-end encryption is a letter sealed in a box that only you and the recipient can open. The van, the sorting office and the filing cabinet all handle a box they cannot open, because the key never leaves the two ends.
That last arrangement is the only one where the service provider is genuinely unable to read what you wrote.
Encryption in transit
Encryption in transit protects data while it travels across a network. On the web this is almost always TLS, the protocol behind the padlock in your browser. The current version, TLS 1.3, was published by the IETF in 2018 and is excellent at what it does: it stops people on the same Wi-Fi network, internet providers and anyone tapping a cable from reading or altering traffic between you and a server.
But TLS ends at the server. The server decrypts the traffic in order to process it, so the company running that server sees everything in the clear. For most websites that is fine and necessary. For private messages it means the provider, anyone who compromises the provider, and anyone who can legally compel the provider all have access to the content.
Encryption at rest
Encryption at rest protects stored data: databases, disks, backups. If someone steals a hard drive or copies a backup file, they get scrambled bytes.
This is valuable, and good services do it by default. Yet the keys for at-rest encryption normally live with the service, because the service needs to read the data to show it to you. A breach that reaches the running system, rather than a stolen disk, usually reaches the keys as well. At-rest encryption protects against lost hardware and careless backups. It does not protect you from the provider.
End-to-end encryption
End-to-end encryption, often shortened to E2E, means the message is encrypted on the sender's device and only decrypted on the recipient's device. The keys are created on those devices and never handed to the server. Everything in between, including the provider's own infrastructure, handles ciphertext only.
The result is a change in who you have to trust. With transport and at-rest encryption you trust the company to protect your data. With end-to-end encryption, the company does not have the ability to read it in the first place.
That distinction became urgent in 2024, when investigators disclosed that state-backed hackers known as Salt Typhoon had penetrated major US telecommunications networks. In December 2024, officials at CISA and the FBI urged people to use end-to-end encrypted messaging, and CISA published mobile communications guidance recommending it. When the network itself cannot be trusted, only encryption that ends on your device helps.
What end-to-end encryption does not do
End-to-end encryption is powerful, but it is not magic. Being clear about its limits is part of using it well.
- It does not hide metadata by itself. A server still has to know where to deliver a message. Who talks to whom, when and how often can reveal a great deal. We cover this in metadata is the message.
- It does not protect an unlocked device. If someone holds your phone open in their hand, they can read what is on the screen.
- It does not stop the other person. The recipient can screenshot, forward or photograph a message. Encryption protects the path, not the person at the other end.
- It depends on the right keys. If an attacker can quietly substitute their own key for your contact's key, they can sit in the middle. This is why key verification and key transparency matter.
- It must be implemented well. A strong algorithm inside a careless app can still leak. Open code and published designs let outsiders check.
Questions to ask any "encrypted" app
A short checklist cuts through most marketing:
- Where are the keys created, and where do they live? If the answer is "on our servers", it is not end-to-end.
- Is end-to-end encryption on by default? Optional encryption that most people never switch on protects very little.
- Does it cover groups, calls and media, or only one-to-one text?
- How are contacts' keys verified, and can key changes be audited?
- Is the cryptographic code open for inspection?
- Is there a plan for quantum computers? Encrypted traffic recorded today could be decrypted later, a threat known as harvest now, decrypt later.
How VOIDEX draws the lines
VOIDEX is built so that the private parts of the platform are end-to-end encrypted by default, and the public parts are clearly labelled as public.
In VOIDEX Messenger, keys are created on members' devices and the servers store only public keys and ciphertext. Direct messages begin with a hybrid post-quantum key agreement, X25519 combined with ML-KEM-768, and then run on a double ratchet with post-quantum re-keying, so each message has its own key. Identities are signed with hybrid Ed25519 and ML-DSA-65 signatures. Groups and private VOIDEX Channels use MLS, the IETF standard published as RFC 9420.
To address the key substitution problem, every device key change is appended to a public, append-only Merkle log, and VOIDEX clients refuse keys that are not in it. The cryptographic core is open source at github.com/voidexbycnota/voidex-crypto, and the design is set out in the public security report.
Just as important is what VOIDEX does not claim. Public posts in VOIDEX Space and Public channels are not end-to-end encrypted, because they are meant to be seen by others, and VOIDEX labels them that way. Private channels are end-to-end encrypted. Knowing which space you are in is part of the promise, and we explain that boundary in detail in what the server cannot see.
There is one more deliberate choice. Each member has a VOIDEX recovery code that opens their message history on a new device. VOIDEX never holds that code, so a lost code cannot be restored by anyone, including VOIDEX. The encrypted history copy is intentionally not forward-secret, because that is what lets the code open the past, and members can switch it off if they prefer the strictest posture.
Why the distinction is worth learning
The three kinds of encryption are not rivals. A well-built service uses all of them: TLS on the wire, encryption on the disk, and end-to-end encryption for anything that should stay between people. The mistake is to hear "encrypted" and assume the strongest of the three.
Once you know the difference, product pages become easier to read. "Encrypted in transit and at rest" means the provider can read your data. "End-to-end encrypted" means it should not be able to, provided the keys stay on your devices and the implementation holds up to scrutiny. The rest of the story, metadata, verification, open code, quantum readiness, tells you how seriously a service has taken the job.
VOIDEX is invite-only. Request access to message inside a platform where private means end-to-end, or read how VOIDEX encryption works before you decide.
Sources
Enter VOIDEX
VOIDEX is invite-only and free, with no ads and no trackers. Messages are protected by hybrid post-quantum encryption (X25519 with ML-KEM-768) and checked against a public key transparency log. VOIDEX runs in your browser and as apps for Windows and Mac, with iPhone and Android on the way.
Explore the Voidverse
VOIDEX is one private universe: post-quantum encrypted messaging, an anonymous social layer, short video, collectibles and a private window onto the web.
Keep reading
Disappearing Messages, Screenshots and Delete: An Honest Guide
How disappearing messages, screenshot control, editing and delete for everyone really work, what they protect, and the limits no app can remove.
Forward Secrecy and the Double Ratchet, Explained Clearly
Forward secrecy and post-compromise security explained: how the Double Ratchet gives every message its own key, and how VOIDEX adds post-quantum re-keying.
How Encrypted Voice and Video Calls Work: WebRTC, DTLS-SRTP, TURN
How encrypted voice and video calls really work: WebRTC, DTLS-SRTP, TURN relays and the call setup problem, and how VOIDEX seals the SDP in every call.