-----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? 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. 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)? Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUeHO0AAoJEBEET9GfxSfMcPEH/iEYxlXtceeG3/wzp97oW/He lPNqqowyXczlyJO0SDG8L96hG6RYQZb7M0t8KJsYJapAznioZi2/qRQEC2/VFXg1 1EN//Bd9iO7QUXaIo1djC97Qoq3qmR/GY50xKYIjxr/gZSLk2dAAtleFUuerBrl9 nLrTr7kSKk3xzY0GFYtYKbj3bvuGusGrFioAIgfnKtF8iAlSjEIo8uE2Y1RFVu2d Q9GOake1VjC5V7Ue/MDCpWagwebPhnDHXSCWSXhvrYT5rmkjrkR2nhl2hAIq/0pA sfjsGquMrT5fdXcRrQaxHsamCt1228/ZlEAkCep/PRpS0NgLDJlRtPe49RD44Gk= =OHtY -----END PGP SIGNATURE-----
On Fri, 28 Nov 2014 13:08:04 +0000 Michael Rogers <michael@briarproject.org> 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
-----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-----
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, -- Yawning Angel [0]: http://cr.yp.to/mac/poly1305-20050329.pdf
On Fri, 28 Nov 2014 15:37:06 +0000 Yawning Angel <yawning@schwanenlied.me> wrote:
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.
Ugh, I did a terrible job of explaining that, sorry to reply to myself. A one time poly1305 key is calculated for each box, based on 32 bytes of zeroes encrypted with a one time Salsa20 key/counter derived from the nonce and the box key. You can view the use of Salsa20 there as an arbitrary keyed hash function (in the case of the original paper, AES was used). Hope that clarifies things somewhat, -- Yawning Angel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 28/11/14 15:50, Yawning Angel wrote:
A one time poly1305 key is calculated for each box, based on 32 bytes of zeroes encrypted with a one time Salsa20 key/counter derived from the nonce and the box key. You can view the use of Salsa20 there as an arbitrary keyed hash function (in the case of the original paper, AES was used).
Hope that clarifies things somewhat,
Thanks - this is similar to the argument I came up with. I called my argument hand-wavy because it relies on HSalsa20 and Salsa20 being PRFs, and I don't know how big an assumption that is. I mean, I'm sure it's fine, I was just wondering if the designers had explicitly said anywhere that it was fine.
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.
Well that's the thing - crypto_secretbox isn't an AEAD mode, it doesn't support additional authenticated data. With a typical AEAD mode like GCM (which doesn't derive the authentication key from the nonce) you can include the nonce in the AAD, so it's explicitly authenticated. With crypto_secretbox it seems like the nonce is implicitly authenticated, but I just wanted to be sure. Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUeLeGAAoJEBEET9GfxSfM3hwH/A72XG9bGgAJM6JgF2aW3SLr rVI+UKb4Z7SgHIP++fgNsVoNG1X6PRZ1/5Va0/TLaLFEIyEQrY77+GIE1h2jADQS 7hdYu3bfSELQDMnib/BeQnrw5cZ348gxG9yXYCGZjXFrhiQJ6nfxpMZdkWUuFSew 4ORj3GgMRPkfw1cuwmOX3O84+ZXb9Nma1elTe6xgL/fUYdmQ6FlM/CEMnD7NKxBK DCVbUr6aiRYI+6x4waCP7ZIMYCGJSAFjzOnfQwDhqdIu7FGeOAw7bpdj7iTREZ7Z XAdh2lfhkYuH815UteDFb151O9ll8BMm9IFDmxPsYmIsDlkjfxQZZ5c+Twp2Dr0= =1Zde -----END PGP SIGNATURE-----
On Fri, 28 Nov 2014 17:57:26 +0000 Michael Rogers <michael@briarproject.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 28/11/14 15:50, Yawning Angel wrote:
A one time poly1305 key is calculated for each box, based on 32 bytes of zeroes encrypted with a one time Salsa20 key/counter derived from the nonce and the box key. You can view the use of Salsa20 there as an arbitrary keyed hash function (in the case of the original paper, AES was used).
Hope that clarifies things somewhat,
Thanks - this is similar to the argument I came up with. I called my argument hand-wavy because it relies on HSalsa20 and Salsa20 being PRFs, and I don't know how big an assumption that is.
For what it's worth "7 Nonce and stream" both support using a counter here as the nonce, and refers to 'The standard ("PRF") security conjecture for Salsa20". IIRC the security proof for the extended nonce variants also hinges on the underlying algorithms being PRFs as well, so it's something I'm comfortable in assuming. http://cr.yp.to/highspeed/naclcrypto-20090310.pdf Regards, -- Yawning Angel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 29/11/14 00:35, Yawning Angel wrote:
On Fri, 28 Nov 2014 17:57:26 +0000 Michael Rogers <michael@briarproject.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 28/11/14 15:50, Yawning Angel wrote:
A one time poly1305 key is calculated for each box, based on 32 bytes of zeroes encrypted with a one time Salsa20 key/counter derived from the nonce and the box key. You can view the use of Salsa20 there as an arbitrary keyed hash function (in the case of the original paper, AES was used).
Hope that clarifies things somewhat,
Thanks - this is similar to the argument I came up with. I called my argument hand-wavy because it relies on HSalsa20 and Salsa20 being PRFs, and I don't know how big an assumption that is.
For what it's worth "7 Nonce and stream" both support using a counter here as the nonce, and refers to 'The standard ("PRF") security conjecture for Salsa20". IIRC the security proof for the extended nonce variants also hinges on the underlying algorithms being PRFs as well, so it's something I'm comfortable in assuming.
Awesome, thanks! Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUeYwsAAoJEBEET9GfxSfM9PsIAIADA/7Lfkx9kxxkvfggMNQZ Ln71QB//POwEskJSVftg/NE30pdw9KiYA8EJLA5El62UxUT4NS8OOyiGTSXz3IDo dvBcnOls9HAVYeE7HjOeKdiwwitjBv0+QFetGY+0XNAjkmHLkU+cQdO9+jkJ122l nWLFaOj1o3qjx7QHiL7TKqFf+Rh1P/quurNBYrexM2uRxsAXQgncGMVaLgGAdvmu h09NotPW5sDTmu4m6HgRFQKYD15sPkkF2C65IkQNiO0Al7NIVcxq6JEtzLMcK66t jZpvZe+U/XrgEFqzkxYep20bFITTovXkC6cMhm4iA5X58ZKWnGf8eBxVs/RCDCY= =2auj -----END PGP SIGNATURE-----
participants (2)
-
Michael Rogers -
Yawning Angel