Why can't rar passwords be cracked?

1. rarfile generation process. When you encrypt a Winrar file, there are two steps: 1. First, compress the source file and compress it into a data segment. 2: encrypt the compressed data segment. For the same source file, the data segments in the rarfile are identical after encryption and compression are completed. However, for the same source file, even if the same password is used, the data segments in the rarfile are different after encryption. This is because the encryption key is dependent on a Salt (eight-byte key, used for encryption, stored in the rarfile header) So the key to decryption of rar encrypted files lies in data decryption. Next we will study how to encrypt the files. 2. encrypt the "compressed data segment" process 1. Obtain the key: Combine the plaintext password with the Salt and generate two 16-byte keys through the HASH algorithm. (One is the KEY (the AES algorithm parameter) and the other is the initVector) 2. encrypt and compress data with the Key and initVector: here, it is a circular encryption structure, encrypt each 16 bytes as a block (this may be the reason why the total length of the encrypted file is a factor of 16 ). Encryption adopts the AES algorithm (RAR adopts the standard application of AES rijndael ). Note: Before AES encryption, there is an exclusive or operation, which is to first convert each 16-byte block to the encryption result of the last 16-byte block, or then perform the AES algorithm. I use a simple schematic code to view the description :; ========================================================== ======= packblock [0] = packblock ^ initVectorencryptBlock [0] = AES (packblock [0]); (KEY is the KEY of AES) for I = 1 to block quantity-1 packblock = packblock ^ encryptBlock [I-1] encryptBlock = AES (packblock); (KEY is the KEY of AES) next www.2cto.com; packblock indicates 16 bytes of data compressed; encryptBlock indicates 16 bytes of data encrypted; ========================================================== ======== 3. decryption process because the AES algorithm is symmetric, therefore, the decryption process is the inverse operation of the encryption process. However, the AES algorithm process is different from that used for encryption during decryption (because the sub-KEY table generated by the KEY is different ). We still need to enter the password and generate two 16-byte keys, KEY and initVector together with salt .; ========================================================== ======= Packblock [0] = AES1 (encryptBlock [0]); (KEY is the KEY of AES) packblock [0] = packblock ^ initVector for I = 1 to the number of blocks-1 packblock = AES1 (encryptBlock); (KEY is the KEY of AES) packblock = packblock ^ encryptBlock [I-1] next; ========================================================== ======== where is the correct password? The decryption process is to decompress the decrypted data block, decompress it into the source file, and perform CRC verification on the file. If the source file CRC verification code in the rarfile is the same, the password is correct, if they are different, the password is incorrect. 4. The reason why rarfile cannot be broken is as follows: We understand the overall idea of rarfile. Everyone on Earth knows that during decryption, there must be a step to determine whether the password is correct or not. In addition, based on past experience, we may be able to move some judgment points, which can reduce the process logic of cracking. Where is this step of RAR? It puts verification in the last step. If it takes seconds to break the mud, how should we make the mud? At least I think it is impossible at present. Let's look back from the decryption process: 1. What is the modification jump of the CRC check? It is meaningless because it is the last step. You can modify the crc value of the rarfile header. You can change it to the same CRC value as the file extracted with any password, but your file is not the original file. It may be totally beyond the public view. Therefore, this process is not feasible. CRC verification is irreversible. 2. How can we advance the judgment to the compressed data? Is there any way to determine whether the compressed data is correct during decompression? Whether the compressed data has fixed features or whether it can be used as an decompression criterion. In this step, we cannot find valid and available fixed features. This step involves the RAR compression algorithm. Even if the first part of a source file is identical and only the subsequent part is modified, the data is the same after compression. Because the compressed data is first a compressed table followed by encoding. The files are different. The scanned compressed tables are different. The encoding depends on the compressed table. Therefore, the compressed data cannot be found in the header, and any fixed features can be used for determination. No matter what the compressed data is, Winrar will continue to decompress it without judging whether the compressed data is effective. 3. If we have cracked the AES mud? Because AES only depends on the KEY, if the AES algorithm is cracked, we know the KEY, and we can solve the compressed data, but there is a problem here, there is an initVector KEY, this parameter is used for the first 16-byte block. If you do not have the initVector parameter, the data of the first 16-byte block cannot be obtained. 4. So we can only start with the Hash algorithm in the first step. Even if you can crack the hash, what is the result of the hash? No result. How do you push back the password. In summary, it is found that rar encryption is mutually restrained by hash and AES algorithms, which cannot be cracked at present. At least there is no second to crack.