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.<p>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 <i>in block ciphers</i> --- and uses a predictable RNG to generate the IV (for simplicity, just call it "time and pid"). 7z uses AES in CBC mode.<p>In CBC, you want IVs to be unpredictable; if you can predict an IV <i>and</i> 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).<p>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.<p>Having said all that: for the normal usage of an encrypted ZIP, this doesn't really matter at all.<p>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.<p>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.<p>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.
>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...<p>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
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.<p>The twitter thread that this is aggregated from has replies that seem to indicate that there is no practical exploit here.<p><a href="https://twitter.com/3lbios/status/1087848040583626753" rel="nofollow">https://twitter.com/3lbios/status/1087848040583626753</a>
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)<p>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)
The attack here is:<p>1) You encrypt two pieces of data within the same second in the same process (so probably using the library?)<p>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.<p>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<p>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.
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.<p>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.
> Open-source "many eyes have looked at it for years so it must be secure" crypto code.<p>Nobody claims this. Open source code is just easier to audit than non-open code.
The way this is written reminds me why I try to never interact with security people in any social or professional situation, ever.<p>When is the insufferably arrogant techno mage trope going to die?
Addressing the debate this thread seems to have spawned, a practical attack on predictable CBC IVs is described here:<p><a href="https://stackoverflow.com/questions/3008139/why-is-using-a-non-random-iv-with-cbc-mode-a-vulnerability" rel="nofollow">https://stackoverflow.com/questions/3008139/why-is-using-a-n...</a><p>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.
knowing the IV does not allow one to crack the message <a href="https://stackoverflow.com/questions/3225640/how-to-decrypt-aes-cbc-with-known-iv" rel="nofollow">https://stackoverflow.com/questions/3225640/how-to-decrypt-a...</a><p><a href="https://stackoverflow.com/questions/3225640/how-to-decrypt-aes-cbc-with-known-iv" rel="nofollow">https://stackoverflow.com/questions/3225640/how-to-decrypt-a...</a><p>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