Sealed Sender: Hiding Who Talks to Whom

End-to-end encryption is the part everyone talks about, and it is the part a patient adversary worries about least. The plaintext of your message is sealed — fine. But the envelope still has to be addressed, and in most “encrypted” messengers the address is written in the clear: Alice to Bob, 3:47 PM, again at 3:49, again at 3:52. That routing pair, repeated across millions of deliveries, is the social graph. It is who you trust, who you organize with, who you call when something is wrong. Content encryption does nothing to hide it. Sealed sender is RVNT’s answer to the half of the problem the marketing usually skips.

The routing pair is the leak

To deliver a message, infrastructure needs a destination. That much is unavoidable — something, somewhere, has to know where the envelope goes next. The mistake most systems make is also stapling the source to the envelope, so a server can show a “from” field, enforce rate limits, or attach a read receipt. Now the server holds both halves: (from, to).

A server that holds (from, to) over time does not need to read a single message to do damage. It can:

• reconstruct your contact graph and rank your closest ties by frequency,
• timestamp the first contact between two parties — the moment a journalist and a source connect,
• infer urgency from message cadence and document exchange from size,
• and hand all of it to anyone with a subpoena or a budget.

“We kill people based on metadata.” — Michael Hayden, former director of the NSA and CIA.

That line is not about content. It is about the routing pair. So the design question is narrow: deliver an envelope to the recipient without ever putting the sender’s identity where the network can see it.

How sealing works

The core move is simple to state. The sender encrypts a certificate that names their own identity to the recipient before handing the envelope to the network. The network gets a delivery address and an opaque blob. The “from” field has been moved inside the ciphertext, where only the recipient’s key can reach it.

In RVNT the mechanics are below, and you can read the implementation in rvnt-crypto/src/sealed_sender.rs rather than take our word for it:

1. The sender generates a fresh ephemeral X25519 keypair for this one envelope. It is unlinkable to their long-term identity and is zeroized after use.
2. The sender does a Diffie-Hellman between that ephemeral secret and the recipient’s X25519 identity public key, then runs the result through HKDF — domain-separated with rvnt-sealed-sender-v1 — to derive an envelope key.
3. Inside the envelope the sender places a sender certificate: their X25519 identity key, their Ed25519 verifying key, an expiry, and an Ed25519 self-signature binding all three together.
4. The certificate is sealed under the envelope key with AES-256-GCM. The message body it travels with is already encrypted by the Double Ratchet.

The recipient runs the same DH from the other side — their identity secret against the envelope’s ephemeral public — derives the identical key, opens the blob, and only then learns who sent it. The sender’s long-term key never appears in any field the network can read. Because the envelope key comes from the recipient’s key and a throwaway ephemeral, there is nothing on the outside to correlate one sealed message to the next.

What the relay actually sees

recipient   : the recipient's routing address
ephemeral   : one-time X25519 key (unlinkable)
sealed_body : opaque AES-256-GCM ciphertext

The relay sees a destination it can route to and an opaque blob. Everything that would identify the sender is inside sealed_body. The full envelope layout is in the sealed sender spec.

The obvious objections

Moving the sender into the ciphertext raises three fair questions. If the network can’t see the sender, can’t anyone forge one, replay an old envelope, or flood a recipient anonymously? Each has a concrete answer.

Forgery — recipient-side certificate verification

Anonymity to the network is not anonymity to the recipient. After unsealing, the recipient verifies the certificate’s Ed25519 self-signature with verify_strict, which rejects malleable, non-canonical signatures and small-order keys. The signature covers the identity key, the verifying key, and the expiry as one unit, so altering any field invalidates it. An attacker who lacks the sender’s private key cannot mint a certificate that names someone else — there is an explicit test (unseal_rejects_forged_signature) that fails the build if unseal ever accepts one. Sealing hides the sender from the network; it does not let a stranger impersonate one of your contacts.

Replay — expiry plus the ratchet

The certificate carries a signed expiry, which bounds how long a captured envelope is worth anything; tampering with that field breaks the signature. Inside that window the Double Ratchet finishes the job: each message key is used once and deleted, so a replayed envelope decrypts to nothing — its key no longer exists. Replay protection here is a property of the ratchet, not a database of seen message IDs that a server would have to keep — and that log would itself become a metadata store.

Abuse — the recipient is the filter

Servers usually need a sender identity to rate-limit. RVNT does not have that lever, and does not want it, because the sender identity is exactly the leak we are removing. That trade has a real cost: the work of deciding who gets through moves to the edge. The recipient is the final filter — an unknown sender is not auto-trusted just because an envelope arrived. The benefit is that the door never logs the guest list. We would rather you do your own bouncing than build the surveillance database that “from”-based rate limiting requires.

Composing with Tor and the mixnet

Sealed sender closes the application-layer leak. It does nothing about the network layer — on its own it would leave your IP address as the new “from” field. That is why it never ships alone:

• Tor carries every envelope over QUIC through onion circuits — 3 hops standard, 5 in maximum-privacy mode — using the embedded arti client, so no single relay sees both your IP and the destination.
• The mixnet, in maximum-privacy mode, batches messages, adds randomized timing delays, and runs cover traffic, attacking the timing correlation that sealing and Tor alone leave exposed.
• Fixed-size padding keeps message length from becoming its own identifier.

Stack them and the picture is: the network can’t see your IP (Tor), can’t read who sent the envelope (sealed sender), can’t line messages up by timing (mixnet), and can’t fingerprint by size (padding). Each layer covers a different observer. See the threat model for how they interlock.

What sealed sender does not do

Honesty is the point, so the residual exposure is worth naming plainly.

• The recipient learns the sender. By design. You have to know who you are talking to. A contact who screenshots, forwards, or hands their device to someone else can reveal that you wrote to them. Sealing protects you from the infrastructure, not from your correspondent.
• The recipient address is still observable. The network sees that some envelope reached a given recipient, even if not from whom. The volume and timing of deliveries to that recipient stay partly visible — which is precisely what Tor, the mixnet, and padding exist to muddy.
• A global passive adversary watching the entire internet at once, with enough correlation power, is outside the model. No mix system fully defeats an observer who sees every link simultaneously. We say so on the security page instead of pretending otherwise.

Sealed sender is one tool that does one job well: it takes the sender’s name off the envelope before the network ever touches it. The code is AGPLv3 and public. Don’t trust the description — read sealed_sender.rs, follow the signature-verification path, and try to forge a certificate. If you can, tell us.