Introduction #

BIP324 proposes a new Bitcoin P2P protocol, which features transport encryption and slightly lower bandwidth usage. The entire document with specification is being discussed here, however the motivation and high-level design are below.

Motivation #

Bitcoin is a permissionless network whose purpose is to reach consensus over public data. Since all data relayed in the Bitcoin P2P network is inherently public, and the protocol lacks a notion of cryptographic identities, peers talk to each other over unencrypted and unauthenticated connections. Nevertheless, this plaintext nature of the current P2P protocol (referred to as v1 in this document) has severe drawbacks in the presence of attackers:

  • While the relayed data itself is public in nature, the associated metadata may reveal private information and hamper privacy of users. For example, a global passive attacker eavesdropping on all Bitcoin P2P connections can trivially identify the source and timing of a transaction.
  • Since connections are unauthenticated, they can be tampered with at a low cost and often even with a low risk of detection. For example, an attacker can alter specific bytes of a connection (such as node flags) on-the-fly without the need to keep any state.
  • The protocol is self-revealing. For example, deep packet inspection can identify a P2P connection trivially because connections start with a fixed sequence of magic bytes. The ability to detect connections enables censorship and facilitates the aforementioned attacks as well as other attacks which require the attacker to control the connections of victims, e.g., eclipse attacks targeted at miners.

This proposal of a new P2P protocol version (v2) aims to mitigate these issues by means of unauthenticated, opportunistic transport encryption. As a secondary goal beside the concealment of the transferred data, the entire bytestream on the wire should be pseudorandom (i.e., indistinguishable from uniformly random bytes) to a passive eavesdropper.

This countermeasure increases the costs of the aforementioned attacks substantially. Encryption, even when it is unauthenticated and used only when both endpoints support v2, impedes eavesdropping or tampering by forcing the attacker to either perform a persistent man-in-the-middle attack or downgrade connections to v1. Since both of these are active attacks, they are in principle detectable by the endpoints and thus hard to perform covertly on large scale: Even very basic checks, e.g., operators manually comparing protocol versions and session identifiers (a feature enabled by this proposal), will expose the attacker. Moreover, a pseudorandom bytestream excludes identification techniques based on pattern matching, and makes it easier to shape the bytestream in order to mimic other protocols used on the Internet.

Design #

This proposal aims to achieve the following properties:

  • Confidentiality against passive attacks: A passive attacker having recorded a v2 P2P bytestream (without timing information and packet metadata) must not be able to determine the plaintext being exchanged by the nodes.
  • Attack Observability: The session ID is derived deterministically from a Diffie-Hellman negotiation. A malicious intermediary is forced to incur a risk of being detected as peer operators can compare encryption session IDs or use other forms of authentication schemes to identify an attack.
  • Pseudorandom bytestream: A passive attacker having recorded a v2 P2P bytestream (without timing information and packet metadata) must not be able to distinguish it from a uniformly random bytestream.
  • Shapable bytestream: It should be possible to shape the bytestream using decoy traffic to increase resistance to traffic analysis (for example, block propagation).
  • Forward secrecy: An eavesdropping attacker should not be able to decrypt the historical pseudorandom bytestream by obtaining compromised keys in the future.
  • Upgradability: The proposal provides an upgrade path using transport versioning which can be used to add features like authentication, PQC handshake upgrade, etc. in the future.
  • Compatibility: v2 clients will allow inbound v1 connections to minimize risk of network partitions.
  • Low computation overhead: the introduction of a new P2P transport protocol should not substantially increase computational cost for nodes that implement it, compared to the current protocol.

The overall proposed design is:

  • Both peers generate ephemeral keypairs and exchange public keys. ** The public keys exchanged on wire use an encoding which makes the handshake (and therefore, the entire bytestream, as what follows is encrypted) indistinguishable from random.
  • Both peers then deterministically derive the ECDH secret and further derive encryption keys and a session ID from the shared secret.
  • We use two instances of an authenticated stream cipher suite in each communication direction (4 total): One for fixed-length keystream uses (metadata encryption and MAC key) and the other to encrypt variable length payloads.
  • The key for the cipher suite is rotated after a specified number of keystream bytes have been used to maintain forward secrecy.

Get involved #

The project is approaching code complete and is in the community engagement phase. Here are way in which we are seeking help: