# AES use same Nonce security risk?

If I use AES-GCM and encrypt data with a 128 Bit Key and always use the same Nonce.

Is using the same nonce a security risk? Can a hacker guess the Key? Or is the Nonce only to verify that the message was not corrupted?

Especially if I encrypt/store small amounts of text like in an dictionary:

``````a
aa
b
bb
c
cc
...
``````

Thanks

• Nonce implies that it should only be used once. Sep 13, 2016 at 20:51
• The only purpose of a nonce is to be a unique value to avoid replay attacks & similar. By using the same nonce everytime you could just not use a nonce at all... in both cases you can be affected by replay attacks. Sep 14, 2016 at 13:28

When using AES-GCM, using the same nonce and key pair for multiple messages is catastrophic. You lose all of the security guarantees AES is supposed to provide. This is the worse possible scenario you could create. It is critical when using AES-GCM that the nonce is never repeated for any given key. The best way to ensure this is to use a cryptographically strong PRNG to generate a new 96-bit nonce for each message, and to re-key at reasonably regular intervals, where "reasonably regular" is defined by how much data and how many messages you're encrypting.

• big thanks for your answer. I wanted to use AES-GCM with the same Nonce to be able to do Search on Encrypted Data. Because the output is always the same. This was my initial question: security.stackexchange.com/questions/136450/… . Its not related to this question here, but could you recommend me an algorithm, in order to be able to do search? Thanks Sep 13, 2016 at 20:57
• You could always use a deterministic algorithm, like a KDF, to determine the nonce. It doesn't matter that it's random, just that it never collides. Especially if you're working with small data, you could run the data itself through a KDF (HKDF is my favorite) to get the number of bytes you need in a deterministic way. Sep 14, 2016 at 5:11
• @JohnSmith: For that purpose (secure deterministic encryption), you should use SIV mode (or even GCM-SIV, if you like GCM). What SIV mode does internally is basically what MrNerdHair suggests, i.e. deriving the IV from the message, but it does it in a specific way that is provably secure, assuming that the underlying cipher is. Sep 14, 2016 at 6:15
• @JohnSmith You could use ROT13 instead. Simpler and the security is pretty close. Sep 14, 2016 at 14:52
• Would it matter if the nonce was simply just incremented each time? Are there any known attacks? Sep 14, 2016 at 15:10

Please refer to NIST publicaton SP 800-38A for details regarding the best practices for using an 'nonce' as an IV.

There are two recommended methods for generating unpredictable IVs. The first method is to apply the forward cipher function, under the same key that is used for the encryption of the plaintext, to a nonce. The nonce must be a data block that is unique to each execution of the encryption operation. For example, the nonce may be a counter, as described in Appendix B, or a message number. The second method is to generate a random data block using a FIPS approved random number generator.

In regards to AES-GCM mode (Galois/Counter Mode); as quoted from the NIST published paper from David A. McGrew & John Viega.

The primary purpose of the IV is to be a nonce, that is, to be distinct for each invocation of the encryption operation for a fixed key. It is acceptable for the IV to be generated randomly, as long as the distinctness of the IV values is highly likely.

And of course the obvious obligatory definition of an nonce.

AES-GCM is an authenticated stream cipher.

The nonce will be used for the key of the stream cipher, and the first rule of stream ciphers is you don't talk about stream cipher never use the same key/IV twice.

Ignoring this rule leads to catastrophic failures in encryption.

On the other hand, the nonce will also be used to prevent "replay" attacks on the authentication part of the cipher. So even if you magically avoided directly weakening the cipher by reusing the nonce, you'd still be weakening authentication and consequently the cipher.