Discussions happend here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/thread.html#16806 https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#comments
Implementations is partially merged in Bitcoin Core (AEAD, KDF).
@dr-orlovsky I think BOLT8 is very similar to the proposed AEAD scheme we use in BIP324. I guess BOLT8 was inspired by BIP151 which is the predecessor of BIP324. The main differences are the handshake as well as the MACing of the encrypted length.
The reason why I don’t think using BOLT8 directly are the following:
13+
14+This BIP describes a new Bitcoin peer to peer transport protocol with opportunistic encryption.
15+
16+== Motivation ==
17+
18+The current peer-to-peer protocol is partially inefficient and in plaintext.
I don’t like “current” for the same reason I don’t like it on Wikipedia, it will be weird reading this document in 5 years. Better just write “the P2P protocol supported in Bitcoin 0.20.1”.
“partially inefficient” in which way? Because of the double-SHA256? Surely the lack of encryption isn’t inefficient, which is what most of the section talks about. I would at least just remove “partially”, inefficiency isn’t black/white in any case, so the word “partially” doesn’t add anything.
9+ License: PD
10+</pre>
11+
12+== Abstract ==
13+
14+This BIP describes a new Bitcoin peer to peer transport protocol with opportunistic encryption.
19+
20+With the current unencrypted message transport, BGP hijack, block delay attacks and message tampering are inexpensive and can be executed covertly (undetectable MITM)<ref>[https://btc-hijack.ethz.ch/files/btc_hijack.pdf Hijacking Bitcoin: Routing Attacks on Cryptocurrencies - M. Apostolaki, A. Zohar, L.Vanbever]</ref>.
21+
22+Adding opportunistic encryption introduces a high risk for attackers of being detected. Peer operators can compare encryption session IDs or use other form of authentication schemes <ref name="bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki BIP150]</ref> to identify an attack.
23+
24+Each current version 1 Bitcoin peer-to-peer message uses a double-SHA256 checksum truncated to 4 bytes. Roughly the same amount of computation power would be required for encrypting and authenticating a peer-to-peer message with ChaCha20 & Poly1305.
23+
24+Each current version 1 Bitcoin peer-to-peer message uses a double-SHA256 checksum truncated to 4 bytes. Roughly the same amount of computation power would be required for encrypting and authenticating a peer-to-peer message with ChaCha20 & Poly1305.
25+
26+Additionally, this BIP describes a way to identify data which has been manipulated by peers (intercepting, then blocking or tampering with messages).
27+
28+Encrypting traffic between peers is already possible with VPN, tor, stunnel, curveCP or any other encryption mechanism on a deeper OSI level, however, most of those solutions require significant technical experience in setting up a secure channel and are therefore not widely deployed.
53+
54+A peer usually learns an address along with the expected service flags which MAY be used to filter possible outbound peers.
55+
56+A peer signaling <code>NODE_P2P_V2</code> MUST accept encrypted communication specified in this proposal.
57+
58+Peers MAY only make outbound connections to peers supporting <code>NODE_P2P_V2</code>.
Before you connect, you can’t know whether the node supports V2. Why not say “maintain” instead of “make”?
Why is “peers” plural here, when it is singular above? An implementer of this BIP will write node software for a single peer, so I think singular works better. Better use plural for the other nodes.
62+<pre>
63+ ----------------------------------------------------------------------------------------
64+ | Initiator Responder |
65+ | |
66+ | x, X := SECP256k1_KEYGEN() |
67+ | CLIENT_HDATA := X |
78+ ----------------------------------------------------------------------------------------
79+</pre>
80+
81+To request encrypted communication (only possible if yet no other messages have been sent or received), the initiating peer generates an EC secp256k1 ephemeral key and sends the corresponding 32-byte public key to the responding peer and waits for the remote 32-byte public key from the counterparty.
82+
83+ODD secp256k1 public keys MUST be used (public keys starting with 0x02). If the public key from the generated ephemeral key is an EVEN public key (starting with 0x03), its public key SHOULD be negated and then recalculated.
81+To request encrypted communication (only possible if yet no other messages have been sent or received), the initiating peer generates an EC secp256k1 ephemeral key and sends the corresponding 32-byte public key to the responding peer and waits for the remote 32-byte public key from the counterparty.
82+
83+ODD secp256k1 public keys MUST be used (public keys starting with 0x02). If the public key from the generated ephemeral key is an EVEN public key (starting with 0x03), its public key SHOULD be negated and then recalculated.
84+Only using ODD public keys makes it more complex to identify the handshake based on analyzing the traffic.
85+
86+The handshake request and response message are raw 32byte payloads containing no header, length or checksum (the pure 32byte payload) and MUST be sent before anything else.
92+do {
93+ ecdh_key.MakeNewKey();
94+ if (ecdh_key.GetPubKey()[0] == 3) {
95+ ecdh_key.Negate();
96+ }
97+} while (m_ecdh_key.GetPubKey()[0..3] == NETWORK_MAGIC);
83+ODD secp256k1 public keys MUST be used (public keys starting with 0x02). If the public key from the generated ephemeral key is an EVEN public key (starting with 0x03), its public key SHOULD be negated and then recalculated.
84+Only using ODD public keys makes it more complex to identify the handshake based on analyzing the traffic.
85+
86+The handshake request and response message are raw 32byte payloads containing no header, length or checksum (the pure 32byte payload) and MUST be sent before anything else.
87+
88+Public keys starting with the 4-byte network magic are forbidden and MUST lead to local regeneration of an ephemeral-key.
97+} while (m_ecdh_key.GetPubKey()[0..3] == NETWORK_MAGIC);
98+</pre>
99+
100+Once a peer has received the public key from its counterparty, the shared secret MUST be calculated by using secp256k1 ECDH.
101+
102+Private keys will never be transmitted. The shared secret can only be calculated if an attacker knows at least one private key and the counterparty's public key. This key-exchange is based on the discrete log problem and thus not sufficiently strong against known forms of possible quantum computer algorithms. Adding an additional quantum resistant key exchange like NewHope is possible but out of scope for this proposal.
104+After a successful handshake, messages MUST use the "v2 messages structure". Non-encrypted v1 messages from the initiating peer MUST lead to an immediate connection termination.
105+
106+After a successful handshake, both peers MUST wipe the ephemeral-session-key from memory and/or persistence storage.
107+
108+A peer not supporting this proposal will not perform the described handshake and thus send a v1 version message.
109+Peers supporting this BIP MAY optionally allow unencrypted v1 communication by detecting a v1 version message by the initial 11-byte sequence of <code>4byte net magic || "version"</code>.
I suggest changing plural for singular.
If it is a MAY there is no need to say “optionally”. Also, I don’t think you can say “detecting by”. Maybe a native speaker like @jnewbery can chime in. I’d suggest “allow unencrypted v1 communication after detecting a v1 version message with its 11 byte prefix 4byte net magic || "version"
108+A peer not supporting this proposal will not perform the described handshake and thus send a v1 version message.
109+Peers supporting this BIP MAY optionally allow unencrypted v1 communication by detecting a v1 version message by the initial 11-byte sequence of <code>4byte net magic || "version"</code>.
110+
111+=== Symmetric Encryption Cipher Keys ===
112+
113+Once the ECDH secret (<code>ECDH_KEY</code>) is calculated on each side, the symmetric encryption cipher keys MUST be derived with HKDF <ref>[https://tools.ietf.org/html/rfc5869 HKDF (RFC 5869)]</ref> after the following specification:
These are just my suggestions, I think it is easier to read but a native speaker like @jnewbery could confirm.
135+
136+=== ChaCha20-Poly1305@Bitcoin Cipher Suite ===
137+
138+==== Background ====
139+
140+ChaCha20-Poly1305@Bitcoin AEAD is almost identical to the openSSH version <ref>[https://github.com/jhcloos/openssh-chacha-poly1305/blob/master/PROTOCOL.chacha20poly1305]</ref>. The only difference to the @openSSH version is that the @Bitcoin version has a 3 byte package length (instead 4) and reuses the remaining bytes of the ChaCha20 round (21 length field encryption per ChaCha20 round; 21 x 3 < 64).
openSSH -> OpenSSH.
What does the ampersand mean?
I think the x is multiplication, but I’d suggest just spelling it out instead: “21 times 3 is less than 64”.
137+
138+==== Background ====
139+
140+ChaCha20-Poly1305@Bitcoin AEAD is almost identical to the openSSH version <ref>[https://github.com/jhcloos/openssh-chacha-poly1305/blob/master/PROTOCOL.chacha20poly1305]</ref>. The only difference to the @openSSH version is that the @Bitcoin version has a 3 byte package length (instead 4) and reuses the remaining bytes of the ChaCha20 round (21 length field encryption per ChaCha20 round; 21 x 3 < 64).
141+
142+ChaCha20 is a stream cipher designed by Daniel Bernstein and described in <ref>[http://cr.yp.to/chacha/chacha-20080128.pdf ChaCha20]</ref>. It operates by permuting 128 fixed bits, 128 or 256 bits of key, a 64 bit nonce and a 64 bit counter into 64 bytes of output. This output is used as a keystream, with any unused bytes simply discarded.
“any unused bytes simply discarded” -> “unused bytes discarded”.
“128 or 256 bits”. Surely this must be fixed for the purposes of this spec? If one of these configurations is unused in this BIP, maybe it would be nice to explain which one it is. If they can somehow both be used, it would be nice with a pointer to the section where this is selected.
141+
142+ChaCha20 is a stream cipher designed by Daniel Bernstein and described in <ref>[http://cr.yp.to/chacha/chacha-20080128.pdf ChaCha20]</ref>. It operates by permuting 128 fixed bits, 128 or 256 bits of key, a 64 bit nonce and a 64 bit counter into 64 bytes of output. This output is used as a keystream, with any unused bytes simply discarded.
143+
144+Poly1305 <ref>[http://cr.yp.to/mac/poly1305-20050329.pdf Poly1305]</ref>, also by Daniel Bernstein, is a one-time Carter-Wegman MAC that computes a 128 bit integrity tag given a message and a single-use 256 bit secret key.
145+
146+The chacha20-poly1305@bitcoin combines these two primitives into an authenticated encryption mode. The construction used is based on that proposed for TLS by Adam Langley in <ref>[http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03 "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley]</ref>, but differs in the layout of data passed to the MAC and in the addition of encryption of the packet lengths.
I suggest “The construction is based on a proposal for TLS”.
When you say “in addition”, I think you mean that this is yet another difference. But since this is a text using mathematics, I think it would be better to avoid this phrasing and instead say “…, but differs in the layout of the data passed to the MAC. It also encrypts the packet lengths differently.”
149+
150+The chacha20-poly1305@bitcoin cipher requires two 256 bits of key material as output from the key exchange. Each key (K_1 and K_2) are used by two separate instances of chacha20.
151+
152+The instance keyed by K_1 is a stream cipher that is used only to encrypt the 3 byte packet length field and has its own sequence number. The second instance, keyed by K_2, is used in conjunction with poly1305 to build an AEAD (Authenticated Encryption with Associated Data) that is used to encrypt and authenticate the entire packet.
153+
154+Two separate cipher instances are used here so as to keep the packet lengths confidential (best effort; for passive observing) but not create an oracle for the packet payload cipher by decrypting and using the packet length prior to checking the MAC. By using an independently-keyed cipher instance to encrypt the length, an active attacker seeking to exploit the packet input handling as a decryption oracle can learn nothing about the payload contents or its MAC (assuming key derivation, ChaCha20 and Poly1305 are secure). Active observers can still obtain the message length (ex. active ciphertext bit flipping or traffic shemantics analysis)
157+
158+==== Packet Handling ====
159+
160+When receiving a packet, the length must be decrypted first. When 3 bytes of ciphertext length have been received, they may be decrypted.
161+
162+A ChaCha20 round always calculates 64bytes which is sufficient to encrypt a 3 bytes length field 21 times (21*3 = 63). The length field sequence number can thus be used 21 times (keystream caching).
* for multiplication, it should be consistent with the other inline formulas. I suggest using full English words so that it is clear.
159+
160+When receiving a packet, the length must be decrypted first. When 3 bytes of ciphertext length have been received, they may be decrypted.
161+
162+A ChaCha20 round always calculates 64bytes which is sufficient to encrypt a 3 bytes length field 21 times (21*3 = 63). The length field sequence number can thus be used 21 times (keystream caching).
163+
164+The length field must be enc-/decrypted with the ChaCha20 keystream keyed with K_1 defined by block counter 0, the length field sequence number in little endian and a keystream position from 0 to 60.
I suggest replacing “enc-/decrypted” with “encrypted/decrypted”.
‘Little endian" is not hyphenated the same as above.
197+
198+The responding peer MUST use <code>K_1_A, K_2_A</code> to decrypt messages on the receive channel, <code>K_1_B, K_2_B</code> MUST be used to encrypt messages on the send channel.
199+
200+Optimized implementations of ChaCha20-Poly1305@bitcoin are relatively fast, therefore it is very likely that encrypted messages will not require additional CPU cycles per byte when compared to the current unencrypted p2p message format (ChaCha20/Poly1305 versus double SHA256).
201+
202+The initial packet sequence numbers are 0.
285+| 16 || MAC tag || ? || 128bit MAC-tag
286+|}
287+
288+Encrypted messages do not have the 4byte network magic.
289+
290+The maximum message size is 2^23 (8,388,608) bytes. Future communication MAY exceed this limit and thus MUST be split into different messages.
404+
405+The Re-Keying must be done after every 1GB of data sent (recommended by RFC4253 SSH Transport) or if the last rekey was more than an hour ago.
406+
407+Peers calculate the counterparty limits and MUST disconnect immediately if a violation of the limits has been detected.
408+
409+=== Test Vectors ===
219+ | msg := AEAD(k=K_1_A,K_2_A, n=0, ..., MSG_A_CIPH) |
220+ | |
221+ ------------------------------------------------------------------------------------------
222+</pre>
223+
224+==== AEAD Test Vectors ====
