Size of IV in AES-GCM according to RFC 4106

Question

RFC 4106 specifies about nonce. It contains a salt of size 4 octets and an iv of size 8 octets. Further, RFC specifies that salt is assigned at the beginning of the security associations which is established through Internet Key Exchange (IKE) and salt value is constant. But all most all of the implementations and descriptions found about AES-GCM specifies iv as 12 octets and there is no consideration of salt value.

AES-GCM takes inputs as a secret key, an IV, a plaintext and Additional Authenticated Data (AAD). AES-GMAC is a variant of AES-GCM which provides authentication of data by keeping plaintext as zero bits.

Other questions I have regarding AES-GCM mode are.

1. I know that AES-GCM can be used for authentication of data by Can we use AES-GCM mode only for encryption by ignoring authentication?
2. Is it mandatory to use iv for encryption using AES-GCM?
3. What are the allowable variants of AES-GMAC like AES-GMAC128, AES-GMAC256 etc. ?

Answer 1

kelalaka answered your questions, however I do believe there are things that could use some clarification:

RFC 4106 specifies about nonce. It contains a salt of size 4 octets and an iv of size 8 octets. Further, RFC specifies that salt is assigned at the beginning of the security associations which is established through Internet Key Exchange (IKE) and salt value is constant. But all most all of the implementations and descriptions found about AES-GCM specifies iv as 12 octets and there is no consideration of salt value.

First, a clarification on terminology (at least, the terminology I'll be using in my answer below):

• Nonce - this is the (typically 96 bit) value passed to the GCM routine

• IV - this is the value within the packet - IPsec with GCM uses 64 bit IVs

• Salt - this is the additional value that is included with the recipe to generate the nonce.

RFC 4106 is specifically about how to use GCM within IPsec; as such, it has a recipe for generating the nonce (which you refer to as an 'iv') that GCM requires. It does it by talking 8 bytes chosen by the encryptor (which he places in the 'iv field' within the packet, and which the decryptor extracts from the packet), and 4 bytes for the key derivation (the 'salt') and concatenating them.

This is specific to IPsec (actually, TLS's use of GCM does the same thing); other protocols which use GCM may generate (and communicate) their nonces in a different way. Because a cryptographical routine is typically protocol agnostic, they would not have the IPsec-specific recipe built in. Instead, they would assume that something protocol specific would generate the nonce, and pass the entire nonce in.

As for why IPsec uses this specific recipe to generate GCM nonces, well, it's to frustrate potential multitarget attacks. Suppose that the attacker has a large number of GCM encrypted sessions, and that he would like to recover the contents of one of them (and doesn't really care which one it is). Further suppose that the GCM implementations use the same IVs for each session (e.g. the first encrypted packet might always use an IV of 0). Then, what the attacker might try to do is guess an AES key, and generate the GCM privacy keystream, and see if that the correct keystream for the initial packet for any session (that turns out to be efficient with plausible assumptions). If he could do that, that would mean that, for a 128 bit key and $N$ sessions, his expected work effort to break one of the sessions is $2^{128}/N$ trial decryptions, which is less than we want. However, by including the 32 bit salt (which varies between sessions), this expected work effort increases to $2^{160}/N$ (because he has to guess the salt as well as the key); in particular, this means that this multitarget attack is actually less efficient than a simple brute force attack unless $N > 2^{32}$, which is quite a lot. Note that this salt doesn't actually help against brute force attacks against a single session; it doesn't hurt either. And, it doesn't really have to be secret (however, there's no particular reason we have to go out of our way to publish it either...)

Answer 2

1. I know that AES-GCM can be used for authentication of data by Can we use AES-GCM mode only for encryption by ignoring authentication?

Let's remember that AES-GCM is an Authenticated Encryption with Associated Data (AEAD) that uses

• AES in CTR mode for confidentiality which can only provide CPA security
• GMAC for integrity and authentication which is a Wegman-Carter MAC based on a polynomial hash function called GHASH.

The combination is an encrypt-then-MAC fashion.

Of course - not advised - one can use AES-GCM without authentication by simply discarding the authentication tag. Since GCM uses the first two counter this will be equal to CTR if you start the counter from 2.

One will have some problems mostly performance with standard implementations that will generate and require the tag. One may need to generate it, send it, provide it to the decrypter, and ignore any tag error! Wait! or one may need to modify the source code.

By not using the GCM part, one gets only confidentiality at most CPA security, instead one can use the CTR mode for confidentiality. One doesn't need the GCM part. Just use plain CTR mode that will reduce the processing time of GCM calculations. This is not advisable in modern cryptography. At least

• IND-CCA2—ciphertext indistinguishability under adaptive chosen-ciphertext attack

is required.

2. Is it mandatory to use iv for encryption using AES-GCM?

An (IV,key) pair must not be used more than once. If an IV reused with the same key it will cause a crib-dragging attack as in two-time-pad and also it can have a catastrophic failure for signature forging.

If you can guarantee that you will always use a new key then you can keep the IV fixed or even zero. This is also not advisable since you are reducing the collision probability of the IV-Key pair and not advised from the authors, too. You will have a collision with 0 probability after generating $2^{64}$ keys instead of $2^{128}$ if the IV and the encryption key is randomly generated. If we stick to RFC 4106 then $2^{112}$ since it uses 92-bit IV (RFC 4106 uses nonce instead of IV not to mix with ESP's IV.)

3. What are the allowable variants of AES-GMAC like AES-GMAC128, AES-GMAC256 etc.?

RFC 4106 only mentions AES-GCM. If you want to use it, you have only GCM.

The GMAC (Galois Message Authentication Code) is an authentication-only variant of the GCM which can form an incremental message authentication code. GCM and GMAC are standardized in NIST 800-38d .

AES-GCM is also used in TLS 1.3 where there are only 5 cipher suites.

But all most all of the implementations and descriptions found about AES-GCM specifies iv as 12 octets and there is no consideration of salt value.

NIST GCM specification (NIST.SP.800-38D) recommends 12 octets and if you use 16 octets or more generally if you supply a nonce not equal to 12-byte, then it will be processed with GHASH and the size will be 12-byte after that.

if len(IV) = 96 then 
    J_0 = IV || 0^{31}1
else 
    J_0=GHASH_H(IV||0^{s+64}||len(IV_64))

The salt defined in RFC 4106. NIST is governmental and if you are in the USA you need to be using the NIST standard to be compatible and competitive.

The salt field is a four-octet value that is assigned at the beginning of the security association, and then remains constant for the life of the security association.

so it is specific to the protocol.