41

I need to send some sensitive information to a client. I thought I would email a password protected zip file I created using Windows XP and then call them with the password. Presuming I pick a good password, how secure is this approach? Specifically, how difficult is it to decrypt a password protected zip file?

AviD
  • 72,138
  • 22
  • 136
  • 218
Dave Aaron Smith
  • 513
  • 1
  • 4
  • 6
  • How can you create a password-protected ZIP file in Windows XP (or any other) pure shell? _Send to a compressed ZIP file_ functionality (from context menu) does not offer entering password AFAIK. Can you create a password-protected file ZIP file at all using just pure Windows, without extra 3rd-party software like 7-Zip or WinZip? – trejder May 13 '13 at 08:05
  • 2
    If you want an alternative to Windows zip, consider [7-Zip](http://www.7-zip.org/). It's open source, and uses AES-256 (which is *very* unlikely to be broken any time soon :) It can also compress to .zip format, so anyone can read it. Note - I just double-checked, and Windows XP's built-in zip can *not* decrypt AES. However, it's possible to use 7-Zip to [make a self-extracting .exe file](http://www.wikihow.com/Use-7Zip-to-Create-Self-Extracting-excutables), so your client doesn't need the actual software. – John C Jul 18 '11 at 20:32
  • If you go the 7z method, I believe you can combine the encryption with the self-extracting option. – Zoredache Jul 19 '11 at 00:30
  • Self-extracting .exe files are a *terrible* idea, from a security perspective (see my answer). – D.W. Jul 19 '11 at 20:47
  • To my knowledge, there has been no credible independent security review of 7zip's encryption algorithms, so I would be somewhat reluctant to place too much trust in them to be secure. – D.W. Jul 19 '11 at 20:48
  • @D.W. yes, opening strange executables is generally a bad idea - but this is a deliverable between the OP and his clients, who presumably trust him. And though there are good alternatives, as always - it gets down to ease-of-use versus difficulty. Regarding 7-Zip's security - at least it's open source, so can be checked for holes or backdoors. That's more than you can say for any build-in *Windows* encryption, which was the OP's original choice. – John C Jul 20 '11 at 01:01
  • @John, trust is not enough. Email is not authenticated. Just because the email *purports* to come from Dave Aaron Smith, doesn't mean it actually came from him. Moreover, if clients get used to the idea of running .exe's from people they "trust", then they will be vulnerable to targeted attacks (e.g., the equivalent of spear phishing) and other nasty attacks. This is not how we want to train users to behave. I realize it is more convenient, but I believe it is doing clients a disservice. – D.W. Jul 20 '11 at 03:16
  • @John, 7zip may be open-source, but I don't know of any credible independent analysis of it, so that doesn't really help. I don't care whether it is better than Windows or not; I care whether it is good enough for his purposes. In my judgement, it is unclear whether 7zip is good enough for his purposes. Personally, I think PGP or GPG would be safer. – D.W. Jul 20 '11 at 03:17
  • AES256 encryption is a standard that is well accepted as presently very secure (used by major security providers). The 7-zip implementation is certified as are several other products. Suffice to say that if the product implements the spec (it works between different implementations) then it is very likely 'secure'. Compare to the ZipCrypto algorithm supported by Windows which is proven hackable in minutes if not hours on common hardware. – Darrell Teague Feb 05 '15 at 19:47
  • This is useful advice, but does not answer the question 'How secure is a Windows password protected zip file?' – mikemaccana Nov 12 '15 at 15:37

5 Answers5

46

When creating a password-protected Zip file (with the "compressed folder" utility integrated in the OS), Windows XP uses the "standard" encryption algorithm for Zip files. This is a homemade stream cipher, and it is weak. With 13 bytes of known plaintext, the complexity of the attack is about 238 operations, which is doable in a few hours on a PC. 13 bytes are relatively easy to obtain (e.g. if one of the files in the archive is an image, it will probably be uncompressed and begin with a known header). The result has even been improved, notably because the files in an archive are encrypted separately but without proper key diversification. Some years ago (quite a few now, tempus fugit), I have seen a password cracking software by Ivan Golubev which put this science to good use, and could crack Zip encryption in an hour.

The attack on Zip encryption is actually:

  • a nice introduction to cryptanalysis;
  • a good exercise in programming;
  • a reminder that you should not roll your own crypto. Phil Katz was very good in his domain, but the best cryptographers in the world will tell you that it takes much more than one extremely good cryptographer to make a secure algorithm -- it takes many cryptographers who feverishly propose designs and try to break the designs of the others, for a few years, until a seemingly robust design emerges (where "robust" means "none could find the slightest argument to support the idea that they may, possibly, make a dent in it at some unspecified date").

Now, if you use a tool which supports the newer, AES-based encryption, things will look better, provided that the format and implementation were not botched, and the password has sufficient entropy. However, such Zip files will not be opened by the stock WinXP explorer.

If an external tool is required, you might as well rely on a tool which has been thoroughly analyzed for security, both in the format specification and the implementation; in other words, as @D.W. suggests: GnuPG.

As for self-decrypting archives, they are all wrong, since they rely on the user doing exactly what should never be done, i.e. launching an executable which he received by email. If he does open a self-decrypting archive you send him, then he will just, by this action, demonstrate that he is vulnerable to the myriad of virus/worms/whatevers which roam the wild Internet, and he is probably already infected with various malware, including keyloggers.

Nevertheless, there is a way, in your specific situation, to make a self-decrypting archive reasonable. It still needs your client to install a new piece of software, but at least it is straight from Microsoft: the File Checksum Integrity Verifier -- a pompous name for a tool which computes file hashes. Send the self-decrypting archive to your client, and have him save it as a file (without executing it, of course). Then, have him run FCIV on it, to get the SHA-1 hash of the file. Do the same on your side. Finally, compare the two hashes by phone (it is not hard to dictate 40 hexadecimal characters). If the two hashes match, then your client will know that the file was not modified during the transfer, and he will be able to execute it with confidence.

(That is, if your client trusts you, and trusts that your machine is not clock full with virus which could have infected the archive on its way out.)

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Are there any ZipCrypto crackers that use known plaintext currently available? Your link to "Ivan Golubev" is now broken, and I don't see any on the first page of Google for "zipcrypto cracker". – Rich Aug 21 '18 at 21:04
  • 1
    @Rich Look for pkcrack or yazc (disclaimer I'm the author of yazc). Also the majority of commercial zip recovery tools implement the plaintext attack. – bookmarc Dec 07 '18 at 15:51
6

For sensitive data, I'd be a little reluctant to use password-protected ZIP or 7ZIP archives. The current versions of encryption they use has not been well-studied or vetted by independent researchers. Older versions of the software had security weaknesses, which is mild cause for concern. The newer versions might be OK, but since they haven't been independently reviewed, I'm reluctant to place a lot of trust in them. Ideally, something like GPG or PGP is better.

Please be warned that encrypting with a password tends to be weak. Most people choose passwords that do not have enough entropy to be secure against offline search (e.g., dictionary attack, exhaustive search). Moreover, long and strong passwords are inconvenient to use, providing a further disincentive against them.

I recommend that you avoid sending people self-extracting .exe files. That is a security risk. When you send people self-extracting .exe files, you are training them to receive a .exe attachment by email and run it. That is very dangerous practice, from a security perspective. I think the fact that ZIP and 7ZIP encourage this practice is a sign of disregard for security.

If you must use password-based encryption, I recommend: Use GPG or PGP (e.g., gpg -c). The security of GPG's encryption has been well-studied and is strong. Use a long, strong password: e.g., use a utility to generate a cryptographically random password. You want a password that's about 14-16 random characters long, with no patterns whatsoever.

This is probably going to be the easiest option for your client to use, that also provides strong protection.

If you want extra security, store the encrypted data on a CD or DVD, and then send the CD or DVD by Fedex (rather than by email). That way, you get two layers of security: someone can steal the data only if they can get access to the CD or DVD, and if they have the password to decrypt it.

If your clients have trouble using PGP or GPG, you could use a recent version of ZIP or 7ZIP's password encryption. In that case, I would avoid a self-extracting .exe file and I would probably be more inclined to send the encrypted data through the mail (on a CD or DVD) rather than over the Internet.

Alternatively: If your client is technically savvy and you have frequent communications with them, another option is to have them use GPG or PGP to generate a random public keypair, send you their public key, and then you can encrypt data under their public key. This will provide stronger security, if they know how to use GPG or PGP. However, it is less intuitive and so probably not feasible for sending a piece of data to an average client.

D.W.
  • 98,420
  • 30
  • 267
  • 572
4

It isn't that hard to decrypt a password protected ZIP file. There's plenty of apps out there to either figure out the password or just remove the password.

Odds are that no one will be intercepting the email between you and them. Public email servers have a massive amount of data flowing between them. Putting a password on the email is probably good enough. If you need something more secure then look at encrypting the email that the attachment is sent through, or post the file to a secure drop location like drop box (yes I'm aware of the issue they had a couple weeks ago) and send them the link.

mrdenny
  • 157
  • 2
  • 2
    In the light of recent events, I'd consider Dropbox only as cloud storage - convenient but without any actual protection (no matter what their marketing dept. says). Also, "send them the link" - that's every bit as good as sending the file unencrypted, as Dropbox public links need no authentication (thus "has link" == "has file"). – Piskvor left the building Jul 19 '11 at 14:33
  • 6
    *"Odds are that no one will be intercepting the email between you and them."* - this is poor security posture. I don't think it's even true. All it takes is for someone to read their email over an open wireless network, or to mis-type the To: address and have autocomplete send it to the wrong person. If the data is very sensitive, I wouldn't recommend counting on email to be secure. – D.W. Jul 19 '11 at 20:49
4

I have used password protected zip files as an ad-hoc encryption mechanism (although I prefer to use GPG when possible). Much is made of password recovery for zip files, but as long as you are using a current version, the only practical recovery mechansim is brute force. I believe both 7-zip and Winzip both support AES-256. If you client already has Winzip, I would use that (just make sure you use AES and not "Legacy" encryption).

The most important aspect of using this is your password (I would recommend a passphrase, at least 16 characters, throw in some special characters). The passphrase has the advantage that brute force is difficult, and you can exchange it over the phone with relative ease.

This is not a perfect mechanism by any means, but it could be good enough for your purposes (depending on the sensitivity of data).

Andrew
  • 161
  • 1
  • 4
  • This is incorrect. A ZIP file uses ZipCrypto which is highly vulnerable to known plaintext attacks, as others have pointed out. Simply using an up to date version of Windows does not provide stronger crypto. Only third party tools like the two you mentioned can do that. – guest Nov 19 '17 at 02:33
1

With dual GTX 295s a 4-char password can be recovered in under an hour.

http://is.hut.vn/~phongph/uploads/publications/1277074631.pdf

  • That seems like a pretty low rate, given that the possible permutations in their spec (62 chars ^ 4) is only 15 million combinations. Note also that the approach documented relied on human fallibility in the password generation process (they reduce the potential password list by discarding ones that are unlikely to be chosen by a human). EFF's cracker back in 1998 could make about 18,000,000,000 attempts per second against DES. –  Jul 18 '11 at 21:56
  • They say why in the paper: "The major obstacle of this cryptanalysis method is that the computational complexity of the hash function is quite high." While a ZIP file can be encrypted with DES, the paper seems to be attacking AES-256, which is much more expensive to attack. –  Jul 18 '11 at 23:21
  • Fair point, but ops question wasn't specific. You can crack a 4-char zip password in seconds but, as you say, only if it's DES. –  Jul 18 '11 at 23:50