AES-GCM Overview

When using AES-GCM encryption, both the encrypted data (ciphertext) and the authentication tag (auth tag or MAC) must be sent to the recipient for decryption and integrity verification.

What Gets Sent

During encryption, the following values are generated:

• IV (Initialization Vector, often 12 bytes)
• Ciphertext (the encrypted data)
• Auth Tag (typically 16 bytes)

These must all be delivered to the decrypting party.

Typical Formats for Transmission

Concatenation Format (most common)

[IV || Ciphertext || AuthTag]

• All three are concatenated into a single byte array.
• The recipient splits them based on known lengths (e.g., IV = 12 bytes, AuthTag = 16 bytes, rest is Ciphertext).

Explicit Structure (e.g., JSON or protocol-defined):

{
    "iv": "base64-encoded-IV",
    "ciphertext": "base64-encoded-ciphertext",
    "tag": "base64-encoded-tag"
}

• Used in protocols or REST APIs where explicit fields are preferred.
• Easier to debug and parse, especially in cross-language systems.

Embedded or Appended Tag:

The tag is appended to the ciphertext, and the IV is sent separately, or agreed upon beforehand.

[Ciphertext || AuthTag]

On Decryption

The receiver must:

1. Extract the IV, Ciphertext, and Auth Tag.
2. Initialize the GCM cipher with the IV.
3. Set the expected Auth Tag.
4. Attempt decryption—succeeds only if the tag matches.

   ---

AES-GCM Examples using Chilkat

Summary

• Encrypted data and tag must both be transmitted.
• Common practice: append the tag to the ciphertext, often with the IV at the beginning.
• Structured formats (e.g., JSON) are also used when clarity and interoperability are important.