BIP 151: Peer-to-Peer Communication Encryption #362

  11 | +
  12 | +This BIP describes a way that peers can authenticate to other peers to guarantee ownership and/or allowing to access additional or limited services.
  13 | +
  14 | +== Motivation ==
  15 | +
  16 | +We assume peer operators want to limit the access of different services to a selective subset of peers. Also we assume peers want to connect to specific peers to broadcast or filter transactions (or similar action that reveals sensitive information’s) and therefore they want to authenticate the remote peer and make sure that they have not connected to a MITM. 

jonathancross commented at 9:35 PM on April 15, 2016:

"information’s" => "information"

  13 | +
  14 | +== Motivation ==
  15 | +
  16 | +We assume peer operators want to limit the access of different services to a selective subset of peers. Also we assume peers want to connect to specific peers to broadcast or filter transactions (or similar action that reveals sensitive information’s) and therefore they want to authenticate the remote peer and make sure that they have not connected to a MITM. 
  17 | +
  18 | +Benefits with peer authentication:

jonathancross commented at 9:36 PM on April 15, 2016:

"Benefits of peer authentication:"

  19 | +* Nodes could allow resource hungry transaction filtering only to specific nodes
  20 | +* Nodes could allow access to sensitive information that can lead to node fingerprinting (fee estimation)
  21 | +* Nodes could be sure they do not connect to a MITM
  22 | +* Nodes could allow custom message types (private extensions) to authenticated peers
  23 | +
  24 | +A simple authentication scheme based on elliptic cryptography will allow peers to identify each other and selective allow access to restricted services or reject the connection if the identity could not be verified.

jonathancross commented at 9:42 PM on April 15, 2016:

• "elliptic curve cryptography" or maybe just replace with "ECDSA"?
• "selective" => "selectively"

  47 | +{|class="wikitable"
  48 | +! Field Size !! Description !! Data type !! Comments
  49 | +|-
  50 | +| 33bytes || identity-pubkey || comp.-pubkey || The identity pubkey of the requesting peer
  51 | +|-
  52 | +| 64bytes || signature || normalized comp.-signature || A signature of the encryption-session-ID from the requesting-to-responing communication direction.

jonathancross commented at 10:00 PM on April 15, 2016:

"requesting-to-responding"

  52 | +| 64bytes || signature || normalized comp.-signature || A signature of the encryption-session-ID from the requesting-to-responing communication direction.
  53 | +|}
  54 | +
  55 | +Replay attacks are not possible because the <code>auth</code> message must be sent only if communication encryption according to BIP-???? [1]) has been established. Peers must ignore unencrypted <code>auth</code> messages.
  56 | +
  57 | +The requesting <code>auth</code> message must be responded with an identical <code>auth</code> message. The response-auth message must contain the identity-pubkey from the responding-peer as well as the encryption-session-ID from the opposit communication direction.

jonathancross commented at 10:02 PM on April 15, 2016:

"opposit" => "opposite"

jonathancross commented at 10:08 PM on April 15, 2016:

Unfortunately messages cannot be "responded" in English. Would this sentence below correctly capture what you mean?

An <code>auth</code> message request must be replied to with an identical <code>auth</code> message.

  31 | +
  32 | +The '''encryption-session-ID''' is available once channels are encrypted (according to BIP-???? [1]).
  33 | +
  34 | +Authentication can be verified by verifying the signature of the encryption-session-ID with a provided "identity-pubkey" (standard ec pubkey).
  35 | +
  36 | +The authentication state must be kept until the encryption/connection terminates.

jonathancross commented at 10:10 PM on April 15, 2016:

Should "encryption/connection" be "encrypted connection"?

  13 | +
  14 | +== Motivation ==
  15 | +
  16 | +The current p2p communication is unencrypted and can be analyzed and modified by many network authority (ISP, WiFi providers, router-firmware, etc.). Mostly this is negligible because of the nature of Bitcoins trust model, however for SPV nodes this can have significant privacy impacts [1] and could reduce the censorship-resistance of a peer.
  17 | +
  18 | +Encrypting the communication will reduce the capabilities of analyzing the p2p communication of a specific peer. Today it's trivial for a network provider or any other men-in-the-middle to identify a Bitcoin user and its controlled addresses/keys (and link with his Google profile, etc.). Just created and broadcasted transactions will reveal the amount and the payee to the network provider.

jonathancross commented at 10:25 PM on April 15, 2016:

Suggestions for first sentence: Encrypting peer traffic will make analysis and specific user targeting much more difficult than it currently is.

  11 | +
  12 | +This BIP describes an alternative way that a peer can encrypt their communication between a selective subset of remote peers.
  13 | +
  14 | +== Motivation ==
  15 | +
  16 | +The current p2p communication is unencrypted and can be analyzed and modified by many network authority (ISP, WiFi providers, router-firmware, etc.). Mostly this is negligible because of the nature of Bitcoins trust model, however for SPV nodes this can have significant privacy impacts [1] and could reduce the censorship-resistance of a peer.

jonathancross commented at 10:32 PM on April 15, 2016:

Suggestion for first sentence: The Bitcoin network does not encrypt communication between peers today. This opens up security issues (eg: traffic manipulation by others) and allows for mass surveillance / analysis of bitcoin users.

  43 | +
  44 | +It is important to include the cipher-type into the symmetric cipher key to avoid weak-cipher-attacks.
  45 | +
  46 | +=== Session ID ===
  47 | +
  48 | +Both side must also calculate the 256bit session-id by <code>HMAC_SHA256(key=ecdh_secret,msg="session id")</code>. The session-id can be used for linking the encryption-session to an identity check.

jonathancross commented at 10:35 PM on April 15, 2016:

Both sides must also calculate the 256bit session-id using <code>HMAC_SHA256(key=ecdh_secret,msg="session id")</code>.

  61 | +
  62 | +Possible symmetric key ciphers types
  63 | +{|class="wikitable"
  64 | +! Number !! symmetric key ciphers type !! Comments
  65 | +|-
  66 | +| 0 || Chacha20-Poly1305 [3] || encrypted message length must be used as AAD.

jonathancross commented at 10:59 PM on April 15, 2016:

Seems the second "C" in "ChaCha" is normally capitalized, so I'd suggest writing as "ChaCha20-Poly1305" here and below.

• http://cr.yp.to/chacha/chacha-20080128.pdf
• https://en.wikipedia.org/wiki/Salsa20#ChaCha_variant
• https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-04

  58 | +
  59 | +The responding peer can reject the authentication request if the peer was not found in the “authorized-peers” database or if the signature was invalid.
  60 | +
  61 | +Rejecting the <code>auth</code> request will not reveal the responding peers identity that could lead to fingerprinting the node, however this BIP does not cover protection against fingerprinting the requesting node from the perspective of the responding node.
  62 | +
  63 | +Responding peers must ignore the requesting peer after a unsuccessfully authentication initialization to avoid resource attacks (banning would lead to fingerprinting of peers that support authentication).

jonathancross commented at 11:01 PM on April 15, 2016:

"Responding peers must ignore the requesting peer after an unsuccessful authentication attempt to avoid resource attacks..."

  88 | +! Field Size !! Description !! Data type !! Comments
  89 | +|-
  90 | +| 33bytes || ephemeral-pubkey || comp.-pubkey || The session pubkey from the responding peer
  91 | +|}
  92 | +
  93 | +At this point, the shared secret key for the symmetric key cipher must be calculated by using ECDH (own privkey MUL remote pub key).

jonathancross commented at 11:11 PM on April 15, 2016:

Seems "MUL" here means "MULTIPLIED BY"? Might consider using × symbol or * multiplication operator.

  89 | +|-
  90 | +| 33bytes || ephemeral-pubkey || comp.-pubkey || The session pubkey from the responding peer
  91 | +|}
  92 | +
  93 | +At this point, the shared secret key for the symmetric key cipher must be calculated by using ECDH (own privkey MUL remote pub key).
  94 | +Private keys will never be transmitted. The shared secret can only be calculated if an attacker knows at least one private key and the remote peers public key.

jonathancross commented at 11:12 PM on April 15, 2016:

Needs apostrophe: ...and the remote peer's public key.

   7 | +  Created: 2016-03-23
   8 | +</pre>
   9 | +
  10 | +== Abstract ==
  11 | +
  12 | +This BIP describes a way that peers can authenticate to other peers to guarantee ownership and/or allowing to access additional or limited services.

jonathancross commented at 11:25 PM on April 15, 2016:

Suggestion: This BIP describes a secure authentication protocol for use between peers within the Bitcoin network.

  37 | +
  38 | +=== Known-peers and authorized-peers database ===
  39 | +Each peer that supports p2p authentication must provide two user editable databases
  40 | +
  41 | +# '''known-peers''' contain known identity-pubkeys together with a network identifier (IP & port), similar to the "known-host" file supported by openssh.
  42 | +# '''authorized-peers''' contains identity-pubkeys, together with allowed services (example: encryption,filtering,fee-estimation).

jonathancross commented at 11:35 PM on April 15, 2016:

Nit: Can we add a space after each comma? encryption, filtering, fee-estimation