## aes iv value_AES encryption: difference between GCM and CBC mode

** AES encryption: the difference between GCM and CBC modes**

Difference between GCM and CBC

**Introduction **

In the build scan results of the project code, Sonarsource Rule recommends using AES-GCM instead of AES-CBC. What is the difference between the two? Can it be replaced as suggested? Taking this opportunity, I learned the basic concepts of the commonly used AES algorithm, as well as the CBC mode and GCM mode, and used JMH to do the benchmark ~

**background**

**One, the main difference**

AES-GCM can encrypt and decrypt in parallel, and the mode of AES-CBC determines that it can only encrypt serially. Because encryption is a time-consuming step, and the encryption method is the same, when the AES-GCM algorithm is implemented in parallel, its efficiency is higher than that of AES-CBC;

AES-GCM provides the GMAC message check code to verify the integrity of the ciphertext. AES-CBC does not, and cannot effectively check the integrity of the ciphertext;

AES-GCM is a stream encryption mode that does not require padding of plaintext. AES-CBC is a block encryption mode that requires padding of the plaintext. (The AES encryption in AES-GCM is the counter, and the AES encryption in AES-CBC is the plaintext block);

Since padding must be used in AES-CBC, the last plaintext block is different from other ciphertext blocks, so it may be subject to padding Oracle attacks, so that the plaintext can be obtained directly through the initial vector IV and password.

**2. Introduction of ASE**

AES is a symmetric encryption algorithm. In practice, the AES key is generally encrypted by RSA for key transmission. The following will briefly introduce some concepts and main steps of AES encryption.

**block cipher**

AES is a block cipher, that is, the plaintext is divided into groups of equal lengths. In the standard specification of AES, the length of the packet is 128 bits. The length of the key can be 128 bits, 192 bits or 256 bits. The length of the key is different, and the recommended number of encryption rounds is also different:

**encryption mode**

Because AES is block encryption, block encryption can only encrypt fixed-length blocks, and the actual plaintext to be encrypted may exceed the block length. At this time, an encryption mode is required to complete the encryption of the entire plaintext. Common encryption modes are as follows:

**initial vector**

The role of the initial vector IV is similar to that of MD5's salting. The purpose is to prevent the same plaintext block from being always encrypted into the same ciphertext block. Take CBC mode as an example as follows:

CBC mode XORs the plaintext block with a value before each plaintext block is encrypted. IV acts as an initialization vector and participates in the XOR of the first plaintext block. Each subsequent plaintext block is XORed with the ciphertext block encrypted by the previous plaintext block, thus ensuring that the encrypted ciphertext blocks are different

**filling method**

Since AES encryption can only process fixed-length input data, and the data length is usually variable, it is necessary to pad the last data block. Data is padded before encryption. Padding modes are PKCS5, PKCS7, NOPADDING.

**AES overall process**

The whole process of AES encryption is carried out on a 4*4 byte matrix State. This byte matrix is processed by the current plaintext block. Similarly, the encryption key also needs to do the same transformation to get the matrix of the extended key.

The AES algorithm mainly has four operation processing: 1-key addition AddRoundKey, 2-byte replacement SubByte, 3-row shift layer ShiftRows, 4-column confusion layer MixColumn. When decrypting, perform the corresponding inverse operation according to the process. The four operations of the AES algorithm are all performed on the GF (Galois Field) domain.

**AddRoundKey**

That is, the current matrix State and the extended key are bitwise XORed.

**SubBytes**

Byte transformation is to replace each byte in the matrix State with its corresponding value in the transformation array S_box and replace it with a new byte. There is a corresponding inverse S_box when decrypting.

The S-box and the inverse S-box implement the following processes:

**ShiftRows**

**MixColumn**

The column obfuscation operation is the main diffusion element in AES, it obfuscates each column of the input matrix so that every byte of input affects 4 bytes of output.

**key expansion**

A G function is mainly used in the key expansion, which can enhance the nonlinearity in the key arrangement and eliminate the symmetry in AES, so as to better resist some block cipher attacks.

**Three, CBC mode**

**Introduction to CBC Mode**

The picture above shows the CBC mode. The block cipher encryption in AES-CBC uses AES encryption. CBC uses an initial vector IV that is XORed with the plaintext block to add salt. Each subsequent plaintext block is XORed with the previously generated ciphertext block, so as to prevent the same plaintext block from encrypting the same content.

When decrypting the current ciphertext block, it is necessary to first perform AES decryption on the current ciphertext block to obtain A, because the previous ciphertext block B is known, and only A XOR B is needed at this time, the current ciphertext block can be obtained. plaintext C.

As can be seen from the above figure, CBC mode can only perform serial encryption, because the encryption of each plaintext block depends on the encryption result of the previous plaintext block. The decryption process can be performed in parallel.

At the same time, because the cipher block is used as the salt, if there is a block encryption error, it will cause the phenomenon of error propagation.

Padding is required in CBC, which makes the last plaintext block different from the other plaintext blocks. Create an opportunity for attack. Therefore, CBC mode may be subject to padding oracle attacks.

**Fourth, GCM mode**

GCM (GMAC Counter Mode), which uses the Counter mode and has a GMAC message authentication code.

**CTR mode**

Because GCM is based on CTR (Counter Mode), the following describes CTR Mode.

As can be seen from the above figure, in the CTR mode, the plaintext is no longer encrypted, but a counter that is accumulated successively is encrypted, and the encrypted bit sequence is XORed with the plaintext packet to obtain the ciphertext of each plaintext block. . The initial value of the counter is based on a nonce.

Because the counter is incremented, the bit sequences obtained by encryption are different, and then XOR with the plaintext can prevent the same plaintext block from being encrypted into the same ciphertext block.

Because the encryption of each plaintext block is independent and does not depend on other plaintext blocks, the AES encryption in CTR mode can encrypt the plaintext blocks in parallel without error propagation.

The following is the CTR decryption mode:

Decryption of CTR is also relatively straightforward. Encrypt the counter directly to get the bit sequence, and then XOR with the corresponding ciphertext block to get the corresponding plaintext block.

Because AES encryption in CTR mode is encrypted for the counter, padding is not required in CTR mode.

**MAC and GMAC**

Neither CBC nor CTR modes can verify message integrity. The integrity of the message cannot be guaranteed by ordinary hash, because when the tamperer intercepts the original ciphertext message, he first tampers with the ciphertext, and then calculates the hash of the tampered ciphertext to replace the original hash. At this time, the receiver of the message still has no way to detect the tampering of the source ciphertext. Therefore, relying on the one-way hash function to calculate the hash value still cannot solve the problem of message integrity verification.

**MAC**

MAC (Message Authentication Code, message verification code), MAC is a one-way hash function related to the key, which solves the problem of ordinary hash. The sender and receiver of the ciphertext need to share a key in advance. The sender of the ciphertext sends the MAC value of the ciphertext along with the ciphertext. The received ciphertext can be checked for integrity by comparing the MAC value of the received ciphertext. Because the tamperer does not have a shared key, the probability of being tampered with is reduced.

In the case that Mode requires an initial vector, or nonce, or counter, etc., it needs to be used as an additional message to calculate the MAC value.

**GMAC**

GMAC (Galois MAC) uses the multiplication operation of the GF (Galois) field to calculate the MAC value of the message

**GCM**

The following is the GCM mode. Among them, Ek is the encryption algorithm, which is the AES encryption algorithm in AES-GCM. Mh is to multiply the input and the key h on the finite field GF.

GCM is a combination of CTR counter mode and GMAC verification code. In this way, the encryption process can be performed in parallel, and the integrity of the information can be checked.

At the same time, because the counter mode is a stream encryption mode, not a block encryption mode. Therefore, the plaintext in GCM does not need padding.

**practice**

JMH, Java Microbenchmark Harness, is a suite of testing APIs dedicated to microbenchmarking code. In the AES-GCM and AES-CBC benchmarks, JMH is used for performance testing.

**Demo**

Encryption generally exists as a tool class. Therefore, in the encrypt and decrypt methods, a Cipher instance is created. The part of creating a Cipher instance is extracted from the code, and the time when the Cipher instance is created in the two modes is compared at the same time. When actually writing tool code, it should be optimized. **AES: AES encryption and decryption tool class, providing CBC mode and GCM mode**

**MyTest: Use JMH for benchmarking**

**Benchmark**

**Test Result 1**

Test data: a string of length 32.

Test method: The duration of one iteration is 5s, each function to be tested is warmed up for three rounds, and the average time-consuming of each operation is calculated for 15 iterations.

**Test Result 2**

Test data: 1109-word Chinese article.

Test method: same as above.

**Test Result 3**

Since the separate CBC does not include GMAC, and GCM includes the calculation of GMAC, it is a reasonable way to compare CBC+GMAC and GCM. Test 1 and Test 2 do not add GMAC to CBC. In addition, the specific implementation of the algorithm also affects its performance. Below are benchmark data for other references.

OpenSSL 2017/04

AES CBC+HMAC and GCM performance benchmarks for Java JCE, Bouncy Castle, Commons Crypto and Clojure Buddy.

**Summarize**

It can be seen from Test1 and Test2 that there is little difference in performance between CBC and GCM in general application encryption and decryption scenarios. From other benchmark data, the overall effect of GCM is better than CBC.

In terms of algorithm and mode design, GCM can be encrypted in parallel and has verification bits, and CBC may be attacked because of padding. So GCM is more secure.

So it makes sense that Sonarsource recommends AES-GCM to replace AES-CBC.

**long**

**according to**

**close**

**Note**

**TDTP phonograph**

Leave the voice of our struggle

Three people must have my teacher......