How to use GCM mode and associated-data properly

I'm currently migrating a project to use the bouncy castle GCM mode. I understand that using an authenticated mode removes the need for a HMAC, however I want to be sure that I'm using this mode correctly. When applying a HMAC to ciphertext, I know it's imperative to include in the HMAC'd data any params that could affect the outcome of the decryption (IV, block-size, algorithm name, etc). The bouncy castle GCM implementation accepts AEAD parameters, one of which is 'Associated Text'.

With authenticated modes, is it correct to:

• use encryption params as Associated Text
• encrypt cleartext (without params appended)
• append params to ciphertext (in cleartext) to facilitate future decryption

I assume this workflow applies to EAX mode as well?

-

GCM mode already incorporates any params that could affect the outcome of the decryption. The associated authenticated data is there to allow you to rely on context for your decryption.

For example, say you are encrypting some records associated with a user. You may want to include the user's database ID as the authenticated data. If a user found a way to copy another user's data and key into his own record, it would still fail to decrypt since his database ID is not the same.

In general, you would like it to be something that's inherently managed separately from the nonce and ciphertext.

-
As for GCM mode already incorporating any params that could affect the outcome of the decryption, if I use PBKDF2 to generate a key from a password, and the iterations and salt (may) change for each encryption, then changing them would obviously affect the outcome of the decryption. GCM can't automatically incorporate these params unless it knows about them, so is it right to assume that they should be included as associated data? Thanks for your explanation... I gather that the Associated Data param works like the 'info' param in HKDF. –  hunter Mar 17 at 16:00
Those aren't really useful to include. The KDF should be assumed to be collisionless, so the mere fact that they have the key should be sufficient to prove that they know the password and salt. Also, I believe that the AAD should not be used for any data that must be kept secret (which the password and nonce must be). –  Stephen Touset Mar 18 at 5:43
the nonce must be kept secret? I've never used CTR or GCM mode in production, but I understood that it's similar to the IV in CBC mode in that it isn't secret, and can be prepended to the ciphertext in the clear. Is that incorrect? –  hunter Mar 18 at 14:38
Sorry, the salt for the password should be kept secret. Not the nonce for encryption. –  Stephen Touset Mar 18 at 16:30
Sorry to be a pain in the a but I was under the impression that salts (whether for hashes or KDFs) didn't need to be secret. Is there an advantage to keeping them secret? –  hunter Mar 18 at 17:02
show 2 more comments