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