# Ciphertext and tag size and IV transmission with AES in GCM mode

I am completely new to using AES in GCM mode of operation, and I have not a very large background in cryptography as well. I have been playing with OpenSSL trying to encrypt and decrypt some messages. From my simple experiments rise the following questions:

1. First of all, I noticed that the size of the output is exactly the same as the input. I am confused. As far as I knew, AES works in blocks of 16 bytes. I am used to CBC mode, where the message needed padding. Does this mean that GCM can work with any size of the input, without having to pad and unpad things?
2. I read that the IV can be of any size, and that it is sufficient for it to be non-repeating. Does this mean, for example, that I can use a 4 bytes iv with a progressive counter? Is that just as easy as that or are there security issues with short and predictable IVs?
3. Since I need to generate a new IV for every message, how am I supposed to transfer it? As far as my understanding goes, the secrecy of IVs is not fundamental... does this mean that I can just send each IV in plaintext along with its message? If not, what should I do to let the other endpoint know about my iv?
4. Are MAC tags always 16 bytes long?

I hope these questions are not exceedingly dumb. They should definitely be simple and quick to answer.

• 1) Yes, GCM internally uses CTR mode (bit precision), which turns block-ciphers into stream ciphers 2)Yes, counters are allowed for GCM, the only requirement is non-repeating. 3) Implicit (message number) or explicit (just prepend it) 4) For GCM, yes, they're always 16 bytes long due to the way the MAC is generated. – SEJPM Jul 7 '15 at 20:55
• 4) is incorrect in your comment / answer according to the NIST specifications. That said, the algorithm simply creates a 128 bit tag result first and then as many bits are truncated from the right (keeping on byte boundaries). – Maarten Bodewes Jul 7 '15 at 21:17
• If you want to use short MACs use a different MAC algorithm (e.g. HMAC). – CodesInChaos Sep 30 '15 at 16:15

1. Output size = input size That's correct, GCM uses CTR internally. It encrypts a counter value for each block, but it only uses as many bits as required from the last block. CTR turns the block cipher into a stream cipher. Note that this doesn't include the optional additional authenticated data (AAD), the optional IV nor the required authentication tag.

2. IV of any size For GCM a 12 byte IV is strongly suggested as other IV lengths will require additional calculations. In principle any IV size can be used as long as the IV doesn't ever repeat. NIST however suggests that only an IV size of 12 bytes needs to be supported by implementations.

3. How to transport IV Yes, generally the IV is prefixed to the ciphertext or calculated using some kind of nonce on both sides. The size of the IV should be defined by the protocol.

4. Size of authentication tags The calculated tag will always be 16 bytes long, but the leftmost bytes can be used. GCM is defined for the tag sizes 128, 120, 112, 104, or 96, 64 and 32. Note that the security of GCM is strongly dependent on the tag size. You should try and use a tag size of 64 bits at the very minimum, but in general a tag size of the full 128 bits should be preferred.

NIST Special Publication 800-38D (page 8) defining GCM has the following on the tag sizes:

The bit length of the tag, denoted $t$, is a security parameter, as discussed in Appendix B. In general, $t$ may be any one of the following five values: 128, 120, 112, 104, or 96. For certain applications, $t$ may be 64 or 32; guidance for the use of these two tag lengths, including requirements on the length of the input data and the lifetime of the key in these cases, is given in Appendix C.

• is the authentication tag always appended at the last of ciphertext? – RE350 May 27 '16 at 11:14
• @RE350 No, it is just an output of GCM. But there might be things like this RFC that define otherwise. It is kind of common practice though. Personally I don't like cryptographic API's that see it as part of the ciphertext as it makes for an asymmetric implementation for encrypt/decrypt which is not on line during decryption (as you don't know if something is ciphertext or authentication tag before you know the end of the stream). It's OK for protocols to specify it that way though, especially if the stream size is known beforehand. – Maarten Bodewes May 27 '16 at 11:19
• @MaartenBodewes completely agree, how is one to know what is CT and what is not if everything is appended "willy nilly" – ragardner Mar 18 at 9:23