Live data from Hacker News

7-zip broken password random number generator

threadreaderapp.com

51–60 of 67 posts

Re: 7-zip broken password random number generator

#52

>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 ba…

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.

Re: 7-zip broken password random number generator

#53
post #5

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. https://twitter.com/3lbios/status/1087848040583626753

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.

Re: 7-zip broken password random number generator

#54
post #46
post #39

Earlier quoted context omitted.

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.

In fact, that's basically what Telegram did with their impossible "crypto contests": provide a specific attack scenario, promise lots of money to break that (impossible) scenario, and then claim that it is secure against all possible attacks.

That seems interesting. Do you have any links explaining the situation?

Re: 7-zip broken password random number generator

#55
Addressing the debate this thread seems to have spawned, a practical attack on predictable CBC IVs is described here:

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.

Re: 7-zip broken password random number generator

#56
post #34
post #11

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 unpredic…

> 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 roun…

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

Re: 7-zip broken password random number generator

#57
post #43

Earlier quoted context omitted.

I don't follow your response. If you're wondering whether it's OK to have predictable IVs, check: * Rogaway's IPSEC chained CBC IV attack * Bard's HTTPS predictable CBC IV attack * Dai's attack on SSH * Thai Duong and Juliano Rizzo's BEAST ... all of which are based on predictable IVs (usually: the last block of the previous message, which is taken as a synthetic IV in 1990s-era protocols). In short: no, CBC IVs must…

If you reuse an IV on 2 files at rest, information that both files have the same prefix leaks. If you use a counter IV, or a random IV, you got nothing -- that's the only point I'm making ivs don't have to be random in the confines of the right context

You should read about the attacks tptacek mentioned. If IVs are predictable, it's the same impact as if you reuse the same IV, you just have to compute (m' xor IV' xor IV) instead of just m' if IV' = IV Then in both cases you check if c' = c

Re: 7-zip broken password random number generator

#58

Earlier quoted context omitted.

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)

No, it's not and has never been; you have it backwards. Closed-source code is guaranteed[0] to be in secure, open source code may or may not be secure. New open source code is almost certainly insecure for much the same reasons closed code is insecure, but trends toward security over time as more people inspect it and fix security holes. 0: In the same sense that the hash of a arbitrary string is guaranteed to not be…

I don't claim that the "Linus's law" is true, I only point out it was used by some open source evangelists. It took decades and a few high-profile bugs to show it's not that simple.

As to the core of your argument, I think your position is too extreme. It depends very much if the software was developed using formal methods and a specialized language. Safety-critical systems are rarely open source, and yet a lot of effort and resources is put to make them secure. That other project choose time-to-market rather than security is their choice, not something inherent to open or closed-source software.

Re: 7-zip broken password random number generator

#59
post #11

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 unpredic…

> 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…

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

Re: 7-zip broken password random number generator

#60

The way this is written reminds me why I try to never interact with security people in any social or professional situation, ever. When is the insufferably arrogant techno mage trope going to die?

> When is the insufferably arrogant techno mage trope going to die?

Probably at the same time as insufferably bad software engineering dies

Post reply on HN