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.
> 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.
> 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).
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.
> 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.
>I thought about reporting this at 7zip Sourceforge forums but then I vomited again when I saw a long thread of largely incoherent exchanges on how 7z should be using Twofish instead of AES-256 because...
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
Hi! I've reported it already on 7zip Sourceforge page. No response. In the forums I saw a thread someone had already started where the author said it's better to save 8bytes per archive than fix the IV ¯_(ツ)_/¯
Well, at some point you get tired communicating with tinfoils, and it's reasonable to expect that author just didn't have a motivation/incentive to even start. Better spend time for something more productive.
It is not clear if anything is actually wrong here. It would be nice if someone who has spent more than "30 minutes" looking at this code could verify these claims and publish an article explaining the implications of these design choices.
The twitter thread that this is aggregated from has replies that seem to indicate that there is no practical exploit here.
On the other hand, using the system cryptographic RNG (/dev/urandom, CryptGenRandom) is probably less effort than it took to write this strange half-baked RNG.
I hear this argument again and again: "there's no exploit, or show one".
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.
not a cryptographer: but from memory the main quality important in an IV for CBC is that it isn't reused for the same key (chosen plain-text attacks aside)
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)
In Common Encryption (encrypted mp4 files) 8 bytes IVs are a fully supported and documented. And sometimes preferred for compatibility. CENC mode even uses CTR, so the IV is simply incremented every block.
Correct, the guy on twitter doesn’t seem to know what he is talking about.
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.
Monotonically increasing CBC IVs are in fact not fine; you have them confused with CTR nonces, which need single-use rather than unpredictability. See Bard for more details of the best-known attack on predictable IVs. If you're going to try to take someone down a peg, be right.
It seems every few months we hear a story about something which is supposed to be secure not actually being secure or secure as expected.
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.
Cryptography doesn't quite work that way. Just because recovering cleartext is not feasible in some specific case does not make a cryptosystem secure in general.
Well, in the past it was one of the main arguments in favor of open source. There is even a related article on the WP: https://en.wikipedia.org/wiki/Linus%27s_Law (it has nothing to do with Linus though)
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.
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
tptacek|7 years ago
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|7 years ago
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.
quietbritishjim|7 years ago
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).
anyfoo|7 years ago
Often the password comes in the same mail or website, after all.
hannob|7 years ago
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.
tinus_hn|7 years ago
warkdarrior|7 years ago
paulpauper|7 years ago
so 7zip AES is not actually AES? Obviously the source code shows it is
tomatotomato37|7 years ago
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
3lbios|7 years ago
deepsun|7 years ago
unknown|7 years ago
[deleted]
deckar01|7 years ago
The twitter thread that this is aggregated from has replies that seem to indicate that there is no practical exploit here.
https://twitter.com/3lbios/status/1087848040583626753
MrRadar|7 years ago
deepsun|7 years ago
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.
tptacek|7 years ago
blibble|7 years ago
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)
slimscsi|7 years ago
lawnchair_larry|7 years ago
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.
matthewaveryusa|7 years ago
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.
tptacek|7 years ago
paulpauper|7 years ago
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.
cataflam|7 years ago
https://juliareda.eu/2018/12/eu-fossa-bug-bounties/
zokier|7 years ago
saagarjha|7 years ago
Nobody claims this. Open source code is just easier to audit than non-open code.
dvfjsdhgfv|7 years ago
jenscow|7 years ago
endofcapital|7 years ago
When is the insufferably arrogant techno mage trope going to die?
zokier|7 years ago
Probably at the same time as insufferably bad software engineering dies
technion|7 years ago
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.
paulpauper|7 years ago
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
tptacek|7 years ago