Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

At times, I send emails with attached documents that contain sensitive data. I learned recently that the policy is to create an encrypted archive that contain such documents. As a result, I have seen three different ways such emails are sent:

  1. Send archive with the archive password in the same email.
  2. Same as #1, but with the password on the very bottom of the email.
  3. Send archive and archive password in separate emails...typically the email containing the archive is sent before the one containing the archive password.

I currently practice #1 by policy, and I'm not sure if this is the best approach.

I use Outlook Express. I have no admin privileges on my computer and the only way (company approved) software is installed on my computer is through a request procedure.

What is the best practice for sending encrypted archives over email?

share|improve this question

closed as not constructive by Ƭᴇcʜιᴇ007, Randolph West, random Sep 18 '12 at 16:50

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

You choose whatever works for you, and whatever the rules are governing the management of the data you're sending. There is no one single answer to this problem. – user3463 Sep 18 '12 at 16:36
There's no point in even encrypting the data if you include the password in the same message. It's even pretty risky to send the password via a separate email message. If company policy prevents you from installing tools that will permit a better process then you should go on record as objecting, especially if laws such as HPAA are involved. – Daniel R Hicks Sep 18 '12 at 18:03
@DanH Interesting that a HIPPA compliant software I once worked with sends email consistent with #2 above... – ᴍᴀsᴛᴇʀᴍɪɴᴅ_ᴇᴅ Sep 18 '12 at 18:15
It only got to be "HIPAA compliant" because no one ever actually looked at how it worked but just read the checklist. – Daniel R Hicks Sep 18 '12 at 18:37

Send the password via a different method. Any other method will do, just not the same method as your archive.

If you do not trust your mail, then you gain nothing by sending both the archive and the key in the same mail. The same is true for lots of other methods (e.g. sending documents in a safe with the key glued to the front of the safe).

You either pre-agree on the key(s), or you use two different methods. One for the actual data (archive), one for the key.

Which is a long winded way of answering: D) None of the above.
All three are insecure. If anyone can intercept your mail then all three methods are equally bad.

share|improve this answer
Snail mail, secured webserver, in person, phone, etc. Its just bad practice to send a lock & key via the same method. If one method is comprimised, then the security is not lost. – Keltari Sep 18 '12 at 16:17
@edmastermind29 See gertvdijk's Answer - PGP or some other form of public key encryption allows encrypted data to be sent without ever actually sending the key to decrypt it (effectively). – Darth Android Sep 18 '12 at 16:18
Use public private key encryption. It's really the only way to guarantee it's not been tampered with or seen – Cole Johnson Sep 18 '12 at 16:23
@Keltari Perhaps I will use a secured webserver. That's simpler than trying to work around my locked down situation. – ᴍᴀsᴛᴇʀᴍɪɴᴅ_ᴇᴅ Sep 18 '12 at 16:30

Rather than a simple recommendation or how-to, here's my thought.

Consider using either

  • S/MIME, a way similar to SSL on public websites. Using keys and certificates to encrypt and/or sign the whole mail.
    This is considered to be the corporate solution and usually requires buying signed certificates from a CA.
  • PGP/MIME, similar to S/MIME, but using simpler public/private keypairs. You can also encrypt and/or sign with it.
    Widely used, especially signing, in open source communities.
    For Tunderbird, one can use the Enigmail plugin. Other mail clients offer this too usually.
    Does not require buying singed certificates or such - there's no central CA, but a web of trust.

Benefits over sending plain text e-mails with only the attachment encrypted:

  • The whole e-mail body is encrypted and checked for integrity. The recipient can really check that the mail is originating from one having the private (secret) key. This way instructions or other secrets in the body are also encrypted and provably not changed.
  • No mistakes possible in typing the encryption passphrase. CAPS LOCK problems for example...
  • At least for GnuPG it's possible to add multiple recipients without sharing an encryption passphrase. Just add multiple public keys to allow decryption the mail. Really? yes.

Drawbacks of S/MIME or PGP/MIME:

  • Client support is lacking.
  • Webmail applications need the private key on the server usually.
  • IMAP servers or other mail gateways are unable to index your mails on the body (but hey, it's a feature of encryption to have this impossible).
  • Recipients cannot decrypt mail if their private key is not accessible (mobile devices, on the road, etc.)
  • Similarly, senders cannot encrypt mail if their private key ...
share|improve this answer

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