# AES-GCM and its IV/nonce value

I was reading about the differences between the GCM and the CBC more here and I have a follow up doubt on the same.

In the CBC mode the person who performs the encryption is the one who provides the IV for the encryption -- and the IV is required to decrypt the ciphertext.

However, in GCM i read that the nonce value is internal -- so is it a value which needs to be kept in track off by the person who encrypts / decrypts the values? I'm specifically referring to the Java BouncyCastle implementation of AES-GCM.

Is the nonce value effectively an IV supplied by the person who encrypts the data appended with an internal counter?

-

Yes, the nonce will be used with a counter appended in order to generate the CTR mode keystream.

It will also be used as an input to GHASH: which is a polynomial MAC used to authenticate the data.

The nonce itself does not have to be random, it can be a counter. But it absolutely must be unique for each message encrypted with the same key. Using GCM on two different messages with the same key and nonce basically allows an attacker to decrypt both messages and forge further messages. (There are some limitations, but they aren't significant enough for it not to be devastating to the cryptosystem.)

So you can either have each side keep track of a counter as the nonce, or you can send it in the clear before each message; so long as it's unique.

For an example in a real-world protocol, see the GCM spec for TLS 1.2: https://tools.ietf.org/html/rfc5288#section-3. It concatenates a value from the handshake and a counter to form the nonce.

-
One minor correction: if the nonce isn't exactly 12 bytes, when the method for generating the internal counter is rather more complex than what you described. On the other hand, I've never seen anyone actually use a size other than 12 bytes with GCM –  poncho Dec 23 '12 at 16:22