Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Can somebody explain how this mode works? What view has cipher text and how does it help to authenticate input’s data?

share|improve this question

closed as too broad by hunter, Reid, e-sushi, Gilles, B-Con Oct 14 '13 at 18:23

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Is the wikipedia page dedicated to this topic not adequate? –  hunter Oct 13 '13 at 17:01
As this is encryption mode unclear what view will have the ciphertext. From this article it is clear just where to get auth tag. –  user100552 Oct 13 '13 at 18:35
I don't understand what you're asking... you understand the authentication part, but not the encryption? The encryption is based on counter mode (CTR). Directly from wikipedia: "As the name suggests, GCM mode combines the well-known counter mode of encryption with the new Galois mode of authentication". –  hunter Oct 13 '13 at 23:04

2 Answers 2

In addition to information on the wiki, add some explanations and definitions contained in RFC 4106 "The Use of Galois/Counter Mode (GCM)" (AES-GCM) can help them better understand the working of the mode.


authenticated encryption operation has four inputs: a secret key, an initialization vector (IV), a plaintext, and an input for additional authenticated data (AAD). It has two outputs, a ciphertext whose length is identical to the plaintext, and an authentication tag. In the following, we describe how the IV, plaintext, and AAD are formed from the ESP fields, and how the ESP packet is formed from the ciphertext and authentication tag.

ESP also defines an IV. For clarity, we refer to the AES-GCM IV as a nonce in the context of AES-GCM-ESP. The same nonce and key combination MUST NOT be used more than once.

Because reusing an nonce/key combination destroys the security guarantees of AES-GCM mode, it can be difficult to use this mode securely when using statically configured keys. For safety's sake, implementations MUST use an automated key management system, such as the Internet Key Exchange (IKE) [RFC2409], to ensure that this requirement is met.

ESP Payload Data

The ESP Payload Data is comprised of an eight-octet initialization vector (IV), followed by the ciphertext. The payload field, as defined in [RFC2406], along with the ICV associated with the payload.

Initialization Vector (IV)

The AES-GCM-ESP IV field MUST be eight octets. For a given key, the IV MUST NOT repeat. The most natural way to implement this is with a counter, but anything that guarantees uniqueness can be used, such as a linear feedback shift register (LFSR). Note that the encrypter can use any IV generation method that meets the uniqueness requirement, without coordinating with the decrypter.


The plaintext input to AES-GCM is formed by concatenating the plaintext data described by the Next Header field with the Padding, the Pad Length, and the Next Header field. The Ciphertext field consists of the ciphertext output from the AES-GCM algorithm. The length of the ciphertext is identical to that of the plaintext.

Implementations that do not seek to hide the length of the plaintext SHOULD use the minimum amount of padding required, which will be less than four octets.

Integrity Check Value (ICV)

The ICV consists solely of the AES-GCM Authentication Tag. Implementations MUST support a full-length 16-octet ICV, and MAY support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths. Although ESP does not require that an ICV be present, AES-GCM-ESP intentionally does not allow a zero-length ICV. This is because GCM provides no integrity protection whatsoever when used with a zero- length Authentication Tag.

Packet Expansion

The IV adds an additional eight octets to the packet, and the ICV adds an additional 8, 12, or 16 octets. These are the only sources of packet expansion, other than the 10-13 octets taken up by the ESP SPI, Sequence Number, Padding, Pad Length, and Next Header fields (if the minimal amount of padding is used).

For more information you can contact to another RFC for examle 5647 which describe AES Galois Counter Mode for the Secure Shell Transport Layer Protocol. (AES-GCM in the TLS)

share|improve this answer
While I appreciate the effort - copying and pasting large portions of an RFC is not really appropriate as an answer - and is not helpful to the community. But then again, neither is asking a question which could be answered by simply reading the RFC. –  hunter Oct 13 '13 at 23:17

The best explanation is in Dan Bernstein's Poly1305 paper, where he provides references to the original works on Carter-Wegman authentication. AES-GCM works by viewing the message as a polynomial and evaluating it at a random point. The sole way to forge is to blindly chose a polynomial which is zero at that point, but you have no information to do so, since the tags are encrypted.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.