Published on: 2016-05-25T09:36:24+00:00
The discussion revolves around the maximum message length that can be sent in an encrypted package/message in Bitcoin Improvement Protocol (BIP). The current assumption is that an encrypted package can contain 1..n bitcoin messages, but the suggestion is to reduce the outer (encrypted) length field while keeping the 4 byte length on the protocol level. This would not limit the length of Bitcoin messages and allow the receiver to detect malformed data sooner. The tradeoff is slightly higher bandwidth and CPU requirements due to additional headers+MACs.TLS/SSH tunneling is already possible with third-party software like stunnel, but what is required is a simple, openssl-independent traffic encryption built into the core p2p layer. The implementation is not utterly complex, and before deployment, it will require intense cryptoanalysis first.In this email thread, Jonas Schnelli is responding to feedback from Lee about a BIP (Bitcoin Improvement Proposal) regarding encryption and authentication of Bitcoin messages. Lee suggests that the MAC length should be inferred from the cipher and authentication mode, rather than fixed. He also raises concerns about unauthenticated buffering requirements, which would require an implementation to buffer up to 4GiB of data per connection before authenticating the length field. To address this, he suggests reducing the outer length field to 2 or 3 bytes, which would reduce the unauthenticated buffering requirements to 64 KiB and 16 MiB respectively. Jonas agrees with this suggestion and mentions that he has updated the BIP to reflect it, but leaves the maximum message length up to the implementation. Lee clarifies that his suggestion does not limit the length of Bitcoin messages and explains that it is similar to tunneling Bitcoin messages over TLS or SSH, which have their own length fields that do not prevent larger Bitcoin messages from being tunneled.The discussion between two individuals includes feedback on the encryption of messages in BIP, including the use of public keys for cold-storage key revocation, and the implementation of chacha20-poly1305 for AEAD. They also discuss the use of multiple keys to prevent implementation errors and handling failed authentication attempts. The format for encrypted messages is specified, with a suggestion to allow for unencrypted messages containing the 4 byte network magic to avoid collisions. The issue of unauthenticated buffering is addressed, with a proposal to reduce the length field to decrease buffer requirements while allowing for larger message sizes. Finally, re-keying is discussed, with recommendations for resetting the message count and implementing bi-directional re-keying.Jonas Schnelli, a bitcoin-dev, has submitted two draft versions of BIPs on GitHub. He updated the PR with another overhaul of the BIP and removed AES256-GCM as cipher suite while focusing on Chacha20-Poly1305. Two symmetric cipher keys must be calculated by HMAC_SHA512 from the ecdh secret. A session-ID must be calculated (HMAC_SHA256) for linking an identity authentication (ecdsa sig of the session-ID) with the encryption. Re-Keying ('=hash(old_key)') can be announced by the responding peer after x minutes and/or after x GB, local peer policy but not shorter than 10mins. AEAD tag is now the last element in the new message format. The encrypted message format may perform slightly better than the current message format. The requesting node could generate an ECDH secret from the long-term public key of the expected peer and its own session private-key to encrypt (no MAC) the signature with the same symmetric cipher agreed upon previously. The responding peer must ignore the requesting peer after an unsuccessful authentication initialization to avoid resource attacks. 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.Chacha20-Poly1305 defined in an IETF draft and RFC 7539 both include the ciphertext length in the authentication tag generation. A single shared-secret could be used to generate keys for each direction. K_1 must be used to only encrypt the payload size of the encrypted message to avoid leaking information by revealing the message size. K_2 must be used in conjunction with poly1305 to build an AEAD. After a successful encinit/encack interaction from both sides, the messages format must use the 'encrypted messages structure'. Non-encrypted messages from the requesting peer must lead to a connection termination.A responding peer can inform the requesting peer over re-keying with an encack message containing 33 bytes of zeros to indicate that all encrypted messages following this encack message will be encrypted with the next symmetric cipher key. The new symmetric cipher key will be calculated by SHA256(SHA256(old_symmetric_cipher_key)).
Updated on: 2023-08-01T18:00:13.282875+00:00