Problem G
A La Mode
You now have constructed a block cipher that can encrypt and decrypt a single block of data. Using that code as a building block, you will implement different modes of encryption to handle larger amounts of data.
Padding
Since block ciphers work on fixed-length blocks of data, sometimes the data we encrypt must be a multiple of that length. To do this, we pad out our data so that we can evenly break it up into a whole number of blocks. There are several standard methods to do this. According to the malware report, you discover that the malware developers used PKCS7 padding. This common padding scheme works by taking the number of bytes needed and repeatedly adding that number (as a byte) to the end of the data until the length is a whole number of blocks. Upon decryption, this padding can be easily removed as the final decrypted byte reveals how many padding bytes were used. Using this method usually requires that data always be padded, so even data that is already a whole number of blocks will have a full block of padding added on to it. These examples illustrate PKSC7 padding for an 8 byte wide block cipher like the one you created:
DATA |
PADDED DATA |
0xAF12376C |
0xAF12376C04040404 |
0xDEAD |
0xDEAD060606060606 |
0x87F433A67892BF |
0x87F433A67892BF01 |
0x4852C72399AE0601 |
0x4852C72399AE06010808080808080808 |
Modes of encryption
Reverse engineers were able to determine that based on the version number, malware developers experimented with three different modes of encryption. An encryption mode describes how to repeatedly apply a block cipher’s single-block operation to encrypt or decrypt amounts of data larger than one block.
ECB - Electronic Codebook
Electronic Codebook (ECB) mode is the simplest mode. Once you have correctly padded the data, break it into blocks, encrypt each block independently, concatenating the encrypted blocks to produce the encrypted output. To decrypt, simply decrypt each block individually, concatenating the plaintext together, and then removing the padding. See diagram below for illustration of these steps.
The following representation summarizes the steps for encryption and decryption in equation form:
\[ C_0 = E_ k(P_0), C_1 = E_ k(P_1), \ldots , C_ i = E_ k(P_ i) \]\[ P_0 = D_ k(C_0), P_1 = D_ k(C_1), \ldots , P_ i = D_ k(C_ i) \]where $C_ i$ are $P_ i$ are the $i$-th cipher and plaintext blocks and $E_ k()$, $D_ k()$ are the encryption and decryption routines for the block cipher created in the previous problem with the key $k$.
CTR - Counter
Counter (CTR) mode differs from ECB mode in that the data is not actually input into the block cipher. Instead, encrypt a varying value and use the output from this process as key which is XORed onto the plaintext blocks, essentially creating a stream cipher. Because of this padding is not actually a necessity in CTR mode as the last unused bytes can be discarded, but the ransomware developers have padded the data in this mode also. Counter mode utilizes counter and nonce values, these are typically combined in different ways to create variance in the output, as they are the input to the block cipher. In the ransomware, the nonce is XORed with a $64$-bit counter that is initialized to ${\tt 0}$. The counter is incremented with each block. This generates a key that we XOR with the plaintext to produce our ciphertext. To decrypt, repeat this process but XOR the output key with ciphertext to produce padded plaintext. See diagram below for illustration of these steps.
The following representation summarizes the steps for encryption and decryption in equation form:
\[ C_0 = E_ k(N \oplus cnt_0) \oplus P_0, C_1 = E_ k(N \oplus cnt_1) \oplus P_1, \ldots , C_ i = E_ k(N \oplus cnt_ i) \oplus P_ i \]\[ P_0 = E_ k(N \oplus cnt_0) \oplus C_0, P_1 = E_ k(N \oplus cnt_1) \oplus C_1, \ldots , P_ i = E_ k(N \oplus cnt_ i) \oplus C_ i \]where $N$ is the $64$-bit nonce and $cnt_ i$ is the $64$-bit representation of the integer $i$. Notice $E_ k()$ is used for both encryption and decryption.
CBC - Cipher Block Chaining
Cipher Block Chaining (CBC) mode chains the cipher blocks together. It is implemented by XORing every plaintext block with the previous cipher block prior to encryption. For this reason, we need a block of data at the beginning to bootstrap the process. This block is called the initialization vector (IV) and is usually provided with the encrypted content as it is needed for decryption. For decryption, the process is similar except that you need to XOR after the decryption process instead of before. See below for illustration.
The following representation summarizes the steps for encryption and decryption in equation form:
\[ C_0 = E_ k(P_0 \oplus IV), C_1 = E_ k(P_1 \oplus C_0), \ldots , C_ i = E_ k(P_ i \oplus C_{i-1}) \]\[ P_0 = D_ k(C_0) \oplus IV, P_1 = D_ k(C_1) \oplus C_0, \ldots , P_ i = D_ k(C_ i) \oplus C_{i-1}) \]where $IV$ is the $64$-bit initialization vector.
Input
The input consists of several lines. Similar to the previous block cipher problem, the first line is ENCRYPT or DECRYPT, but is now followed by a space and the mode (ECB,CTR,CBC) to employ. The second line is the HEX representation of the KEY. The third line contains the HEX encoded IV (for CBC mode) or NONCE (for CTR mode). This line will not exist for ECB mode. The last line will be data in HEX which you will encrypt or decrypt.
Output
The HEX representation of the output of either ENCRYPTing or DECRYPTing the data using the KEY and IV or NONCE, if applicable.
Sample Input 1 | Sample Output 1 |
---|---|
ENCRYPT ECB 30313233343536373839616263646566 4578616d706c65204461746120746f20656e637279707420696e206d756c7469706c65206d6f6465732e |
5e4c15bbac51b1835d05f459be1513d52d2188cc5e665b7c336765f8f9a6fe4bd1cc42abb0eb0142b387c8c7767e77f8 |
Sample Input 2 | Sample Output 2 |
---|---|
ENCRYPT CTR 00000000000000000000000000000000 0102030405060708 fffefdfcfffefdfcfffefdfcfffefdfcfffefdfcfffefdfc |
1dc86e20468047d09a08fa4c8b84c9e7a7f06b994a865ff46267b8f60fc2233c |
Sample Input 3 | Sample Output 3 |
---|---|
ENCRYPT CBC 21402324255e262a28295f2b71776572 3132333435363738 4c6f72656d20697073756d20646f6c6f722073697420616d65742c20636f6e73656374657475722061646970697363696e6720656c69742c2073656420646f20656975736d6f642074656d706f7220696e6369646964756e74207574206c61626f726520657420646f6c6f7265206d61676e6120616c697175612e |
191eea62b329c7080e6bb6b69ead38da144bf771d45eadf494ee1cbe99a75bb0688ee50e17a64908ac6f7f16c3735336a71b628056150c1bdf4b9134bcf1138abdf328cdc8be32bd8270df9022e86a53f6d71e7957d4743a95b10234284d0707a2bda561e4804fa32ab97599601074e48a2a85e0c203a91c57e0149776aa3538 |
Sample Input 4 | Sample Output 4 |
---|---|
DECRYPT ECB 00000000000000000000000000000000 d151ee7fa3f9401631953dd6c9ddcb255312ade36e06d9c7ca427cec24678ac6ef2515eeff594a5bc364ff9a268d2710 |
4578616d706c65204461746120746f20656e637279707420696e206d756c7469706c65206d6f6465732e |
Sample Input 5 | Sample Output 5 |
---|---|
DECRYPT CTR 21402324255e262a28295f2b71776572 3132333435363738 c3ef3034cd6ab02542a8075a9195b1cc19378aeb7316a6a16f0cfa52e5011ea1 |
fffefdfcfffefdfcfffefdfcfffefdfcfffefdfcfffefdfc |
Sample Input 6 | Sample Output 6 |
---|---|
DECRYPT CBC 30313233343536373839616263646566 0102030405060708 81040f72b5c901ac7de56de127e40fab78b8a564a3c4c6c268c57e3cc49007bf94643809327bb12787f6c0939accd294c99d761285bb3106fa27c85f17a81da9078a7c64dbad082828b5a2353e83cd20169253e8226655e5388667010c62fbd0f5ab7447caa1b8eb3818621811b671be6351abbb04540f480b104f9bc144da52 |
4c6f72656d20697073756d20646f6c6f722073697420616d65742c20636f6e73656374657475722061646970697363696e6720656c69742c2073656420646f20656975736d6f642074656d706f7220696e6369646964756e74207574206c61626f726520657420646f6c6f7265206d61676e6120616c697175612e |