What an End-to-End Encrypted Server Can and Cannot See

"We cannot read your messages" is one of the strongest promises a company can make. It is also one of the easiest to misunderstand. End-to-end encryption removes the provider from the list of people who can read what you write, but it does not make the provider blind. A server still has to store things, route things and run a service, and each of those jobs leaves it holding something.

This article is an honest map of that territory. It sets out what an end-to-end encrypted service holds, what it genuinely cannot see, and what it can still observe. It then explains exactly where VOIDEX draws those lines, including the parts of VOIDEX that are public by design.

What the server holds

In a properly built end-to-end encrypted system, the server stores two main kinds of cryptographic material.

Public keys. Every device generates its own key pairs. The private halves never leave the device. The public halves are uploaded so that other people can encrypt to you and verify your identity. Public keys are, as the name says, meant to be public. Holding them lets the server help people find each other's keys, not decrypt anything.

Ciphertext. Messages, files, voice notes and images are encrypted on the sender's device before upload. The server stores and forwards the scrambled result. Without the private keys, which it does not have, ciphertext is only noise with a size attached.

That is the heart of the promise. A breach of the server, a rogue employee or a legal demand for message contents all run into the same wall: the content was never there in readable form.

What the server cannot see

When end-to-end encryption is done well, the provider cannot see:

• The text of your messages, in one-to-one chats or in encrypted groups.
• The contents of media and files you send in those conversations.
• Your private keys, because they are created and kept on your devices.
• Old messages after a key is retired, where forward secrecy is in place, because the keys that opened them no longer exist.

These guarantees are only as strong as two supporting pieces. First, the provider must not be able to quietly swap in its own key for your contact's key, which is the job of key transparency. Second, the implementation must be open to inspection, so that outsiders can check the promise instead of taking it on trust.

What the server can still see

Here is the part that marketing tends to skip. Any service that delivers messages between people needs to know enough to deliver them. That means some metadata is visible to the system:

1. That an account exists, and roughly when it was created.
2. Which devices are registered, because messages must be encrypted to each of them.
3. Routing information, meaning which conversation a piece of ciphertext belongs to and which accounts should receive it.
4. Timing and size, meaning when something was sent and how large the encrypted blob is.
5. Network information, such as the IP address a device connects from, which any internet service sees at the moment of connection.

Different services reduce this in different ways. Signal, for example, developed sealed sender to hide the sender of a message from its own servers, and publishes the legal requests it receives and what it was able to hand over. These are good practices, and they show that metadata is taken seriously by the best teams in the field.

Metadata matters because patterns reveal a great deal even without content. Who contacts a lawyer, a doctor or a journalist, at what hour and how often, can tell a story on its own. We explore this in metadata is the message. The honest position is that end-to-end encryption protects content, and metadata needs separate, deliberate work.

A thought experiment: the breach

It helps to picture the worst day. Imagine an attacker copies the entire database of an end-to-end encrypted messenger. What do they walk away with?

They get a directory of public keys, which were public anyway. They get a very large pile of ciphertext that they cannot open without private keys that were never on the server. And they get whatever metadata the service kept: account records, device lists, perhaps delivery logs. The content of private conversations is not in the haul.

Now run the same experiment against a service that only uses transport and at-rest encryption. The database keys usually sit near the database, so the attacker leaves with the messages themselves. The difference between those two outcomes is the entire value of end-to-end encryption, and it is also why the metadata that remains deserves attention.

Public is public

There is a second category that no encryption scheme can hide from a server: things you publish on purpose.

A public post exists to be read by strangers. If it were end-to-end encrypted to every possible reader, the server would still need to hand out the key to anyone who asked, which is the same as not encrypting it. Services that mix private messaging and public posting therefore have two very different zones, and the most important privacy feature is making sure you always know which one you are standing in.

Where VOIDEX draws the line

VOIDEX is built around that boundary, and it is explicit about it.

The private zone. In VOIDEX Messenger, keys are created on members' devices, and VOIDEX servers store only public keys and ciphertext. Direct messages use a hybrid post-quantum key agreement, X25519 combined with ML-KEM-768, followed by a double ratchet with post-quantum re-keying, so each message has its own key. Groups and private VOIDEX Channels use MLS, the IETF standard RFC 9420. Every device key change is written to a public, append-only log that clients check before trusting a key.

The recovery code. Each member has a VOIDEX recovery code that opens their message history on a new device. VOIDEX never holds it. That is why a lost code cannot be restored by anyone, and why VOIDEX cannot open that history either. The encrypted history copy is deliberately not forward-secret, because that is what lets the code open the past, and members can switch it off. More in own your keys.

The public zone. Public posts in VOIDEX Space and Public channels are not end-to-end encrypted. They are meant to be seen, VOIDEX can read them like any public post, and VOIDEX labels them as public so there is no ambiguity. Private channels, by contrast, are end-to-end encrypted.

Even in the public zone, VOIDEX limits what a post gives away about you. Images are re-encoded before publishing, which removes EXIF data such as GPS coordinates, and videos have capture metadata such as location, device model and creation time stripped before a post goes public. If a file cannot be cleaned, it is refused rather than published raw.

And every member has two identities in Space: a public Face and an anonymous VOIDEX Phantom. VOIDEX never publishes a link between a Phantom and the person behind it, and Phantom content is stored under the Phantom only.

Search. VOIDEX Pulse reaches the web through VOIDEX, so the sites and search engines you visit never see who is asking, and your search history is encrypted with a key only your devices hold.

How to read any privacy promise

A useful habit, whatever service you use, is to ask three separate questions instead of one:

• Content: can the provider read what I write? End-to-end encryption answers this.
• Metadata: what does the provider learn about who, when and how often? This needs its own answer.
• Publication: which parts of the service are public by design, and are they clearly marked?

A trustworthy service answers all three plainly, including the parts that are not flattering. The full VOIDEX answer is set out in the public security report, and the cryptographic core is open source at github.com/voidexbycnota/voidex-crypto for anyone who prefers to read the code.

VOIDEX is invite-only. Request access to a platform that tells you exactly what its servers hold, or start with the VOIDEX security report.

Sources

• Signal: Technology preview, sealed sender (2018)
• Signal: Government communication and subpoena responses
• RFC 9420: The Messaging Layer Security (MLS) Protocol
• VOIDEX cryptographic core on GitHub