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