What is the impact of the reported weak IV in 7 Zip?

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.

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.