Encrypted in transit or end-to-end?

‘Your messages are encrypted’ doesn’t mean much unless you specify who holds the keys. There are two very different architectures behind this statement.

Encrypted in transit

The message is encrypted between you and the server, then decrypted on arrival, stored, and re-encrypted before being sent to the recipient.

Alice --(figure)--> [S] --(figure)--> Bob
                      (S, the server, reads everything in plain text)

A network observer cannot see anything. But the server, however, reads everything. It often does so for good reasons: searching the history, filtering, previews.

This is the model used by most email services and many messaging apps.

End-to-end encryption

The key exists only on the devices. The server simply carries content that it cannot access.

Alice --(figure)--> [S] --(figure)--> Bob
                      (S can only see an opaque block)

The message is encrypted at Alice’s end, decrypted at Bob’s end, and no one in between can access it — including the service provider.

The right question

When faced with a service that claims to offer encryption, ask yourself: can the server read my messages?

There are two tell-tale signs. If you can view your entire history from a new device without providing anything other than your password, the server probably holds the keys. And if the service offers server-side full-text search, it must be reading the content.

The cost

End-to-end encryption isn’t free. Searching becomes difficult, as does backing up data, and losing your keys means losing your messages — the service cannot restore anything.

This isn’t a design flaw but the direct trade-off for the guarantee: a service provider unable to read your messages is also unable to return them to you.