On Fri, 28 Nov 2014 13:08:04 +0000 Michael Rogers michael@briarproject.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi,
In the obfs4 spec I couldn't find a description of how the secretbox nonces for the frames are constructed. A 16-byte nonce prefix comes from the KDF, but what about the remaining 8 (presumably frame-specific) bytes?
It's a simple 64 bit frame counter (Big endian, starts at 1). Guess I never bothered to copy the relevant information from the gigantic comment in framing.go into the spec, oops.
The code cuts the connection if the counter would wrap though that's unlikely at any sort of realistic data rate given the use case.
If an attacker changes the order of the secretboxes so that the recipient tries to open a secretbox with the wrong nonce, is that guaranteed to fail, as it would if the secretbox had been modified? I can make a hand-wavy argument for why I think it will fail, but I don't know whether the secretbox construct is designed to ensure this.
Yes, the poly1305 verification will fail.
Any particular reason for using two different MACs (HMAC-SHA256-128 for the handshake, Poly1305 for the frames) and two different hashes (SHA-256 for the handshake, SipHash-2-4 for obfuscation)?
No particular reason beyond "historical". Ntor is specified to use HMAC-SHA256, ScrambleSuit used HMAC-SHA256-128. I briefly toyed with sending 2 secretboxes one with the length, one with the payload, but that was kind of heavyweight, so I went with something lighter (Thus SipHash). I may go back to the two box design if I do an obfs5, not sure about that yet.
Regards,