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?

  • Yes, correct.
    – Adi
    May 31, 2013 at 7:08
  • One caveat: not all zip client tools support all decryption methods, so you can't assume everyone will have the tools for opening the file you send them. May 31, 2013 at 10:54
  • WARNING: The 7zip program on windows often leaves encrypted files in a plain-text state in temporary files. While 7zip is a great protocol, the program itself is incredibly insecure and refuses to fix the issue, so please don't use that one and be aware that other programs may have similar problems
    – B T
    Oct 6, 2015 at 23:06
  • @BT or anyone else - is this still the case for 7zip? Do you have a source for this claim?
    – Pedro A
    Apr 28, 2020 at 1:38
  • 1
    @PedroA The owner of the project doesn't think its a problem for some reason. Its very irresponsible that Igor has knowingly left this gaping security hole in 7zip for years, getting near a decade now. sourceforge.net/p/sevenzip/bugs/1448
    – B T
    May 10, 2020 at 2:27

2 Answers 2


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?


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.

  • 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.

  • I believe this assumes the attacker can also manipulate the executable in a way that allows it to have the same SHA1 hash (which has been securely transferred) as the original executable... right? -- of course, the recipient would have to actually compute and compare the hash before running the executable... Jul 8, 2015 at 20:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .