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.
I have summarized my research on how to use AES-GCM correctly in a blog post.