[tor-dev] obfs4 questions

Yawning Angel yawning at schwanenlied.me
Fri Nov 28 13:39:14 UTC 2014

On Fri, 28 Nov 2014 13:08:04 +0000
Michael Rogers <michael at briarproject.org> wrote:

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


Yawning Angel
-------------- 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/c820fb4e/attachment.sig>

More information about the tor-dev mailing list