[tor-dev] obfs4 questions
michael at briarproject.org
Fri Nov 28 14:47:29 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
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.
>> 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
> 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  against an
unauthenticated length field, even though that specific attack
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the tor-dev