Best practice for emailing encrypted data

The government agency my company works for has the following practice when sending sensitive data:

  1. Encrypt the data into a zip file, using a tool like Winzip or 7-zip
  2. Email the encrypted file
  3. Send another email to the same recipients, with a different subject line, containing the password

It seems to be that if someone can intercept the encrypted file they can also intercept the password. How is this secure? It seems to me that the password should be provided on a different channel.

You should be using public key encryption, like gpg.

Sending the password in another email is highly insecure.

Also, Zip files can easily be cracked. 7-zip is a bit stronger, but if a weak password is used it can still be cracked.

You definitely need public key encryption.

PGP is the tried, tested, and most widely used solution.

Mailvelope provides browser extensions for Chrome, Firefox, and Edge to use PGP encryption with Gmail and other webmail services.

We use Microsoft Outlook with Exchange.

Try this, it has an Outlook plugin

If this simply means “put plaintext into a password-protected zip file”, it’s a poor level of security, as GreenWyvern has noted.

Yes, this is pretty much exactly the problem that public key cryptography is meant to solve – if your communication channel is insecure, then you shouldn’t pass keys over it, and if you’ve got a channel that is secure enough to pass keys over, then just send the original message over that channel.

The procedure you describe is secure against an attacker that has compromised a small fraction of your emails, but not all of them, which is a very, very rare situation. Usually if someone has compromised one of your emails, they can see all of them, and matching up a “payload” email with a “password” email is trivial in that case (it would not, for example, be a big deal to automatedly try every word in every email sent within six months of the payload as a password and see what works).

I’d suggest setting up an SFTP server for the “payload” channel and transferring files that way instead of using email (i.e. the email would be, “look here on the sftp server”). Or if the situation allows it, use some kind of cloud storage system and let someone else worry about the security. Sending encrypted data over email can be done properly, but it is constant effort and easy to slip up.

Password protecting a file is not encryption. WinZip has AES encryption, but the recipient also has to have a copy of WinZip to decrypt.

Using AES encryption with 7zip is fine but the password should be sent using a different method. I typically use phone or text message.

But weak passwords can be cracked nonetheless, and many users will tend to use weak passwords.

Public key encryption is better because it doesn’t involve the exchange of passwords at all.

To expand on this a bit more: Let’s say that I want to send a secret file to John Doe. John Doe first generates a private key, that he tells nobody at all, ever. Then he uses some simple and easy math to generate a public key. Once he has that, he tells me “My public key is a19fe72de60f” (actually it’d be longer than that, but not all that much longer; you could fit it on an index card at easily-readable size). It doesn’t matter how John Doe tells me that: It could be email, it could be whispered in my ear, it could be in a full-page ad in the New York Times. It’s public; the system is designed around the assumption that anyone who wants it can get it. All you have to make sure of here is that the guy who’s telling you the key is the real John Doe, the guy whom you trust with your secrets.

In principle, just like it was possible to generate the public key, given the private key, it’s also possible to do the reverse. But while it was really easy to turn the private key into the public one, it’s really hard to go the other way: Like, you can easily make it so hard that all of the computers in the world working nonstop would take many times the age of the Universe to solve the problem. So in practice, John Doe is still the only one who has his private key.

Now, I take Doe’s private key, and my secret message, and I combine them using some simple and easy math. This creates a new message, that looks like random garbage. I send that new message to Doe, using any method I like, including a full-page ad in the New York Times (who I’m sure appreciates all the ad revenue we’re giving them). It’s also simple and easy to unscramble that message… if you have the private key. But it’s impossible for anyone else. And remember, only John Doe has the private key.

Meanwhile, anyone else in the world can use Doe’s public key to also send secret messages to him, if they want. And I can create my own key so that anyone (including Doe) can send me private messages, and so on. And these keys can also be used in various other ways.

I think that was the approach my employer used when I was peripherally involved in this about five or six year ago.

I think you meant “I take Doe’s public key” there :slight_smile:

Best practice: don’t email it.
Upload it somewhere secure that requires credentialled access; send a link that will a) only work for the intended recipient, b) resist bruteforce access by locking out and c) expire after a fairly short time.

I’ve used PGP in the past, but…

When you need to send a confidential file to a counterpart outside the intranet and your counterpart has to access the file as soon as they get it, PGP has a lot of overhead. Even if your IT has put in place a seamless framework to handle the send/receive (here, they haven’t), the other side probably hasn’t, so they have to get it in place in order to receive.

Just about everyone in a corporate environment has WinZip (though I once sent a confidential file to someone at No Such Agency after she assured me she had WinZip, only to discover that what she had was a desktop shortcut to a program that was no longer on her computer).

TL;DR- Better is the enemy of good enough

Yup, inevitable that in a post of that length I’d make a mistake somewhere.

@Mangetout, your proposed solution isn’t a solution at all, but merely a restatement of the problem: “a link that will a) only work for the intended recipient” depends upon having some way of knowing that that person is the intended recipient. How do you know that?

That’s the reason you use an Outlook plugin, as @DPRK suggested, or a browser extension for webmail - not PGP directly.

It’s fairly easy and painless for everyone to install the same plugin. The plugin sets up and deals with PGP so you don’t have to.

Smartcard login?

The federal agency is required to use a government PIV card to login. However, we are sending emails from our own network to theirs and we do not have smart support on our network.

I use 7Zip which doesn’t merely password-protect the file, it encrypts it, using either something they call ZIpCrypto or AES-256.

Also, we often send data to more than one person. If we use PKI then we would have to encrypt it separately for each recipient.

(P.S. Never trust a Microsoft Office product to securely protect your content with a password.)

Yeah, the government agency where I work does that sometimes (encrypt and send a password later).

They are not going to setup a SFTP server or any of the other suggestions here. I would just go along with what they say to do.

You could always send 5 emails with different passwords, and then call them on the phone and tell them which password to use :slight_smile: