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

-

## 2 Answers

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

Its generally use it to authenticated the sequence number to protect against deleted messages and replay attacks

-
Do you have any sources to back up your answer? I'm not so sure you are correct. –  mikeazo Jan 26 at 14:19
Your answer is very hard to understand. What is “it”? How does this relate to the question? –  Gilles Jan 26 at 17:46
This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post - you can always comment on your own posts, and once you have sufficient reputation you will be able to comment on any post. –  e-sushi yesterday
Authenticated encryption by itself doesn't protect against deleted or replayed messages. It only prevents modifications of the message itself. A protocol can use a nonce together with authenticated encryption to achieve these properties, but if mean that, you should say it clearly. –  CodesInChaos 16 hours ago