AES
Advanced Encryption Standard
Last updated
Was this helpful?
Advanced Encryption Standard
Last updated
Was this helpful?
AES offers three different versions:
AES-128 takes a key of 128 bits (16 bytes)
AES-192 takes a key of 192 bits (24 bytes)
AES-256 takes a key of 256 bits (32 bytes)
The term bit security is commonly used to indicate the security of cryptographic algorithms. For example, AES-128 specifies that the best attack we know of would take around operations. This number is gigantic, and it is the security level that most applications aim for.
Looking at the interface of AES for encryption, we see the following:
The algorithm takes a variable-length key as discussed previously. For AES-128, this key length is 128 bits.
It also takes a plaintext of exactly 128 bits.
The block size is 128 bits.
It outputs a ciphertext of exactly 128 bits.
Because AES encrypts a fixed-size plaintext, we call it a block cipher. Some other ciphers can encrypt arbitrarily length plaintexts as you will see later in this chapter.
The decryption operation is exactly the reverse of this: it takes the same key, a ciphertext of 128 bits, and returns the original 128-bit plaintext. Effectively, decryption reverts the encryption. This is possible because the encryption and decryption operations are deterministic; they produce the same results no matter how many times you call them.
A permutation is also reversible. From a ciphertext, you have a map back to its corresponding plaintext (otherwise, decryption wouldn't work).
Let’s dig a bit deeper into the guts of AES to see what's inside. Note that AES sees the state of the plaintext during the encryption process as a 4-by-4 matrix of bytes:
This doesn't really matter in practice, but this is how AES is defined. AES also has a round function that it iterates several times, starting on the original input (the plaintext):
Each call to the round function transforms the state further, eventually producing the ciphertext. Each round uses a different round key, which is derived from the main symmetric key during KeyExpansion
.
The combination of the key schedule and the rounds ensure that the slightest change in the bits of the key or the message renders a completely different encryption.
SubBytes
Confusion through substitution (using S-Box)
ShiftRows
Diffusion through permutation part 1
MixColumns
Diffusion through permutation part 2
AddRoundKey
Encryption
The first three are easily reversible but the last one is not. It performs XOR(state, round key)
thus needs the knowledge of the round key to be reversed:
AES-CBC is bad. Since AES encryption is deterministic, and so encrypting the same block of plaintext twice leads to the same ciphertext. This means that by encrypting each block individually, the resulting ciphertext might have repeating patterns:
To encrypt with the CBC mode of operation, start by generating a random IV of 16 bytes, then XOR the generated IV with the first 16 bytes of plaintext before encrypting those. This effectively randomizes the encryption. Indeed, if the same plaintext is encrypted twice but with different IVs, the mode of operation renders two different ciphertexts. If there is more plaintext to encrypt, use the previous ciphertext (like we used the IV previously) to XOR it with the next block of plaintext before encrypting it. This randomizes the next block of encryption as well. Remember, the encryption of something is unpredictable and should be as good as the randomness we used to create our real IV:
AES encryption with PyCryptodome:
To decrypt with the CBC mode of operation, reverse the operations. As the IV is needed, it must be transmitted in clear text along with the ciphertext. Because the IV is supposed to be random, no information is leaked by observing the value:
AES decryption with PyCryptodome:
An IV needs to be unique (it cannot repeat) as well as unpredictable (it really needs to be random). When an IV repeats or is predictable, the encryption becomes deterministic again, and a number of clever attacks become possible. This was the case with the famous BEAST attack (Browser Exploit Against SSL/TLS) on the TLS protocol.
Indeed, there's no integrity mechanism to prevent that! Changes in the ciphertext or IV might have unexpected changes in the decryption. For example, in AES-CBC, an attacker can flip specific bits of plaintext by flipping bits in its IV and ciphertext:
To prevent modifications on the ciphertext, we can use MAC. For AES-CBC, we usually use HMAC in combination with the SHA-256 hash function to provide integrity. We then apply the MAC after padding the plaintext and encrypting it over both the ciphertext and the IV; otherwise, an attacker can still modify the IV without being caught.
Prior to decryption, the tag needs to be verified. The combination of all of these algorithms is referred to as AES-CBC-HMAC and was one of the most widely used authenticated encryption modes until we started to adopt more modern all-in-one constructions.
The associated data argument is optional and can be empty or it can also contain metadata that is relevant to the encryption and decryption of the plaintext. This data will not be encrypted and is either implied or transmitted along with the ciphertext. In addition, the ciphertext’s size is larger than the plaintext because it now contains an additional authentication tag (usually appended to the end of the ciphertext). To decrypt the ciphertext, we are required to use the same implied or transmitted associated data. The result is either an error, indicating that the ciphertext was modified in transit, or the original plaintext:
Of course, we do not have the room to list all the possible plaintexts and their associated ciphertexts. That would be mappings for a 128-bit block cipher. Instead, we design constructions like AES, which behave like permutations and are randomized by a key. We say that they are Pseudorandom Permutations (PRPs).