17 ms·
7-zip broken password random number generator
- saagarjha 8y ago> Open-source "many eyes have looked at it for years so it must be secure" crypto code. Nobody claims this. Open source code is just easier to audit than non-open code.
- jenscow 8y agoYes, and the article itself is an example of this.
- dvfjsdhgfv 8y agoWell, 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 https://en.wikipedia.org/wiki/Linus%27s_Law (it has nothing to do with Linus though)
- z_open 8y agoLinus's law says that if enough people look at something, the bugs will appear. But often not very many people are actually looking at the source code of open source software. So there is no contradiction here.
- loeg 8y agoHeavy emphasis on "in the past," and probably also, "ESR claimed."
- a1369209993 8y agoNo, it's not and has never been; you have it backwards. Closed-source code is guaranteed[0] to be insecure, 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 all-bits-zero or that a fair coin is guaranteed not to come up heads 100 times in a row.
- dvfjsdhgfv 8y agoI 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.
- blibble 8y agonot 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)
- lawnchair_larry 8y agoCorrect, 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 8y agoNo, 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 8y agoWhat? 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 8y agoNo. 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.
- deckar01 8y agoIt 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 https://twitter.com/3lbios/status/1087848040583626753
- MrRadar 8y agoOn 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.
- deleted 8y ago[deleted]
- shittyadmin 8y agoYup, if you want to see the state of the art in this, here it is from libsodium: https://github.com/jedisct1/libsodium/blob/master/src/libsodium/randombytes/sysrandom/randombytes_sysrandom.c#L335 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
- loeg 8y agoIt seems they use getrandom() on FreeBSD too: # if defined(__FreeBSD_version) && __FreeBSD_version >= 1200000 # include <sys/random.h> # define HAVE_LINUX_COMPATIBLE_GETRANDOM
- chasil 8y agoThis likely happened because 7-zip is Windows-centric, and the p7zip packages for UNIXish systems are assembled afterwards.
- tomatotomato37 8y ago>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
- deleted 8y ago[deleted]
- deepsun 8y agoWell, 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.
- 3lbios 8y agoHi! 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 ¯_(ツ)_/¯
- matthewaveryusa 8y agoThe attack here is: 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 8y agoMonotonically 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.
- matthewaveryusa 8y agoThey are if you don't have an oracle afaik
- tptacek 8y agoI 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 be unpredictable.
- matthewaveryusa 8y agoIf 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
- tptacek 8y agoThis 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.
- warkdarrior 8y agoSo your argument is that 7z's insecure AES encryptor is not a problem because nobody _should_ use it?
- tptacek 8y agoIt's not a problem because nobody does use it in a setting where this is a practical problem. Somebody could use it that way. They shouldn't. (My confidence here is high but not absolute).
- paulpauper 8y agoknowing the IV does not allow one to crack the message https://stackoverflow.com/questions/3225640/how-to-decrypt-aes-cbc-with-known-iv https://stackoverflow.com/questions/3225640/how-to-decrypt-a... https://stackoverflow.com/questions/3225640/how-to-decrypt-aes-cbc-with-known-iv 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 8y agoOnce again, no, CBC IVs need to be unpredictable.
- paulpauper 8y agoIt 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.
- zokier 8y agoCryptography 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.
- Hello71 8y agoIn 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.
- AnaniasAnanas 8y agoThat seems interesting. Do you have any links explaining the situation?
- whyever 8y agohttps://hackerfall.com/story/a-crypto-challenge-for-the-telegram-developers-1 https://hackerfall.com/story/a-crypto-challenge-for-the-tele...
- cataflam 8y agoNot exactly the same, but the EU has commissioned audits and just started a bug bounty program on some important open source projects. https://juliareda.eu/2018/12/eu-fossa-bug-bounties/ https://juliareda.eu/2018/12/eu-fossa-bug-bounties/
- endofcapital 8y agoThe 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?
- zokier 8y ago> When is the insufferably arrogant techno mage trope going to die? Probably at the same time as insufferably bad software engineering dies
- technion 8y agoAddressing 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-non-random-iv-with-cbc-mode-a-vulnerability 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.