What a File Transfer Relay Can Actually See

A relay is any server that sits between two endpoints and forwards their traffic: a signaling server that passes connection details, a WebSocket relay that forwards file chunks, a TURN server that forwards WebRTC packets, or a mail server that stores a message until it is collected. End-to-end encryption (E2EE) means the relay forwards ciphertext it has no key for. The difference between E2EE and TLS is exactly this: TLS protects the hop to the server, E2EE protects the payload from the server.

What E2EE cannot protect is the information the relay needs to do its job. To deliver a message it must know where it goes. To keep a connection open it sees the address the connection comes from. To forward bytes it sees how many there are and when they arrive. That is metadata: data about the communication rather than in it. Some metadata is unavoidable (the relay must route), some is a design choice (a protocol that sends the file name next to the ciphertext could have encrypted it), and some leaks through side channels such as packet sizes.

The useful question about any encrypted transfer service is therefore not “is it encrypted?” but “what does each party in the path still see?”. The IETF frames the same question in RFC 6973, which asks protocol designers to list which observers can see which identifiers, and in RFC 7624, which treats metadata collection as part of the pervasive-surveillance threat.

Length deserves special attention because it survives almost every encryption scheme. AES-GCM, the mode most modern tools use, is built on counter mode: the ciphertext is exactly as long as the plaintext, plus a 16-byte authentication tag per sealed message (NIST SP 800-38D). Chunked file formats add a small fixed overhead per chunk, so the total ciphertext size reveals the file size almost exactly.

Traffic analysis is the practice of drawing conclusions from metadata alone. It rarely needs the content. Three patterns cover most of what an observer can learn:

• Correlation. If one IP address sends 2.1 GB to a relay while another receives 2.1 GB from it over the same minutes, the two are talking, even if the relay never logged the pairing. Anyone who can see both sides of the relay (its operator, or a network observer near it) can make this match.
• Fingerprinting. A file with a distinctive exact size can be identified by size alone when the observer already has a copy of the candidate file. Sequences of sizes, such as the pages of a website, are even more distinctive.
• Graph building. Collected over weeks, membership and timing turn into a map of who communicates with whom, how often, and who connects otherwise separate groups.

None of this breaks the encryption. It works because encryption was never designed to hide these things, which is why “end-to-end encrypted” and “private” are different claims.

Encrypt the fields that do not need to be visible

The cheapest fix is protocol design: put the file name, type and size inside the encrypted payload instead of next to it. The relay still sees an approximate size from the ciphertext, but no longer the name. This costs nothing at runtime and is the first thing to check in any tool.

Padding

Padding rounds lengths up so that different payloads look alike. TLS 1.3 lets endpoints pad records but explicitly leaves the padding policy out of scope (RFC 8446, section 5.4). For files, padding to coarse buckets (for example the next power of two) hides the exact size at the cost of sending up to twice the data, which is why file transfer tools rarely do it.

Mixnets

A mix network, an idea going back to David Chaum's 1981 paper on untraceable mail, collects messages from many users, delays and reorders them, and often adds cover traffic, so an observer cannot match what goes in with what comes out. The price is latency measured in seconds or more, which suits messaging better than multi-gigabyte live transfers.

Tor and onion routing

Tor routes traffic through a circuit of relays (three by default), each of which knows only the previous and next hop. The destination does not learn the user's IP address, and no single relay sees both ends. Tor does not add delays or cover traffic, so its design paper is explicit that an adversary watching both ends can correlate them by timing. Tor also carries only TCP streams, so UDP-based WebRTC connections cannot run over it directly.

Policy: keep less

An operator that holds metadata only in memory, keeps nothing after a session ends and pseudonymises its logs reduces what can later be subpoenaed, leaked or sold. This is a promise rather than a cryptographic property, so it is only as good as the operator and the code it runs, but it limits damage after the fact.

Going direct

A direct peer-to-peer connection removes the relay from the data path, but it swaps one observer for another: the peers learn each other's IP addresses through ICE candidates (RFC 8828 covers how browsers limit this). A signaling server is still needed to introduce them.

SRIFT is open source, so this inventory is taken from its code (version 4.3.2) rather than from marketing. It covers three observers: the SRIFT server (session signaling, the WebSocket relay for file chunks, the quick-share relay and the AgentNet relay), the third-party TURN services that may carry a WebRTC connection, and the other participant.

What SRIFT keeps

The server has no database. Sessions, members and pending offers live in RAM; idle sessions are dropped after 7 days, and join requests that the host has not answered expire after 5 minutes. Quick-share bytes are forwarded from the sender's process to the downloader and not stored. Log lines pass through a filter that replaces IP addresses, session codes and user IDs with HMAC tags under a random per-process key, and usernames are redacted; file names are not written to the logs. The AgentNet relay likewise holds presence, cards and its search index in memory and delivers only to agents that are online.

• Keep names out of the clear. In SRIFT, a quick-share link made with --encrypt (or --password) moves the name, size and type into the encrypted metadata block. In a live session, the offer carries the real name, so a neutral file or archive name is the only way to hide it.
• Assume the size is known. Neither SRIFT nor most other tools pad files. If the exact size is sensitive, put the file in an archive with padding of your own.
• Hide your address if it matters. A direct connection shows your IP to the other peer, and every relay sees it. A VPN moves that exposure to the VPN provider; Tor spreads it across relays, at a large cost in speed.
• Prefer native protocols over bridges. SRIFT's native AgentNet messages are end-to-end; messages entering through the A2A bridge are not.
• Ask every service the same questions. Which fields travel unencrypted? What is logged, and for how long? Who runs the relays and TURN servers? Can the operator see who talks to whom? The P2P threat model lists more, and STUN vs TURN explains when a TURN relay is in the path at all.