7-Zip Encryption: Practical Effect of Lacking Salt

Question

A previous discussion on Cryptography StackExchange leads me to understand that 7-Zip does not use salt to derive an encryption key from password to use its AES-256 encryption; that this is a potentially severe shortcoming; and that its impact is to make it relatively easy to crack multiple .7z files.

My question is, what does this mean in practice? Possible inferences or points of confusion:

(1) Virtually all other notable AES-256 file encryption tools (e.g., AES Crypt, Gpg4win, Cryptomator) do use salt; therefore they are significantly more secure than 7-Zip.

(2) The absence of salt doesn't have any practical effect on brute force password cracking methods, else Elcomsoft would not say that .7z is still harder to crack than RAR5.

(3) The absence of salt is a severe shortcoming only where the cracker seeks access to multiple .7z files. But why would that make a difference? If all those files use the same password, then yes, brute forcing one will open them all. If they use different passwords, the absence of salt would presumably make no difference.

(4) The absence of salt in 7-Zip is moot if I use some other AES-256 tool with salt to create a .7z file.

Answer 1

The absence of salt is a severe shortcoming only where the cracker seeks access to multiple 7z files. But why would that make a difference?

If there is a password verification method and there is no salt, then password search can be batched. Calculate one hash and test for all targets. If you consider that the 7Zip uses SHA-256 with $2^{19}$ iteration this is a huge reduction in the attacking timing.

The batching is usually performed by building a rainbow table in advance for the small size of passwords including the known passwords. This highly reduces the attack time if the target passwords are on the table.

If the attacker has only one file, then this doesn't matter; instead of building the table, just search. For further usages building the table is preferable.

It seems that 7zip doesn't use a password verification method. One has to decrypt and unzip the file. If during this process there is a format error the process will stop. This severely affects the performance of batching. Still, the attacker can generate the hash of the password and test for all targets this is faster than one by one for each file.

In any case use passwords with good strength like passwords generated from dicewire or Bip-39. If you have a password that has strength > 128 then you are safe against the attacker even the batch.

Note that there is no detailed information about the experiment made with Elcomsoft. Does it a single password or multiple password search. It seems a single search. The article is not well written in this sense.

The less number of password tries is due to the number of iterations.

The absence of salt in 7-Zip is moot if I use some other AES-256 tool with salt to create a 7z file.

Lack of Salt is not a real problem for a power user. Just generate a salt and carry it with the 7zip file. During the key generation prepend the salt to yo your password.

For normal users, the salt must be used against the batch attackers.

Answer 2

Not an expert on 7zip, I'll try a generic answer, I believe is applicable:

Lack of salt can be a serious issue, also using a homebrew key derivation function doens't give me a lot of confidence in how they manage their crypto.

Though I'm not sure how applicable most salt free attacks are to 7zip.

If you lack salt, but still have different IVs, and the format doesn't allow validating password until decryption is complete (validates decryption not the password hash). You are probably OK, because you still can't build rainbow tables, or even verify two files use the same key.

If there is an efficient way to verify the password before decrypting the file (and specifically without mixing in the IV and or data thoroughly). E.g if a hash of the key is saved. You could tell if two files share the same password and you could build rainbow tables in advance to help you crack passwords efficiently when you get the hash.

A home-brew key derivation function will almost definitely be vulnerable to various side channel attacks. This may or may not be applicable to you. If you can cause the password owner to decrypt files on there system on command and monitor them (timing/power/memory cache...) you can probably find the password.