How to apply IV and tag to protect messages encrypted using AES-GCM?

Question

I'm applying the Arduino Crypto Library for the code fragments.

In the above library, example of encryption and decryption using GCM given as follows:

For encryption:

GCM<AES256> gcm;
gcm.setKey(key, sizeof(key));
gcm.setIV(iv, sizeof(iv));
gcm.addAuthData(adata, sizeof(adata));
gcm.encrypt(ciphertext, plaintext, sizeof(plaintext));
gcm.computeTag(tag, sizeof(tag));

For decryption:

GCM<AES256> gcm;
gcm.setKey(key, sizeof(key));
gcm.setIV(iv, sizeof(iv));
gcm.addAuthData(adata, sizeof(adata));
gcm.decrypt(ciphertext, plaintext, sizeof(plaintext));
if (!gcm.checkTag(tag, sizeof(tag))) {
    // The data was invalid - do not use it.
    ...
}

These are my questions:

1. Should the IV be unique for each 128 bit text or for each message? How should the next IV be generated? Should we increment the IV by one for each message or for each block of 128 bit?
2. Does adding the IV in authentication data makes it less secure?
3. Does sending the computed tag by prepending / appending to the ciphertext, create any vulnerability?
4. What is the standard way to share the IV & computed tag?

Answer 1

1.The IV should be unique for each 128 bit text or for each massage?

Per message. Using an IV of 0 for the first message, 1 for the second, etc is just fine (no matter how long each message is), and is actually fairly common.

2.Is adding the IV in auth data makes it less secure?

No, it doesn't. It also doesn't make it any more secure; however if it makes you feel better, feel free.

3.Is sending the computed tag by pepending/appending to the ciphertext, creates any vulnerability?

No, it doesn't create any problems; as long as the decryptor can unambigiously derive the computed tag, IV and raw ciphertext, any method of transport is fine. In fact:

4.What is the standard way to share the IV & computed Tag?

The most common way is the prepend the IV, and append the computed tag to the ciphertext, and send that as a unit; as above, we don't mind revealing the IV and the tag to an evesdropper; and we'll detect any modification to the IV and the computed tag by an active attacker (except for the possibility that he rolls back the entire message to a previously sent one; GCM can't detect that).

The most common variation I've seen to that is not to send the entire IV, but only a portion (64 bits), and have the other 32 bits shared between the sender and the receiver; this reduces the bandwidth used a tad, and we still can send $2^{64}$ messages per key, which is plenty. Of course, this is an implementation trade-off, with no security implications; you don't need to follow this example.

---

Also, unrelated to your question, but the Arduino API is not very well thought out. For one, in the decryption phase, the application is supposed to ask for a decryption, and then separately ask for the tag validation. That means that it's up to the application to maintain cryptographic safety; if the application forgets to ask for the validation, then everyone looks like it's working, but you're not actually secure. This is the sort of 'rake-in-the-grass' behavior that we like to stay away from; if they got this wrong, one can only wonder what other things the crypto library authors messed up on...