You type a message and tap send. The app makes the text unreadable on your device, passes the encrypted result through a service, and the recipient’s device turns it back into words. That is the promise of end-to-end encryption: the service carrying the message does not need the secret that reveals its contents. Signal’s public protocol documentation describes the machinery behind one widely used approach.¹
The principle sounds simple, but the useful questions are more specific. How can two phones share a secret if their owners have never met? What does the server still know? And what happens when one person uses several devices?
Getting a secret to the right device
Each participant has cryptographic keys. A public key can be shared; a corresponding private key stays with the device. Messaging protocols use combinations of keys and mathematical operations to establish shared secrets without sending those secrets openly across the network. The exact setup varies by app, so this is a model of the process rather than a claim that every service uses identical steps.
When you start a conversation, your app obtains the information it needs to establish an encrypted session for the recipient. The recipient need not be online at that instant. Signal’s session-management specification, for example, describes how devices handle asynchronous messages and multiple devices.² Your phone uses the resulting session state to encrypt the message before handing it to the service for delivery.
An analogy is a locked box carried by a courier. The courier can move the box and may know its destination, but cannot open it. Real encryption has no physical box: the device transforms the message into ciphertext, a string of data that should reveal no readable content without the appropriate key. The app also uses integrity checks so that unauthorised changes are detected rather than silently accepted.³
Why the key keeps changing
A conversation does not usually rely on one permanent password for every message. In the Double Ratchet design documented by Signal, the participants derive new message keys as they send and receive.³ The old keys are not simply reused forever. This helps limit the damage if some key material is exposed: a later key should not readily reveal earlier messages, and the protocol is designed to recover security after certain compromises once new secret material is exchanged.
These properties have conditions. They depend on the app implementing the protocol properly, devices keeping secrets as intended and old keys being discarded. “Encrypted” on a marketing page is not a proof that every possible failure has been solved.
At the receiving end, the service delivers the ciphertext. The recipient’s app uses its session state to derive the matching key, checks that the encrypted data is authentic in the protocol’s sense, and decrypts it for display. If the message is waiting while the recipient is offline, the service can hold the encrypted item until delivery without holding a readable copy.
A group chat adds another layer. All intended members need a way to obtain the secrets for the group, and those secrets must be updated when membership changes. The IETF’s Messaging Layer Security standard sets out one approach to establishing and updating keys for groups; existing apps may use different designs.⁴ The essential aim is the same: the delivery infrastructure need not read the conversation.
Ordinary connections to a website may also be encrypted while travelling across the internet. The important distinction is who holds the ability to decrypt at the other end of that connection. With transport encryption alone, the service can receive readable content and then send it onwards. With end-to-end encryption, the service is outside the circle of devices that can open the message.
Encryption still has boundaries
End-to-end encryption protects the message on the route between devices. It does not make the endpoints invisible. The recipient can read, copy, photograph or forward what you send. If someone controls an unlocked phone, malicious software or an unprotected backup, the message may be available there. The Electronic Frontier Foundation stresses the difference between encryption in transit and protection of data on a device.⁵
Nor does content encryption automatically conceal every surrounding fact. A service may still learn some metadata, such as when an account connected, an IP address or information needed to route a message. What it actually collects differs between products and designs.⁵ “The provider cannot read the words” is a narrower, more reliable claim than “nobody can learn anything about this conversation”.
There is also the question of identity. Encryption can secure a connection to a cryptographic key, but you want confidence that the key belongs to the person you mean to contact. Some apps offer a way to compare safety numbers or verification codes outside the conversation. Signal describes safety numbers as a way to check that you are communicating with the right person.⁶ That step matters most where impersonation or a substituted key is a serious concern.
Finally, a padlock symbol may cover only certain parts of an app. Whether backups, linked devices, previews and group features receive equivalent protection depends on the service and its settings. Checking those details is more informative than assuming the phrase “end-to-end encrypted” covers every copy of a message in every place.
When the system works as intended, the server is a courier of sealed data. The sender’s device locks each message, the recipient’s device opens it, and changing keys help protect the conversation over time. The privacy gain is substantial, but it is located in a particular part of the journey: between the people’s devices, where the service carries information it cannot read.