Zero Trust & Encryption

Zero trust is not a policy. It is a structural property. The relay receives ciphertext, has no keys, and cannot read what it routes — regardless of who operates it.

TL;DR

  • Layer 1 — Addressed encryption. Each blob is encrypted on-device for its specific recipient. Only that recipient’s private key can open 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. Nothing else.

Two Layers of Encryption

trueseal encrypts data at two distinct layers, for two distinct purposes. They are independent — Layer 1 protects the blob at rest (even if the relay’s database is captured), Layer 2 protects the channel in transit (even if network traffic is intercepted).

Layer 1 — Addressed Encryption (at rest)

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

The encryption uses X25519 key agreement combined with ChaCha20-Poly1305 authenticated encryption. The sender performs a Diffie-Hellman exchange with the recipient’s static public key to derive a shared secret, then encrypts the payload with that secret. The result:

  • Only the intended recipient can decrypt
  • Cannot be read by the relay, any intermediary, or any other device
  • Is authenticated — any tampering renders it undecryptable

The sender’s identity (author_pub) is not a visible header on the envelope. It is prepended inside the plaintext before encryption. The relay never sees who sent a blob — only who it is addressed to.

This encryption is independent of any live network connection. A blob encrypted this way can be stored on the relay and decrypted later by the recipient, with no session active at the time of encryption.

Layer 2 — Noise Sessions (in transit)

The transport channel between a device and the relay is protected by the Noise Protocol Framework. Two session types are used:

Receive Sessions use the Noise XX handshake pattern — mutual authentication. Both the device and the relay verify each other’s static public keys. The result is a forward-secret, authenticated channel. If session keys are compromised after the fact, past traffic cannot be decrypted.

Push Sessions use the Noise NK handshake pattern — the device verifies the relay’s static public key, but the relay never learns the device’s identity. A fresh ephemeral keypair is generated for each push. Push sessions are closed immediately after 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 the ciphertext. This provides two guarantees:

Tamper detection. Any modification to the envelope after signing — changing the recipient, altering the ciphertext, replaying an old sequence number — invalidates the signature. The recipient discards the envelope silently.

Sender binding. The sender’s identity (author_pub) is inside the encrypted payload. When the recipient decrypts the envelope, they extract author_pub and verify the signature matches. A device cannot impersonate another — if device B encrypts a payload claiming to be from device A, the signature check fails because the signature was made with B’s key, not A’s.

Senders not in the current Group Manifest are discarded after signature verification. The manifest is the authoritative list of trusted devices. See Sync Groups for how membership is managed.

What the Relay Knows

The relay observes the recipient public key per blob (required for routing) and which keys have active Receive Sessions (required to deliver immediately). It does not learn who sent any blob, which devices belong to the same group, or anything about content. An adversary who compromises the relay entirely — binary, database, network — gains a list of public keys that received blobs, and nothing else.

See What the Relay Sees in Architecture for the by-component breakdown.

What Zero Trust Does Not Cover

Zero trust protects against a compromised or malicious relay. It does not protect against:

  • A compromised device. If an attacker has access to a device’s private key, they can decrypt any blob addressed to that device and impersonate it as a sender. Device security is the caller’s and the platform’s responsibility.
  • Traffic analysis at the network level. The relay knows which IPs connect and when. An adversary with network-level access can observe connection patterns even without reading content. trueseal does not route through a mix network or provide timing anonymity.
  • Blobs sent before a compromised device is removed. If a device is removed from a group, it cannot decrypt future blobs. It retains the private key for any blobs it received before removal. See Revocation.