From 1c53c845817afa14ab3029eb5746778e74739206 Mon Sep 17 00:00:00 2001 From: Dario Date: Sun, 19 Aug 2018 18:46:26 +0200 Subject: [Trivial]Typos & links fix BIP 151 Came to learn - fixed a few things [trivial] --- bip-0151.mediawiki | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/bip-0151.mediawiki b/bip-0151.mediawiki index a01a8bb..2d29951 100644 --- a/bip-0151.mediawiki +++ b/bip-0151.mediawiki @@ -18,7 +18,7 @@ This BIP describes an alternative way that a peer can encrypt their communicatio == Motivation == -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. 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. +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. Mostly this is negligible because of the nature of Bitcoin's trust model, however, for SPV nodes this can have significant privacy impacts [1] and could reduce the censorship-resistance of a peer. Encrypting peer traffic will make analysis and specific user targeting much more difficult than it currently is. 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. @@ -26,13 +26,13 @@ This BIP also describes a way that data manipulation (blocking commands by a int Analyzing the type of p2p communication would still be possible because of the characteristics (size, sending-interval, etc.) of the encrypted messages. -Encrypting traffic between peers is already possible with VPN, tor, stunnel, curveCP or any other encryption mechanism on a deeper OSI level, however, most mechanism are not practical for SPV or other DHCP/NAT environment and will require significant knowhow in how to setup such a secure channel. +Encrypting traffic between peers is already possible with VPN, tor, stunnel, curveCP or any other encryption mechanism on a deeper OSI level, however, most mechanisms are not practical for SPV or other DHCP/NAT environment and will require significant knowhow in how to setup such a secure channel. == Specification == A peer that supports encryption must accept encryption requests from all peers. -A independent ECDH negotiation for both communication directions is required and therefore a bidirectional communication will use two symmetric cipher keys (one per direction). +An independent ECDH negotiation for both communication directions is required and therefore a bidirectional communication will use two symmetric cipher keys (one per direction). Both peers must only send encrypted messages after a successful ECDH negotiation in ''both directions''. @@ -40,7 +40,7 @@ Encryption initialization must happen before sending any other messages to the r === Symmetric Encryption Cipher Keys === -The symmetric encryption cipher keys will be calculated with ECDH/HKDF by sharing the pubkeys of a ephemeral key. Once the ECDH secret is calculated on each side, the symmetric encryption cipher keys must be derived with HKDF [2] after the following specification: +The symmetric encryption cipher keys will be calculated with ECDH/HKDF by sharing the pubkeys of an ephemeral key. Once the ECDH secret is calculated on each side, the symmetric encryption cipher keys must be derived with HKDF [2] after the following specification: 1. HKDF extraction PRK = HKDF_EXTRACT(hash=SHA256, salt="bitcoinecdh", ikm=ecdh_secret|cipher-type). @@ -59,7 +59,7 @@ Both sides must also calculate the 256bit session-id using SID = HKDF_EXPA === The encinit message type === -To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an encinit message to the responding peer and waits for a encack message. The responding node must do the same encinit/encack interaction for the opposite communication direction. +To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an encinit message to the responding peer and waits for an encack message. The responding node must do the same encinit/encack interaction for the opposite communication direction. {|class="wikitable" ! Field Size !! Description !! Data type !! Comments @@ -90,11 +90,11 @@ The chacha20-poly1305@openssh.com specified and defined by openssh [5] combines K_2 must be used in conjunction with poly1305 to build an AEAD. -Optimized implementations of ChaCha20-Poly1305 are very fast in general, therefore it is very likely that encrypted messages require less CPU cycles per bytes then the current unencrypted p2p message format. A quick analysis by Pieter Wuille of the current ''standard implementations'' has shown that SHA256 requires more CPU cycles per byte then ChaCha20 & Poly1304. +Optimized implementations of ChaCha20-Poly1305 are very fast in general, therefore it is very likely that encrypted messages require less CPU cycles per byte then the current unencrypted p2p message format. A quick analysis by Pieter Wuille of the current ''standard implementations'' has shown that SHA256 requires more CPU cycles per byte then ChaCha20 & Poly1304. === The encack message type === -The responding peer accepts the encryption request by sending a encack message. +The responding peer accepts the encryption request by sending an encack message. {|class="wikitable" ! Field Size !! Description !! Data type !! Comments @@ -150,7 +150,7 @@ If more data is present, another message must be deserialized. There is no expli === Re-Keying === -A responding peer can inform the requesting peer over a re-keying with a encack message containing 33byte of zeros to indicate that all encrypted message following after this encack message will be encrypted with ''the next symmetric cipher key''. +A responding peer can inform the requesting peer over a re-keying with an encack message containing 33byte of zeros to indicate that all encrypted message following after this encack message will be encrypted with ''the next symmetric cipher key''. The new symmetric cipher key will be calculated by SHA256(SHA256(session_id || old_symmetric_cipher_key)). @@ -172,12 +172,12 @@ This proposal is backward compatible. Non-supporting peers will ignore the