BitTorrent Peer Handshake Verification Explained

The BitTorrent protocol relies on a mandatory, fixed-structure handshake to establish and verify communication between two peers before any data exchange can occur. This article details the exact structure of the 68-byte handshake message, how clients validate the protocol identifier, the process of matching the cryptographic infohash against active swarms, and the validation of unique peer IDs to prevent communication errors and self-connections.

The Handshake Packet Structure

When a BitTorrent client initiates a TCP connection to a remote peer, it immediately sends a raw 68-byte handshake message. The message consists of five distinct fields transmitted in sequence:

1. Protocol Length (pstrlen): A single byte defining the length of the protocol identifier string. In standard BitTorrent (version 1.0), this value is 19 (0x13 in hex).
2. Protocol Identifier (pstr): A byte string containing the protocol name. Standard implementations use the ASCII string "BitTorrent protocol".
3. Reserved Bytes (reserved): An 8-byte extension field. All bits were originally set to zero, but modern extensions (such as Fast Extension BEP 6 or Extension Protocol BEP 10) use specific bits within these 8 bytes to signal extended feature support.
4. Infohash (info_hash): A 20-byte SHA-1 hash of the info dictionary extracted from the torrent’s .torrent metainfo file.
5. Peer ID (peer_id): A 20-byte string chosen by the client to uniquely identify itself across the swarm.

Verification Steps

Upon receiving the initial bytes over a connection, the receiving peer executes a strict sequence of verification checks:

1. Protocol String Validation

The receiving client reads the first byte (pstrlen) and verifies that it matches the expected length of 19. It then reads the subsequent 19 bytes to ensure the string exactly matches "BitTorrent protocol". If the length or string does not match, the connection is deemed non-BitTorrent traffic and is immediately closed.

2. Infohash Matching

The receiver reads the 20-byte info_hash sent by the initiator and compares it against its internal table of currently active torrents. * If matched: The receiver confirms both peers are participating in the exact same swarm. * If mismatched or unknown: The receiving peer drops the connection immediately, as it cannot serve or receive data for an unmanaged swarm.

3. Handshake Response and Asymmetry Handling

• Outbound Connections: When client A connects to client B, client A sends its handshake first. Client A waits for client B’s handshake response and verifies that client B’s 20-byte info_hash matches the hash client A requested.
• Inbound Connections: When client B receives an inbound handshake, it validates the infohash, and if recognized, sends its own matching 68-byte handshake back to client A.

4. Peer ID Verification and Loop Prevention

Once the infohash is verified, the client inspects the 20-byte peer_id: * Self-Connection Detection: A client compares the received peer_id to its own ID. If they match, the client has connected to itself (e.g., via NAT loopback or duplicate tracker entries) and terminates the socket immediately. * Tracker Consistency: If the remote peer was obtained from a tracker that included the peer’s expected ID, the client may verify that the received peer_id matches the tracker’s record, dropping connections that mismatch to prevent impersonation.

Post-Handshake Transition

Only after all five fields are fully parsed and verified does the state of the connection change to active. The peers may then interpret subsequent data on the wire as standard length-prefixed BitTorrent messages, such as bitfield, have, unchoke, and request.