On Fri, 28 Nov 2014 13:08:04 +0000 Michael Rogers <michael@xxxxxxxxxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > 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. The code cuts the connection if the counter would wrap though that's unlikely at any sort of realistic data rate given the use case. > 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. > 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. Regards, -- Yawning Angel
Attachment:
pgpWHTcb2S09K.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev