3lbios

Thanks Igor, the new patch seems to provide a decent RNG seed for all systems. I also saw in the code that PBKDF2 does only 1000 iterations (kNumKeyGenIterations) which is a bit archaic - I'd suggest at least 10000.

Yep, looks like the RNG and IV are fixed now - I just looked at the new code. Still the KDF could use more iterations, at least 10000 (currently it's 1000), but that's another thing.

It seems that the Linux/Unix port - p7zip - was abandoned by the maintainer some time ago and is not further updated.

I shouldn't have said "usually", I was basing on one or two sources. Modern Linux gettimeofday() is probably clocked by TSC so no issue there (although I'm still not comfortable even with microsecond time). It's difficult to find info about resolution on other systems which proves it shouldn't be relied upon, especially if we want to support systems from the times of XP and older. Shouldn't rely on the fact that seeding loop takes 0.1s - it may be so on one particular system. It is unfeasible to...

Yes there could be jitter but it shouldn't be relied upon. As for gettimeofday - it depends on the system. Maybe it's usually better than 10ms if clocked by TSC but in the worst case it is clocked by system tick rate which is usually either 1ms or 10ms. For Linux it is probably dependent on the version. Here is a reference for FreeBSD: https://www.freebsd.org/cgi/man.cgi?query=gettimeofday&sektion=2 "the time may be updated continuously or in ``ticks''"

As you said - in most cases. On some systems (not necessarily very old) the "high resolution performance counter" may be as low as 3.5MHz if the underlying counter is ACPI PM timer. That means a modern processor could execute 1000 instructions (or more if IPC > 1 which it generally is) and the counter value still wouldn't change at all. And your loop has exactly 1000 iterations. It is getting dangerously close to the possibility of getting the exact same seed, even on Windows. Note that gettimeofday()...