-----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
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,
-----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
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,
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,
-----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
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,
-----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
-
Michael Rogers -
Yawning Angel