4
$\begingroup$

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?

Improve this question
$\endgroup$
4
  • $\begingroup$ 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!) $\endgroup$
    – SEJPM
    Oct 15, 2016 at 22:06
  • $\begingroup$ 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. $\endgroup$
    – henrheid
    Oct 15, 2016 at 22:09
  • 1
    $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes ♦
    Oct 15, 2016 at 22:40
  • $\begingroup$ @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? $\endgroup$
    – henrheid
    Oct 15, 2016 at 22:57

1 Answer 1

Reset to default
5
$\begingroup$

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.

So onto your question:

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

Well, zero bits, obviously. GCM doesn't require any padding of the plaintext before it is used within the algorithm. Steps 4 & 5 in 7.1 of 38D define how the input is padded before it is used. Although the specification is limited to accepting bytes, there is nothing stopping you from creating an implementation that operates on bits.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Good answer, thanks! Just to make sure i understand you correctly: It would work perfectly fine to implement it taking 1 bit, but (possibly due to the specification) implementations that are in use will typically take in (and "work on") 1 byte? $\endgroup$
    – henrheid
    Oct 15, 2016 at 23:06
  • $\begingroup$ @henrheid Yeah, I haven't seen many bit level implementations of cryptographic algorithms period. I've tried to generate one myself, but that's a pretty tricky thing to do, if just for the lack of easy to handle input data type. In general the input is in bytes The bytes then get converted to the specific size that the algorithm operates on during actual operation, e.g. 32 bit for SHA-256 and 64 bit for SHA-512 to name just one example. $\endgroup$
    – Maarten Bodewes ♦
    Oct 15, 2016 at 23:59
  • $\begingroup$ Makes sense. :) Thanks for the clarification and the swift replies! Much appreciated! $\endgroup$
    – henrheid
    Oct 16, 2016 at 0:08

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.