Encryption in a client
Torrent encryption is a feature that scrambles the connection between two peers so that equipment on the network in between cannot recognize it as a transfer, and it was built to stop networks slowing that traffic down, not to make anybody anonymous. It covers the bytes on the wire and the handshake that used to identify the protocol on sight. It does not cover the one thing people usually assume it covers, which is the fact that a particular address is in a particular swarm. Understanding the difference between those two is the whole of the subject.
What protocol encryption was built to stop
Protocol encryption was built to stop traffic shaping. In the middle of the 2000s, peer to peer transfer had become a large and easily recognized share of consumer internet traffic, and network operators responded by identifying it and throttling it. Identification was straightforward because the protocol opened every connection with a fixed, distinctive handshake: a length byte, a known protocol name, reserved bytes, then the 20 byte info hash. Anything watching the first few bytes of a connection could label it in an instant and treat it differently from the rest.
Client developers answered with message stream encryption, a scheme layered over the existing connection. Two peers perform a Diffie-Hellman key exchange, derive a shared key and encrypt the stream with it, so the recognizable opening disappears into random-looking bytes. The design goal was obfuscation, and it succeeded at that goal. It was never designed as a privacy system, and the developers of the time did not describe it as one.
What the encryption actually covers
The encryption covers the connection between two peers and nothing outside it. Once negotiated, the protocol messages and the 16 KiB blocks of payload they carry are encrypted, and a passive observer on the path sees an ordinary looking stream of bytes, on whatever port the client is using rather than the 6881 to 6889 range the protocol was once identified by. The obfuscation can be applied to the handshake alone or to the whole stream, and clients let that be chosen because full stream encryption costs a small amount of processing on both ends.
Two limits are structural rather than accidental. There is no authentication in the scheme, because two anonymous peers have no way to know who the other is, so it offers nothing against an attacker positioned between them who is willing to participate rather than just watch. And it protects one connection at a time: the announce a client makes to a tracker is a separate exchange over its own protocol, and unless that tracker itself is reached over an encrypted transport, protocol encryption does not touch it. Distributed hash table traffic is similarly its own thing.
What stays visible whatever the setting says
What stays visible is the shape of what you are doing and the fact that you are doing it with a specific set of peers. Encryption changes what an observer on the wire can read; it does not change who is in the swarm or how the swarm finds them.
| What an observer can see | Encryption off | Encryption on |
|---|---|---|
| The protocol handshake, identifying the connection on sight | Visible | Hidden |
| The contents of the pieces being exchanged | Visible | Hidden |
| The info hash inside the peer handshake | Visible | Hidden on that connection |
| Your address, to every peer you connect to | Visible | Visible |
| Which swarm you joined, to anyone who joins it too | Visible | Visible |
| Many simultaneous connections to scattered addresses | Visible | Visible |
| The volume and duration of what you moved | Visible | Visible |
The bottom four rows are the point. A swarm is a public membership by construction: anybody can join one, connect to the peers in it and write down what they find, and the encryption setting has no bearing on that at all. Traffic analysis is also unaffected, since a machine holding dozens of concurrent connections to unrelated addresses for hours has a recognizable profile whether or not each stream is readable.
The encryption mode setting, and what each position costs
Set the encryption mode in the client's connection preferences, where it usually appears as three positions rather than a switch. qBittorrent presents an encryption mode with a choice to prefer encryption, to require it, or to disable it, and Deluge and Transmission express the same idea in their own wording, with some clients splitting incoming and outgoing connections into separate settings.
- Prefer encryption
- Negotiates an encrypted connection where the other peer supports it and falls back to a plain one where it does not. This is the default in most clients and it costs nothing in reachable peers.
- Require encryption
- Refuses any peer that will not encrypt. It removes the fallback, and the price is a smaller pool of usable peers, which is felt on a small swarm and barely noticed on a large one.
- Disable encryption
- Accepts and makes plain connections only. It saves a negligible amount of processing and restores the recognizable handshake.
A transfer that suddenly connects to very few peers after the setting was moved to require is showing the expected behavior, not a fault. The words used around this setting, peer, swarm, handshake and info hash, are set out in the Glossary.
Why Syncthing encrypts for a completely different reason
Syncthing encrypts because its devices know each other, which is the opposite situation to a swarm. Every Syncthing device holds its own certificate, its device identifier is derived from that certificate, and a device only talks to devices whose identifiers were added deliberately at both ends. The connection is protected by TLS, and because the endpoints are authenticated, the encryption actually means something about who is at the other end.
Protocol encryption in a torrent client cannot make that claim and does not try to. Its peers are strangers reached through a tracker or a distributed hash table, so there is no identity to verify and nothing to compare a certificate against. The two features share a word and almost nothing else: one keeps a private folder private between machines that belong to the same person, and the other keeps a public transfer unrecognizable to equipment in the middle of the path.