What changes when nodes encrypt their traffic?

Evidence

Each numbered marker in the text points here, and the ↩ links lead back to every place that cites an entry. Quotes are verbatim from the BIP files at commit 3a10b5b, including their wiki markup; links open the exact lines; the quoted text sits under each entry. Labels say what kind of statement each is: a rule, the author’s rationale, history, a test vector, or our own inference.

1. ↩ Author’s rationale The authors note that v1 peers talk over unencrypted, unauthenticated connections; the data is public but metadata can reveal private information, such as a transaction's source and timing to a global passive attacker.

   BIP 324 L26 BIP 324 L28

   Quoted source text (2)

   peers talk to each other over unencrypted and unauthenticated connections.

   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.

2. ↩ Author’s rationale The authors note v1 connections can be tampered with cheaply, and are self-revealing because they start with fixed magic bytes, which enables censorship.

   BIP 324 L29 BIP 324 L30

   Quoted source text (2)

   Since connections are unauthenticated, they can be tampered with at a low cost and often even with a low risk of detection.

   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

3. ↩ History BIP 324 (Mehta, Ruffing, Schnelli, Wuille), a Peer Services specification assigned in 2019, is recorded as Deployed and replaces BIP 151.

   BIP 324 L3–14

   Quoted source text (1)

   Layer: Peer Services Title: Version 2 P2P Encrypted Transport Protocol Authors: Dhruv Mehta <dhruv@bip324.com> Tim Ruffing <crypto@timruffing.de> Jonas Schnelli <dev@jonasschnelli.ch> Pieter Wuille <bitcoin-dev@wuille.net> Status: Deployed Type: Specification Assigned: 2019-03-08 License: BSD-3-Clause Version: 1.0.2 Replaces: 151

4. ↩ Rule BIP 324 proposes a new P2P transport with opportunistic encryption, a mild bandwidth reduction, and upgrade negotiation before application messages.

   BIP 324 L20

   Quoted source text (1)

   This document proposes a new Bitcoin P2P transport protocol, which features opportunistic encryption, a mild bandwidth reduction, and the ability to negotiate upgrades before exchanging application messages.

5. ↩ Author’s rationale v2 aims to raise the cost of these attacks mainly through unauthenticated, opportunistic encryption, and makes the bytestream pseudorandom to a passive eavesdropper.

   BIP 324 L32

   Quoted source text (1)

   This proposal for a new P2P protocol version (v2) aims to improve upon this by raising the costs for performing these attacks substantially, primarily through the use of unauthenticated, opportunistic transport encryption. In addition, the bytestream on the wire is made pseudorandom (i.e., indistinguishable from uniformly random bytes) to a passive eavesdropper.

6. ↩ a b Editorial inference v2 changes only how P2P messages are carried: payloads and message types are those of the v1 protocol, and the BIP sits in the Peer Services layer, not consensus.

   BIP 324 L3 BIP 324 L523 BIP 324 L528

   Quoted source text (3)

   Layer: Peer Services

   An unencrypted application layer '''contents''' is composed of:

   a 12-byte ASCII message type (as in the v1 P2P protocol)

7. ↩ a b Test vector A v1 message header is 24 bytes (magic, command, length, checksum); a v2 packet adds 20 bytes plus a 1-byte type ID for listed types, 21 bytes in all, or 33 with a 13-byte type.

   BIP 324 L157 BIP 324 L528

   Quoted source text (2)

   The total size of a packet is 20 bytes plus the length of its contents.

   either a one byte ID in range ''1..255''

8. ↩ a b c Rule A packet is a 3-byte encrypted length, then ChaCha20Poly1305 over a 1-byte header and the contents; a packet is 20 bytes plus its contents, which may be up to 2^24 - 1 bytes.

   BIP 324 L157 BIP 324 L160–163 BIP 324 L161–162

   Quoted source text (3)

   The total size of a packet is 20 bytes plus the length of its contents.

   * A 3-byte encrypted '''length''' field, encoding the length of the '''contents''' (between ''0'' and ''2²⁴-1''

   * An authenticated encryption of the '''plaintext''', which consists of: ** A 1-byte '''header''' which consists of transport layer protocol flags. Currently, only the highest bit is defined as the '''ignore bit'''.

9. ↩ a b Rule Application contents are a message type, a 1-byte ID or 0x00 plus the 12-byte ASCII type as in v1, followed by the message payload.

   BIP 324 L528 BIP 324 L530

   Quoted source text (2)

   | <code>message_type</code> || 1 or 13 || either a one byte ID in range ''1..255'' or <code>b'\x00'</code> followed by a 12-byte ASCII message type (as in the v1 P2P protocol)

   | <code>message_payload</code> || <code>message_length</code> || message payload

10. ↩ a b Author’s rationale The proposal does not include peer authentication; the authors argue authentication should be addressed separately, if desired, and the session ID provides a basis for it.

    BIP 324 L42 BIP 324 L44

    Quoted source text (2)

    The communication protocol establishing that the communication partner's identity matches who we expect them to be, through some public key mechanism. The proposal in this document does '''not''' include such a mechanism.

    As a consequence, we believe that authentication should be addressed separately (if desired), and this proposal aims to provide a solid technical basis for future protocol upgrades, including the addition of optional authentication

11. ↩ Author’s rationale The authors argue encryption forces an eavesdropper to become active: a persistent MitM, downgrading to v1, or running its own nodes; for manual connections, comparing session IDs would expose an attacker.

    BIP 324 L34 BIP 324 L34 BIP 324 L34

    Quoted source text (3)

    Encryption, even when it is unauthenticated and only used when both endpoints support v2, impedes eavesdropping by forcing the attacker to become active: either by performing a persistent man-in-the-middle (MitM) attack, by downgrading connections to v1, or by spinning up their own nodes and getting honest nodes to make connections to them.

    even very basic checks, e.g., operators manually comparing protocol versions and session IDs (as supported by the proposed protocol), will expose the attacker.

    Active attacks at scale are more resource intensive in general, but in the case of manual, deliberate connections (as opposed to automatic, random ones), they are also in principle detectable

12. ↩ a b c d e Author’s rationale Goals include confidentiality against passive attacks, a pseudorandom and shapable bytestream, forward secrecy, upgradability, accepting inbound v1, and low overhead.

    BIP 324 L81 BIP 324 L83 BIP 324 L85 BIP 324 L87 BIP 324 L84

    Quoted source text (5)

    * Confidentiality against passive attacks: A passive attacker having recorded a v2 P2P bytestream (without timing and fragmentation information) must not be able to determine the plaintext being exchanged by the nodes.

    * Pseudorandom bytestream: A passive attacker having recorded a v2 P2P bytestream (without timing information and fragmentation information) must not be able to distinguish it from a uniformly random bytestream.

    * Forward secrecy: An eavesdropping attacker who compromises a peer's sessions secrets should not be able to decrypt past session traffic, except for the latest few packets.

    * Compatibility: v2 clients will allow inbound v1 connections to minimize risk of network partitions.

    * Shapable bytestream: It should be possible to shape the bytestream to increase resistance to traffic analysis (for example, to conceal block propagation)

13. ↩ a b Author’s rationale A session ID derived from the Diffie-Hellman negotiation identifies the channel; operators can compare it out of band, so an active MitM risks detection.

    BIP 324 L82 BIP 324 L329

    Quoted source text (2)

    * Observability of active attacks: A session ID identifying the encrypted channel uniquely is derived deterministically from a Diffie-Hellman negotiation. An active man-in-the-middle attacker is forced to incur a risk of being detected as peer operators can compare session IDs manually

    v2 clients supporting this proposal may present the entire session ID (encoded as a hex string) to the node operator to allow for manual, out of band comparison with the peer node operator.

14. ↩ Author’s rationale The authors argue TLS and Noise are unsuitable: they lack a modular treatment of authentication, a pseudorandom and shapable bytestream, native secp256k1 support, and a packet interface.

    BIP 324 L62 BIP 324 L64 BIP 324 L70–73 BIP 324 L72 BIP 324 L73 BIP 324 L75

    Quoted source text (6)

    While it would be possible to rely on an off-the-shelf transport encryption protocol such as TLS or Noise, the specific requirements of the Bitcoin P2P network laid out above make these protocols an unsuitable choice.

    The primary requirement which existing protocols fail to meet is a sufficiently modular treatment of encryption and authentication.

    * Neither offers a pseudorandom bytestream. * Neither offers native support for elliptic curve cryptography on the curve secp256k1 as otherwise used in Bitcoin.

    * Neither offers shapability of the bytestream.

    * Both provide a stream-based interface to the application layer, whereas Bitcoin requires a packet-based interface

    this would negate the benefits of using them as off-the-shelf solution

15. ↩ Author’s rationale Traffic analysis of packet lengths and timing, and active attacks, can still reveal that v2 is in use.

    BIP 324 L48

    Quoted source text (1)

    Traffic analysis, e.g., observing packet lengths and timing, as well as active attacks can still reveal that the Bitcoin v2 P2P protocol is in use.

16. ↩ Rule Each side sends a 64-byte ElligatorSwift encoding of an ephemeral public key; every 512-bit string is a valid encoding, so encodings sampled uniformly look random.

    BIP 324 L112 BIP 324 L112

    Quoted source text (2)

    Generates a random ephemeral secp256k1 private key and sends a corresponding 64-byte ElligatorSwift

    While a random 256-bit string has about 50% chance of being a valid X coordinate on the secp256k1 curve, every 512-bit string is a valid ElligatorSwift encoding of a curve point, making the encoded point indistinguishable from random when using an encoder that can sample uniformly.

17. ↩ a b Rule Each side may send up to 4095 bytes of garbage after its public key, for shapability and to avoid a recognizable 64-byte pattern.

    BIP 324 L113 BIP 324 L113

    Quoted source text (2)

    bytes of arbitrary data after their public key, called '''garbage''', providing a form of shapability and avoiding a recognizable pattern of exactly 64 bytes.

    May send up to 4095

18. ↩ Rule The responder treats a connection as v1 if the first 16 bytes match the network magic followed by "version" and padding.

    BIP 324 L115

    Quoted source text (1)

    Waits until one byte is received which does not match the 16 bytes consisting of the network magic followed by "version\x00\x00\x00\x00\x00". If the first 16 bytes do match, the connection is treated as using the v1 protocol instead.

19. ↩ a b Rule Both sides compute X-only ECDH and hash it with the exact 64-byte encodings sent (initiator's first), so the encodings cannot be modified without a full MitM.

    BIP 324 L214–221 BIP 324 L121

    Quoted source text (2)

    def v2_ecdh(priv, ellswift_theirs, ellswift_ours, initiating): ecdh_point_x32 = ellswift_ecdh_xonly(ellswift_theirs, priv) if initiating: # Initiating, place our public key encoding first. return sha256_tagged("bip324_ellswift_xonly_ecdh", ellswift_ours + ellswift_theirs + ecdh_point_x32)

    This makes sure that an attacker cannot modify the public key encoding used without modifying the rest of the stream. If a third party wants the ability to modify stream bytes, they need to perform a full MitM attack on the connection.

20. ↩ a b Rule HKDF-SHA256, salted with "bitcoin_v2_shared_secret" and the network magic, derives the session ID, four cipher keys and the two 16-byte garbage terminators.

    BIP 324 L296–308

    Quoted source text (1)

    # Include NETWORK_MAGIC to ensure a connection between nodes on different networks will immediately fail prk = HKDF_Extract(Hash=sha256, salt=b'bitcoin_v2_shared_secret' + NETWORK_MAGIC, ikm=ecdh_secret) peer.session_id = HKDF_Expand(Hash=sha256, PRK=prk, info=b'session_id', L=32) # Initialize the packet encryption ciphers. initiator_L = HKDF_Expand(Hash=sha256, PRK=prk, info=b'initiator_L', L=32) initiator_P = HKDF_Expand(Hash=sha256, PRK=prk, info=b'initiator_P', L=32) responder_L = HKDF_Expand(Hash=sha256, PRK=prk, info=b'responder_L', L=32) responder_P = HKDF_Expand(Hash=sha256, PRK=prk, info=b'responder_P', L=32) garbage_terminators = HKDF_Expand(Hash=sha256, PRK=prk, info=b'garbage_terminators', L=32) initiator_garbage_terminator = garbage_terminators[:16] responder_garbage_terminator = garbage_terminators[16:]

21. ↩ a b Test vector This site's model reproduces all seven BIP 324 packet-encoding vectors: x(ours), X-only ECDH, shared secret, all HKDF outputs, session ID, the full packet for the three vectors that publish one and the published last 128 bytes for the other four, including packets after two, three and four rekeys and one of the largest size allowed (2^24 - 1 bytes of contents). ElligatorSwift decoding is not implemented: the model takes the decoded X coordinates from the vectors.

    BIP 324 L589

    Quoted source text (1)

    * [[bip-0324/packet_encoding_test_vectors.csv|Packet encoding vectors]] illustrate the lifecycle of the authenticated encryption scheme proposed in this document.

22. ↩ a b c Rule Both ciphers rekey every 224 messages. The AEAD's nonce is the packet number within the epoch and the epoch number; its new key is the first 32 bytes of encrypting 32 zero bytes under the old key with the nonce's packet field set to 0xffffffff. The length cipher takes the next 32 bytes of its own keystream as its new key.

    BIP 324 L414 BIP 324 L429–437 BIP 324 L435–437 BIP 324 L448

    Quoted source text (4)

    To provide re-keying every 224 packets, we specify two wrappers.

    nonce = ((self.packet_counter % REKEY_INTERVAL).to_bytes(4, 'little') + (self.packet_counter // REKEY_INTERVAL).to_bytes(8, 'little'))

    if (self.packet_counter + 1) % REKEY_INTERVAL == 0: rekey_nonce = b"\xFF\xFF\xFF\xFF" + nonce[4:] self.key = aead_chacha20_poly1305_encrypt(self.key, rekey_nonce, b"", b"\x00" * 32)[:32]

    rekeying every 224 chunks using the next 32 bytes of the block function output as new key

23. ↩ Rule Each side sends its 16-byte garbage terminator; the first encrypted packet in each direction authenticates the garbage sent as associated data, so a third party cannot modify it without consequence.

    BIP 324 L123 BIP 324 L127 BIP 324 L127

    Quoted source text (3)

    #** Send their 16-byte garbage terminator.

    the first encrypted packet that will be sent in that direction (regardless of it being a decoy packet or not) will make use of the associated authenticated data (AAD) feature of the AEAD to authenticate the garbage that has been sent in that direction.

    Without garbage authentication, the garbage would be modifiable by a third party without consequences.

24. ↩ Rule After the terminators, the responder and initiator each send a version packet with empty contents to indicate v2 support; other contents are reserved for future versions.

    BIP 324 L130 BIP 324 L133 BIP 324 L149

    Quoted source text (3)

    Sends a '''version packet''' with empty content, to indicate support for the v2 P2P protocol proposed by this document. Any other value for content is reserved for future versions.

    Sends a '''version packet''' with empty content as well, to indicate support for the v2 P2P protocol.

    Note that the version negotiation phase does not need to wait for the key exchange phase to complete; version packets can be sent immediately after sending the garbage terminator.

25. ↩ Author’s rationale A fixed 16-byte terminator is used because scanning for a byte sequence is much faster than trying to authenticate a packet at every offset; a receiver reads at most 4111 bytes looking for it.

    BIP 324 L123 BIP 324 L124

    Quoted source text (2)

    While it is in principle possible to use the first packet after the garbage directly as a terminator (scan until a valid packet follows), this would be significantly slower than just scanning for a fixed byte sequence, as it would require recomputing a Poly1305 tag after every received byte.

    #** Receive up to 4111 bytes, stopping when encountering the garbage terminator.

26. ↩ Rule The length field is encrypted with a separate ChaCha20 stream but not covered by the Poly1305 tag; incorrect lengths still make the packet fail authentication.

    BIP 324 L170 BIP 324 L170 BIP 324 L169

    Quoted source text (3)

    The Poly1305 authentication tag only covers the encrypted plaintext, and not the encrypted length field.

    as incorrect lengths will still trigger authentication failure for the overall packet (the plaintext length is implicitly authenticated by ChaCha20Poly1305).

    * Length encryption keeps drawing pseudorandom bytes from the same ChaCha20 cipher for multiple packets, rather than incrementing the nonce for every packet.

27. ↩ Rule Packets with the ignore bit set are decoys, ignored apart from verifying they decrypt; they are the main shapability mechanism.

    BIP 324 L126 BIP 324 L126

    Quoted source text (2)

    Encrypted packets have an '''ignore bit''', which makes them '''decoy packets''' if set. Decoy packets are to be ignored by the receiver apart from verifying they decrypt correctly. Either peer may send such decoy packets at any point from here on. These form the primary shapability mechanism in the protocol.

    How and when to use them is out of scope for this document.

28. ↩ Author’s rationale Encrypting and authenticating a v2 message costs roughly as much as v1's truncated double-SHA256 checksum.

    BIP 324 L519

    Quoted source text (1)

    Each v1 P2P message uses a double-SHA256 checksum truncated to 4 bytes. Roughly the same amount of computation power is required for encrypting and authenticating a v2 P2P message as proposed.

29. ↩ Author’s rationale Rekeying gives forward secrecy within a session: an attacker who compromises current secrets cannot derive past keys; ECDH is not refreshed.

    BIP 324 L174 BIP 324 L174

    Quoted source text (2)

    Re-keying ensures [https://eprint.iacr.org/2001/035.pdf forward secrecy within a session], i.e., an attacker compromising the current session secrets cannot derive past encryption keys in the same session.

    We do not believe protecting against that is a priority

30. ↩ Rule v2 support is signalled with the NODE_P2P_V2 = (1 << 11) service flag; clients met with immediate disconnection are encouraged to retry with v1.

    BIP 324 L581 BIP 324 L581

    Quoted source text (2)

    Peers supporting the v2 transport protocol signal support by advertising the <code>NODE_P2P_V2 = (1 << 11)</code> service flag in addr relay. If met with immediate disconnection when establishing a v2 connection, clients implementing this proposal are encouraged to retry connecting using the v1 protocol.

    An untrusted intermediary could falsely advertise a potential peer as supportive of v2 connections.