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.