Hackers Unveil Their Plan to Change Email
time.com
time.com
And where does Alice store her private key?
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.
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.
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.
tl;dr: This proposal means either the death of webmail as we know it, or little more than an illusion of security.
It might begin that way, but it could evolve into a standard that is supported by many browsers. The "HTML6 email module".
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.
I wonder if that's what they will be using. Do they have technical documents or RFCs?
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"?)
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)
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.
For something that actually works over Tor (or something very similar), there's Adam Langley's Pond: https://pond.imperialviolet.org/tech.html
I don't know how big the need for is DKIM (from an anti-spam view) -- how many receive gpg-encrypted and signed spam anyway?
As I've mentioned before, I think this has similar problems as remailers -- as far back as 1996 intelligence agencies were running quite a few of them[1] -- and I imagine that would be the case going forward as well (ditto for tor nodes). I don't think that makes these things a wasted effort, just not a silver bullet.
Either way, having eg Apple Mail, Thunderbird and Gmail (yes, the webmail) automatically wrap any outgoing mail in a remailer-like envelope might not be a bad idea at all. And once wrapped, everything smtp (with the exception of content-based spam filtering at the intermediary servers) works just like it always has.
[1] http://www.hypertekst.net/misc/anon-remail/
[hn] https://news.ycombinator.com/item?id=6642106 https://news.ycombinator.com/item?id=6671219
Modern spam filters (at sites like Gmail) rely very heavily indeed on the notion of reputation. Without something like DKIM it's hard to calculate accurate reputations: you can do it but it relies on lots of hacks and heuristics. So reputation mechanisms of some form are pretty vital.
mike@blob:~$ dig +short txt mike.cardwell._pka.grepular.com
"v=pka1\;fpr=35BCAF1D3AA21F843DC3B0CF70A5F5120018461F\;
uri=http://grepular.com/0018461F.pub.asc"
mike@blob:~$
sed 's/^[ ]*//'|gpg --verify-options pka-lookups --keyserver-options \
auto-key-retrieve --verifyOr, they were collecting it because it's not protected. If not by encryption at least by the law.
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?
http://www.theguardian.com/world/2014/feb/27/gchq-nsa-webcam...
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.
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.
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.)
The main casualty would be mailing lists, which would likely have to move to forums or subscriptions. It might be technically possible to also say "I accept mail from X without demanding payment" but that's not necessary to make a pay-for email market work, and have much less spam.
And your last point is really just a specialized form of a web of trust anyway.
A large list may have hundreds, thousands, and potentially millions of recipients (though I'm not aware of any such at present). The Debian Project provides email subscription stats, with its biggest list being debian-security-announce, at 34,234 subscribers. That's a cost of $342.34 per message transmitted.
https://lists.debian.org/stats/
It would also be a large overhead to any system with a large userbase that relied on email based notifications. Facebook's financials put its per-user revenues at around $8-$10/year, which would be completely eaten up at the rate of only 3 emails per user per day.
The thing about email is that it's really, really cheap. That's the benefit and the detriment to the system. What you want to do is make the costs asymmetric. Cheap for legitimate and white-hat users, really expensive for the black hats.
Legitimate email would still end up being free, but spammers would have a much harder time getting mail through. And large mailing lists would be forced to be pretty responsible. Or to offer very small amounts per mail, which would be a great signal to file something under "promotions".
My guess is that high-reputation places wouldn't feel obliged to offer large bonds, or wouldn't offer any bonds on communications for established relationships. They wouldn't have to, because their mail gets through. The bonds would be much more useful for senders with deliverability or attention issues. That is, individuals, small companies, and new companies. It could also be great for marketing. If somebody's willing to bet $20 that their email is interesting enough to me that I won't collect the bond, I'd be interested to read it.
I don't want email to be taxed any more than I want IRC to be taxed.
See the problem there?
I am still doubtful that this will work - spam filtering a la GMail requires a good deal of aggregated data, being able to piece together related e-mails from many people's inboxes. It's effectively the reverse problem as NSA surveillance: instead of piecing together patterns in messages to highlight them, you piece together the patterns to block them. And so anything that blocks the NSA will make the spam filters we've come to depend upon non-functional. But that's because of lack of data, not because of client insecurity.
Among other things, I've been unable to convince him that, in fact, I would like to see a secure and useful system designed with end-to-end crypto and other factors associated with it.
Among positives, a secure communications channel would put a lot more onus on message originators in preparing their content -- if mail is encrypted to the recipient, then the recipient needs to be identified, encryption executed, and delivery made. This also effectively stops the process of providing a single message intended to large numbers of recipients. It's fairly likely that a great deal of spam would not be encrypted.
So long as the receiving system knows the originating system, then trust metrics can come into play. A "policy of first refusal" in which the first delivery attempt from any previously unknown system is enforced, and whitelisting of known good / valuable peers, would help somewhat.
I really don't see micropayments as workable, though some work-factor mechanism could well operate.
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.
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.
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?
If I want to get a secure message to someone all I need is:
me --(TLS)--> my SMTP --(TLS)--> receiving SMTP server
All any third party will know is that I'm sending email to gmail/yahoo/ms or whereever.
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.
Securing email will require a lot more than just turning encryption on, IMO.
Would creating a new protocol force daemons to check certificates came from CA? stop third parties controlling servers? or using unpatched OpenSSL though? anymore than a properly setup SMTP server though?
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 were seeing).
Shouldn't that read "he shut the entire project down, and then handed over the records of 400,000-plus email users?"