8
$\begingroup$

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?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
9
$\begingroup$

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.

Improve this answer
$\endgroup$
7
  • $\begingroup$ 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. $\endgroup$
    – hunter
    Mar 17, 2013 at 16:00
  • 1
    $\begingroup$ 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). $\endgroup$
    – Stephen Touset
    Mar 18, 2013 at 5:43
  • 1
    $\begingroup$ Sorry, the salt for the password should be kept secret. Not the nonce for encryption. $\endgroup$
    – Stephen Touset
    Mar 18, 2013 at 16:30
  • 1
    $\begingroup$ 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? $\endgroup$
    – hunter
    Mar 18, 2013 at 17:02
  • 3
    $\begingroup$ Yep, I'm an idiot. The password is the only component that needs to be kept secret. $\endgroup$
    – Stephen Touset
    Mar 18, 2013 at 17:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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