I have set myself a little challenge, to see if I can decrypt my own text file from with a ZIP file...

The AES Key from my encrypted ZIP is all I have managed to extract,
how do I decrypt the zip using this AES Key...

It asks for a password, so how am I supposed to bypass that and only decrypt using the AES Key.

  • $\begingroup$ Welcome to Cryptography. What you are asking the zip encryption scheme. This might help you. $\endgroup$
    – kelalaka
    Feb 14, 2019 at 9:29
  • $\begingroup$ Have you read the pkzip format specifications? $\endgroup$
    – forest
    Feb 14, 2019 at 11:43
  • $\begingroup$ You can not "extract" "the AES Key from an encrypted ZIP": if it was there, or was otherwise obtainable from the encrypted file, that would be a devastating issue! It could be that you extracted an Initialization Vector, or derived the AES key from the password. $\endgroup$
    – fgrieu
    Feb 14, 2019 at 12:41
  • $\begingroup$ @fgrieu Perhaps it was "extracted" via a brute force search? $\endgroup$
    – forest
    Feb 14, 2019 at 12:48
  • $\begingroup$ I'm not sure exactly what I'm doing, this is challenging for me.... The reason I started doing this was because I keep reading how you can simply change a few characters in a RAR or ZIP file and it will ignore the password... as-if it didn't have one... I extracted the ( or an ) AES key by dumping the process and searching through it with findaes.exe .. This gave me one single 256 bit key, that is what I encrypted the zip with, a 256 bit key, so I figure it must be the key... ... I think it might be a key used to decrypt the software's data, and not my key for the zip... $\endgroup$ Feb 20, 2019 at 10:46

1 Answer 1


The details are explained in the WinZip documentation. It describes two encryption formats, termed AE-1 and AE-2. The format itself supports 128, 192, and 256-bit keys for AES in CTR mode, using PBKDF2-HMAC-SHA1 with 1000 iterations for key derivation. The salt is random and is half the size of the key. Help with decrypting data using a library is given elsewhere on the site.

You can verify that the decryption is correct by checking the password verification value:

This two-byte value is produced as part of the process that derives the encryption and decryption keys from the password. When encrypting, a verification value is derived from the encryption password and stored with the encrypted file. Before decrypting, a verification value can be derived from the decryption password and compared to the value stored with the file, serving as a quick check that will detect most, but not all, incorrect passwords. There is a 1 in 65,536 chance that an incorrect password will yield a matching verification value; therefore, a matching verification value cannot be absolutely relied on to indicate a correct password.

The key is derived from the password using PBKDF2, explained as follows:

Key derivation, as used by AE-1 and AE-2 and as implemented in Dr. Gladman's library, is done according to the PBKDF2 algorithm, which is described in the RFC2898 guidelines. An iteration count of 1000 is used. An appropriate number of bits from the resulting hash value are used to compose three output values: an encryption key, an authentication key, and a password verification value. The first n bits become the encryption key, the next m bits become the authentication key, and the last 16 bits (two bytes) become the password verification value.

General useful information on the PKZip format is also available here.

  • 1
    $\begingroup$ Sadly, "The key is generated from the password using PBKDF2 with 1000 iterations". It implies brute force passwords guessing is to fear, as with 7-zip crypto. Note: in the 26 to 64 byte password range, the output entropy can be larger than 160-bit, because the password is fed again as key to HMAC-SHA-1 with a different input. For larger password, it is reduced to 160-bit as the first step of HMAC, hence a limit to the entropy. $\endgroup$
    – fgrieu
    Feb 14, 2019 at 12:34
  • 2
    $\begingroup$ @fgrieu Thanks for the correction. I've removed that claim. It came from the WinZip documentation: Note that, when used in connection with 192- or 256-bit AES encryption, the fact that HMAC-SHA1 produces a 160-bit result means that, regardless of the password that you specify, the search space for the encryption key is unlikely to reach the theoretical 192- or 256-bit maximum, and cannot be guaranteed to exceed 160 bits. This is discussed in section B.1.1 of the RFC2898 specification. $\endgroup$
    – forest
    Feb 14, 2019 at 12:36
  • $\begingroup$ I remove the part of the above assertion that is about 7-zip crypto, which only applied to the part of 7-zip code that deals with WinZip crypto. 7-zip crypto uses $2^{19}$ SHA-256 of counter/salt/password, for about $2^{18}$ rounds of SHA-256. While not ideal, it is much better that 1000 iterations of PBKDF2-HMAC-SHA-1. $\endgroup$
    – fgrieu
    Feb 12, 2020 at 12:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.