RM0440 Rev 4 1509/2126
RM0440 AES hardware accelerator (AES)
1538
Figure 519. Message construction in GCM
The message has the following structure:
• 16-byte initial counter block (ICB), composed of two distinct fields:
– Initialization vector (IV): a 96-bit value that must be unique for each encryption
cycle with a given key. Note that the GCM standard supports IVs with less than 96
bits, but in this case strict rules apply.
– Counter: a 32-bit big-endian integer that is incremented each time a block
processing is completed. According to NIST specification, the counter value is 0x2
when processing the first block of payload.
• Authenticated header AAD (also knows as additional authentication data) has a
known length Len(A) that may be a non-multiple of 16 bytes, and must not exceed
2
64
– 1 bits. This part of the message is only authenticated, not encrypted.
• Plaintext message P is both authenticated and encrypted as ciphertext C, with a
known length Len(P) that may be non-multiple of 16 bytes, and cannot exceed 2
32
-2
128-bit blocks.
• Last block contains the AAD header length (bits [32:63]) and the payload length (bits
[96:127]) information, as shown in Table 320.
The GCM standard specifies that ciphertext C has the same bit length as the plaintext P.
When a part of the message (AAD or P) has a length that is a non-multiple of 16-bytes a
special padding scheme is required.
MSv42157V1
Plaintext (P)
16-byte
boundaries
Additional authenticated data
(AAD)
Authenticated & encrypted ciphertext (C)
0
Len(A) Len(P) = Len(C)
0
[Len(A)]
64
Last
block
[Len(C)]
64
Authentication tag (T)
ICB
4-byte boundaries
CounterInitialization vector (IV)
authenticate
0
encrypt
Zero padding / zeroed bits
authenticate
auth.
Table 320. GCM last block definition
Endianness Bit[0] ---------- Bit[31] Bit[32]---------- Bit[63] Bit[64] -------- Bit[95] Bit[96] --------- Bit[127]
Input data 0x0 AAD length[31:0] 0x0 Payload length[31:0]