mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-04 11:08:05 +01:00
Code Issues Projects Releases Wiki Activity

[Trivial]Typos & links fix BIP 151

Browse source 
Came to learn - fixed a few things [trivial]
This commit is contained in:
Dario 2018-08-19 18:46:26 +02:00 • committed by GitHub
parent b44239a57d
commit 1c53c84581
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 12 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
bip-0151.mediawiki
View file

@ -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
<code>PRK = HKDF_EXTRACT(hash=SHA256, salt="bitcoinecdh", ikm=ecdh_secret|cipher-type)</code>.
@ -59,7 +59,7 @@ Both sides must also calculate the 256bit session-id using <code>SID = HKDF_EXPA
=== The <code>encinit</code> message type ===
To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an <code>encinit</code> message to the responding peer and waits for a <code>encack</code> message. The responding node must do the same <code>encinit</code>/<code>encack</code> interaction for the opposite communication direction.
To request encrypted communication, the requesting peer generates an EC ephemeral-session-keypair and sends an <code>encinit</code> message to the responding peer and waits for an <code>encack</code> message. The responding node must do the same <code>encinit</code>/<code>encack</code> 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
<code>K_2</code> 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 <code>encack</code> message type ===
The responding peer accepts the encryption request by sending a <code>encack</code> message.
The responding peer accepts the encryption request by sending an <code>encack</code> 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 <code>encack</code> message containing 33byte of zeros to indicate that all encrypted message following after this <code>encack</code> message will be encrypted with ''the next symmetric cipher key''.
A responding peer can inform the requesting peer over a re-keying with an <code>encack</code> message containing 33byte of zeros to indicate that all encrypted message following after this <code>encack</code> message will be encrypted with ''the next symmetric cipher key''.
The new symmetric cipher key will be calculated by <code>SHA256(SHA256(session_id || old_symmetric_cipher_key))</code>.
@ -172,12 +172,12 @@ This proposal is backward compatible. Non-supporting peers will ignore the <code
== References ==
* [1] http://e-collection.library.ethz.ch/eserv/eth:48205/eth-48205-01.pdf
* [1] https://e-collection.library.ethz.ch/eserv/eth:48205/eth-48205-01.pdf
* [2] HKDF (RFC 5869) https://tools.ietf.org/html/rfc5869
* [3] ChaCha20 http://cr.yp.to/chacha/chacha-20080128.pdf
* [4] Poly1305 http://cr.yp.to/mac/poly1305-20050329.pdf
* [3] ChaCha20 https://cr.yp.to/chacha/chacha-20080128.pdf
* [4] Poly1305 https://cr.yp.to/mac/poly1305-20050329.pdf
* [5] https://github.com/openssh/openssh-portable/blob/05855bf2ce7d5cd0a6db18bc0b4214ed5ef7516d/PROTOCOL.chacha20poly1305
* [6] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03
* [6] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03
== Acknowledgements ==
* Pieter Wuille and Gregory Maxwell for most of the ideas in this BIP.