43
$\begingroup$

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.

Improve this question
$\endgroup$
3
  • 1
    $\begingroup$ If you want to use short MACs use a different MAC algorithm (e.g. HMAC). $\endgroup$
    – CodesInChaos
    Sep 30, 2015 at 16:15
  • 1
    $\begingroup$ It is not sufficient for an IV to just be non-repeating. It must be non repeating AND unpredictable. This is the difference between an IV an a nonce. $\endgroup$
    – 8vtwo
    Jan 29, 2022 at 2:31
  • $\begingroup$ To echo @8vtwo - your IV should not be predictable unless you're really sure what you're doing. Better to randomly generate one. $\endgroup$
    – DharmaTurtle
    Dec 21, 2022 at 20:50

1 Answer 1

Reset to default
63
$\begingroup$

I'll answer in order:

  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 any additional authenticated data (AAD) that needs to be send, the optional inclusion of the (otherwise required) IV nor size of 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. If it is possible to synchronize a nonce of 12 bytes then the IV doesn't need to be included with the ciphertext.

  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.

Improve this answer
$\endgroup$
6
  • 1
    $\begingroup$ is the authentication tag always appended at the last of ciphertext? $\endgroup$
    – dReAmEr
    May 27, 2016 at 11:14
  • 4
    $\begingroup$ @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. $\endgroup$
    – Maarten Bodewes ♦
    May 27, 2016 at 11:19
  • 2
    $\begingroup$ @RE350 if you are using the standard Java API (i.e. Cipher), then the Auth Tag IS always appended to the ciphertext returned, i.e. cipherInstance.doFinal will return (cipherText + authTag) $\endgroup$
    – david.barkhuizen
    Sep 30, 2019 at 9:25
  • 1
    $\begingroup$ Just note that the FIPS publication mentioned above also accepts 16byte IVs generated using a secure random number generator. However, note that in this case (and even for longer IVs generated in this way) that the total number of encryptions performed under a given key is 2^32. $\endgroup$
    – Dan Draper
    Jan 3, 2020 at 5:33
  • 1
    $\begingroup$ I just want to make one thing clear that UNLIKE A NONCE an IV must NOT BE PREDICTABLE. $\endgroup$
    – 8vtwo
    Jan 29, 2022 at 2:35

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.