> On Jan 12, 2022, at 9:22 AM, Kenton Varda <ken...@cloudflare.com
> Sorry for the long delay in replying, I had a baby the day you sent this!
Congratulations! 🎉 I remember those days...
> This is neat! How many round trips are needed to set up a connection?
There are four messages: C->S, S->C, C->S, S->C. In the current implementation they happen one at a time, so I guess that’s two round trips? But it looks as though messages 1 & 2 can be sent concurrently, and also 3 & 4.
I dimly recall that there are some additional TCP hacks one can do, to piggyback a small payload on the initial packets that open the connection, but I don’t feel like cracking open TCP/IP Illustrated right now :-p
> Hmm if you're using a plain xsalsa20 stream and not secret boxes, does that mean you're implementing only encryption, not authentication? Note that XSalsa20 and related ciphers work by generating a random stream, and then XORing it with the plaintext. So although the attacker can't decrypt the bytes, they can flip individual bits in the ciphertext and this will result in the same bit being flipped in the plaintext.
Yeah, there are no integrity checks in the data stream, and I agree that’s a weakness*. Adding MACs requires adding a block- or message-oriented layer on top, like SecretBox, the way that Scuttlebutt does. This feels like redundant effort since Cap’nP also is itself message-oriented; my guess is that there’s a higher level API inside Cap’nP that exposes the message framing, and the MAC could be added there, but I have not yet delved deeper into the way Cap’nP works. (Hints welcome.)
(Or if there’s a clever stream-based way to insert MACs without having to build a framing layer, that would be even better. I’ve read my share of crypto textbooks, maybe I’ve just forgotten that bit.)
* I should probably call this out in the readme, shouldn’t I.