PrivKE and Block Ciphers


CSE 539 - Spring 2025.

The module is about private-key encryption and block ciphers.


Challenges

In this warm-up challenge, you are required to implement an AES encryption to encrypt one block of message. You will find a file called enc_info.txt in the /challenge directory. It contains a 128-bit plaintext (first row) and a 128-bit AES encryption key (second row). You need to compute the ciphertext block and check its correctness using /challenge/solve. Please be careful about the Endianness since it varies in different implementations.

In this challenge, you are required to implement an AES encryption in the cipher block chaining (CBC) mode to encrypt a message. You will find a file called enc_info.txt in the /challenge directory. It contains a plaintext message, an initial value, and a 128-bit AES encryption key. You need to compute the ciphertext and check its correctness using /challenge/solve. Please be careful about the Endianness since it varies in different implementations.

In this challenge, you are required to implement an AES encryption in the randomized counter (CTR) mode to encrypt a message. You will find a file called enc_info.txt in the /challenge directory. It contains a plaintext message, an initial value, and a 128-bit AES encryption key. You need to compute the ciphertext and check its correctness using /challenge/solve. Please be careful about the Endianness since it varies in different implementations.

Block ciphers such as AES are iterative functions. While the function that is executed in each iteration does not qualify for a strong PRF, the accumulative effect of repeatedly running this function does. For instance, AES-128 iterates the same function for 10 times, with a minor difference in the last round.

In this challenge, you are required to implement a two-round AES that skips all intermediate iterations. It takes a message and key, and only execute the first round (using the first two round-keys) and the last round (using the last round-key). You will find a file called aes_two_round_output.txt in the /challenge directory, which contains a 16-byte ciphertext. You need to find out the plaintext that encrypts to this ciphertext.

Two make the challenge feasible, they AES private key only contains low entropy -- only the first two bytes of the key are non-zero. In this case, you can brute force all possible secret keys in order to find the plaintext. Another hint is that the plaintext is constructed following the PKCS#7 padding. After you get the plaintext, check its correctness using /challenge/solve. Please be careful about the Endianness since it varies in different implementations. The result is a hex value with uppercase letters.

AES requires a key scheduling procedure that expands the secret key to round keys. The key scheduling function does not imply onewayness, which means that given a round key, you can reverse it to the secret key.

Denote AES round keys as r[0], r[1], ..., r[10]. In this challenge, you will be given r[1] and need to reverse it to r[0], which is the AES secret key. You will find a file called aes_key_schedule_roundkey_one.txt in the /challenge directory, which contains r[1]. After you get the key, check its correctness using /challenge/solve. Please be careful about the Endianness since it varies in different implementations. The result is a hex value with uppercase letters.

In the previous challenge, you are required to reverse the AES key scheduling for one round. Now you need to apply it to steal the secret key in the context of the timing attack against pre-computed table-based implementation of AES algorithm.

This algorithm has been described in the lecture. The essential part is that an attacker can guess the last AES round key (r[10]) if (1) the attack can make arbitrary queries to an AES encryption oracle, (2) the implementation of the AES encryption is based on the precomputed tables. By measuring the approximate memory access time during the last round of AES encryption, the attacker can guess the difference between each nearby byte of r[10]. In this way, the attacker only needs to brute force the first or the last byte of r[10] in order to compute all possible r[10], which ultimately leads to the secret key r[0].

In this challenge, you are not required to measure the running time. Instead, an attacker has done that part for you. You will find a file called aes_key_schedule_roundkey_ten_relative_diff.txt in the /challenge directory, which contains the difference of all nearby bytes, namely, $r[10][1] - r[10][0], ..., r[10][15] - r[10][14]$. You will leverage this fact to guess r[10], then reverse it to r[0] using the algorithm you implemented in the previous challenge. To make it easier to distinguish the answer, only the first 8-byte of the secret key is non-zero. After you get the key, check its correctness using /challenge/solve. Please be careful about the Endianness since it varies in different implementations. The result is a hex value with uppercase letters.

The Browser Exploit Against SSL/TLS (BEAST) attack leverages the weak IV in the AES-CBC encryption to obtain the value of an encrypted block. In this challenge, we will emulate the procedures of this attack.

We assume an AES-CBC oracle uses a weak IV generation scheme so that all IVs are predictable. Denote a plaintext block as m, the result of encrypting one block in AES-CBC mode as (iv1, c), and the next (fixed) IV as iv2. You will find some of these values in /challenge/transcript.txt. You need to use these information to construct a series of plaintext queries which will result in a ciphertext that is identical to the previous ciphertext c.

To make the attack easier, you somehow know that the plaintext block starts with cse_539_2025, and consists of only English letters.

To interact with the oracle, you need to generate a file query.txt that contains all of your queries. Each line of your file consists of

your_guess_of_original_message_m your_query_plaintext_that_is_encrypted_with_iv2

The first element consists only English letters, and the second element is hexadecimal. You can check whether your query results in a successful attack by ./solve YOUR_PATH_TO_query.txt.

The padding oracle attack leverages the weak IV in the AES-CBC encryption to obtain the value of an encrypted block. In this challenge, we will emulate the procedures of this attack.

We assume an AES-CBC oracle decrypts whatever ciphertext it receives and checks the correctness of the padding according to the PKCS#7 standard. Denote a plaintext block as m and its ciphertext as c. You will find c in /challenge/ciphertext.txt. You need to use these information to construct a series of CBC ciphertext decryption queries which only tells you whether the padding is correct.

To interact with the oracle, you need to generate a file query.txt that contains all of your queries. Each line of your file consists of

your_iv ciphertext

You can check whether any of these queries result in a correct padding by ./query_oracle PATH_TO_QUERY_TXT. It will return the index of the query with correct padding.

Check the correctness of the plaintext using /challenge/solve.


30-Day Scoreboard:

This scoreboard reflects solves for challenges in this module after the module launched in this dojo.

Rank Hacker Badges Score