[blibble]

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)

[slimscsi]

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.

[lawnchair_larry]

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.

[tptacek]

No, I think you might be the one who doesn't seem to know what they're talking about, unfortunately. I think you have CBC mode confused with CTR (and its derived modes). CBC IVs need to be unpredictable, CTR nonces need to never repeat. Neither IVs nor nonces need to be secret, but it's important not to be able to predict an IV before it's used.

[lawnchair_larry]

What? Even for an encrypted 7zip archive? How does predicting a past event make sense here? Maybe you know an attack I’m not aware of. This isn’t an interactive protocol.

Edit: Sounds like you addressed this in your other comment. So again, there is no attack here and OP doesn’t know what he is talking about...right?

[tptacek]

No. You wrote "there is no security dependency on it [a CBC IV] being random". That is plainly false --- in fact, it's Wikipedia false --- you can literally just go to Wikipedia and search for the word "unpredictable" to see why. People do indeed use random CTR nonces as a way to ensure they never reuse them. But that's not why they randomize CBC IVs. There's a Cryptopals challenge about this if you'd like to play with the concept more.

('garypoc managed to relate this downthread completely in just one sentence, because they're better at this than I am, so maybe track that comment down for more information).

It is actually not a big deal that you're wrong --- people get the properties CBC IVs (which can't be monotonic counters) and CTR nonces (which can) confused all the time. It's why I get hives when libraries refer to the CTR nonce as an "IV".

But you didn't just get this wrong. You said the person who reported the bug "didn't know what they were talking about". Again, it was you that didn't know what they were talking about. Consider apologizing.

[lawnchair_larry]

I feel like you’re telling me (and others) I’m wrong in this comment but agreeing with me in others.

As far as I can tell, the reporter made rather public denigrating statements against the authors for a total non-issue that has no attack. As in, doesn’t know what he is talking about. So I’m not sure why you want me to apologize instead of him.

You seem to be taking issue with how I worded my comment in that I made an unqualified statement about CBC IVs, which is true in applications like this, but not true broadly. Is that accurate?

The only security risk of relevance here is that if a password is reused, and any blocks are the same in multiple files, this will be evident. This is defeated so long as an IV is not reused, which can’t happen (I’m comfortable rounding “unless a user makes a 7zip archive with the same password at the exact same time on multiple machines and manages to get the same PID” down to “can’t”, to be clear) even though the IV is reasonably predictable.

In other applications, like TLS, or IPSEC, yes, the OP would have had a legit bug finding.

There is no bug here, just a bad crypto code smell. It’s like pointing to a strcpy and saying “this code has buffer overflows!” when all call sites have bounds checking or fixed size inputs.

If you think I’m still wrong about this, I’m inclined to believe you, but I think you’re only saying predictable IVs are a problem in other, unrelated applications, which I am not disagreeing with.

It’s a completely dick move even if he were correct (but he isn’t). That’s not how you report issues. The author of this (free!) software obviously isn’t a cryptographer, but he thanklessly wrote an otherwise good piece of software that millions benefit from.

If you’re going to publicly shit on his code to get points from security twitter, at least nake sure you have a real finding. But better yet, don’t be that guy.

Appsec people need to learn that they aren’t better than developers because they found the one narrow domain that they know more about than the author. It’s extremely likely that the author could teach you way more than you can teach them, so if you have a leg up somewhere, be humble about it.

Edited to add: Igor, the author, appears to be having a civil and receptive dialog with the reporter on the 7z mailing list after the fact, discussing alternatives and tradeoffs and trying to validate a potential attack. So, this isn’t even a case where someone gave a well-meaning researcher the middle finger and motivated them to go public. OP just started shitting on the guy for public praise right out of the gate (even saying he wanted to vomit over how bad this is), completely unnecessarily.

I encourage him to apologize to Igor, who sounds like he is going to fix it regardless.

[tptacek]

I'm sorry. You remain wrong. Predictable IVs in CBC mode are a vulnerability. A low-severity vulnerability; so are most CSRFs. We don't generally write dozens of paragraphs about how irresponsible and clueless someone is when they report a sev:lo CSRF. In fact, what a lot of companies do for that is pay a bounty. (I know, not the fact pattern here).

You're also missing pretty much the whole conversation about why predictable IVs in ZIP's CBC is a vulnerability. Yes, as lots of people have pointed out, in the 95% use case of 7z as a simple file format, the IV doesn't matter. You can't use the flaw to decrypt someone else's 7z file.

But 7z is a file format. Applications build on top of those. Plenty of applications generate zip files. If one of them, for whatever reason, chose to generate 7z zip files with 7z's code, this sev:lo vulnerability stops being sev:lo. A predictable IV plus known prefixes turns CBC mode into ECB mode. If this person had reported 7z using ECB mode, nobody would be question the competence of the report. But they reported a more sophisticated flaw. It flies over people's heads. They claim it's bogus. You can see my issue here.

The world does not need more encouragement to write bad crypto code. We're up to our ears in it. But the world definitely needs more people to do the harder job of looking through the bad crypto and mapping out the pitfalls. Thats's what this person did. I'm fine if you don't want to thank him, I'm even fine if you just want to debate whether they reported it the best possible way (I'll disagree but we disagree on lots of things).

What I will not let anyone get away with is claiming that the finding itself is incompetent because predictable IVs are not a bug. That's not just wrong, it's theatrically wrong. I don't care if you apologize about slagging this person for reporting something. But I think you should apologize for claiming, falsely, that they were incompetent. I'm kind of a little surprised you haven't already!