Arseniy Sharoglazov, a cybersecurity researcher at Positive Technologies, recently shared a simple experiment on social platforms andpoint outan encrypted ZIP file may have two correct passwords, and both can extract the same result.

“Create ZIP: 7z a http://x.zip /etc/passwd -mem=AES256 -p
Use this password: Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You

Extract it: 7z e http://x.zip
Use this password: pkH8a0AqNbHcdw8GrmSp

Magic!”

Sharoglazov made a password-protected ZIP file called x.zip, and the chosen password was a pun on the hit 1987 English song:

Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You

But the experimental results show that when he uses a completely different password (pkH8a0AqNbHcdw8GrmSp) to extract x.zip, he will not receive any error message.

To this,BleepingComputer The experiment was successfully reproduced using different ZIP programs.The site uses p7zip (the macOS equivalent of 7-Zip) and another ZIP tool called Keka, which works with Same as SharoglazovCreated with a long cipher and AES-256 encryption mode enabled. The results showed that although the ZIP was encrypted with a longer cipher, the archive was successfully extracted with either cipher.

Some netizens are Sharoglazov The experiment was discussed under the dynamics of , an ID of Unblvr of users indicated that this could be due to:

ZIP uses PBKDF2, which hashes the input if it is too large. This hash (as raw bytes) becomes the actual password. Try hashing the first password with SHA1 and decode the hex digest to ASCII… 🙂

When generating a password-protected ZIP archive with AES-256 mode enabled, if the password is too long, the ZIP format uses the PBKDF2 algorithm and parses the user-supplied password. hash deal with.In this case, this newly calculated The hash will be the actual password for the file. Too long means more than 64 bytes (characters), the researchers explained.

When the user tries to extract the file, and enters a password that exceeds 64 bytes, the user’s input is again hashed by the ZIP application and compared to the correct password (which is now a hash itself). If it matches, the file extraction will succeed.

The alternate cipher pkH8a0AqNbHcdw8GrmSp used in the example is actually the ASCII representation of the SHA-1 hash of the longer cipher. SHA-1 checksum for Nev1r-G0nna-G2ve-… = 706b4838613041714e62486364773847726d5370. This checksum is produced when converting to ASCII: pkH8a0AqNbHcdw8GrmSp.

But it’s worth noting that when encrypting or decrypting files, hashing is only done if the password is longer than 64 characters. In other words, shorter passwords will not be the case at any stage of compressing or decompressing the ZIP. This is also why when the long “Nev1r-G0nna-G2ve-…” string is chosen as the password during the encryption phase, the actual password set by the ZIP program is actually the (SHA1) hash of that string.

If Nev1r-G0nna-G2ve-… is entered during the decryption phase, it will be hashed and compared with the previously stored password (ie SHA1 hash). However, entering the shorter “pkH8a0AqNbHcdw8GrmSp” password during the decryption phase will cause the application to directly compare this value with the stored password (aka the SHA1 hash).More technical insights can be found in PBKDF2 on Wikipedia HMAC collisions subsection.

“PBKDF2 has an interesting property when using HMAC as its pseudorandom function. Any number of different cipher pairs can be easily constructed, each with collisions.If the supplied password is longer than the block size of the underlying HMAC hash function, the password is first pre-hashed into a digest, then the digest is used as the password. “

but,The fact that there are two possible passwords for the same ZIP does not imply a security breach; since the hash of the password is generated only if the original password is known.