p2p authentication and encryption BIPs

> Hi
>
> I have just PRed a draft version of two BIPs I recently wrote.
> https://github.com/bitcoin/bips/pull/362
> Responding peers must ignore (banning would lead to fingerprinting) the
> To ensure that no message was dropped or blocked, the complete communication
> On Wednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote:
> * why would you not allow encryption on non-pre-approved connections?
> * we just removed (ssl) encryption from the JSON interface, how do you suggest
> this encryption to be implemented without openSSL?
> * What is the reason for using the p2p code to connect a wallet to a node?
> I suggest using one of the other connection methods to connect to the node.
> This avoids a change in the bitcoin protocol for a very specific usecase.
> * Why do you want to do a per-message encryption (wrapping the original)?
> Smaller messages that contain predictable content and are able to be matched
> to the unencrypted versions on the wire send to other nodes will open this
> scheme up to various old statistical attacks.
>> Responding peers must ignore (banning would lead to fingerprinting) the
> requesting peer after 5 unsuccessfully authentication tries to avoid resource
> attacks.
>
> Any implementation of that kind would itself again be open to resource
> attacks.
> Why 5? Do you want to allow a node to make a typo?
>> To ensure that no message was dropped or blocked, the complete communication
> must be hashed (sha256). Both peers keep the SHA256 context of the encryption
> session. The complete <code>enc</code> message (leaving out the hash itself)
> must be added to the hash-context by both parties. Before sending a
> <code>enc</code> command, the sha256 context will be copied and finalized.
>
> You write "the complete communication must be hashed" and every message has a
> hash of the state until it is at that point.
> I think you need to explain how that works specifically.
>> I have just PRed a draft version of two BIPs I recently wrote.
>> https://github.com/bitcoin/bips/pull/362
>
> I suggest running a spellchecker ;)
> * why would you not allow encryption on non-pre-approved connections?
> * we just removed (ssl) encryption from the JSON interface, how do you suggest
> this encryption to be implemented without openSSL?
> * What is the reason for using the p2p code to connect a wallet to a node?
> I suggest using one of the other connection methods to connect to the node.
> This avoids a change in the bitcoin protocol for a very specific usecase.
> * Why do you want to do a per-message encryption (wrapping the original)?
> Smaller messages that contain predictable content and are able to be matched
> to the unencrypted versions on the wire send to other nodes will open this
> scheme up to various old statistical attacks.
>
>> Responding peers must ignore (banning would lead to fingerprinting) the
> requesting peer after 5 unsuccessfully authentication tries to avoid resource
> attacks.
>
> Any implementation of that kind would itself again be open to resource
> attacks.
> Why 5? Do you want to allow a node to make a typo?
>
>
>> To ensure that no message was dropped or blocked, the complete communication
> must be hashed (sha256). Both peers keep the SHA256 context of the encryption
> session. The complete <code>enc</code> message (leaving out the hash itself)
> must be added to the hash-context by both parties. Before sending a
> <code>enc</code> command, the sha256 context will be copied and finalized.
>
> You write "the complete communication must be hashed" and every message has a
> hash of the state until it is at that point.
> I think you need to explain how that works specifically.
> On Wednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote:
> > Hi
> >
> > I have just PRed a draft version of two BIPs I recently wrote.
> > https://github.com/bitcoin/bips/pull/362
>
> I suggest running a spellchecker ;)
>
> Some questions;
>
> * why would you not allow encryption on non-pre-approved connections?
> * we just removed (ssl) encryption from the JSON interface, how do you
> suggest
> this encryption to be implemented without openSSL?
> * What is the reason for using the p2p code to connect a wallet to a node?
> I suggest using one of the other connection methods to connect to the node.
> This avoids a change in the bitcoin protocol for a very specific usecase.
> * Why do you want to do a per-message encryption (wrapping the original)?
> Smaller messages that contain predictable content and are able to be
> matched
> to the unencrypted versions on the wire send to other nodes will open this
> scheme up to various old statistical attacks.
>
> > Responding peers must ignore (banning would lead to fingerprinting) the
> requesting peer after 5 unsuccessfully authentication tries to avoid
> resource
> attacks.
>
> Any implementation of that kind would itself again be open to resource
> attacks.
> Why 5? Do you want to allow a node to make a typo?
>
>
> > To ensure that no message was dropped or blocked, the complete
> communication
> must be hashed (sha256). Both peers keep the SHA256 context of the
> encryption
> session. The complete <code>enc</code> message (leaving out the hash
> itself)
> must be added to the hash-context by both parties. Before sending a
> <code>enc</code> command, the sha256 context will be copied and finalized.
>
> You write "the complete communication must be hashed" and every message
> has a
> hash of the state until it is at that point.
> I think you need to explain how that works specifically.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> I have just PRed a draft version of two BIPs I recently wrote.
> https://github.com/bitcoin/bips/pull/362
> Each peer that supports p2p authentication, must provide two user editable
> databases (can be a simple record-per-line file).
> A peer can send an authenticate message by wrapping the desired message into
> an <code>auth</code>-message-wrapper to the remote peer.
> 33bytes || identity-pubkey || comp.-pubkey || The identity pubkey of the
> requesting peer
> 8bytes || auth-msg-id || int64 || up-counting auth-msg-id (0 to INT64MAX)
> Responding peers must ignore (banning would lead to fingerprinting) the
> requesting peer after 5 unsuccessfully authentication tries to avoid
> resource attacks.
> The peers should display the identity-pubkey as a identity-address to the
> users, which is a base58-check encoded ripemd160(sha256) hash.
> This proposal is backward compatible. Non supporting peers will ignore the
> <code>auth</code> message.
> 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 a secure channel.
> The responding peer will set a session timeout time-interval. The default
> must be 1'800 seconds.
> This proposal is backward compatible. Non supporting peers will ignore the
> <code>enc*</code> messages.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> Hi
>
> I have just PRed a draft version of two BIPs I recently wrote.
> https://github.com/bitcoin/bips/pull/362
>
> Two BIPs that addresses the problem of decoupling wallets/clients from
> nodes while assuming a user (or a group) know the remote peer.
>
> Authentication would be necessary to selective allow bloom filtering
> of transactions, encryption or any other node service that might lead
> to fingerprinting or resource attacks. Authentication would also be a
> pre-requirement for certificate free encryption-handshakes that is
> (enough?) resistant to MITM attacks.
>
> Encryption is highly recommended if you connect a SPV node to a
> trusted node.
>
> Authentication would allow accessing private p2p extensions from a
> remote SPV peer (example: fee estimation).
>
> I'm aware of other methods to increase privacy and integrity (tor,
> VPN, stunnel, etc.), however I think authentication and a basic
> communication encryption should be part of the protocol and its setup
> should be complete hassle-free.
>
> Thanks for your feeback.
>
> /jonas
>
- The motivation sections seem weak. Why not use SSH? It would have
  similar setup requirements, and is already a deployed solution. If
  there are additional setup simplicities (compared to SSH),
  consider listing them. And if one of the motivating factors is
  complexity reduction from the various "do everything you could
  possible want" protocols/implementations, then add this to the
  motivation.
- ECDSA and "ec pubkey" are mentioned, but not the specific curve.
- The hash algorithm for ECDSA is not explicitly mentioned.
- There is no way to change the cryptographic primitives being used or
  to update to a new protocol version. Would it be done with a new
  message type `auth2` ... ?
- The following seems to be contradictory:
> If the responding peer could not lookup the requesting peer's
> identity-pubkey in the local authorized-peers database or if the
> responding peer could not verify the signature, the requested auth
> message must be ignored to avoid fingerprinting of peers with
> authentication support.
>
> Responding peers must ignore (banning would lead to fingerprinting)
> the requesting peer after 5 unsuccessfully authentication tries to
> avoid resource attacks.
  If I connect to a peer, send 5 auth messages followed by another type
  of message that gets no response, this could indicate auth support.
  Or is this supposed to say ignore further auth messages, but not
  other types of messages? The wording seems to suggest an ignore-all.
- The pubkey from the requester is sent in cleartext, which can be used
  as an identifier across connections (similar to a MAC, except it can
  be seen across every network hop and correlated across connection
  types). Hiding this will likely require encryption, and the protocol
  will start to look similar to CurveCP. If the additional complexity
  is not worth fixing this issue, a section in the encryption BIP
  should be added to explain the identifier leakage.
- The known-peers has an IP and port section. Should the requester limit
  signatures based on this information? This algorithm or process needs
  to be better defined than the vague paragraph about verifying the
  integrity of the remote peer; if an implementation uses the
  any-one-of server approach the known-peers file becomes more like a
  SSL CA list, which does not seem like the intent. However, the example
  at the bottom says "Requesting peer does a lookup of (F) in
  known-peers database (B)".
- The encryption portion does not mention the pubkey pairs in use for
  ECDH (this needs to be described), so I am assuming the pairs from
  authentication are re-used. This increases the chances of data
  exposure since a single botched k selection (re-use) for ECDSA would
  allow for forged authentications, and the decryption of all
  historical data. Adding a temporary key exchange would add slight
  complexity and one RTT from the requesters perspective, but it
  provides forward-secrecy and protection against ECDSA implementation
  failures.
- Can the responding peer set a different cipher in the `ecinit`
  response, or should/must it be the same?
- What happens if the responding peer does not support the cipher?
  Presumably, a rejection?
- The contents of the IV field are unspecified, and should be
  specified to contain new output from a CSPRNG for each message.
- Should `enc` messages be wrapped in `auth` messages (presumably so
  since there is no MAC)? `encinit` have this restriction, but nothing
  is specified for `enc`.
- Is the context hash unique in each direction? There seems to be one,
  which would be racy - what if the client wanted to pipeline messages?
  Or is the intent a single open request/response style? I think this
  _adds_ a restriction to the Bitcoin protocol.
- Instead of a hash, what about a counter in each direction for the
  `enc` stream? The auth portion verifies integrity, authenticity, and
  completeness of each message (including this counter). Missing
  messages (through TCP injection?) would still detected. Using TCP
  injection to forcefully teardown a connection is possible in both
  designs.
> I have just PRed a draft version of two BIPs I recently wrote.
> https://github.com/bitcoin/bips/pull/362
> How does a peer know what messages the other peer requires to be
> How does banning in this specific case enable fingerprinting as
>> This proposal is backward compatible. Non supporting peers will
> ... and not process it at all? How is that backward compatible?
> This proposal is backward compatible. Non supporting peers will ignore
> >> I have just PRed a draft version of two BIPs I recently wrote.
> > * why would you not allow encryption on non-pre-approved connections?
>
> The encryption should be optional.
> The proposed authentication scheme does take care of the
> identity-management and therefor prevent MITM attacks.
> Without the identity management, you might not detect sending/receiving
> encrypted data from/to a MITM.
> > * What is the reason for using the p2p code to connect a wallet to a node?
> > I suggest using one of the other connection methods to connect to the
> > node.
> > This avoids a change in the bitcoin protocol for a very specific usecase.
>
> Most known use-case: SPV.
> > * Why do you want to do a per-message encryption (wrapping the original)?
> > Smaller messages that contain predictable content and are able to be
> > matched to the unencrypted versions on the wire send to other nodes will
> > open this scheme up to various old statistical attacks.
>
> It's probably extremely inefficient to create a constant time stream.
> >> Responding peers must ignore (banning would lead to fingerprinting) the
> >
> > requesting peer after 5 unsuccessfully authentication tries to avoid
> > resource attacks.
> >
> > Any implementation of that kind would itself again be open to resource
> > attacks.
> > Why 5? Do you want to allow a node to make a typo?
>
> Good point. Maybe one false try should lead to ignoring the peer.
> >> To ensure that no message was dropped or blocked, the complete
> >> communication>
> > must be hashed (sha256). Both peers keep the SHA256 context of the
> > encryption session. The complete <code>enc</code> message (leaving out
> > the hash itself) must be added to the hash-context by both parties.
> > Before sending a <code>enc</code> command, the sha256 context will be
> > copied and finalized.
> >
> > You write "the complete communication must be hashed" and every message
> > has a hash of the state until it is at that point.
> > I think you need to explain how that works specifically.
>
> This is a relative simple concept and does not require rehashing the
> whole communication.
> As far as the use cases others mentioned, connecting and SPV wallet to
> your full node is certainly one. It would make it easy to, say, connect
> the android bitcoin-wallet to your own node. I've hacked on that wallet
> to make it connect to my .onion node, but it's very slow border-line
> unusable. Basic encryption and authentication would make that viable.
>> The encryption should be optional.
>> The proposed authentication scheme does take care of the
>> identity-management and therefor prevent MITM attacks.
>> Without the identity management, you might not detect sending/receiving
>> encrypted data from/to a MITM.
>
> If you want to extend the Bitcoin protocol itself, you will have to resolve
> that. Which many other solutions do (ssh for instance).
>>> * What is the reason for using the p2p code to connect a wallet to a node?
>>> I suggest using one of the other connection methods to connect to the
>>> node.
>>> This avoids a change in the bitcoin protocol for a very specific usecase.
>>
>> Most known use-case: SPV.
>
> You didn't answer the question.
>>> * Why do you want to do a per-message encryption (wrapping the original)?
>>> Smaller messages that contain predictable content and are able to be
>>> matched to the unencrypted versions on the wire send to other nodes will
>>> open this scheme up to various old statistical attacks.
>>
>> It's probably extremely inefficient to create a constant time stream.
>
> Your use of "probably" makes me wonder if you already have an implementation.
> Doing any encryption and handshaking design *without* actually having it coded
> and gone though testing yet makes no sense.
> I do not belief Bitcoin will benefit from "design by committee" where a
> specification is drawn before an implementation is written.
>
> Also, you didn't actually address the attack-vector.
>
>
>>>> Responding peers must ignore (banning would lead to fingerprinting) the
>>>
>>> requesting peer after 5 unsuccessfully authentication tries to avoid
>>> resource attacks.
>>>
>>> Any implementation of that kind would itself again be open to resource
>>> attacks.
>>> Why 5? Do you want to allow a node to make a typo?
>>
>> Good point. Maybe one false try should lead to ignoring the peer.
>
> That doesn't take away the resource attack at all.
>
>
>>>> To ensure that no message was dropped or blocked, the complete
>>>> communication>
>>> must be hashed (sha256). Both peers keep the SHA256 context of the
>>> encryption session. The complete <code>enc</code> message (leaving out
>>> the hash itself) must be added to the hash-context by both parties.
>>> Before sending a <code>enc</code> command, the sha256 context will be
>>> copied and finalized.
>>>
>>> You write "the complete communication must be hashed" and every message
>>> has a hash of the state until it is at that point.
>>> I think you need to explain how that works specifically.
>>
>> This is a relative simple concept and does not require rehashing the
>> whole communication.
>
> Apologies, I should have been more clear; the BIP should specify the actual
> algorithm, otherwise you can't create an implementation from just reading the
> BIP.
>
> Also, this may be a good time to ask why you want to have a per-message
> encryption?
> Practically every single popular end-to-end encryption uses one approach or
> another were it just encrypts as another layer. (the  L in ssl). You are
> mixing layers, and unless you do that for a very good reason, or have a very
> good reason why everyone else is doing it wrong, I suggest using a layered
> encryption approach.
> An encrypted channel together with a trusted full node would finally
> allow to have a secure and save SPV communication.
> > Also, you didn't actually address the attack-vector.
>
> Which attack-vector?
> I guess my question didn't get across.
>
> Why would you want to make your usecase do connections over the peer2peer
> (net.cpp) connection at all?
> Mixing messages that are being sent to everyone and encrypted messages is
> asking for trouble.
> Making your private connection out-of-band would work much better.
>>> Also, you didn't actually address the attack-vector.
>>
>> Which attack-vector?
>
> The statistical attack I mentioned earlier.  Which comes from knowing which
> plain text messages are being sent over the encrypted channel, So as long as
> you keep saying you want to encrypt data that identical copies of are being
> sent to other nodes at practically the same time, you will keep being
> vulnerable to that.
> On Friday 25 Mar 2016 19:43:00 Jonas Schnelli via bitcoin-dev wrote:
> > An encrypted channel together with a trusted full node would finally
> > allow to have a secure and save SPV communication.
>
> I guess my question didn't get across.
>
> Why would you want to make your usecase do connections over the peer2peer
> (net.cpp) connection at all?
>
> Mixing messages that are being sent to everyone and encrypted messages is
> asking for trouble.
> Making your private connection out-of-band would work much better.
>
>
> > > Also, you didn't actually address the attack-vector.
> >
> > Which attack-vector?
>
> The statistical attack I mentioned earlier.  Which comes from knowing which
> plain text messages are being sent over the encrypted channel, So as long
> as
> you keep saying you want to encrypt data that identical copies of are being
> sent to other nodes at practically the same time, you will keep being
> vulnerable to that.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>     I guess my question didn't get across.
>
>     Why would you want to make your usecase do connections over the
>     peer2peer
>     (net.cpp) connection at all?
>
>     Mixing messages that are being sent to everyone and encrypted
>     messages is
>     asking for trouble.
>     Making your private connection out-of-band would work much better.
>
>
> I agree doing it out-of-band is the easiest solution for people who need
> this privacy right now, but I do like the idea of adding this feature as
> the number of SPV wallets is going to increase. I think the best way to
> organize things would be to give encrypted messages their own port
> number, similar to how http vs. https works.
> We don't want two networks to develop, separated by which nodes support
> encryption and which don't, so ideally nodes would rebroadcast messages
> they receive on both (encrypted and non-encrypted) channels. This would
> essentially double the required bandwidth of the network, which is
> something to think about.
>
> >     I guess my question didn't get across.
> >
> >     Why would you want to make your usecase do connections over the
> >     peer2peer
> >     (net.cpp) connection at all?
> >
> >     Mixing messages that are being sent to everyone and encrypted
> >     messages is
> >     asking for trouble.
> >     Making your private connection out-of-band would work much better.
> >
> >
> > I agree doing it out-of-band is the easiest solution for people who need
> > this privacy right now, but I do like the idea of adding this feature as
> > the number of SPV wallets is going to increase. I think the best way to
> > organize things would be to give encrypted messages their own port
> > number, similar to how http vs. https works.
>
> I'm not sure if different ports would make sense. I can't see a benefit
> (happy if someone can convince me).
> How would this affect p2p address management (address relay)? Wouldn't
> this require to extend the current address message to support two port
> numbers?
>
> I'm assuming clients that connect with encryption don't want to use
>
> > We don't want two networks to develop, separated by which nodes support
> > encryption and which don't, so ideally nodes would rebroadcast messages
> > they receive on both (encrypted and non-encrypted) channels. This would
> > essentially double the required bandwidth of the network, which is
> > something to think about.
>
> It can be the same "p2p network". The only difference would be, that
> once two peers has negotiated encryption, the whole traffic between
> _these two peers_, and _only_ these two pears, would be encrypted (would
> _not_ affect traffic to/from other peers).
>
>
> A simplified example:
> 1. Peer Alice connects to peer Bob
> 2. Alice asks Bob: "lets do encrypted communication, here is my session
> pubkey"
> 3. Bob also supports encryption and answers "Yes, let's do this, here is
> my session pubkey"
> 4. Alice tells Bob (encrypted now): "Perfect. Here I prove that I'm
> Alice by signing the session ID with my identity pubkey"
> 5. Bob checks his "authorized-peers" database and look-up Alices pubkey
> and verifies the signatures.
> 6. Bob tells Alice: "Good! I trust you now Alice, here is my identity
> pubkey with a signature of our session-ID"
> 7. Alice looks up Bobs pubkey in her "known-peers" database and verifies
> the signature.
> 8. Alice response to bob: "Perfect. Indeed, you are Bob!"
> ---
> At this point, the communication is encrypted and the identities has
> been verified (MITM protection).
>
>
> (simplified negotiation [only one-way, missing dh explanation, missing
> KDF, session-ID, cipher suite nego., missing re-keying, etc.])
>
>
> </jonas>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> I have just PRed a draft version of two BIPs I recently wrote.
> https://github.com/bitcoin/bips/pull/362
> > I have just PRed a draft version of two BIPs I recently wrote.
> > https://github.com/bitcoin/bips/pull/362
>
> Hi.
> I just updated the PR above with another overhaul of the BIP.
> It's still under heavy review/work, nevertheless – at this point – any
> feedback is highly welcome.
>
> Changes since last update:
> -> Removed AES256-GCM as cipher suite
> -> Focusing on Chacha20-Poly1305 (implementation size ~300L)
> -> Two symmetric cipher keys must be calculated by HMAC_SHA512 from
> the ecdh secret
> -> A session-ID (both directions) 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 then 10mins).
> -> AEAD tag is now the last element in the new message format
>
> It is very likely that the encrypted message format performs slightly
> better than the current message format (removing the SHA256 checksum).
>
> ---
> </jonas>
>
> Rejecting the <code>auth</code> request will not reveal the
> responding peers identity that could lead to fingerprinting the node,
> however this BIP does not cover protection against fingerprinting the
> requesting node from the perspective of the responding node.
> Responding peers must ignore the requesting peer after a
> unsuccessfully authentication initialization to avoid resource
> attacks (banning would lead to fingerprinting of peers that support
> authentication).
> 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.
> Possible symmetric key ciphers types
> {|class="wikitable"
> ! Number !! symmetric key ciphers type !! Comments
> |-
> | 0 || Chacha20-Poly1305 [3] || encrypted message length must be used
> as AAD. |}
>
> <code>K_1</code> must be used to only encrypt the payload size of the
> encrypted message to avoid leaking information by revealing the
> message size.
>
> <code>K_2</code> must be used in conjunction with poly1305 to build
> an AEAD.
> After a successful <code>encinit</code>/<code>encack</code>
> 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 (can be
> detected by the 4 byte network magic in the unencrypted message
> structure).
> {|class="wikitable"
> ! Field Size !! Description !! Data type !! Comments
> |-
> | 4 || length || uint32_t || Length of ciphertext payload in number
> of bytes
> |-
> | ? || ciphertext payload || ? || One or many ciphertext command &
> message data
> |-
> | 8 || MAC tag || ? || MAC-tag truncated to 8 bytes
> |}
> 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''.
>
> The new symmetric cipher key will be calculated by
> <code>SHA256(SHA256(old_symetric_cipher_key))</code>.
>
> Re-Keying interval is a peer policy with a minimum timespan of 600
> seconds.
>
> *Key Revocation*
> This is probably too complicated, but an additional public key would
> allow for cold-storage key revocation. Spreading the knowledge of such
> an event is always painful, but it could be stored in the blockchain. I
> think this is likely too complicated, but having these long-term keys
> constantly in memory/disk is unfortunate.
>
>> <code>K_1</code> must be used to only encrypt the payload size of the
>> encrypted message to avoid leaking information by revealing the
>> message size.
>>
>> <code>K_2</code> must be used in conjunction with poly1305 to build
>> an AEAD.
>
> Chacha20 is a stream cipher, so only a single encryption key is needed.
> The first 32 bytes of the keystream would be used for the Poly1305 key,
> the next 4 bytes would be used to encrypt the length field, and the
> remaining keystream would be used to encrypt the payload. Poly1305
> would then generate a tag over the length and payload. The receiver
> would generate the same keystream to decrypt the length which
> identifies the length of the message and the MAC offset, then
> authenticate the length and payload, then decypt with the remaining
> keystream.
>
> Is it safer to define two keys to prevent implementations from screwing
> this up? You have to split the decryption and authentication, so the
> basic modes of libsodium cannot be used for instance. If a custom tag
> generation scheme is being used, then the basic modes are already
> unusable ...
>
> *Failed Authentication*
> What happens on a failed MAC attempt? Connection closure is the
> easiest way to handle the situation.
>> After a successful <code>encinit</code>/<code>encack</code>
>> 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 (can be
>> detected by the 4 byte network magic in the unencrypted message
>> structure).
>
> The magic bytes are at the same offset and size as the encrypted length
> field in the encrypted messages structure. So the magic bytes are not a
> reliable way to identify unencrypted messages, although the probability
> of collision is low.
>> {|class="wikitable"
>> ! Field Size !! Description !! Data type !! Comments
>> |-
>> | 4 || length || uint32_t || Length of ciphertext payload in number
>> of bytes
>> |-
>> | ? || ciphertext payload || ? || One or many ciphertext command &
>> message data
>> |-
>> | 8 || MAC tag || ? || MAC-tag truncated to 8 bytes
>> |}
>
> Why have a fixed MAC length? I think the MAC length should be inferred
> from the cipher + authentication mode. And the Poly1305 tag is 16 bytes.
>
> *Unauthenticated Buffering*
> Implementations are unlikely to (i.e. should not) process the payload
> until authentication succeeds. Since the length field is 4 bytes, this
> means an implementation may have to buffer up to 4 GiB of data _per
> connection_ before it can authenticate the length field. If the outter
> length field were reduced to 2 or 3 bytes, the unauthenticated
> buffering requirements drop to 64 KiB and 16 MiB respectively. Inner
> messages already have their own length, so they can span multiple
> encrypted blocks without other changes. This will increase the
> bandwidth requirements when the size of a single message exceeds 64 KiB
> or 16 MiB, since it will require multiple authentication tags for that
> message. I think an additional 16 bytes per 16 MiB seems like a good
> tradeoff.
>
>
>> 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''.
>>
>> The new symmetric cipher key will be calculated by
>> <code>SHA256(SHA256(old_symetric_cipher_key))</code>.
>>
>> Re-Keying interval is a peer policy with a minimum timespan of 600
>> seconds.
>
> Should the int64_t message count be reset to 0 on a re-key? Or should
> the value reset to zero after 2^63-1? Hopefully the peer re-keys before
> that rollover, or keystream reusage will occur. Unlikely that many
> messages are sent on a single connection though. And presumably this
> only re-keys the senders side? Bi-directional re-keying would be racy.
> Hi Lee
>
> Thank you very much for the valuable input.
> I'm still processing your feedback....
> > Why have a fixed MAC length? I think the MAC length should be
> > inferred from the cipher + authentication mode. And the Poly1305
> > tag is 16 bytes.
> >
> > *Unauthenticated Buffering*
> > Implementations are unlikely to (i.e. should not) process the
> > payload until authentication succeeds. Since the length field is 4
> > bytes, this means an implementation may have to buffer up to 4 GiB
> > of data _per connection_ before it can authenticate the length
> > field. If the outter length field were reduced to 2 or 3 bytes, the
> > unauthenticated buffering requirements drop to 64 KiB and 16 MiB
> > respectively. Inner messages already have their own length, so they
> > can span multiple encrypted blocks without other changes. This will
> > increase the bandwidth requirements when the size of a single
> > message exceeds 64 KiB or 16 MiB, since it will require multiple
> > authentication tags for that message. I think an additional 16
> > bytes per 16 MiB seems like a good tradeoff.
> >
>
> Good point.
> I have mentioned this now in the BIP but I think the BIP should allow
> message > 16 MiB.
> I leave the max. message length up to the implementation while keeping
> the 4 byte length on the protocol level.
>
> </jonas>
>
>> Good point.
>> I have mentioned this now in the BIP but I think the BIP should allow
>> message > 16 MiB.
>> I leave the max. message length up to the implementation while keeping
>> the 4 byte length on the protocol level.
>
> I expect the implementation defined max size to work (SSH 2.0 does this
> after all), but I want to make sure my suggestion is understood
> completely.
>
> There is a length field for the encrypted data, and length field(s)
> inside of the encrypted data to indicate the length of the plaintext
> Bitcoin messages. I am suggesting that the outter (encrypted) length
> field be reduced, which will _not limit_ the length of Bitcoin
> messages. For example, if a 1 GiB Bitcoin message needed to be sent
> and the encrypted length field was 3 bytes - the sender is forced to
> send a minimum of 64 MACs for this message. The tradeoff is allowing
> the receiver to detect malformed data sooner and have a lower max
> buffering window **against** slightly higher bandwidth and CPU
> requirements due to the additional headers+MACs (the CPU requirements
> should primarily be in "finalizing each Poly1305").
> An alternative way to think about the suggestion is tunnelling Bitcoin
> messages over TLS or SSH. TLS 1.2 has a 2-byte length field and SSH 2.0
> a 4-byte length field, but neither prevents larger Bitcoin messages from
> being tunnelled; the lengths are independent.