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.
Yes, you can set the IV to zero if you use a different key each time. You speak about a random key, but is the key truly random, even in time? What happens if a file is changed, what attack vectors would surface in such a case? 

Using a 32 bit random "fixed" integer is not a good idea. You'd quickly produce collisions even for a relatively small amount of files stored with the same key. So whatever you try to fix with that, it won't be fixed enough to be called secure in a cryptographic sense.

If you worry about the keys not being random, I'd add some startup tests for the random number generator instead. Because without a trusted random number generator a lot of operations are not going to be secure.