note: Title edited to make the answer more useful to a wider audience

I'm reading source code for encrypting files with AES GCM and see the following binary output.

     AdditionalAuthData  IV            Encrypted Data          Tag (16 bytes)
     --------------------_____________------------------..... ----------------------------
byte 012345678901234567890123456789012345678901234567890.....   42  ........  57 

Where the

  • AES key is secureRandom and 16, 24, or 32 bytes (Aside: is random sufficient? the code I'm seeing isn't secureRandom)
  • IV is a non repeating value. Can be random or increment per usage
    • Size is no smaller than 96 bits (12 bytes by NIST standard)
  • Tag/mac bit size equals 128

I want to be able to decrypt these files on a variety of devices. What changes to the parameters above should be done to ensure broad compatibility across devices?

Specifically, what should the length and contents of AdditionalAuthData be?

Is this the common layout for AES GCM encrypted data? (variable length cleartext, IV, followed by encrypted data)?

1 Answer 1


"Additional authenticated data" is whatever you wish it to be. GCM is an authenticated encryption mode in which the inputs are:

  • a key K suitable for AES (128, 192 or 256 bits);
  • a 96-bit IV;
  • some plaintext data P whose length is at most 239-256 bits (i.e. about 68.7 gigabytes);
  • some additional data A whose length is at most 264 bits (i.e. about 2.3 millions of terabytes).

From these inputs, AES/GCM produces:

  • a ciphertext C;
  • an authentication tag T.

For decryption, you need these as inputs:

  • the key K;
  • the IV;
  • the ciphertext C;
  • the authentication tag T;
  • and the additional authenticated data A (pay attention ! That's the tricky point).

Then AES/GCM decryption will produce either P (the plaintext), or complain loudly in case one of the parameters has been altered (i.e. the provided K, IV, C, T or A does not match that which was used or obtained during the encryption).

So what does that mean ? That means that an AE system, like AES/GCM, offers the following services:

  • It ensures confidentiality of P: adversaries who do not know K cannot guess anything about the contents of P, when they see only the other values (IV, A, C and T).

  • It ensures integrity of P and A: adversaries who do not know K cannot alter the IV, A, C and T values such that the decryption algorithm does not complain. So if the decryption works, then there is a good guarantee that the A and resultant P are identical to what they were when encrypting.

Nowhere in the standard is it specified how the various values should be concatenated, wrapped, or otherwise serialized for transmission. How C, IV, T and A are known to the receiver is completely out of scope, and is up to whatever protocol is using AES/GCM. The values needs not necessarily be transmitted. For instance, if you consider TLS 1.2 (and GCM-specific details): the IV is partially transmitted, and partially inferred (4 bytes from the handshake, 8 bytes with each record); the additional authentication data A is partially transmitted and partially inferred (concatenation of the record sequence number, protocol version and plaintext length); C and T are transmistted in the record body.

Any given protocol which uses GCM may or may not have need for the "additional authenticated data"; this is a feature of GCM: it can ensure integrity over more than the data which was also encrypted. Since both sender and receiver must know the same "additional authenticated data" for the decryption algorithm to succeed, that additional data may have to be transmitted, although it could also, in any protocol (as in the case of TLS), be inferred from context. In any case, that data cannot be recovered from the ciphertext C even with knowledge of the key, which is why it is called "additional".

Therefore, your first question makes no sense. AES/GCM output is not a sequence of bytes accumulating A, IV, C and T. AES/GCM produces two sequences of bits, C and T. Your question should be: is there a widely used protocol which builds on AES/GCM, and defines serialization formats for transmission of A, IV, C and T together ? And the answer to that question is: to my knowledge, no. There are some protocols, but nothing which qualifies as "widely used". In particular, in most cases, at least parts of A will be inferred from context, not transmitted, and the same could apply to parts or all of the IV. This makes it unlikely that a general purpose format emerges and is actually used everywhere.

The answer to your second question (length and contents of A) is: "whatever floats your boat". You don't encrypt and/or authenticate in abstracto, just for the sake of it. You encrypt and authenticate as part of an overall protocol used in a given context which dictates what should be encrypted and what should be authenticated (as is done in TLS).

As for your question about "whether random is sufficient" for the key, then the only possible comment is: I must respectfully ask, Sir, that you drop this keyboard and stop trying to do cryptography. Lest I should use violence.

  • For those interested in the non-random key, the source is here ; please direct violence to that link ;) (or a Git pull request) Commented Mar 19, 2014 at 17:30
  • 1
    That program is a benchmark; it measures encryption speed. There is no security requirement here; any key generation process would be fine (AES processing speed does not depend on the key value -- actually, when it does, we call that a timing attack). Commented Mar 19, 2014 at 17:46
  • Thank you. Also, I found T ... it was computed internally by Bouncy Castle and appended to the end of C. I suppose that all Bouncy-based code serializes in this order. Commented Mar 19, 2014 at 18:03
  • Can a given implementation set A or even P to null? And use AES GCM just for integrity? or is that a bad practice? Commented Mar 19, 2014 at 18:06
  • 1
    The standard certainly allows you to set either or both of A and P to a sequence of no bits. Whether a given implementation will allow a null pointer to represent an empty sequence is another question... As for using AES/GCM just for integrity: it is feasible, but usually not as efficient as HMAC (depending on hardware and the underlying hash function). HMAC is also more robust against poor design, because it has no IV, and thus no requirement on not-repeating IV values. Commented Mar 19, 2014 at 20:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .