2
$\begingroup$

Building off of Relationship between AES GCM and AES CTR... if your GCM nonce is "aaaa aaaa aaaa" (no spaces) then the CTR IV is that with (0,0,0,2) appending to it.

My question is... what happens when the counter gets to (255, 255, 255, 255)? Would the last five bytes be (98, 0, 0, 0, 0) (where 98 = b) or would they be (97, 0, 0, 0, 0) (where 97 = a)?

I'm guessing the latter but idk.

Thanks!

| improve this question | |
$\endgroup$
  • 2
    $\begingroup$ I think the simple answer is : it should not so it is not defined. You'd hope for $\bot$, i.e. an error. Note that this is some 64 GiB of data that you're talking about, well above the maximum size of data to be encrypted using GCM and a single key. $\endgroup$ – Maarten Bodewes♦ Dec 3 '18 at 9:09
3
$\begingroup$

In the NIST Special Publication 800-38D page #8 the maximum inputs lengths are defined in the standards as;

The bit lengths of the input strings to the authenticated encryption function shall meet the following requirements:

  • $len(P) \leq 2^{39}-256$

and in section 8.3 the number of invocations requirements for all implementations:

The total number of invocations of the authenticated encryption function shall not exceed $2^{32}$, including all IV lengths and all instances of the authenticated encryption function with the given key.

  • As a result, the recommendation doesn't advice the overflow of the counter.

We can find the maximum as:

$2^{32}$ invocation, per invocation you can encrypt 128-bit ($2^7$-bit) with AES, thus

$2^{32} \cdot 2^{7} = 2^{39}\text{-bit} \approx 68.7\text{GB}$ is the maximum data that one can encrypt with AES-GCM under the NIST recomendation.

| improve this answer | |
$\endgroup$
  • $\begingroup$ @MaartenBodewes $2^{32}$ invocation times $128=2^7$-bit block = $2^{39}$-bit when converted 68.7194767 gigabytes. Messing something? $\endgroup$ – kelalaka Dec 3 '18 at 13:25
  • 1
    $\begingroup$ Well, you go from bits to bytes without explicit conversion. I guess it makes sense to clearly indicate bits in the first len calculation and the left side of the equation. Without it I expect the same unit as the result. Note that the part of 8.3 is identical to the previous len calculations, just less precise. I'm a programmer, I hate it when I cannot tell bits from bytes in a program :) $\endgroup$ – Maarten Bodewes♦ Dec 3 '18 at 13:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.