4 ms·
I'm going to suggest a compromise way to get wide scale email encryption rolling out: The key benefits are that (1) the user doesn't have to do anything at all
by cantrevealname 12y ago
I'm going to suggest a compromise way to get wide scale email encryption rolling out: The key benefits are that (1) the user doesn't have to do anything at all and (2) it prevents mass surveillance and recording of email, but with a downside that it's not authenticated. There's significant benefit even when it's non-authenticated.
These days I get email from the other side of the Earth in several seconds. So adding a few more seconds to delivery shouldn't be a deal breaker on what I'm about to suggest.
Let every email client do opportunistic non-authenticated encryption with every other email client. That way, the user doesn't have to do a damn thing.
Example: Alice wants to send an email to Bob. Before sending the real email, Alice's email program sends an ephemeral public-key to Bob's email program -- hoping that Bob's email will promptly reply with its own ephemeral public-key. If Alice gets a reply within, say, 20 seconds, great. They can now send encrypted but non-authenticated email to each other. If Alice receives no reply or an error message, then her email program sends the email the usual way (as plaintext).
At this point, most readers will yell "man-in-the-middle attack." Bear in mind that this can be built upon and improved. The advantage is that it requires nothing at all from the user; the user might not even realize the email is being encrypted and decrypted. It requires only that the email client developers agree on the handshake mechanism.
But importantly, this thwarts the problem that we're most worried about, which is mass NSA surveillance. Yes, the NSA or others can still do targeted MITM attacks, but they are unlikely to do a MITM on every email exchange. And if they did, it would be detected and provable, and result in a backlash demand for authenticated encryption. Furthermore, clandestine wholesale recording of your emails is useless because the keys are ephemeral.
- napoleond 12y agoUsing Gmail (or any SSL-enabled mail server) already affords you those protections. (I'm not trying to be a naysayer, just that the protections PGP provides specifically go a step beyond what you're describing, which we essentially already have.)
- cantrevealname 12y ago> Using Gmail (or any SSL-enabled mail server) already affords you those protections. It absolutely does not. What I'm suggesting is end-to-end. With Gmail or with SSL-enabled connections, the host (Google in your example) can read your email; the encryption there is only between you and Google. I'm saying that the key exchange should be from your email client (Thunderbird, Outlook, a browser) to the other person's client. I think it could be made to work even with Gmail if the functionality was built into the browser.
- napoleond 12y agoI didn't read your parent comment as a suggestion for peer to peer ephemeral exchange. In that case you would be correct, but negotiating server less peer to peer key exchange (especially on mobile devices) isn't currently practical. EDIT: s/parent comment/your parent comment