Re: [tor-dev] obfs4 questions

[Michael Rogers <michael@xxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Thanks for the quick response!

On 28/11/14 13:39, Yawning Angel wrote:
>> 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.

Cool, thanks.

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

I believe so too, but is it stated anywhere that this is a guaranteed
property of crypto_secretbox?

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

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.

Cheers,
Michael

[1] http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJUeIsAAAoJEBEET9GfxSfMcuAH/RsyuUI78hw8d3Zii3ke8INY
lA/9ID/2VW0Qh51HfvEkzzogl41AYG9u+Y0PUvMeDm4vCIMt35CqPxiaVDk4L45Z
rkOlenEr3AUoKQglZWuntwcc1tESpFHQ96aXfzQ9+fuayIPlPrnlmKXwAQubunfU
XUeXqiAFu4cGulAxF0hksgXlwOrbBywZD06aiwFodXc+8hfNxiedokdB7Xz3E2Rs
JExeRJw6PVpFfT9qhRlD5TaKEFne/DwZqbIfEO8xNqlTD29LlYc21KK5eGIx0ufE
PR3qNUeh0Kv6iSA14tdmbooQ5ls+ULYQzJL1uW0bp35spG3U98Nb2YqbUAuCsuk=
=noec
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev