Simple, secure, interoperable communications anywhere - what would it take to add the "secure" part?
July 17, 2012 3:37 PM Subscribe
Let's say everyone in the world suddenly decided they would like secured email - as in, email that's encrypted from sender to recipient. What would be the current barriers to making that happen?
Let’s pretend that everyone in the world decided that they wanted to be able to encrypt every email they send so only the intended recipient can read it, and they are willing to pay for it. For instance, everyone suddenly becomes willing to pay a certificate authority so the sender could encrypt their email and the designated recipient could get a key from the CA to decrypt the message.
What are the other issues that would make it difficult to exchange encrypted emails? Would we instantly be in encrypted email nirvana, happily exchanging encrypted emails? Or are there other obstacles? So far the biggest modern-day challenge I can think of is the lack of support in some major email providers (e.g., Gmail). But what else would make this change difficult, assuming that every email user wanted to transition to encrypted messages?
(This isn't a practical question, as evidenced by assuming that every email user wanted to transition to encrypted messages - I know that's not happening anytime soon. I was just thinking about how amazing email is - it's a nearly-universal interoperable standard, attachments are one of the easiest ways to send files, HTML emails allows a lot of really useful customization, etc. Then I thought about my major issue with email - it's not secure, so whenever I have to send sensitive work documents I have to find another solution)
Let’s pretend that everyone in the world decided that they wanted to be able to encrypt every email they send so only the intended recipient can read it, and they are willing to pay for it. For instance, everyone suddenly becomes willing to pay a certificate authority so the sender could encrypt their email and the designated recipient could get a key from the CA to decrypt the message.
What are the other issues that would make it difficult to exchange encrypted emails? Would we instantly be in encrypted email nirvana, happily exchanging encrypted emails? Or are there other obstacles? So far the biggest modern-day challenge I can think of is the lack of support in some major email providers (e.g., Gmail). But what else would make this change difficult, assuming that every email user wanted to transition to encrypted messages?
(This isn't a practical question, as evidenced by assuming that every email user wanted to transition to encrypted messages - I know that's not happening anytime soon. I was just thinking about how amazing email is - it's a nearly-universal interoperable standard, attachments are one of the easiest ways to send files, HTML emails allows a lot of really useful customization, etc. Then I thought about my major issue with email - it's not secure, so whenever I have to send sensitive work documents I have to find another solution)
There are two parts to secure email. Verification and Encryption. The encryption part is easy - two people exchange public keys. Then they have to create a workflow that makes it easy.
Te second part, marginally less scalable is verification. Is the email I received from who I think it is, and does it contain what they sent exactly? That requires a key exchange across a different medium, usually inperson or via some sort of key-party (not the 70s kind).
The real reason we don't have encrypted email is exactly why you think - every email user doesn't want it. People who do think it's great, people who don't think people who do wear tinfoil hats or are pedophiles.
The way to approach this is socially, not technically.
posted by bensherman at 3:48 PM on July 17, 2012 [1 favorite]
Te second part, marginally less scalable is verification. Is the email I received from who I think it is, and does it contain what they sent exactly? That requires a key exchange across a different medium, usually inperson or via some sort of key-party (not the 70s kind).
The real reason we don't have encrypted email is exactly why you think - every email user doesn't want it. People who do think it's great, people who don't think people who do wear tinfoil hats or are pedophiles.
The way to approach this is socially, not technically.
posted by bensherman at 3:48 PM on July 17, 2012 [1 favorite]
Best answer: I sign my e-mails, so anyone can find my public key, which will encrypt a message, or verify that the signed message is really coming from me. The problem, as you say, is being able to trust that a public key you find for someone (for example, on the http://pgp.mit.edu database) is really theirs.
That's where certification comes in-- they don't give out the decryption keys. If you want to send me an encrypted message, you encrypt it using my public key, and I decrypt it using my private key. That's how RSA (or any public key encryption) works. (Well, it's actually about factoring really large numbers...)
I use GPGTools, which interfaces with Mac Mail. If a critical mass of people were interested, software and webmail would have these tools built in. It would be almost trivial; they'd be able to look up the public key of any of your recipients from a public key database, and assuming they find a public key, the message could be encrypted. All outgoing messages can be "signed".
So really, assuming that you're ok with not knowing FOR SURE that the public key you find for me is really mine (assuming I haven't, like, given you one in person on a thumb drive), there's no barrier. Install a plugin, upload a public key, and you're using it.
posted by supercres at 3:48 PM on July 17, 2012 [1 favorite]
That's where certification comes in-- they don't give out the decryption keys. If you want to send me an encrypted message, you encrypt it using my public key, and I decrypt it using my private key. That's how RSA (or any public key encryption) works. (Well, it's actually about factoring really large numbers...)
I use GPGTools, which interfaces with Mac Mail. If a critical mass of people were interested, software and webmail would have these tools built in. It would be almost trivial; they'd be able to look up the public key of any of your recipients from a public key database, and assuming they find a public key, the message could be encrypted. All outgoing messages can be "signed".
So really, assuming that you're ok with not knowing FOR SURE that the public key you find for me is really mine (assuming I haven't, like, given you one in person on a thumb drive), there's no barrier. Install a plugin, upload a public key, and you're using it.
posted by supercres at 3:48 PM on July 17, 2012 [1 favorite]
Also, there are export controls on the RSA algorithm, despite the fact that it's incredibly easy to implement. This would make the amount of paperwork for shipping any e-mail client incredibly onerous, and Gmail likely wouldn't be able to enable it for overseas accounts. (That's just a guess, though.)
posted by supercres at 3:51 PM on July 17, 2012 [1 favorite]
posted by supercres at 3:51 PM on July 17, 2012 [1 favorite]
Response by poster: Let me see if I'm understanding - tell me if I'm not quite getting it. All that would be required is:
1) Everyone agrees on an encryption scheme (e.g. S/MIME, PGP, GPG).
2) Everyone uses an email client that supports this encryption method.
3) Everyone finds a way of exchanging keys easily (probably through a Certificate Authority so there's some level of trust that the public key you get when trying to send an email is actually the right public key for the recipient).
Then the workflow is something like:
1) I compose an email.
2) When I hit Send, my email client contacts the CA for they recipient's public key, and encrypts the email with that public key.
3) When the now-encrypted email arrives in the recipient's email client, the client already has the private key and decrypts the message.
Is that all it would take?
posted by Tehhund at 4:06 PM on July 17, 2012
1) Everyone agrees on an encryption scheme (e.g. S/MIME, PGP, GPG).
2) Everyone uses an email client that supports this encryption method.
3) Everyone finds a way of exchanging keys easily (probably through a Certificate Authority so there's some level of trust that the public key you get when trying to send an email is actually the right public key for the recipient).
Then the workflow is something like:
1) I compose an email.
2) When I hit Send, my email client contacts the CA for they recipient's public key, and encrypts the email with that public key.
3) When the now-encrypted email arrives in the recipient's email client, the client already has the private key and decrypts the message.
Is that all it would take?
posted by Tehhund at 4:06 PM on July 17, 2012
supercres, that RSA page is way out of date. While there are still controls on encryption, the only countries that you can't export RSA (asymmetric key > 512 bits) to without a license are Iran, Sudan, North Korea, Syria and Cuba. Open source encryption, such as GPG, has effectively been de-controlled entirely. There's no real export-related reason why email encryption can't be widely used.
posted by tommasz at 4:12 PM on July 17, 2012 [1 favorite]
posted by tommasz at 4:12 PM on July 17, 2012 [1 favorite]
As I understand it, your understanding is correct.
In terms of step 2 of the workflow, I had a collection of public keys stored locally ('a collection' being 'those of the two other people I knew using GPG') and never actually used a key server.
posted by hoyland at 4:13 PM on July 17, 2012 [1 favorite]
In terms of step 2 of the workflow, I had a collection of public keys stored locally ('a collection' being 'those of the two other people I knew using GPG') and never actually used a key server.
posted by hoyland at 4:13 PM on July 17, 2012 [1 favorite]
Everyone finds a way of exchanging keys easily (probably through a Certificate Authority so there's some level of trust that the public key you get when trying to send an email is actually the right public key for the recipient).
That's the difficult part. Authentication is a nontrivial problem. They deal with that now with web site certificates, and there have been occasional issues with it, i.e. security failures.
One time someone gained control over Microsoft's security certificate, for example.
Your workflow is incomplete. What it does is confirm that the recipient is the one it is intended for. There's a better approach:
1. I encipher with my private key.
2. I then encipher again with your public key.
3. I send the message to you.
4. You decipher with your private key.
5. You decipher again with my public key.
In this transaction, you are sure that I am the sender, and you are the only one who can receive it.
But you can only be sure I am the sender if you truly have my public key. If someone fools you about that, then they can pretend to be me.
posted by Chocolate Pickle at 4:17 PM on July 17, 2012 [1 favorite]
That's the difficult part. Authentication is a nontrivial problem. They deal with that now with web site certificates, and there have been occasional issues with it, i.e. security failures.
One time someone gained control over Microsoft's security certificate, for example.
Your workflow is incomplete. What it does is confirm that the recipient is the one it is intended for. There's a better approach:
1. I encipher with my private key.
2. I then encipher again with your public key.
3. I send the message to you.
4. You decipher with your private key.
5. You decipher again with my public key.
In this transaction, you are sure that I am the sender, and you are the only one who can receive it.
But you can only be sure I am the sender if you truly have my public key. If someone fools you about that, then they can pretend to be me.
posted by Chocolate Pickle at 4:17 PM on July 17, 2012 [1 favorite]
All that would be required is:
1) Everyone agrees on an encryption scheme (e.g. S/MIME, PGP, GPG).
2) Everyone uses an email client that supports this encryption method.
Those two already pretty much exist. PGP counts as the de facto standard, and GPG just provides an "open" implementation of that.
3) Everyone finds a way of exchanging keys easily
That part actually doesn't take too much work, for people you actually know. You don't need a secure channel to receive or confirm it, just confirmation that you have the real key (so they could email it to you, and you read it back to them on the phone to make sure you got it unmodified). You could swap thumbdrives with your keys on them. You could even print it out and put it on a business card, it would take a minute or two to type in, but not unrealistically long.
But...
Is that all it would take?
No. As bensherman pointed out most people consider those of us who want to encrypt our email as half a screw shy of hanging out in bell-towers casually watching people through a rifle scope. That, and really nothing else, poses the real limitation to ubiquitous adoption of email encryption.
posted by pla at 6:17 PM on July 17, 2012 [3 favorites]
1) Everyone agrees on an encryption scheme (e.g. S/MIME, PGP, GPG).
2) Everyone uses an email client that supports this encryption method.
Those two already pretty much exist. PGP counts as the de facto standard, and GPG just provides an "open" implementation of that.
3) Everyone finds a way of exchanging keys easily
That part actually doesn't take too much work, for people you actually know. You don't need a secure channel to receive or confirm it, just confirmation that you have the real key (so they could email it to you, and you read it back to them on the phone to make sure you got it unmodified). You could swap thumbdrives with your keys on them. You could even print it out and put it on a business card, it would take a minute or two to type in, but not unrealistically long.
But...
Is that all it would take?
No. As bensherman pointed out most people consider those of us who want to encrypt our email as half a screw shy of hanging out in bell-towers casually watching people through a rifle scope. That, and really nothing else, poses the real limitation to ubiquitous adoption of email encryption.
posted by pla at 6:17 PM on July 17, 2012 [3 favorites]
2. I then encipher again with your public key.
How do I know it's your public key?
You posted in on a website? Dude, easy hack. You post it as the signature in your email? What if an intermediary is seeing that, and replacing it? Don't think that's not a trivial hack if my evil SMTP server is in between you and the guy you want to get email from?
He notices a different PGP public key than before? Keys are changed -- are you sure they only have one? What if the previous private key was compromised or lost? Maybe there's a good reason that signature's PGP key is different now than then.
If you hand me the key, I read it out, and you verify it, then I am willing to believe that *the person who handed me the key* is the owner of the public key. Verifying that you are you varies. For a very few on this website, it's easy. For the rest? Really, you're $USERNAME? Prove it. Oh you logged into MeFi. As if passwords haven't been stolen before.
That's the crux. That's what makes sending from me to you encrypted very hard. How do you know it's me. How do I get a key to you? What if I don't want the traceability that PGP creates -- if you encrypt something with a public key of mine, you are declaring, in a cryptographically strong fashion, than you are trying to talk to whomever holds the private key, and there are plenty of reasons why that's a bad idea at times.
Indeed, it is the very hard problem in almost all encryption systems. How do you securely transmit a keying system, *prove* that you sent it, and prove that the key that was received was the one that was sent?
This is why the system that has been proven, when properly implement, to be impossible to break -- not improbably given massive computer time, actually impossible. One Time Pads, where you xor the data with a truly random bitstream that you've created, and use that random stream as the key, when properly implemented and used, cannot be broken, period.
They are also basically useless in most real world scenarios, because the key has to be at least as long as the message, you can NEVER reuse that key, and you have to come up with some way, if you want to encrypt 10TB of day, of creating a truly random bitstream that is 10TB long *and* shipping it to the receiver without it being intercepted.
posted by eriko at 7:34 PM on July 17, 2012 [1 favorite]
How do I know it's your public key?
You posted in on a website? Dude, easy hack. You post it as the signature in your email? What if an intermediary is seeing that, and replacing it? Don't think that's not a trivial hack if my evil SMTP server is in between you and the guy you want to get email from?
He notices a different PGP public key than before? Keys are changed -- are you sure they only have one? What if the previous private key was compromised or lost? Maybe there's a good reason that signature's PGP key is different now than then.
If you hand me the key, I read it out, and you verify it, then I am willing to believe that *the person who handed me the key* is the owner of the public key. Verifying that you are you varies. For a very few on this website, it's easy. For the rest? Really, you're $USERNAME? Prove it. Oh you logged into MeFi. As if passwords haven't been stolen before.
That's the crux. That's what makes sending from me to you encrypted very hard. How do you know it's me. How do I get a key to you? What if I don't want the traceability that PGP creates -- if you encrypt something with a public key of mine, you are declaring, in a cryptographically strong fashion, than you are trying to talk to whomever holds the private key, and there are plenty of reasons why that's a bad idea at times.
Indeed, it is the very hard problem in almost all encryption systems. How do you securely transmit a keying system, *prove* that you sent it, and prove that the key that was received was the one that was sent?
This is why the system that has been proven, when properly implement, to be impossible to break -- not improbably given massive computer time, actually impossible. One Time Pads, where you xor the data with a truly random bitstream that you've created, and use that random stream as the key, when properly implemented and used, cannot be broken, period.
They are also basically useless in most real world scenarios, because the key has to be at least as long as the message, you can NEVER reuse that key, and you have to come up with some way, if you want to encrypt 10TB of day, of creating a truly random bitstream that is 10TB long *and* shipping it to the receiver without it being intercepted.
posted by eriko at 7:34 PM on July 17, 2012 [1 favorite]
Eriko has it. The hard part is _entirely_ reliable key distribution.
posted by bfranklin at 7:42 PM on July 17, 2012
posted by bfranklin at 7:42 PM on July 17, 2012
Verifying the authenticity of a key is both easier and harder than eriko says. The crux is this paragraph:
posted by hattifattener at 8:50 PM on July 17, 2012
If you hand me the key, I read it out, and you verify it, then I am willing to believe that *the person who handed me the key* is the owner of the public key. Verifying that you are you varies.Think about what you mean by "you" in that last sentence. There is no absolute identification in the world. In all cases, you have a (usually arbitrary, personal, and subjective) idea of who you are trying to talk to, and what you want to do is bind a public key to that mental notion. The way you do that depends on how you developed that notion. Do I know you in person? Then I can easily verify your key in person. If I only know you online, then meeting someone in person doesn't help me at all; I need to verify your key by whatever means I know you online. (Putting your key fingerprint in your .sig or your profile page is an example— yes it's spoofable, but if someone's been running a MITM spoof of our communications since before I even met you, then cryptography really can't help us.)
posted by hattifattener at 8:50 PM on July 17, 2012
Eriko, if there's a way to reliably deliver the one time pad, then it could be used to deliver the public key instead.
posted by Chocolate Pickle at 10:10 PM on July 17, 2012
posted by Chocolate Pickle at 10:10 PM on July 17, 2012
« Older Can these over-ripe cucumbers be saved? | Does this thing ever turn off? Help me get a... Newer »
This thread is closed to new comments.
As someone who's played with this - and deployed it at companies - it's a total pain in the ass. However, the traditional route is to use PGP (or GPG) on the client to encrypt to your interlocutor's public key. This requires significant key management put into the users' hands, managing revocation, confirmation that the key you're using corresponds to your intended recipient, and not losing your private key, which would render all your mail unreadable and unsearchable.
There are PGP/GPG client for most mainstream clients: I've used it on Mutt, Mail.app and Outlook. However, you may not be able to search the contents of your messages, and you certainly are not able to search using a webmail client.
It's worth noting that more and more email is being encrypted in transit using TLS, and it's not uncommon for companies or providers to require TLS to exchange information. That only protections the in-transit mail, however.
posted by These Premises Are Alarmed at 3:47 PM on July 17, 2012 [1 favorite]