Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 5 down vote accepted

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.

share|improve this answer
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 '13 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 '13 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 '13 at 14:38
Sorry, the salt for the password should be kept secret. Not the nonce for encryption. – Stephen Touset Mar 18 '13 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 '13 at 17:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.