-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Thanks for the quick response!
On 28/11/14 13:39, Yawning Angel wrote:
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.
Cool, thanks.
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.
I believe so too, but is it stated anywhere that this is a guaranteed property of crypto_secretbox?
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.
Interesting, thanks. Would SHA-256 be too slow for obfuscation? It just seems like a lot of dependencies for a simple protocol.
For what it's worth, we're using the two-box approach for the next version of the Briar transport protocol. I'm concerned about the possibility of an attack conceptually similar to [1] against an unauthenticated length field, even though that specific attack wouldn't apply.
Cheers, Michael
[1] http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf