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.
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.
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).
Often the password comes in the same mail or website, after all.
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.
(My confidence here is high but not absolute).
so 7zip AES is not actually AES? Obviously the source code shows it is
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.
Just because a bunch of tinfoils are arguing over whatever doesn't mean you shouldn't still report it! Just be sure to word the report more generic than usual so the hordes don't find the issue and turn it into a battleground before a serious maintainer can get to it
The twitter thread that this is aggregated from has replies that seem to indicate that there is no practical exploit here.
https://github.com/jedisct1/libsodium/blob/master/src/libsod...
They sum it up in their docs like this:
- On Windows systems, the RtlGenRandom() function is used
- On OpenBSD and Bitrig, the arc4random() function is used
- On recent Linux kernels, the getrandom system call is used
- On other Unices, the /dev/urandom device is used
And 7-Zip first shipped in 1999. Granted, AES support was only added in 2003, but the app still had to run on Win2K and 9x back then.
Guys, this is not how info security should be taken. Just follow best practices, and experts recommendations, even when you cannot immediately see how it can be exploited. Because tomorrow someone _may_ actually find an exploit there. Finding exploits is a hard job, and a bit of luck.
so that routine... while far from ideal would seem to mostly satisfy that property if you are making zip files of your own data to send to people (unless you use the same key rather a lot)
Random IVs in CBC mode are an easy way to be fairly sure that you wont accidentally repeat a key+IV without much effort, but there is no security dependency on it being random nor on it being secret.
1) You encrypt two pieces of data within the same second in the same process (so probably using the library?)
2) or if you're using the command-line, the attack is you encrypt two pieces of data within the same second, and somehow wrap-around your pid within the second to get the same pid again.
That may be enough, or not enough -- but for those that claim that's not enough, one needs to recognize the cognitive dissonance with reusing the same password
A monotonically increasing integer as IV is perfectly fine, and this dude is a bit out of his depth thinking IVs need to be random.
Someone should make a bug bounty for all the major encryption programs, 7zp, wnzip, etc. Allocate 5 or so encrypted bitcoin private keys (with brute-force resistant passwords) for each program and see how long it lasts, with he public keys made public so people verify the status. if zip's bounty has lasted years, then it's reasonable to assume it's safe.
Nobody claims this. Open source code is just easier to audit than non-open code.
0: In the same sense that the hash of a arbitrary string is guaranteed to not be all-bits-zero or that a fair coin is guaranteed not to come up heads 100 times in a row.
When is the insufferably arrogant techno mage trope going to die?
Probably at the same time as insufferably bad software engineering dies
https://stackoverflow.com/questions/3008139/why-is-using-a-n...
Therefore in a strict sense, this is "broken". However, the "I zipped a file and it to someone" scenario is not one in which the above attack is practical.
https://stackoverflow.com/questions/3225640/how-to-decrypt-a...
the odds of the 7zip generator choosing an IV that corresponds to a re-USED IV for the same first block for a different message are very small and one would need to have access to this message
