Hacker News Reader

Comment by deckar01 | Hacker News Reader

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

View on HN

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 <sys/random.h>
    #  define HAVE_LINUX_COMPATIBLE_GETRANDOM

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

CryptGenRandom first appeared in WinXP.

And 7-Zip first shipped in 1999. Granted, AES support was only added in 2003, but the app still had to run on Win2K and 9x back then.

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.

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

Reply on news.ycombinator.com