It has been reported that 7 Zip generates IVs in a weak manner.

What is the actual impact of this? I'm asking about historical Zip files that I've sent. I've no plans to use 7 Zip going forward until this is fixed.

If I understand correctly, 7 Zip uses AES-CBC and this would not have a major impact. Even if a user repeatedly used the same password, the small amount of randomness in the IV would be enough to prevent cryptographic attacks.

  • 3
    Can we get a definition of "IV" so people can look it up and research? – JPhi1618 Jan 25 '19 at 16:17
  • 7
    @JPhi1618: when discussing ciphers, IV stands for Initialization Vector. – Jacob Krall Jan 25 '19 at 16:51
  • 4
    IV stands for Initialization Vector – Captain Hypertext Jan 25 '19 at 17:34

In CBC mode, the Initialization Vector (IV) has to meet two properties:

  • Uniqueness: Here the IV is very likely unique because of time(NULL) and gettimeofday() which are basically the current time of your system. It's even more likely on Windows platform since the CPU cycle is involved.
  • Unpredictability: This property is mandatory if the user can choose the message to encrypt, which is not the case here.

Note that the IV does not have to be secret. As a matter of fact, it is often appended at the beginning of the ciphertext, as clear text. The fact that an attacker can recover the IV is not a vulnerability: the IV is assumed to be public after the encryption is done. Only the two properties listed above are mandatory.

The IV generation is definitely not good (mostly for the size of the IV), but the reaction of OP is exaggerated, the impact isn't that big. It's actually pretty small.

The bigger impact would be that an attacker would be able to recognize two ciphertexts encrypting the same plaintext only if they've been encrypted within the same microsecond, using the same key. Even in this conditions, on a Windows platform, the CPU cycle are very unlikely the same, so the IV will be different.

To give answer to your concerns: No, this vulnerability doesn't have a big impact in this particular case.

  • 2
    "with a probability of 1-2⁻⁶⁴ with time(null)" That would be the case only if the calls to time(null) were uniformly randomly spread over a time period of 2⁶⁴ seconds. – A. Hersean Jan 25 '19 at 13:00
  • You are right, it's even less probable, since time(NULL) is basically the current time of the system. I have edited my answer. – Faulst Jan 25 '19 at 13:40
  • 3
    time(NULL) provides a value to the second, not microsecond. – Random832 Jan 25 '19 at 14:52
  • 3
    Yes but gettimeofday does, which is also used. I've edited the answer accordingly. – Faulst Jan 25 '19 at 15:00
  • 2
    @David The IV is not consider secret, as a matter of fact, it is often append at the beginning of the ciphertext. You can assume that an attacker knows the IV, without weakening CBC mode encryption. The bigger problem would be re-using an IV, or if an attacker could predict which IV will be used, and have a control over the next encrypted messages. I added a clarification to my answer – Faulst Jan 26 '19 at 9:31

7-Zip added AES-256 support (for the 7z format) in version “2.30 Beta 25” (January 2003) and the necessary support for its (somewhat) “random” IVs in version “4.48 beta” (June 2007).

AES is a block cipher, which means that it “translates” one block of unencrypted data (plaintext) to one block of encrypted data (ciphertext) during encryption. Without additional enhancements, i.e. in the ECB mode, this creates deterministic mappings between plaintext and ciphertext, and even between individual blocks of both.

The CBC mode enhances this scheme by “randomizing” each block of plaintext first. To do that, it XORs the plaintext block with the ciphertext of the previous block. Thus, the resulting ciphertext of a plaintext block does not only depend on the key but also on every single preceding block.

For the first block, you don’t have any previous block, so you use an initialization vector (IV). For AES, you need 128 bits or 16 bytes of “randomness” for your IV.

Without any IV at all during encryption, you still could not simply decrypt an encrypted file (which you may have sent years before) without knowing the key. But you could certainly infer knowledge from ciphertexts that you observe and attempt chosen-plaintext attacks.

Now what seems to have happened here with 7-Zip means it doesn’t fully protect against certain attacks, but nobody can just decrypt your ciphertext easily. Nevertheless, guessing and applying the attacks (which IVs are meant to protect against) is much easier with this wrong implementation.

By the way, had this issue been reported just one week later, there would have been a bug bounty for 7-Zip – with bounties between 350 € and 15,000 € – paid for by the European Commission’s FOSSA 2 program. But it’s great that this has been reported as early as possible.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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