Zero Trust & Encryption

Zero trust here isn’t a policy you opt into. It’s a structural fact. The relay receives ciphertext, holds no keys, and can’t read what it’s routing — and that doesn’t change based on who’s running the relay.

TL;DR

  • Layer 1 — Addressed encryption. Each blob is encrypted on the device for one specific recipient. Only that recipient’s private key opens it.
  • Layer 2 — Noise sessions. The transport channel between device and relay is encrypted and forward-secret.
  • Signatures. Every envelope is Ed25519-signed; tampering and impersonation both fail verification.
  • What the relay sees. Recipient public keys. That’s it.

Two layers of encryption

trueseal encrypts at two different layers for two different reasons. They’re independent. Layer 1 protects the blob at rest, even if someone walks off with the relay’s database. Layer 2 protects the channel in transit, even if someone is sitting on the network.

Layer 1 — Addressed encryption (at rest)

Before a blob leaves the sender’s device, it gets encrypted separately for each recipient. The blob is addressed to a specific public key, and only the holder of that key’s private half can decrypt it.

The mechanics: X25519 key agreement combined with ChaCha20-Poly1305 authenticated encryption. The sender does a Diffie-Hellman against the recipient’s static public key to derive a shared secret, then encrypts with it. End result:

  • Only the intended recipient can decrypt.
  • The relay, any middlebox, any other device — none of them can read it.
  • Tampering breaks the authentication tag, so it just won’t decrypt.

The sender’s identity (author_pub) isn’t a visible field on the envelope. It’s prepended inside the plaintext before encryption, so the relay never knows who sent what — only who it’s going to.

None of this depends on a live connection. A blob encrypted this way can sit on the relay for a while and still decrypt cleanly when the recipient finally shows up.

Layer 2 — Noise sessions (in transit)

The transport between a device and the relay is wrapped in the Noise Protocol Framework. Two session shapes, two handshake patterns:

Receive Sessions use Noise XX — mutual auth. Device and relay each verify the other’s static public key. The result is a forward-secret authenticated channel: even if a session key leaks later, past traffic stays unreadable.

Push Sessions use Noise NK — the device verifies the relay’s static public key, but the relay never learns who the device is. A throwaway ephemeral keypair is generated for each push, and the session is closed the moment the blobs are sent.

Signatures

Every envelope is signed by the sender’s Ed25519 signing key. The signature covers the sequence number, parent hashes, recipient public key, and ciphertext. That gets you two things:

Tamper detection. Change anything — flip a byte of ciphertext, swap the recipient, replay an old sequence number — and the signature stops matching. The recipient drops the envelope without ceremony.

Sender binding. The sender’s author_pub lives inside the encrypted payload. When the recipient decrypts, they pull author_pub out and check the signature against it. Device B can’t pretend to be device A: if B encrypts a payload and labels it as A’s, the signature was made with B’s key, so verification fails.

After signature verification, the sender is checked against the current Group Manifest. Anything from a key that isn’t a member gets discarded. The manifest is the authoritative trusted-device list — see Sync Groups for how it’s managed.

What the relay knows

It sees the recipient public key on each blob (needed for routing) and which keys have active Receive Sessions (needed to deliver immediately). It doesn’t see who sent a blob, doesn’t see groups, doesn’t see content. Compromise the relay fully and you walk away with a list of public keys that received blobs, and nothing else.

For the by-component breakdown, see What the Relay Sees in Architecture.

What zero trust doesn’t cover

Zero trust covers a malicious or compromised relay. It does not cover:

  • A compromised device. If an attacker has a device’s private key, they can decrypt anything addressed to that device and forge messages as it. Device security is on the OS, the platform, and the application — not on us.
  • Network-level traffic analysis. The relay sees which IPs connect when. Anyone watching the network can observe connection patterns without reading any payload. trueseal doesn’t run over a mix network and doesn’t pretend to give you timing anonymity.
  • Blobs already received before removal. If a device gets kicked from a group, it can’t decrypt anything new — but anything it already received and decrypted is its forever. See Revocation.