Can I properly make password-protected 7z archives secure?

Question

After reading the question and answers of this and this, I left with an overall impression from the last one that zips were considered not safe and insecure way of sharing data.

I still think password-protected compressed files can be made secure. So let me get this straight with this very

Specific scenario

• You're using the 7z command, version 9 or above, in a Linux machine. Not zip. Not rar.
• Correct me if I'm wrong, but 7z uses AES-256 by default when password protected, no matter if the archive format is going to be .zip or .7z

• You want to create a self-extract file archive.exe from directory dir1 and want all filenames contents and names and all headers to be encrypted, so you run

  7z a -mhe=on -psecretpassword -sfx archive.exe dir1

• The password used was very strong, assume entropy enough
• You securely shared the password with the file's intended recipient. Only you two know the password
• You also securely share the archive's SHA1 hash
• You now make this file available for the person to download

I say that

• The person can extract this archive even in a Windows machine without any program just with knowledge of the password
• The names of the files in encrypted directory dir1 cannot be read if you don't know the password
• The archive cannot be tampered with file substitution because filenames and headers were also encrypted
• Any tempering would be noticed if the person checked the SHA1 after downloading
• In terms of confidentiality of file names and contents, this is as secure as compressing the directory with anything (zip, rar, tar.gz) and applying openssl aes-256-cbc on it
• The self-extraction adds no vulnerability, and if it did, simply removing the -sfx or changing it to -t7z would fix it, though in this case the person would need 7-zip to extract it

Correct or not?

Answer 1

The question: Is a self-extracting archive encrypted with a perfect implementation of AES, using a key with sufficient entropy secure against an eavesdropper or active man-in-the-middle, if a cryptographic hash of the archive and the key are transmitted over a separate channel which is assumed to be secure?

Yes.

Some of these assumptions may not hold in the real world, though.

Examining the first assumption, there's a relevant question on this forum from almost a year ago: https://stackoverflow.com/questions/12470378/how-key-derivation-and-key-verification-functions-are-implemented-of-a-7-zip-arc

According to the discussion there, 7z uses a strong password-based key derivation function, and AES in CBC mode (which is fine, because we're assuming a SHA1 hash of the archive gets verified before decryption is attempted; which will stop padding oracle attacks).

However, the previous discussion also highlights a lack of documentation, and hard-to-read code in 7z. I'm not aware of any substantial cryptanalysis being done on 7z; so in using it, you're ultimately putting your trust in its developer to have gotten all the crypto implementation correct.

Answer 2

• The archive cannot be tampered with file substitution because filenames and headers were also encrypted
• The self-extraction adds no vulnerability

This is incorrect: if the expected use case is by running the self-extracting archive, any attacker able to tamper with the .exe file may also modify the self-extraction code to change the decompressed files in any way he sees fit. (Of course, he can also do much more, like logging the password or installing a backdoor)

So if you're in a situation where tampering is even remotely possible, self-extracting archives are a very bad idea.