7-zip broken password random number generator • Hacker News Board

Re: 7-zip broken password random number generator

#21

Post by paulpauper » Wed, Jan 23, 2019, 9:33 PM UTC

tptacek wrote: 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…

: unless you're absolutely sure otherwise, you should always assume any ZIP program you're using doesn't actually encrypt password-protected ZIPs.

so 7zip AES is not actually AES? Obviously the source code shows it is

Re: 7-zip broken password random number generator

#22

Post by tptacek » Wed, Jan 23, 2019, 9:36 PM UTC

paulpauper wrote: post #16

knowing the IV does not allow one to crack the message https://stackoverflow.com/questions/3225640/how-to-decrypt-a... 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

Once again, no, CBC IVs need to be unpredictable.

Re: 7-zip broken password random number generator

#23

Post by anyfoo » Wed, Jan 23, 2019, 9:39 PM UTC

tptacek wrote: 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…

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.

Re: 7-zip broken password random number generator

#24

Post by [deleted] » Wed, Jan 23, 2019, 9:39 PM UTC

tomatotomato37 wrote: post #7

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

[deleted]

Re: 7-zip broken password random number generator

#25

Post by chasil » Wed, Jan 23, 2019, 9:42 PM UTC

MrRadar wrote: post #9

deckar01 wrote: 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

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.

This likely happened because 7-zip is Windows-centric, and the p7zip packages for UNIXish systems are assembled afterwards.

Re: 7-zip broken password random number generator

#26

Post by loeg » Wed, Jan 23, 2019, 9:43 PM UTC

shittyadmin wrote: post #19

MrRadar wrote: post #9

Earlier quoted context omitted.

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.

Yup, 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/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

It seems they use getrandom() on FreeBSD too:

    # if defined(__FreeBSD_version) && __FreeBSD_version >= 1200000
    #  include 
    #  define HAVE_LINUX_COMPATIBLE_GETRANDOM

Re: 7-zip broken password random number generator

#27

Post by tptacek » Wed, Jan 23, 2019, 9:47 PM UTC

deckar01 wrote: 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

It is obviously wrong to have a CBC IV that is straightforwardly predictable.

Re: 7-zip broken password random number generator

#28

Post by loeg » Wed, Jan 23, 2019, 9:47 PM UTC

dvfjsdhgfv wrote: post #8

saagarjha wrote: post #2

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

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)

Heavy emphasis on "in the past," and probably also, "ESR claimed."

Re: 7-zip broken password random number generator

#29

Post by paulpauper » Wed, Jan 23, 2019, 10:03 PM UTC

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.

Re: 7-zip broken password random number generator

#30

Post by a1369209993 » Wed, Jan 23, 2019, 10:03 PM UTC

dvfjsdhgfv wrote: post #8

saagarjha wrote: post #2

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

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