Traffic analysis against a mediator

What a mediator can and cannot see lists the metadata a mediator necessarily holds. This page is the follow-on question: what can somebody actually do with it? Read that page first, this one assumes it.

The adversaries, and they are not the same

• The mediator operator. Sees everything the service records: connection times, routing keys, sizes, delivery events. The most capable observer by a distance, including when the operator is us.
• A network observer. Sees encrypted traffic to and from the mediator's endpoint: source addresses, timing, volume. Not routing keys, which are inside the encrypted envelope.
• A correspondent. Sees what you send them, plus the timing of your replies.
• Someone who compromises the mediator. Inherits the operator's view, plus stored queues, still ciphertext, because the mediator holds no key that opens it.

What each of them can infer

Relationship discovery. Consistent traffic between two routing keys establishes a relationship without a word of content. The mediator does not need to know who you are to know that you two talk.

Schedule extraction. Pickup timing is a direct read on when an agent is awake. Over weeks that is a timezone, a working pattern, and the days you were absent. See Pickup Protocol 3.0, every pickup is a beacon.

Event detection. Quiet, then a burst. You may not learn what happened, but you learn that something did, and precisely when. In many settings that is the sensitive part; the content is predictable once the event is known.

Message-class fingerprinting. Sizes cluster by kind. A ping, a credential presentation and an attachment-bearing message occupy different size bands, and the 1 MiB envelope cap makes the top of that range narrow. See queue depth and backpressure.

Cross-referencing. The strongest attack is rarely internal to the mediator. Timing observed here, correlated with an event visible elsewhere, links a routing key to a real-world identity, and no property of the mediator prevents that.

What Solidus Relay does about it

Nothing, and we would rather say so than imply otherwise. No padding to uniform envelope sizes. No cover traffic. No batching or mix-network delay. No timing jitter.

Those are real techniques with real costs, latency, bandwidth, complexity, and we have not paid them. If your adversary can observe the mediator, a mediator is the wrong layer to solve that at.

What you can do

1. Pairwise routing keys. The cheapest and most effective control available to you: a distinct key per correspondent means the observer sees several apparently-unrelated recipients. Note the limit, the mediator's own keylist still groups them, per keylist management. See pairwise DID.
2. Decouple pickup from events. If you collect messages on a schedule rather than on arrival, your pickup timing stops being a readout of your activity.
3. Keep envelopes uniform-ish. Move bulk out of band; a reference is a smaller and less distinctive envelope than a payload.
4. Run your own mediator where the operator's view is the thing you cannot accept, see vs running your own mediator. It moves the observation point rather than removing it, which is sometimes exactly enough.
5. Route less. The most reliable defence against traffic analysis is traffic that does not exist.

The honest summary

End-to-end encryption protects what you say. It does not protect that you said it, to whom, how often, or when, and a mediator sits precisely where those four are visible. Anyone selling a mediator as a privacy product without this page is selling the first sentence and hiding the second.