cause

A few days ago, I wrote a very simple encryption program in Python, using the AES-128-CTR encryption method provided by tinyyaes, and then I didn’t complete the iv because it was too troublesome. In the past few days, I have been searching for information about iv in AES, and I have never understood what that iv is used for.

After I read those 5 encryption modes about AES for a few days, a lot is said about the encryption modes of ECB and CBC, and it is very unclear about the other encryption modes… But the only thing that is clearly written is that ECB is very difficult Safe, reusing the same key and iv to encrypt data is very insecure, especially CTR mode, which completely loses confidentiality ?, this is not a complete negation of what I wrote a few days ago, but I haven’t written anything other than these Others… Then why did it lose its confidentiality, and I didn’t make it clear, so I had to think about it myself?.

explore

First of all, I looked at the differences between the five encryption modes in AES, and found that the difference between CTR mode and other modes is that it encrypts passwords, not data. It encrypts the password and iv through the AES encryption algorithm and then encrypts the The obtained thing is XORed with the plaintext data and then the ciphertext is obtained. No wonder it can be encrypted and decrypted using the same method. It turns out that it is really XOR encryption ?, is XOR encryption safe? I also searched on the Internet, and many people said that this is a very insecure encryption method. Only people who don’t understand and people who have just started cryptography can use it. Coincidentally, I’m just someone who doesn’t understand cryptography?, However, why is XOR encryption insecure and I don’t say it online… I’m really speechless.

If I don’t say it, I can only think for myself… First of all, they say that CTR insecure encryption is limited to encrypting different data with the same iv and password, and the encryption method is through XOR, so let’s calculate it like this:

K = AES(key, iv)

C1 = K xor P1

C2 = K xor P2

where K is the value obtained by encrypting the cipher and iv with AES, C stands for ciphertext, and P stands for plaintext. Then I thought about it, what would happen if I used C1 xor C2? Finally, I calculated it with the XOR operation law, and I probably understood why it is not safe, because:

C1 xor C2 = P1 xor P2

We know that in this case if you use P1 or P2 to XOR the value obtained by the above formula, then you can get another plaintext, that is:

(C1 xor C2) xor P1 = P2

This way you can crack all other ciphertexts as long as you know a set of ciphertexts and plaintexts encrypted with this key!

So based on this principle, I tried to write a program in Python to obtain the ciphertext based on the known plaintext ciphertext pair:

 import sys if not len ( sys . argv ) == 4 : exit ( f "Usage: { sys . argv [ 0 ] } [enc_file1] [enc_file2] [plain_file2]" ) with open ( sys . argv [ 1 ], "rb" ) as enc_file1 : with open ( sys . argv [ 2 ], "rb" ) as enc_file2 : with open ( sys . argv [ 3 ], "rb" ) as plain_file2 : with open ( sys . argv [ 1 ] + ".crack" , "wb" ) as crack_file1 : crack_file1 . write ( bytes ( a ^ b for ( a , b ) in zip ( bytes ( a ^ b for ( a , b ) in zip ( enc_file1 . read (), enc_file2 . read ())), plain_file2 . read ())))

After writing it, I found that it used the same number of lines as the encrypted program. After trying it, I can really get the corresponding plaintext of the other ciphertext! And in the case where you don’t need to know the password, but I don’t know whether there is a problem with the writing of my program or a problem with the calculation. When the length of the file to be cracked is longer than the file of the known plaintext ciphertext, the cracked plaintext will be It can only be cracked to a position as long as the known plaintext ciphertext… In short, it can be proved that the encryption written before has indeed “completely lost confidentiality”.

Solution

In order to make up for the problems encountered by the encryption program written in the previous article, this time I still use iv according to the official instructions. Based on this principle, I re-wrote my program:

 import hashlib , tinyaes , sys , os if not len ( sys . argv ) == 3 : exit ( f "Usage: { sys . argv [ 0 ] } [filepath] [key]" ) enc = False if len ( sys . argv [ 1 ]) > 4 : if sys . argv [ 1 ][ - 4 :] == ".enc" : enc = True with open ( sys . argv [ 1 ], 'rb' ) as orig : iv = os . urandom ( 16 ) key = tinyaes . AES ( hashlib . md5 ( sys . argv [ 2 ]. encode ()). digest (), orig . read ( 16 ) if enc else iv ) with open ( sys . argv [ 1 ][: - 4 ] if enc else sys . argv [ 1 ] + ".enc" , 'wb' ) as targetfile : if not enc : targetfile . write ( iv ) for byte_block in iter ( lambda : orig . read ( 4096 ), b '' ): targetfile . write ( key . CTR_xcrypt_buffer ( byte_block ))

This time I saved the randomly generated iv to the beginning of the file, but that’s exactly what I was doing, I couldn’t use the exact same method to encrypt and decrypt… So I used the .enc suffix as the distinction between plaintext and ciphertext . Also the number of lines of the program has almost doubled?.

impression

It seems that for subjects that are not well understood, it is better to follow the instructions written in the instructions, otherwise, if you do not understand, you will not achieve the expected ideas.

This article is reprinted from: https://mabbs.github.io/2022/10/14/crack-aes.html
This site is for inclusion only, and the copyright belongs to the original author.