4 ms·

You can already encrypt email bodies end-to-end using PGP. The unsolved problem is the (queue dramatic music) METADATA!!! For an email to get from your comput

You can already encrypt email bodies end-to-end using PGP. The unsolved problem is the (queue dramatic music) METADATA!!! For an email to get from your computer to the recipients, it has to have metadata that the intermediate computers understand: The SMTP protocol is designed to deliver your email by relaying it any which way it is set to. So when you send it, it goes to your office SMTP server, which then might relay it to your head office SMTP server, which then might relay it to the recipient's spam filtering service, which might then relay it to the recipient's head office, which might then relay it to your recipient's office from where the recipient retrieves the email when they're good and ready. SMTP is not ever going to be secure. Even if you use TLS (which most mail servers do by default these days) you're only encrypting the message-in-transit so any of the myriad of systems between each SMTP server can't read it. All it takes for the NSA to read your metadata (and cache your encrypted message) is to compromise one of the SMTP servers it passes through. Then they can compel you to decrypt it using any method they have at hand. The secure way to send email is to have your computer connect directly to your recipient's computer over an encrypted transport layer (TLS) and possibly for your recipient to authenticate to accept that connection (so AFK means no email). You'll have to know your destination point's IP address somehow. (DNS sounds fine, after all it's just a phonebook. However requesting an IP address could easily be logged and so you've leaked metadata again) This means you can't send an overnight email and expect someone to get it in the morning when they switch on their computer. If you want to do that it needs to sit on a server somewhere. And that server is subject to attack. So for convenience, we could build a server designed to accept any of these messages from anywhere. But it also needs to accept messages to anywhere as it can't be allowed to know who the recipient is. That's metadata. The problem now is how do I get my messages from my server? The server isn't allowed to have my key, so it can't go and attempt to decrypt every waiting message (or decrypt every envelope). At some point, you'll have to either give up convenience (can't get email unless you're both online) or security (you'll have to trust something you're not in control of). I'd be stocking up on tin cans. And string.

Spooky23 13y ago
Actually, its really simple. You operate your own mail system, and require secure network access to use it. For example, The social security administration requires each state to do this for the state employees who handle disability-related business. Those employees must use their mail system.
- lessnonymous 13y ago
  Again, you're trusting something that isn't yours. In this case you're trusting the state's server.
  - Spooky23 13y ago
    You're looking for a unicorn. There isn't a convenient way to have a third-party deliver something to someone without knowledge of where that thing is going. If you need a trusted chain of custody for whatever you're moving, than you need to build that infrastructure (as in the example I provided previously). If you need the ability to securely communicate outside of a secure infrastructure, there are various ways to do that (bank-style, ssl-secured messaging centers, PGP, S/MIME, etc). Anonymity is a separate problem. Spies use techniques like dead drops. The boss in "The Godfather" didn't use the phone. Corporate executives use PIN-to-PIN blackberry messaging and swap phones periodically.
  - SolarNet 13y ago
    But in this case the you that's worried about security is the social security administration for the state. The real problem with the argument is that it's hard for people to set up their own secure mail servers, but organizations, like in this example, can do it decently well.
e3pi 13y ago
Don't remailer services solve the metadata anonymity? I understand forwarding after a variable waiting period also frustrates sender address detection. Finland still good hosts for these? Wikipedia: An anonymous remailer is a server that receives messages with embedded instructions on where to send them next, and that forwards them without revealing where they originally came from. There are Cypherpunk anonymous remailers, Mixmaster anonymous remailers, and nym servers, among others, which differ in how they work, in the policies they adopt, and in the type of attack on anonymity of e-mail they can (or are intended to) resist.
- lessnonymous 13y ago
  From my comment: > At some point, you'll have to either give up ... security (you'll have to trust something you're not in control of). The anonymous remailer must be trusted for this to work. And this doesn't get around the fact that email is broken generally. Companies wont start using anonymous remailers.
hippich 13y ago
Am I correct, the "To:" field is really required to deliver email? If so, standards can be changed, or plugins developed to hide rest of metadata with encryption.
- lessnonymous 13y ago
  The 'to' header isn't required to deliver email. You could essentially encrypt the entire header block if you're changing the protocols. What actually delivers the email is the 'RCPT TO' command on the SMTP transaction. At the moment, SMTP requires that you also give it a 'MAIL FROM' command that tells who the sender is. Most servers also require a HELO that identifies the sending server, but you can basically get away with putting anything in there. But now you're left with an authorization problem. Currently the combination of these three fields is what determines whether an SMTP server will accept the message for delivery or relay. If all you get is the 'RCPT TO' command, then you have no idea who's sending the message until it's decoded. This puts the authorization task on to the recipient's computer. So the 90% of all email that's spam will now need to be parsed on the desktop. One solution here would be to include another section above the encrypted email header+body that is the authorization block. Now the recipient's server holds then entire encrypted message using the RCPT TO as the destination. The recipient downloads a list of auth-blocks addressed to them and issues back a DENY if they don't want the message. The authorization block would identify the sender who has signed their identity in a publicly identifiable way. BAM! There goes spam. Unfortunately the BIGGEST problem in all this is Microsoft. They could have added simple-to-set-up PGP to Outlook years back. So how likely do you think it is that they'll switch to any new protocol. (The anti-spam industry really lives in fear of Microsoft waking up and working on implementing any of the new protocols that would instantly stop spam.) In all this, I'm ignoring web-based email for all this: that's a much bigger security nightmare as you have to trust your private keys to the third party

Spooky23 13y ago

Actually, its really simple. You operate your own mail system, and require secure network access to use it. For example, The social security administration requires each state to do this for the state employees who handle disability-related business. Those employees must use their mail system.

lessnonymous 13y ago
Again, you're trusting something that isn't yours. In this case you're trusting the state's server.
- Spooky23 13y ago
  You're looking for a unicorn. There isn't a convenient way to have a third-party deliver something to someone without knowledge of where that thing is going. If you need a trusted chain of custody for whatever you're moving, than you need to build that infrastructure (as in the example I provided previously). If you need the ability to securely communicate outside of a secure infrastructure, there are various ways to do that (bank-style, ssl-secured messaging centers, PGP, S/MIME, etc). Anonymity is a separate problem. Spies use techniques like dead drops. The boss in "The Godfather" didn't use the phone. Corporate executives use PIN-to-PIN blackberry messaging and swap phones periodically.
- SolarNet 13y ago
  But in this case the you that's worried about security is the social security administration for the state. The real problem with the argument is that it's hard for people to set up their own secure mail servers, but organizations, like in this example, can do it decently well.

e3pi 13y ago

Don't remailer services solve the metadata anonymity? I understand forwarding after a variable waiting period also frustrates sender address detection. Finland still good hosts for these? Wikipedia: An anonymous remailer is a server that receives messages with embedded instructions on where to send them next, and that forwards them without revealing where they originally came from. There are Cypherpunk anonymous remailers, Mixmaster anonymous remailers, and nym servers, among others, which differ in how they work, in the policies they adopt, and in the type of attack on anonymity of e-mail they can (or are intended to) resist.

lessnonymous 13y ago
From my comment: > At some point, you'll have to either give up ... security (you'll have to trust something you're not in control of). The anonymous remailer must be trusted for this to work. And this doesn't get around the fact that email is broken generally. Companies wont start using anonymous remailers.

hippich 13y ago

Am I correct, the "To:" field is really required to deliver email? If so, standards can be changed, or plugins developed to hide rest of metadata with encryption.

lessnonymous 13y ago
The 'to' header isn't required to deliver email. You could essentially encrypt the entire header block if you're changing the protocols. What actually delivers the email is the 'RCPT TO' command on the SMTP transaction. At the moment, SMTP requires that you also give it a 'MAIL FROM' command that tells who the sender is. Most servers also require a HELO that identifies the sending server, but you can basically get away with putting anything in there. But now you're left with an authorization problem. Currently the combination of these three fields is what determines whether an SMTP server will accept the message for delivery or relay. If all you get is the 'RCPT TO' command, then you have no idea who's sending the message until it's decoded. This puts the authorization task on to the recipient's computer. So the 90% of all email that's spam will now need to be parsed on the desktop. One solution here would be to include another section above the encrypted email header+body that is the authorization block. Now the recipient's server holds then entire encrypted message using the RCPT TO as the destination. The recipient downloads a list of auth-blocks addressed to them and issues back a DENY if they don't want the message. The authorization block would identify the sender who has signed their identity in a publicly identifiable way. BAM! There goes spam. Unfortunately the BIGGEST problem in all this is Microsoft. They could have added simple-to-set-up PGP to Outlook years back. So how likely do you think it is that they'll switch to any new protocol. (The anti-spam industry really lives in fear of Microsoft waking up and working on implementing any of the new protocols that would instantly stop spam.) In all this, I'm ignoring web-based email for all this: that's a much bigger security nightmare as you have to trust your private keys to the third party