[tptacek]

This is getting a lot of play today on Twitter but it's not all that consequential in the normal setting of a ZIP file.

The flaw they're pointing out is that 7z's AES encryptor has a 64-bit IV (half the block size) --- not itself a vulnerability in block ciphers --- and uses a predictable RNG to generate the IV (for simplicity, just call it "time and pid"). 7z uses AES in CBC mode.

In CBC, you want IVs to be unpredictable; if you can predict an IV and you control some of the plaintext, you can in some cases make predictions about secret data that follows your controlled plaintext (this is an "adaptive chosen plaintext" attack).

This doesn't really come up in 7z's usage model; you're supposing someone integrates 7z with their own application, which, on-demand, encrypts attacker-controlled data with a secret suffix and puts it somewhere the same attacker can see the resulting ciphertext. Don't do this. In fact, if you're using ZIP archives in your application, don't use ZIP's AES at all; encrypt yourself with a modern mode. ZIP AES isn't meaningfully authenticated.

Having said all that: for the normal usage of an encrypted ZIP, this doesn't really matter at all.

It's a good finding, though! Cheers to anyone who takes the time to look at the underlying code for any popular cryptography. I hope they keep it up.

A more important PSA: unless you're absolutely sure otherwise, you should always assume any ZIP program you're using doesn't actually encrypt password-protected ZIPs. It's just as likely that it's using the old, broken PKWARE cipher, which is dispiritingly common due to backwards-compat concerns. It would be nice if there was a mainstream, built-in way to password-protect a file that you could share with someone else (or just stick on a thumb drive), but ZIP encryption isn't it.

Pentesters sometimes go out of their way to use 7z because it actually does encrypt with a real cipher. And, I guess for what we're doing with it, 7z is fine. But it's sad that it's the best common denominator we have.

[13of40]

> It would be nice if there was a mainstream, built-in way to password-protect a file that you could share with someone else

This is going to sound really ghetto, but if you zip up some files, drag and drop the zip archive into a (modern) Word document, then pick File->Info->Protect Document->Encrypt With Password, you end up with a shareable file with decent encryption. IIRC, key generation is done with 500,000 rounds of SHA512 (which takes about 0.8 seconds on a contemporary CPU) and the encryption is 256-bit AES.

[techntoke]

Or just use GnuPG

[13of40]

Yep, there are a lot of ways you can do it. The point is, what are the chances my accountant is going to have GnuPG already installed on their laptop versus MS Word?

[tptacek]

None, is the answer. There is a none percent chance. And if you're going to get someone to install something, it's not going to be GPG. Without loss of generality this applies as well to lawyers, IT managers, development leads, chief security officers, cryptographers, and some former PGP developers.

[techntoke]

It's a simple install and even has a GUI app for right-click support.

[gus_massa]

Nice method! But it's surprisingly similar to https://xkcd.com/763/ .

[quietbritishjim]

> In fact, if you're using ZIP archives in your application, don't use ZIP's AES at all; encrypt yourself with a modern mode. ZIP AES isn't meaningfully authenticated.

It sounds like you are conflating the zip file format with the 7z file format (both of which can be created by 7zip, the program). The plaintext attack discussed in the tweets was for zip files created by 7zip, while most of the blog post was about 7z files. (Edit: are you suggesting that there is the same security issue in both? Because that was unclear from both your comment and the blog post, given that neither explicitly says so but, presumably, 7z format and zip format are quite different).

I think a lot of techies (I really mean "me") would already suspect that zip format could be problematic, even with AES encryption. But the same techies (me again) would reasonably expect 7z with AES to be safe so long as you have a sufficiently strong password, since it was created a lot later than zip with encryption designed in from the start. I still don't really understand if the issue in the blog post is really a problem for me (sharing files through one channel while sending passwords through another channel).

[zokier]

In this case the vuln applies to 7z format, it also uses cbc with same weak rng iv.

[anyfoo]

Coupled with the very simplistic and predictable passwords often encountered in passworded (avoiding the word "encrypted") ZIPs, I often have the impression that the intention is more to add an explicit human step to open the ZIP. So, making it (less) accessible to crawlers, or give a non-malicious recipient a moment to think whether they want/need/should extract this.

Often the password comes in the same mail or website, after all.

[13of40]

I got a chance to ask the guy who invented the ZIP encryption scheme a couple of years back, and he basically said it was designed to be exportable under the US's encryption export restrictions at the time, which I understood to mean they made it intentionally weak.

[hannob]

> Pentesters sometimes go out of their way to use 7z because it actually does encrypt with a real cipher. And, I guess for what we're doing with it, 7z is fine.

Well, it's a "real" cipher, but with a legacy, unauthenticated cipher mode. This means basically as soon as you encrypt any active content you can have an attack similar to efail.

[tptacek]

I agree, this is a good attack to game out.

[tinus_hn]

Whatever the excuses, this is just stupid because it is so easy to get right. Don’t invent your own random number generator, use the one from the OS.

[int_19h]

Keep in mind that 7-Zip is a fairly old app - it first shipped two years before Windows XP, which also happens to be the first version of Windows that had cryptographic APIs, and in particular, CryptGenRandom.

[tptacek]

I mean, yeah, 7z should fix this, but they're still going to be using unauthenticated CBC, which is a much bigger problem, so I'm going to have a hard time getting too worked up about this.

[warkdarrior]

So your argument is that 7z's insecure AES encryptor is not a problem because nobody _should_ use it?

[tptacek]

It's not a problem because nobody does use it in a setting where this is a practical problem. Somebody could use it that way. They shouldn't.

(My confidence here is high but not absolute).

[paulpauper]

: unless you're absolutely sure otherwise, you should always assume any ZIP program you're using doesn't actually encrypt password-protected ZIPs.

so 7zip AES is not actually AES? Obviously the source code shows it is

[olliej]

His point is that “zip” is an old data packaging format first, encrypted bundle second, many aeons ago the decryption was purely based - think “authenticated” PDFs that were plain text, but the application was meant to ask for a password before displaying the content.

Essentially, if you take an arbitrary “zip” implementation that offers password protection there are reasonably good odds that it isn’t using the “modern” aes based mechanism.

A predictable IV is only really useful if you can induce a target to repeatedly encrypt content using the same secret key, then an attacker can use known source content for some outputs to break the encryption for the unknown cases.

But again this requires a service that isn’t likely to really exist.

[int_19h]

7-Zip has its own format, completely distinct from ZIP.