# AES-encrypted 128-bit null block: lookup table?

Let's say a 1MB file has many many consecutive null-bytes 128-bit blocks. Then, as AES works with blocks, the encrypted file will also have recurrent 128-bit-long patterns of aes_encrypt(000...0) (where 000...0 is a 128-bit long null block).

How isn't this a weakness?

As null-bytes blocks is very frequent in files, we could easily recognize "oh this recurrent pattern in cipher is certainly the result of the encryption of 128 null bits".

Then a lookup table:

Key                          Cipher of null 128-bits
----------------------------------------------------
Hello                        a8ff00ac..ff6b


could help to find the key, isn't it possible?

Is the fact it "works in blocks" not a weakness?

• This would be a weakness if somebody uses the cipher in ECB (Electronic Code Book) mode of operation. However, it is well-known that cipher needs to be used in other block cipher modes of operation to be secure. Learn more about Block cipher modes of operation at https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation. Oct 27 '17 at 16:52
• @user4982 Thanks for the link, the weakness is obvious here. What is the standard AES mode of operation (I guess it's not ECB!) by default in most encryption tools?
– Basj
Oct 27 '17 at 17:09
• Previously, CBC was considered the default mode of operation. However, nowadays I would rarely recommend CBC, because it does not provide integrity or authenticity protection and because of padding issues. There are different modes of operation for different needs, so it is almost incorrect to consider any of modes of operation as a default, but rather than consider them as different tools for different needs. GCM is very common for data transfer. There are also uses for XTS, CCM, KW(P), etc. Oct 27 '17 at 18:20

In practice we use something called a block mode.

The traditional block mode is cipher block chaining (see image). In this block mode we XOR the ciphertext of the a block with the plaintext of the next block. The first plaintext block will be XOR'd with a public initialization vector. This way we make sure that every ciphertext is different.

How isn't this a weakness?

It is. In your case the block mode that is used is ECB, basically applying the block cipher to each block independently. ECB is considered insecure for normal use.

Could you make a lookup table for all blocks of only zeros?

No. Because almost always keys are generated randomly, we would need to store $2^{128}$ entries in our lookup table. Our universe will never have enough disk space to store it.

• Thanks for your answer, it totally answers my question. PS: about the lookup table, of course not a 2^128 entry-one. But I meant it the other direction (i.e. use a dictionary of common passwords, compute the AES encryption of 000...0 (128 bits), and store the result in a table. then when in a ciphertext we have a pattern that looks like a zero-bits aes encryption, we see if it matches common passwords/keys).
– Basj
Oct 27 '17 at 18:48
• "Common AES keys" is not really a thing. Almost always AES keys are generated randomly. Oct 27 '17 at 19:07
• Oh okay @DaanSprenkels, didn't know that. I used AES in 7z, and it was asking for a password, that's why I was assuming that the key can be generated from a password, for some use cases.
– Basj
Oct 27 '17 at 20:07
• @Basj These protocols use what's called a key derivation function such as PBKDF2 that derives the key from a password. Unfortunately no normal user would understand what it does. The mode of operation is usually not mentioned either. Users have serious grabbing even what AES means, or what 256 bit encryption brings for them. These issues are as important as the block cipher, but yeah, teaching users to be cryptographers is not an option either. Oct 27 '17 at 22:56