# Can I use a deterministic NONCE for AES-GCM file encryption if I generate "fresh" keys for each encrypted file

The NIST specification states that the deterministic NONCE(IV) should be 96 bits. It should consist of two fields: fixed field of 32 bits and a 64 bit counter. The use of a random 96 bit NONCE is discouraged (https://eprint.iacr.org/2016/475.pdf).

My use case is encrypting files on disk. Each file is encrypted with a new key generated by a KeyGenerator, initialized with the default SecureRandom() implementation. My question is this: do I really need a fixed field, or can I make the whole 96 bit NONCE initialized to 0. As in a 96 bit counter. This way the NONCE is effectively deterministic and I don’t have to store it as part of the file. Since a new key will be generated for each new encrypted file, then I shouldn’t ever reuse a key/NONCE pair which would be detrimental for AES-GCM.

I’ve seen some suggestions that the fixed field is actually a 32 bit random integer, but I think this is not necessary as I’d never re-use a key/IV in my construct (http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-spec.pdf).

My only concern then would be to ensure that I never generate 2 identical 256 bit keys out of SecureRandom, but that proof seems impossible to me and the probability of such event seems negligible. The only way to ensure I never generate duplicate keys is to keep the keys or their fingerprint in a database, but this is undesirable. But then even if I do employ a 32 bit random integer in my fixed field I also have no guarantee that a probabilistic event won’t happen and create a duplicate key/IV.

## Update

I have summarized my research on how to use AES-GCM correctly in a blog post.

• Yep, that should work. KeyGenerator and new SecureRandom() normally suffices. Maybe you could seed the RNG with the filenames and such (seed is added to the RNG state, it doesn't replace it) just to be somewhat less reliant on the OS. Feb 23 '17 at 0:30