AES Encryption Modes: CBC, GCM, and More

AES encryption secures video content during packaging and delivery by transforming clear segments into encrypted blocks. Common modes like Cipher Block Chaining (CBC) and Galois/Counter Mode (GCM) differ in how they handle block processing and authentication. CBC operates and is applied in offline workflows due to its inability to support parallel processing or built-in integrity checks.

GCM supports parallelism and includes authentication for suitability for live and adaptive streaming scenarios. These modes influence encryption segment structure, key rotation strategies, and compatibility with player-side decryption. Mode selection affects CDN caching behavior and playback reliability across devices.

Understanding AES in Video Encryption

AES operates on 128-bit blocks and supports 128, 192, or 256-bit keys. However, video content exceeds this size, so a mode of operation applies AES to large data streams. Each mode addresses different requirements for confidentiality, integrity, and performance. For video, encryption is applied per segment or file chunk. Modes are selected based on the streaming format, use case, and need for authenticity.

AES Encryption Modes

AES-CBC (Cipher Block Chaining)

AES-CBC operates by chaining each block of plaintext with the previous ciphertext block using an XOR operation. Each data block is encrypted sequentially, where the first block is XORed with an initialization vector (IV) before encryption. The chaining process ensures that identical plaintext blocks encrypt to different ciphertext blocks, preventing pattern leakage.

Encyption Flow:

C0 = AES(K, P0 XOR IV)
C1 = AES(K, P1 XOR C0)
C2 = AES(K, P2 XOR C1)

AES-GCM (Galois/Counter Mode)

AES-GCM uses counter mode for encryption, where each block of plaintext is XORed with a keystream generated by encrypting a counter value concatenated with a nonce. This mode provides both encryption and authentication (integrity), making it suitable for environments where both confidentiality and data integrity are critical.

Encryption Flow:

CT[i] = PT[i] XOR AES(K, nonce || counter)

AES-CTR (Counter Mode)

AES-CTR also uses a counter mode, where each block of plaintext is XORed with an encrypted counter value. The key difference between AES-CTR and AES-GCM is that AES-CTR does not provide authentication (integrity), so it is used in environments where encryption alone suffices and integrity can be managed separately.

Encryption Flow:

CT[i] = PT[i] XOR AES(K, nonce || counter)

Authentication and Integrity

AES-CBC

AES-CBC does not provide any inherent message authentication. As a result, it requires additional mechanisms, such as HMAC (Hash-based Message Authentication Code) or another external method, to verify the integrity of the ciphertext.

Authentication: Not built into the mode.

Integrity: Must be handled separately (e.g., HMAC).

AES-GCM

AES-GCM is an authenticated encryption mode. It combines the encryption process with a Galois field multiplication mechanism to generate an authentication tag, which ensures both the confidentiality and integrity of the data. The tag allows the recipient to verify that the ciphertext has not been altered.

Authentication: Built into the mode.

Integrity: Authenticated with a Galois tag.

AES-CTR

AES-CTR does not provide authentication. While it encrypts the data using a counter mechanism, it does not guarantee that the ciphertext has not been tampered with. To ensure integrity, it must be paired with a separate authentication mechanism, such as a MAC or a separate encryption mode like GCM.

Authentication: Not built into the mode.

Integrity: Must be handled separately (e.g., HMAC).

Parallelization and Performance

AES-CBC

AES-CBC processes blocks sequentially, meaning that each block"s encryption depends on the previous one. This sequential processing makes AES-CBC less efficient for environments that require high throughput or parallel processing, such as real-time video encryption.

Parallelization: Not parallelizable.

Performance: Slower compared to other modes like AES-CTR.

AES-GCM

AES-GCM is highly parallelizable. The counter mode encryption of each block can be processed independently, which makes AES-GCM suitable for high-performance environments where speed is essential, such as live video streaming or file encryption.

Parallelization: Fully parallelizable.

Performance: High performance due to parallel processing capabilities.

AES-CTR

AES-CTR is also highly parallelizable. Similar to AES-GCM, the counter mode can be processed in parallel, making it suitable for real-time applications that require fast encryption and decryption, such as video streaming or secure communications.

Parallelization: Fully parallelizable.

Performance: High performance with lower overhead compared to AES-CBC.

Error Propagation and Handling

AES-CBC

AES-CBC has significant error propagation. If a ciphertext block is corrupted, it will affect not only the decryption of the corrupted block but also the next block due to the chaining mechanism. This can result in the loss of large portions of data, making it less resilient to transmission errors.

Error Propagation: High.

Recovery: Requires additional error-correction mechanisms.

AES-GCM

AES-GCM offers error detection and integrity verification using the authentication tag. If any part of the ciphertext or additional associated data is altered, the authentication check will fail, signaling an error. This provides a built-in method of error detection and prevents partial decryption from being used.

Error Propagation: Low.

Recovery: Built-in authentication to detect errors.

AES-CTR

AES-CTR has no inherent error propagation. If a ciphertext block is corrupted, only that block is affected, and subsequent blocks can still be decrypted. However, without an integrity mechanism, it is not possible to detect the corruption unless a separate mechanism like HMAC is used.

Error Propagation: Low.

Recovery: Requires a separate integrity check (e.g., HMAC).

Summary Table: AES Modes Comparison