Why even you can't decrypt the message you just sent

A common assumption about end-to-end encryption: the sender always has the key to their own messages. They wrote the plaintext, so surely they kept whatever they used to encrypt it.

BlindPost doesn't work that way. Once you send a message, the encrypted bytes that travel through our infrastructure cannot be decrypted by anyone except the intended recipient — not us, not by you after the send completes, not even if your phone is later compromised. Your own phone keeps a plaintext copy locally so you can see what you wrote in your chat history. But the ciphertext that moves through our servers and rests on the recipient's path is sealed against everyone but them.

Here's the architectural reason, at the level of standard crypto primitives.

What happens when you send a message

When you tap send, your client roughly:

1. Generates a fresh, single-use X25519 keypair just for this one message. Call it the ephemeral key. It lives only inside the send operation. It is never written to disk, never persisted in your account, never transmitted anywhere in raw form.
2. Computes a shared secret by doing Elliptic-Curve Diffie–Hellman between this ephemeral private key (yours, just now) and the recipient's published public key.
3. Derives a session key from the shared secret using HKDF, with a domain-separation label binding both your user identifier and the recipient's identifier into the key derivation.
4. Encrypts the plaintext under that session key, using an authenticated cipher with associated data binding sender / recipient / timestamp into the authentication.
5. Signs the ciphertext with your long-term identity private key, so the recipient can verify the message really came from you.
6. Packages ciphertext + signature + ephemeral public key + routing metadata into an envelope, and sends it.
7. Returns. The local variable holding the ephemeral private key drops out of scope. Garbage-collected. Gone.

What ends up traveling through our infrastructure:

• The encrypted ciphertext.
• The ephemeral public key (not the private — the private was discarded the moment the send completed).
• Your signature on the ciphertext.
• Minimum routing metadata (sender / recipient identifier, timestamp).

What's required to decrypt the ciphertext:

• ECDH between the ephemeral private key (gone) and the recipient's public key (visible), OR
• ECDH between the recipient's private key (in their phone's secure storage) and the ephemeral public key (visible).

Exactly one party in the universe can do that math: the recipient. And only while they still hold the relevant private key — we rotate prekeys, and users can retire old keys themselves.

You — the sender — let the ephemeral private go out of scope when the send returned. Nobody on our infrastructure ever saw it. The recipient never saw it either; they only have the public half, plus their own private key, which is the other piece of the same Diffie–Hellman math.

Why this matters: a threat-model walkthrough

Scenario 1: your phone is stolen today. Attacker dumps everything — every key in secure storage, every byte of your local database. They get:

• Your long-term identity private key (used for signing, not for encryption).
• Your current short-term private key (used to decrypt messages people send to you).
• Plaintext copies of every message you've sent (your client keeps these locally for chat history).

What they cannot do: retroactively decrypt the ciphertext versions of those messages, wherever those ciphertexts might exist (on our infrastructure, in backups, in evidence-locker copies). Each one was encrypted with a different ephemeral key, none of which exist anywhere on your phone any more.

Scenario 2: stack it with a full server compromise. Add an attacker who also exfiltrates every encrypted envelope. Cross-referenced with the keys from scenario 1, they still cannot decrypt your sent messages. The math doesn't close.

What this combined capability does yield:

• Decryption of messages people sent to you, by using your short-term private (until you rotate).
• Plaintext that your local database happens to still hold (already on your phone).
• The ability to forge new messages signed as you going forward, until your contacts revoke trust.

What it does not yield:

• Retroactive plaintext for the encrypted envelopes corresponding to messages you sent. Those entered a one-way math box that needs either the ephemeral private (gone) or the recipient's private (theirs alone).

Group messages: same property

Group sends use the same shape, with the recipient's public key replaced by the group's public key (which is what defines the group). Each send mints a fresh ephemeral private, runs Diffie–Hellman against the group's public key, encrypts, signs, drops the ephemeral. Even if every member of a large group were compromised tomorrow and every byte of stored ciphertext were exfiltrated, your past sends remain mathematically out of reach to anyone who doesn't hold either (a) one of the long-gone ephemeral privates, or (b) the group's private key, which only members ever held, and only on their devices.

Why we built it this way

A simpler end-to-end protocol can keep a stable, sender-known key for encryption — encrypt with my long-term key, deliver the same key under the recipient's public key, decrypt on either side. Faster. But that protocol has a brittle property: the sender's compromise = retroactive decryption of every message they ever sent, anywhere those ciphertexts were stored. Including backups. Including server copies that hadn't been deleted yet. Including subpoenaed copies sitting in evidence lockers years from now.

The ephemeral-per-message Diffie–Hellman pattern (sometimes called sender forward secrecy, or "fire-and-forget encryption") removes that attack surface entirely. The cost is a few extra milliseconds of crypto per send. The benefit is that any future you, any future compromise, any future cooperative-by-court-order key disclosure — none of those can pull plaintext from the past-sent ciphertexts that left your device.

Your past is sealed even from yourself. That's the property we wanted.