On Thu, 23 Feb 2023 10:18:11 -0000, Paul <nospam@needed.invalid> wrote:

> On 2/23/2023 3:10 AM, Commander Kinsey wrote:
>> On Wed, 15 Feb 2023 17:09:44 -0000, Paul <nospam@needed.invalid> wrote:
>>
>>> On 2/15/2023 11:13 AM, Tim Slattery wrote:
>>>> "Commander Kinsey" <CK1@nospam.com> wrote:
>>>>
>>>>> Trying to get into a password protected zip. Got three instances of a free password cracker (Stella Data Recovery) running for the last handful of hours trying three different methods (they only use 1 core each). Still not got in. I find it hard to believe zips are that tightly sealed.
>>>>
>>>> The ZIP format was created for data compression, not security. Since
>>>> then password protection has been added to it. I guess it would be as
>>>> strong or weak as any other encrypted format.
>>>
>>> The export laws on crypto, historically had a chilling effect
>>> on crypto strength.
>>
>> No government can stop me encrypting how I wish, then sending it to anyone in any country.
>>
>>> And to some extent, that hasn't changed.
>>> It's only when it impacts the competitiveness of a country,
>>> that it stops.
>>>
>>> It used to be "you stop it before it happens" was how
>>> you handled crypto. Today, it's the usage of rubber hoses
>>> which is the preferred method (the TrueCrypt mystery,
>>> and legislative attempts to build backdoors).
>>>
>>> When ZIP was invented, elliptic curve didn't exist. But
>>> there were still likely to have been methods which signal
>>> you are using the "tough" version. Using a weak-as-piss
>>> method ensures your product can be Exported.
>>>
>>> The same kinds of things happened on PDF format.
>>>
>>> And the old protection on ZIP is so weak, if Google wants to,
>>> they can scan ZIP attachments in GMail with that protection method,
>>> in "real time". You can't have a much weaker crypto than that.
>>> It's no barrier at all.
>>>
>>> The newer method on the other hand, is more of an impediment.
>>>
>>> Even the encryption on 7Z has had the odd issue, but these
>>> implementation details have been corrected.
>>
>> Isn't 7zip just a zip program, using the same standards as any other?
>
> Just as RAR has a custom compressor (and charges money for it),
> 7ZIP has a custom compressor (7z) and it is free.
>
> I think these are arithmetic compressors, similar to LZMA, but
> you'll probably find a wikipedia entry with the details.
>
> The other thing it has, is a pre-processor. There is a method
> for re-encoding EXE files, and if 7Z senses EXE files, it passes
> the data through the pre-processor, before the main 7Z compression
> step runs.
>
> 7ZIP has multithreaded compression and multithreaded decompression.
> By using all the cores, the slow LZMA-like method is delivered at
> moderate speed.

Everything should be multithreaded, we've had multicore CPUs for donkey's years.

> To compress a hard drive full of data with 7Z, costs about $1 worth
> of electricity. Just to give some idea, that certain computing things
> do cost real money. A machine can grind for most of the day,
> compressing a disk drive.

Does it cost much to have a drive compressed by Windows? Every time you read and write you're using the processor. But less of the drive motor and the wear on it.

> Some of the other compressors built into 7Z, are not multicore.
> The winZIP compressor is probably not running on multiple cores.
>
> PIGZ is a parallel version of GZIP. It uses multiple cores during
> compression, but only one core during decompression. And the
> multiple cores, may have a limit. Whereas 7ZIP can use all your
> cores for .7z .
>
> On Win10 or Win11, you set the thread count to 2x as many as
> the CPU. A CPU with 6C 12T, you set the thread count to 24,
> so that the 12 virtual cores are well-loaded. This helps keep
> the CPU usage bar at 100%. If you set the thread count to 12
> (one per virtual core), it only runs at about 80% or so.
> Since the dictionary size for Ultra mode is 600MB per thread,
> 24*600 = close to 16GB of RAM. So if you want to make your
> CPU as hot as possible, you need sufficient RAM for all the
> threads of execution to use.

Doing that might overload the caches and slow it down.

> And then, when 7ZIP is finished all that mumbo-jumbp, it
> can do a pass of AES256 and encrypt the output blocks.
> Encryption is done after compression, because encrypted
> data does not compress. That's how you can tell the
> quality of encryption, if it does not compress and
> the file becomes smaller.