Incorrect MAC for AES-encrypted compressed 0-byte file
A free file archiver for extremely high compression
Brought to you by:
ipavlov
Menu
▾
▴
1 Attachments
#2026 Incorrect MAC for AES-encrypted compressed 0-byte file
When a 0-byte file is deflated and encrypted with AES (WinZip style), 7-zip doesn't compute the MAC properly - it never calls CHmac::Update with the 2 bytes of compressed data.
As far as I can tell, 7-zip itself never compresses 0-byte files, but they naturally occur when generating .zip files programmatically, when you don't necessarily know how much data you're compressing ahead of time.
Attached is an example zip. Password is "test". WinZip 9.0 accepts the file empty-good.txt, but 7-zip 16.04 reports an error. I also added an empty-7zip.txt entry that has the MAC computed the way the current 7-zip expects, and WinZip reports an error on that.
Thanks for report!
I'll try to fix it.
Do you know any software that can generate such archives (instead of "Store" as in 7-zip)?
So what chance to see such archives in real world?
I found this when using zip4j, a zip library for Java. Its "ZipOutputStream" API lets you write a zip directly to non-file output streams like sockets, without needing a temporary file. But this means you have to choose whether to compress an entry or not ahead of time. If compression ends up enlarging an entry's data, it can't go back and re-write without compression like command-line zip tools do.