Despite the word "stream" being mentioned multiple times in BIP-324, the handshake part is message-based. This issue is indirectly addressed in the proposal:
To avoid the recognizable pattern of first messages being at least 64 bytes, a future backwards-compatible upgrade to this protocol may allow both peers to send their public key + garbage + garbage terminator in multiple rounds, slicing those bytes up into messages arbitrarily, as long as progress is guaranteed
It's a big task, understandably, to turn this protocol into a fully streamed one. The adversarial model might be different, and the security requirements might change. So, I didn't create this issue to critique an implementation that is following the design laid out by BIP-324. I'm only showcasing my attempt at implementing a streamed variant of this protocol.
I am working on a library that performs a MitM over BIP-324. One requirement of the library is to be as transparent as possible. So, I don't assume the order in which the bytes are transmitted, meaning that as soon as a byte is intercepted on one side, a byte is transmitted on the other. This can only be achieved if the channels are fully streamed on both sides of the MitM channel. The only exception to this is the garbage terminator, which can only be detected when we receive it in its entirety.
RazorBest/bip324-mitm#1
Here are some differences from the original BIP324 protocol:
- The state needs to include some extra buffers for the messages that are partially received but can't be processed yet
FSChaCha20 is rewritten to support streaming- Similarly,
ChaCha20Poly1305 has its streamed implementation. However, the rekeying mechanism made it challenging to fully replace FSChaCha20Poly1305. So, I kept the original struct in order to keep track of rekeying, and used a second struct, named ChaCha20Poly1305Stream that supports streamed encryption of one payload. For each payload, a new instance of type ChaCha20Poly1305Stream is created.
- Lastly, my library doesn't implement the classic client-server paradigm, so it's not a substitute for this
Despite the word "stream" being mentioned multiple times in BIP-324, the handshake part is message-based. This issue is indirectly addressed in the proposal:
It's a big task, understandably, to turn this protocol into a fully streamed one. The adversarial model might be different, and the security requirements might change. So, I didn't create this issue to critique an implementation that is following the design laid out by BIP-324. I'm only showcasing my attempt at implementing a streamed variant of this protocol.
I am working on a library that performs a MitM over BIP-324. One requirement of the library is to be as transparent as possible. So, I don't assume the order in which the bytes are transmitted, meaning that as soon as a byte is intercepted on one side, a byte is transmitted on the other. This can only be achieved if the channels are fully streamed on both sides of the MitM channel. The only exception to this is the garbage terminator, which can only be detected when we receive it in its entirety.
RazorBest/bip324-mitm#1
Here are some differences from the original BIP324 protocol:
FSChaCha20is rewritten to support streamingChaCha20Poly1305has its streamed implementation. However, the rekeying mechanism made it challenging to fully replaceFSChaCha20Poly1305. So, I kept the original struct in order to keep track of rekeying, and used a second struct, namedChaCha20Poly1305Streamthat supports streamed encryption of one payload. For each payload, a new instance of typeChaCha20Poly1305Streamis created.