[tor-dev] obfs4 questions

Michael Rogers michael at briarproject.org
Fri Nov 28 14:47:29 UTC 2014

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.


[1] http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf
Version: GnuPG v1.4.12 (GNU/Linux)


More information about the tor-dev mailing list