[tor-dev] obfs4 questions

[Yawning Angel]

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
attackers either.

For more details see the original poly1305 paper[0] (nb: specified in
terms of using AES for the nonce->16 byte string mapping, but that is
arbitrary).

> >> 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 [1] 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).

Regards,

-- 
Yawning Angel

[0]: http://cr.yp.to/mac/poly1305-20050329.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20141128/6139e1db/attachment.sig>