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