> <i>So if you’re on Google, you get a doll that says ‘This doll came from Yahoo.’ Then you hand it to the next layer and they open it up and say, ‘This is for Alice.’ Then when Alice opens it up, Alice gets the whole message.</i><p>And where does Alice store her private key?<p>A very large percentage of email users currently use either webmail (e.g. Gmail) or a vendor-provided app (again, Gmail) to access their email. In order for Google to show you the content of your emails in such settings, it needs to be able to open up the last layer. So your private key gets stored on Google's servers, and they can capture your passphrase every time you log in.<p>Remember that Lavabit used your passphrase as the key to your auto-generated private key, which was stored on their servers. This was necessary, not only for compatibility with existing IMAP clients, but also in order for the webmail to work at all. Other companies like Hushmail developed a workaround using Java applets and/or a copious amount of JavaScript cryptography, but all of that is also rubbish because you can't guarantee that they aren't serving you a backdoored version of those scripts.<p>The only way end-to-end security could possibly work in the context of webmail would be for everyone to install a vendor-neutral browser plugin that does all the heavy lifting and that is completely beyond the control of the webpage on which it works (you can't allow the webpage to fetch the decrypted content back into the DOM). But if you're going down that route, you might as well install a standalone email app. It's basically going to be Thunderbird + Enigmail on steroids. Anybody who doesn't want to do that will be stuck keeping their private keys on someone else's machine. Guess what, most users really, really hate having to manage their own keys.<p>tl;dr: This proposal means either the death of webmail as we know it, or little more than an illusion of security.
Sounds awesome but the naming is unfortunate. Dark Mail, to the average person, will have a negative impression. It sounds scary and intimidating and something those <i>darn illegal hackers use</i>.
The concept is very interesting - apparently, each "doll" or layer is encrypted, and only the target can decode the message - so I guess the equivalent of the MX would be the outmost doll, while the equivalent of a To: field would be the innermost doll.<p>This reminds me of something else I've found quite interesting - the idea of publishing pubkeys or at least their hashes as DNS records (yes, unsafe unless there is DNSSEC etc, but that would be much better than now), so that the sender could encrypt the message automatically, without requiring the user to select say GPG target keys.<p>I wonder if that's what they will be using. Do they have technical documents or RFCs?<p>A new and non backward compatible email system using that (say even running on a different port) would indeed be quite interesting, but I wonder if there wouldn't be weaknesses that would make spam a problem as serious as in 2004/2005 (or maybe SPF is yet another of their "dolls"?)<p>Edit: about anonymous remailer and tor, it doesn't look the same to me. Say I publish 2 keys, one for my domain, one for my user. Everything one wishes to send to my domain is encrypted first with my key, then with my domain key, and then signed with the sender domain key (to add equivalent of SPF). Once it arrives, the equivalent of an MTA can try and decrypt that - if it suceeds, it can then put it in a spool of mail "not fetched yet" (so to as add a layer of protection against a malveolent sysadmin - the user could download all the encrypted mails in the spool and try to decrypt them itself)<p>The only thing that would be seen (besides the DNS lookups, but they could be cached by the client with a TTL) would be that domain A is sending a message to domain B.
“Ironically, we have been protecting the stuff that they’re not collecting,” Callas said.<p>Or, they were collecting it because it's not protected. If not by encryption at least by the law.<p>That said, I have a feeling the NSA was also checking out the message bodies. Wasn't there one leak about analysts sharing nude photos from intercepts?
A big downside is that it seems like this would make spam harder to block. (Intuitive claim, I'm not familiar with the technical details.) It also seems like it has the disadvantage of chicken-and-egg adoption before it's a useful service.<p>So here's a possible solution to both problems at once: I've always liked the idea of disincentivizing spam by charging a micropayment per email. So include a tiny bitcoin payment encoded into each layer of the doll to reward the intermediary, and you'll simultaneously provide an incentive for participation in the network (payment for participating) while simultaneously discouraging frivolous emails (since you now have to pay per spam message.) Obviously you'd make the charge small enough to not matter to most people for daily use (<$0.01) but I assume any nonzero price would hurt spammers badly.<p>You'd have to prevent intermediaries from decoding all the layers and taking the full payment, but presumably the Dark Mail folks have a solution for this already. Otherwise otherwise anyone in the middle could decrypt all the layers and read the contents of the email, and Dark Mail wouldn't work at all.<p>Or maybe I'm missing something. (Decent chance of that, since all I'm going on is a Time article and I'm not a security guru.)
Should we re-think email addresses too?<p>Currently most people have just one email address they give to everyone. What we gave everyone we want to talk to a unique address e.g. <random_long_string>@provider.com - even with this simple change, it would be very hard for a government to track an individual though metadata.<p>You could even create new from address for each outbound email - since you assume that if you digitally sign your email the recipient will know it's you.
So what is going to prevent the US from just serving NSL to everybody in the paths of the emails? They already read all the network traffic anyway.<p>Freenet works substantially the same way, with routers not knowing the end paths and endpaths not knowing the sender, but it is build for file transfer - something where you would think the average person has an interest as it would prevent nasty letters from RIAA - and it hasn't taken of. Why should this?
Sounds great but it's really hard to get adoption of a new protocol.<p>If I want to get a secure message to someone all I need is:<p>me --(TLS)--> my SMTP --(TLS)--> receiving SMTP server<p>All any third party will know is that I'm sending email to gmail/yahoo/ms or whereever.<p>If I can't trust my ISP's outbound SMTP server, then I could have one on my own machine or even built in the mail client. The problem of course is that many ISPs put client IP addresses on RBL lists.
Younger HNers may not remember the anonymous remailer days (ah, pre-spam internet, how I miss you) but this kind of technology has existed before. Specifically, this sounds a lot like mixmaster, the "Type II" anonymous remailer from the mid-90's that was pretty popular amongst the cypherpunks crowd.<p><a href="http://mixmaster.sourceforge.net/faq.shtml" rel="nofollow">http://mixmaster.sourceforge.net/faq.shtml</a>
> The creator of an ultra-secure email service once said to be used by Edward Snowden [...]<p>By the way, for those that don't recognize the name, the "ultra-secure" email service is Lavabit, that was secure only by pinky-swear (that is, they just promised to encrypt the emails they <i>were</i> seeing).
For anyone interested, the webpage of "Dark Mail / DIME":
<a href="https://www.darkmail.info/" rel="nofollow">https://www.darkmail.info/</a>