diff options
Diffstat (limited to 'bip-0151.mediawiki')
| -rw-r--r-- | bip-0151.mediawiki | 26 |
1 files changed, 13 insertions, 13 deletions
diff --git a/bip-0151.mediawiki b/bip-0151.mediawiki index a01a8bb..005c552 100644 --- a/bip-0151.mediawiki +++ b/bip-0151.mediawiki @@ -5,7 +5,7 @@ Author: Jonas Schnelli <dev@jonasschnelli.ch> Comments-Summary: Controversial; some recommendation, and some discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0151 - Status: Draft + Status: Withdrawn Type: Standards Track Created: 2016-03-23 License: PD @@ -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. |