I would like to send a document that is confidential to users that have no clue what PGP is (so no point in teaching them how to install it etc...) via email.

The real question is how to do that?

Currently I am thinking of the following approaches and wondering whether anybody knows which one is the most secure:

I have the following options:

  • encrypt it using the security functionality provided by Microsoft Office Word. Then the name of the document is visible! And I don't know whether or not I should trust this encryption method from Word.
  • Encrypt it with WINRAR. I can encrypt even the document name, so upon opening, they should be prompted to provide the password and hence even the document name is encrypted.
  • Make it a PDF file and encrypt it using PDF. Similar to Word maybe a bit more powerful / or less??

Of course some would say use a combination, but I don't want to look that paranoid to my customers ;)

  • 6
    So once they decrypt it to read it, then they potentially have a cleartext copy lying around. What then? This might be a problem to solve between people, and not between computers. Do they understand exactly how confidential it is? ( Or isn't ? )
    – pboin
    Commented Nov 24, 2010 at 15:48
  • They are aware that it is a confidential document, so from that side it is fine. It is the technical part I am wondering about. Commented Nov 24, 2010 at 15:53
  • 2
    Is this for a one-time transaction, or something you want to be convenient for repeated use? If you use a password-based scheme, how do you plan to get the password to them?
    – nealmcb
    Commented Nov 24, 2010 at 16:38
  • I would think the name of the document might be less of an issue than the subject, recipient address and body of the message that you send it with. Do you also need the rest of the email to be encrypted?
    – nealmcb
    Commented Nov 24, 2010 at 16:43

11 Answers 11


You assume that the document has to be sent via email. It sounds like you are only protecting against interception while the email is being sent (smtp). If that is the case, you only need secure transport and not necessarily encryption handled by the end user.

Can't you have them download the document from a web server you control over SSL? You still have to give them the URL and password in some manner, but at least you can remove the document from the webserver. They are going to have a clear text version of the document anyway, so it doesn't matter if you keep it in the clear on your webserver, but behind a password. You can control access and pull it down after they get it.


With regards to MS Office security, do not use Office 2003. The key-length is limited to 40-bits which is still a bit of work but technically can be brute-forced.

I have looked at Office 2007 file encryption and it seems suitable. It is difficult to determine for sure because to my knowledge the spec is not publicly available (if anyone knows different, I would love to look at it) but there is some documentation.

The key-lengths and cipher choices are appropriate. 2007 Word files (.docx) are now XML-based. The file encryption leaves some header information available (the user will know it is a .docx file and the filename), as well as a fingerprint of the file (so that if the key is entered wrong, it has something to match it to), but the contents of the file itself is otherwise encrypted.

As mentioned, creating a SDA (Self-Decrypting Archive) with PGP seems to perfectly meet your criteria but I believe it is only available with PGP (the $$$ one) and not GPG (the free one). If you have actual PGP, I'd go that route. Otherwise, file-encryption with Word seems safe.

  • The encryption for Office 2007 is determined. OpenOffice can display the ".docx" file. Being open-sourced, you can see the encryption! Commented Nov 27, 2012 at 8:25

Ahh - such a long-standing and knotty problem :)

A lot depends on your "threat model" - who and what you're worried about and who trust. It sounds like you aren't looking for encryption after they get the document, just while it is in transit. As I noted in my comment above, I would think you'd care about the privacy of your messages as well as the privacy of the document name and the document itself while in transit.

One thing you can probably count on is reasonable support for TLS in your browsers. So if there is a secure web services provider which always uses https that you both trust, that would work. But you might not want to trust, e.g., a state-controlled ISP or mobile provider in an oppressive country. See the Blackberry fights with the United Arab Emirates, for example.

E.g. if you both have gmail, and always access it with https, that may work. Google docs also can be accessed with https. Of course you may not trust Google, but there are many others out there (e.g. fastmail.fm) that you might trust.

If you both use some secure peer-to-peer protocol or instant messaging scheme, or mobile phone platform, that may well be more secure than email.


This one is a perennial problem and I've seen quite a few solutions to it.

A couple of considerations

Is this a one-off exchange or regular?

if it's a one off exchange then a password/passphrase communicated through an out-of-band mechanism (eg, SMS text message, verbally over the phone, in person) should suffice.

If it's a regular transfer then that may well not be practicable, so one option at that point would be to have a pre-set list of passwords (again communicated out of band) and work through that at pre-determined intervals.

From the point of getting the document over to the other person, it's largely determined by what software they have installed and what blocking/filtering is in place on the transport used to make the transfer.

Self-Decrypting archives can work, but some e-mail systems will block executable content in attachments (renaming the file can help here if the the system purely works on file extension)

Encrypted MS office documents, if it's a modern version and the selected encryption options are good, work reasonably well. As you mention, there can be a bit of a perception problem as older versions of Office had weak crypto, but I'm not aware of that being an issue with up do date versions (they use the Microsoft CryptoAPI which has strong ciphers available)

Encrypted ZIP archives, likewise as long as it's up to date versions of the software (older zip encryption was not very strong).

  • 1
    +1 for mentioning the blocking on file extension: Many organisations I have worked with still use this - implementing a check on the file for encrypted content is an option now for almost all mail gateways, but it still doesn't seem to be used enough.
    – Rory Alsop
    Commented Dec 17, 2010 at 10:21

If you already have the commercial version of PGP then you can create an SDA (Self-Decrypting Archives):

"Another way to put files and folders into a single encrypted and compressed package. An SDA is slightly larger in size than a PGP Zip archive because the executable file is included in the archive, but this means that the SDA can be opened on Windows systems that don't have PGP Desktop installed. SDAs can only be protected by passphrases, so you have to find a secure way to communicate the passphrase of the SDA to the intended recipient."

Other options:
dropsend.com http://www.dropsend.com/pricingsignup.php (business level to add security)
winzip w/encryption is popular http://www.winzip.com/


If it's a word document, consider Microsoft Rights Management server


..it's built into MS Word 2003 and newer.


Your choice of filename doesn't have to reflect the actual content. A Word file called 'Untitled 1.doc' is still a Word file, and the title on page 1 of the document can give the real information.

To extend your list of options, newer versions of zip (sorry, I don't know the format version, it's whatever WinZip 9 supports) offer AES encryption.


I think S/MIME is truly awesome, but surely WinZip with encryption (send the passphrase over the phone, or SMS/text-messaging) will work in a pinch.


For situations like this I use AxCrypt. This allows us to encrypt the attachment without concern for the version of office and if desired create a self extracting file. Be mindful that many email programs will remove executables so you may need to work around that.


You could consider setting up hushmail accounts, and GENERATING SECURE PASSPHRASES FOR THOSE USERS and giving them the passphrases in some secure manner. (But see Hushmail's note about them complying with valid law enforcement - http://www.wired.com/threatlevel/2007/11/hushmail-to-war/ )

That would deliver the content to them, but would not protect it once on their computer. But then, un-savvy users would probably have the content unprotected anyway.

Depending on the importance of the documents and the resources of the attacker there's software to brute force most encryption offerd by software. (see Elcomsoft offerings, for example, which allow you to use GPU clusters and dictionary attacks as well as pure bruteforce)

Don't forget that crypto is hard, and many of the softwares you've mentioned have already implemented broken encryption in previous versions.


The Zip 2.0 (Legacy) encryption format is supported by most, if not all, other Zip file utilities. Password protecting a Zip file with Zip 2.0 encryption provides a measure of protection against a casual user who does not have the password and is trying to determine the contents of the files. However, the Zip 2.0 encryption format is known to be relatively weak, and cannot be expected to provide protection from individuals with access to specialized password recovery tools.

Do not rely on Zip 2.0 encryption to provide strong data security.


I can believe no one has suggested printing out our document and sending it via express postal mail! Unless the client urgently needs the information, and its doesn't sound like this is not the case, overnight/next day delivery should suffice. Another option is to use a secure fax machine, which are common in medical office and HR departments, though not to many people have those handy.

You must log in to answer this question.

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