On Fri, 28 Nov 2014 14:47:29 +0000 Michael Rogers michael@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,