AES Modes and Unbreakability

Shoeb Ilyas - October 30, 2026 - 1419 Words

As we discussed in previously, AES is one of the most common encryption algorithms out there.

As a re-cap, on a very high level, AES works by dividing our data into 128-bit blocks. The blocks are then encrypted using the AES encryption algorithm that we discussed in great detail and then the blocks are combined together to form the final cipher text.

Today we will discuss about the different modes of AES encryption and their unique characteristics.

AES ECB - Electronic Code Book

This is the simplest mode of AES encryption that we discussed in our previous article. The upside of ECB is that we can run many different block encryptions in parallel before combining everything as a final ciphertext. This means that our ECB encryption is going to be extremely fast.

One drawback of ECB mode is that if two plaintext blocks have the exact same content, it will generate the exact same ciphertext. This entails that for any piece of data having a lot of repetitive pattern, a lot of repetitive ciphertexts will be present. An attacker might intercept and analyse these patterns to decode parts of our cipher text.

I will demonstrate this with an example. We have this image below with a lot of repetitive features.

The goal is to encrypt this image using AEC-128-ECB encryption and see if we can somehow still get some idea about the plaintext from the ciphertext. Following is the JavaScript code I have used for encrypting this image. Additionally, I was using BMP image format for encryption. So if you try to replicate this locally, make sure to run this downloaded image through a to-BMP converter.

  const crypto = require('crypto');
  const fs = require("fs");
  const { pipeline } = require("stream")
  
  // Encryption secret key
  const key = Buffer.from(crypto.randomBytes(16));
  
  const cipher = crypto.createCipheriv("aes-128-ecb", key, null);
  
  const plaintext = fs.createReadStream("./rep.bmp");
  const ciphertext = fs.createWriteStream("./ciphertext.enc");
  
  
  // Piping our plaintext through the cipher to generate ciphertext.
  pipeline(plaintext, cipher, ciphertext, (err) => {
    if (err) return console.log("Error encountered:", err);
    console.log("Encryption completed");
  })

The first 54 bytes in a BMP image file are the headers. Without this header our image viewer application will not be able to open this file.

We run the following command to get the first 54 bytes from our plaintext BMP image and store it in a temporary header file.

  head -c 54 plaintext.bmp > header

The first 54 bytes in the ciphertext also contain the header but this header is encrypted. Therefore, we copy the ciphertext with an offset of 55 bytes into a temporary body file.

  tail -c +55 ciphertext.enc > body

Finally, we combine our header and body in a final BMP image. This image is encrypted but with the headers now properly available, we will be able to view our image in an encrypted format in an image viewer.

  cat header body > ciphertext-img.bmp

The encrypted image looks like this:

As you can see, we can understand a lot of things and figure out a lot of patterns from this image even though it's encrypted.

Another disadvantage of ECB is that the encryption of each block is independent. If there is an error encrypting a block, we will never know.

Let's say you send an encrypted message to the me saying 'Hi. Please send me $10 ASAP'. Someone tampers with the encrypted message mid-flight and by some chance, now the message reads, 'Hi. Please send me $90 ASAP'. In most cases it will be some gibberish.

This brings us to the next mode of AES encryption known as CBC.

AES CBC - Cipher Block Chaining

CBC works by chaining the block encryption to produce unique ciphertexts.

Our plaintext is divided into 128-bit blocks. We have an initialization vector called IV. We XOR the first block with the IV to get an intermediate value. This intermediate value is then encrypted using the AES encryption to produce the ciphertext block, as already explained in our previous article. The ciphertext block produced acts as the IV for the next plaintext block. So the entire process is to XOR the plaintext with the previous ciphertext (or IV in case of the first block) and then encrypt it with AES.

Let's encrypt the above plaintext image with CBC and see what we get.

You can see that there's no pattern recognition in this ciphertext image because of the IV vector and chained encryption. In context of the IV, we need to ensure that this IV is random and fresh for every encryption and must never be used again. It's job is to make the ciphertext unique. Sharing it publicaly, given that we follow the proper guidelines, is safe since the CBC key is always private.

key = 2b7e1516 28aed2a6 abf71588 09cf4f3c

The main drawback of the CBC is that the blocks are encrypted sequentially and depend on the encryption of their previous block. This means that this mode of AES is slow and even with a powerful computer, it will take relative longer amount of time for encrypting huge data sets compared to other parallel modes of encryption like ECB or CTR.

Let's now have a look into the CTR mode of AES encryption that offers the speed of ECB and the benefits of CBC as well.

AES CTR - Counter Mode

CTR, short for, counter mode of AES encryption, offers the best of both worlds. We get the parallelism of ECB and the unique ciphertext generation of CBC.

In this method, we have a random 128 bit number, that call counter. For the first block, we use counter+0 as our IV to XOR with the AES key. Then the block is encrypted with the result. Then for the second block we use counter+1. For the third block, we use counter+2 and so on.

For decryption, we are going to do the exact XOR operations to generate the original plaintext message. It doesn't require any additional code logic to decrypt our ciphertext.

Breaking AES Encryption

Breaking AES encryption is theoretically possible given some unlimited amount of computing. However, this is not at all practically feasible and it's impossible to break. The only threat we have is quantum computing that we will be discussing in more detail.

Our goal is to calculate how much of an effort it will take to decipher an AES secret key to decrypt a ciphertext.

A secret key is 128-bit in size for AES-128. Since we do not know the secret key, we will need to try out as many combinations of 128-bit keys as possible until we find our secret key.

A 128-bit key has 2¹²⁸ combinations.

In AES-128, we use 10 rounds during encryption. Let's say each AES algorithm requires 1000 bit operations. This means for each AES-128 encryption, we will be performing 10,000 bit operations.

The number of bit operations we will need to perform is: 2¹²⁸ x 10⁴.

Let's assume, we are using the world's fastest super computer, China's LineShine. It can perform 2.198 × 10¹⁸ bit operations per second.

If we divide the number of operations by the performance of LineShine, we get 1.548 x 10²³ seconds to break AES. This is 4.91 x 10^16 in years. That's the number of years we need to break AES even with the faster computer humans has ever built.

Quantum Computers and AES

With a quantum computers, breaking AES is theoretically possible since they offer quadratic speedup for generic AES key search. So deciphering 1 128-bit key will take quadratic less amount of equivalent computation. Which means equivalent to 2⁶⁴. This is fairly easy to break in seconds. Or that's what you thought right? NO! For quantum computers, Grover's algorithm does give a quadratic speedup. so AES-128 drops to about 2^64 quantum evaluations. However, those are mostly sequential iterations of a full AES circuit and Grover doesn't parallelize well. Even at an impossibly generous one nanosecond per iteration, 2^64 should take about 580 years. Real error corrected quantum computer can be much slower.

When using 256-bit key encryption, we re-introduce the same classical complexity in quantum world as well and theoretically, breaking AES will take millions of years even with a quantum computer.

All this is theoretical since we do not have any practical benchmarks as we are still in the process of developing a quantum computer.

This is it for today's article. In the next article, we will discuss about hashing.

Thanks for reading!