The government agency my company works for has the following practice when sending sensitive data:
Encrypt the data into a zip file, using a tool like Winzip or 7-zip
Email the encrypted file
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.
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.
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.
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.
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).
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?
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.)