# Minimum plaintext length for AES-GCM

In AES-GCM, from what i understand, the plaintext(as well as AAD and IV) bit length taken in must be a multiple of 8 (as specified by NIST Spes. Pub 800-38D). The AES-CTR however, doesn't "care" about the bit length.

The majority of my confusion comes from looking at how the AES-GCM works as a whole. It seems to me that to appropriately generate an authentication tag it needs two strings of plaintext. Additionally , the GHASH function seems to take in n 128-bit ciphertext strings.

Which leaves me with the question: What is the minimum amount of plaintext data required(after any padding) to appropriately encrypt and authenticate using AES-GCM?

• Data is usually enforced to be of length a multiple 8 bit, for practical reasons (you can actually use the smallest common unit in programming to address anything) and to avoid potential nasty bit-padding and to extend the reach of counters (imagine being only able to encrypt $2^{32}$ bit instead of $2^{32}$ bytes!) Oct 15, 2016 at 22:06
• This much i understand, but i find it unclear as to whether this means 8 bit plaintext is the minimum and that everything works appropriately with such a length, or if it has to be more than this to properly go through the GCM algorithm. Oct 15, 2016 at 22:09
• What do you mean with "after any padding"? GCM should work for zero bits without issue, and you aren't required to perform any padding before performing GCM. Oct 15, 2016 at 22:40
• @MaartenBodewes It was a poorly worded attempt to avoid someone coming with an answer talking about how i should do padding to fit with AES-GCM if that was necessary, rather than my actual question. — So one could without any issue or adverse effects on the properties of AES-GCM put in a single bit (or 17 bits for that matter) as the plaintext? Oct 15, 2016 at 22:57

The original proposal specifies:

A plaintext $P$, which can have any number of bits between 0 and $2^{39} − 256$.

The NIST SP 800-38D specifies:

Although GCM is defined on bit strings, the bit lengths of the plaintext, the AAD, and the IV shall all be multiples of 8, so that these values are byte strings.

So there is a clear difference between the original proposal and 38D. I presume that this is because the test vectors almost never contain any tests for plaintext (or AAD, IV and authentication tag) that are not a multiple of 8 bits. In that case it is probably better to leave it out.