On Fri, 28 Nov 2014 14:47:29 +0000 Michael Rogers <michael@xxxxxxxxxxxxxxxx> 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
Attachment:
pgpiq0LVamXur.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev