2
$\begingroup$

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.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Thanks, Maarten! This answers my question if a truly 0 based IV would suffice. For my use case I generate a new key for each encrypted file and I never reuse keys. If a file needs to be re-encrypted then a new key is generated. What do you mean by "is the key truly random, even in time"? I am using KeyGenerator class in Java. It is initialized with SecureRandom() default implementation which should get entropy from the OS among other things and should provide enough randomness. $\endgroup$
    – Stan Ivanov
    Feb 23, 2017 at 0:25
  • $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes ♦
    Feb 23, 2017 at 0:30
  • $\begingroup$ Yes indeed. One of my goals is to add additional entropy to SecureRandom at a regular interval by utilizing additional factors in order to improve the general security of the application. I'll come back with questions about entropy generation soon :) $\endgroup$
    – Stan Ivanov
    Feb 23, 2017 at 0:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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