Sealed Sender
Also known as: sealed-sender envelope, sender anonymity, anonymous sender
Sealed sender is a technique that encrypts the sender's identity inside the message envelope, so the relay or server delivering the message learns the recipient but never sees who sent it. A short-lived signed sender certificate is sealed alongside the ciphertext; only the recipient can unwrap it. It removes the cleartext "from" field that would otherwise let an intermediary build a social graph of who talks to whom.
In an ordinary messaging system, a relay needs a "to" address to deliver a message, but the "from" address rides along in the clear. That single field is enough for an operator (or anyone who compels it) to map every conversation: who contacted whom, and when. Even an end-to-end-encrypted service that cannot read your words can still record that Alice messaged Bob at 3:47 PM.
Sealed sender removes the cleartext sender. The sender builds a sender certificate — their identity public key, username, and a timestamp, signed with their own key — and places it inside an encrypted envelope addressed to the recipient. The relay sees only an opaque blob plus a recipient identifier. When the recipient decrypts the envelope, they recover the certificate and verify the signature, so they (and only they) learn who actually wrote the message.
Signal introduced this design in 2018, sealing a short-lived sender certificate inside the envelope. The crucial honest caveat: sealed sender hides identity from the server and network, not from the recipient — by design, your contact must know who you are. And on its own it does nothing against traffic analysis: an observer watching packet timing and volume can still correlate sender and receiver. That is why it is one layer, not the whole answer.
How it works
The sender generates a fresh ephemeral key per message and does a Diffie-Hellman with the recipient's key — never their own — so no public field links back to the sender. That shared secret is run through HKDF to derive an envelope key, and the certificate plus the ratchet-encrypted body are sealed under AES-256-GCM. The relay sees: a recipient identifier, the ephemeral public key, and ciphertext. The recipient repeats the DH, decrypts, verifies the sender's signature, and checks the timestamp to reject replays.
How RVNT uses Sealed Sender
RVNT seals every message: a fresh per-envelope X25519 ephemeral key DH'd against the recipient's identity key derives the envelope AES-256-GCM key, wrapping a signed sender certificate plus the ratchet payload. The relay sees only a 20-byte truncated BLAKE3 recipient ID and opaque ciphertext. Combined with Tor (hiding IP) and the mixnet (hiding timing), it closes the metadata gap. See sealed sender.
Frequently asked questions
Does sealed sender hide who I am from the person I'm messaging?
No, and that is intentional. Sealed sender hides your identity from the relay and any network observer, but the recipient unwraps a signed sender certificate so they can confirm who you are. You cannot have an authenticated conversation without the other side knowing who they are talking to.
If sealed sender hides the sender, why does RVNT still need Tor and a mixnet?
Because sealed sender only removes the cleartext "from" field. It does nothing about your IP address (Tor handles that) or the timing and volume of your traffic, which traffic analysis can correlate. The three layers cover different parts of the metadata problem.
Can the server tell two sealed messages came from the same sender?
Not from the envelope itself. RVNT derives a fresh ephemeral key per envelope and runs the Diffie-Hellman against the recipient's key, so no public field links two messages to a common sender. Linkage would have to come from network-level signals like IP or timing, which Tor and the mixnet address.
Every definition here describes something RVNT actually ships — a post-quantum, end-to-end-encrypted, peer-to-peer messenger with no phone number and no servers.