[tor-dev] obfs4 questions
yawning at schwanenlied.me
Fri Nov 28 15:37:06 UTC 2014
On Fri, 28 Nov 2014 14:47:29 +0000
Michael Rogers <michael at briarproject.org> wrote:
> I believe so too, but is it stated anywhere that this is a guaranteed
> property of crypto_secretbox?
The Poly1305 authenticator is calculated based on the payload and the
nonce. In the case of the NaCL secretbox construct, 32 bytes of zeroes
encrypted based on a one time key/counter derived from the actual key
and the nonce. If the frames are reordered, the derived authenticator
would be different.
So yes, it is a property of crypto_secretbox because that's how Poly1305
works. It wouldn't be a workable AEAD mode if nonces (which usually
are transmitted in the clear) could be modified undetected by
For more details see the original poly1305 paper (nb: specified in
terms of using AES for the nonce->16 byte string mapping, but that is
> >> 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.
Probably not, but at that point, 2 boxes is also likely fine since it
wasn't unusably slow.
> 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
> wouldn't apply.
This was brought up by phw during the obfs4 design phase. The code
randomizes the length if it is invalid as per one of the suggested
countermeasures in section 6 of the paper (So an identical failure to
a modified plaintext/tag is observed).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the tor-dev