Sealed Sender: Hiding Who Talks to Whom
Sealed sender hides who is messaging whom from the server. Learn how the technique works, its real limits, and why a no-account design protects you further.
By The PrivacyPortal Team
Sealed sender is a technique that hides who sent a message from the server relaying it. The message body is already end-to-end encrypted, but sealed sender goes one step further and encrypts the sender's identity too — so the server can route your message to its destination without ever learning who dropped it in the envelope.
That distinction matters more than it first sounds. End-to-end encryption protects what you say. Sealed sender is one of the few mainstream attempts to protect who you say it to — the part of messaging that leaks even when the content is locked tight.
What sealed sender actually does
Think of a normal encrypted message as a sealed letter. The contents are unreadable, but the outside of the envelope still carries a return address and a destination address. Anyone handling the letter — including the postal service — can log who wrote to whom, how often, and when.
Sealed sender erases the return address. The recipient's app can still prove the message is authentic once it arrives, but the relay in the middle can no longer tie the message back to a specific sender account.
Mechanically, a messenger normally authenticates you to the server before it will deliver anything on your behalf. Sealed sender replaces that step: your credentials are moved inside the encrypted payload, backed by a short-lived sender certificate and a delivery token the recipient can verify. The server sees an incoming blob addressed to a recipient, and delivers it — without a verified identity attached. Recipients typically choose whether to accept sealed-sender messages from anyone or only from existing contacts.
Signal is the best-known implementation of sealed sender, and it deserves credit for shipping it as a default part of a widely used, open-source app.
Why "who talks to whom" is so sensitive
Content is only half of a conversation's story. The pattern of contact — the metadata — is often enough on its own.
Consider what the following reveal without a single word of message text:
- A reporter's phone contacting a government office late at night, repeatedly, the week before a leak.
- A steady stream of messages between two people who are each married to someone else.
- A burst of contact with a divorce lawyer, an addiction helpline, or an oncologist.
Metadata is also cheap to collect, easy to store, and trivial to analyze at scale — precisely because it's small and structured. That's why "who talks to whom, when, and how often" is a prize target, and why hiding the sender is worth the engineering effort. We go deeper on this in messaging metadata explained.
What the server can still see
Here's the honest part that marketing pages often skip: sealed sender is a real improvement, but it is not invisibility.
Even with sealed sender switched on, a relay can typically still observe:
- The recipient. The message has to be delivered somewhere, so the destination remains visible.
- Your IP address and network. Your connection still originates from a real place, which can be logged and correlated with timing.
- Timing and size. When messages appear and how big they are can be enough to link two ends of a conversation.
Signal itself has been candid that sealed sender reduces metadata rather than eliminating it. And crucially, sealed sender is an add-on bolted to a system that still has accounts underneath. Signal requires a phone number to register (usernames can now hide that number from other users, but the account still exists). The sender identity is hidden on a given message — but the account it belongs to is still real and still registered.
A different route: no account to unmask
Graphite approaches the same problem from the other end. Instead of hiding a sender who has an account, it removes the account entirely.
There is no account on the Graphite server. Your identity is a 12-word recovery phrase generated on your device — never a phone number, never an email. The server has no user record to map a message back to, because there is no user record. There's nothing to unmask.
That structural choice pairs with a few others that close the gaps sealed sender leaves open:
- The relay only ever sees sealed ciphertext. It never touches plaintext, your keys, or your recovery phrase. Messages carry a 7-day maximum time-to-live and are deleted after delivery is acknowledged — a design we unpack in what a no-logs messenger really means.
- Tor is on by default, fail-closed. Graphite bundles Tor and routes signaling and messages to a hidden service, which hides your IP and network — the correlation vector that sealed sender alone doesn't address.
- Encryption is layered. Message encryption uses NaCl/libsodium X25519 sealed boxes with a hybrid post-quantum layer (ML-KEM-768), and forward secrecy comes from a Signal-style double ratchet.
One honest caveat, because it's a real trade-off: live voice and video call media travels peer-to-peer over DTLS-SRTP rather than through Tor, for latency reasons. On mobile, those calls are routed so the other person doesn't see your IP.
Sealed sender vs. a no-account design
| What the server can learn | Sealed sender (on an account system) | No-account + onion routing |
|---|---|---|
| Sender identity | Hidden per message | No account identity exists |
| Recipient | Usually visible | Delivered to a routing address, not a registered user |
| Your IP / network | Typically visible | Hidden via Tor by default |
| Underlying account | Still required (e.g. a phone number) | None — a 12-word phrase on-device |
| Message content | End-to-end encrypted | End-to-end encrypted (+ post-quantum layer) |
The point isn't that one is "encrypted" and the other isn't — both encrypt content well. The difference is what's left to leak around the content.
The honest limits
No design is magic, and it's fair to say so.
Sealed sender is a genuinely good feature, and Signal minimizes metadata further than most mainstream apps. If a phone-number account fits your threat model, it's a strong, well-audited choice. Routing over Tor, meanwhile, costs latency, and Graphite is currently a free public beta. Different tools suit different risks, and the goal here is to explain the mechanics honestly rather than to declare a winner.
If you're weighing options across the whole category, our encrypted messenger guide lays out the trade-offs side by side.
The bottom line
Sealed sender answers a real question — how do you hide the sender from the middle? — and answers it well within a system that still keeps accounts. A no-account design answers a broader one: if there's no account and no IP to see, there's far less "who talks to whom" to hide in the first place.
Try it for yourself. Graphite is a free, end-to-end-encrypted messenger from PrivacyPortal — no phone number, no email, no logs. It runs on Windows, Android, and the web. See graphite.chat.