# Is it safe to use a counter as IV for AES256-GCM

What if I will use 96-bit integer counter starting from 0 as IV for AES256-GCM cipher. Is it safe? Is there any other ways to ensure uniqueness of IV for GCM cipher?

• Yes GCM was designed to work with simple counters. Aug 6, 2018 at 14:50
• Just be careful to NEVER, EVER reuse the counter - the IV is a nonce. Safely implementing a counter isn't as easy as it might seem at first. Aug 20, 2018 at 15:04

There is no difference in terms of security as long as no AES input block (the counter/IV not the plaintext) is repeated. (And you're not doing something extremely silly like making the input $AES_k^{-1}(ctr)$.)

You probably don't want/need to use a 96 bit IV if you can use a counter. Using a larger IV is good when you need to use random IVs to prevent repeats. But you're not using random IVs and it only leaves 32 bits for the other counter. You probably won't encrypt $2^{96}$ messages but you could want to encrypt something larger than 64 GB. (Or $2^{32} * (128 / 8)$ bytes.)

• Thank you for the answer. Unfortunately I don't understand what "making the input $AES_k^{-1}(ctr)$" means. Aug 6, 2018 at 16:28
• No I don't think I will encrypt something bigger than 64GB Aug 6, 2018 at 16:29
• @igor.sol The inverse of AES block encryption (decryption) using key $k$ and some value $ctr$ short for counter. But $ctr$ could be from any non-repeating pattern. $AES_k(AES_k^{-1}(x)) = x$ just as $AES_k^{-1}(AES_k(y)) = y$. It's unrealistically silly, but it was a necessary warning if we want to be pedantic. Aug 6, 2018 at 16:36
• Well, I probably won't encrypt $2^{96}$ messages. On the other side there are some difficulties with maintaining last used counter value between sessions. I need very fast generation of IV values so I cannot store counter value into durable memory after each increment. So I will reserve counter range blocks of some size (maybe something like $2^{15}$). This is why I will need at least 64 bits for counter. Anyway I will need to estimate these numbers Aug 6, 2018 at 16:39
• Ah, ok now I see what $AES_k^{-1}(ctr)$ means. This can happen randomly in a very rare case. Aug 6, 2018 at 16:43

See page 20 of the NIST recommendations (28 in the pdf, 20 on the page) - basically this is the deterministic construction (assuming you're doing less than $2^{64}$ messages), so yes this should be fine - assuming (!) that you don't reuse IV (even across restarts / crashes).

Alternatively, you can use the RBG construction, and use a secure random source to generate the IV.