Hacker News new | past | comments | ask | show | jobs | submit login
Hackers Unveil Their Plan to Change Email (time.com)
130 points by hachiya on Aug 9, 2014 | hide | past | web | favorite | 68 comments

> 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.

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.

> vendor-neutral browser plugin

It might begin that way, but it could evolve into a standard that is supported by many browsers. The "HTML6 email module".

A reliable crypto module built right into the browser, with strict access controls, would indeed be a very welcome addition to the web. No need to mess with crypto in JS anymore!

So long as you trust the browsers to implement it correctly.

You trust them to implement TLS correctly

You could still have webmail under this proposal; it just wouldn't be much more secure than the current email system.

There is actually a set of APIs to make encryption work in the browser. The interesting thing would be to make those work with hardware tokens so that the service can't just decrypt all the users files.

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 darn illegal hackers use.

I just went to the talk and they have renamed it to DIME. Possibly for the reasons you have stated. Levison stated that all big projects go through a name change when in development.

I would upload the Slides, but I can't find it on the disc that every one gets with a ticket.

It's not just average people, but "average tech writers" too. If it keeps the name Dark Mail, most of them would use the angle: "Dark Mail is for hackers and criminals who want to escape law enforcement's snooping"....or something like that - rather than the "DIME is for people who value privacy and want to escape the government's mass surveillance" angle.

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.

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.

Are there any (new) technical info on this? I recall it's been discussed here before[hn] -- and as then -- I don't really see what's wrong with anonymous remailers (the old kind). I suppose DKIM and DNSSEC might form the foundation for additional standards to augment mixmaster remailers: DKIM should allow for rudimentary SPAM filtering on the "in" side of the remailer network/onion -- and DNSSEC might be one way to at least get "any" domains "remailer" public key (so that you could send eg all gmail mail to eg: reamailer@gmail.com, with the actual mail wrapped inside) -- and "any" standard mail client could wrap up mail like that (as a minimum, optionally with an additional remailer added).

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

> 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?

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.

My point was that spammers typically wouldn't gpg encrypt mail to the recipient, even if just through a generic mixmaster wrapper service (the service could filter on content and dkim as normal on the incomming side). So if setting up such a network, i don't know if dkim would be useful on the "inside" and/or for opaque/encrypted-to-recipient messages. I suppose one could simply recommend smtp servers to clear-sign any trusted (originating at smtp servers domain) mail and stash server gpg keys in dns...

I store the fingerprint and URL to fetch my public PGP key in a DNSSEC protected DNS record. It's called PKA:

  mike@blob:~$ dig +short txt mike.cardwell._pka.grepular.com
My HN profile is GnuPG signed. You can automatically fetch my key using my PKA record and verify it by running it through the following command:

  sed 's/^[ ]*//'|gpg --verify-options pka-lookups --keyserver-options \
  auto-key-retrieve --verify

The doll concept sounds awfully close to either tor or anonymous remailers(which are much more private). But anonymous remailers had much trouble with authorities so i wonder how that will work.

Speaking of: Were the anon.penet.fi days REALLY 20 years ago? Good lord. they were.

I think they said in this video that the model is somewhat similar to Tor: https://www.youtube.com/watch?v=hRwArF3BAZk

For something that actually works over Tor (or something very similar), there's Adam Langley's Pond: https://pond.imperialviolet.org/tech.html

Yep, I was imediately reminded on onion routing (which is what tor uses) when reading the article.

Spam could be prevented by attaching an encryption cost to each message. It would make bulk mail prohibitively expensive. Inside companies you could have a trusted mail concept to allow mails to entire departments, but as soon as a mail leaves the domain a proof of work is implied.

The bad spammers are using botnets. This would be extremely difficult to implement and would mostly hurt mailing lists.

Spam filtering is not about blocking bulk mail.

“Ironically, we have been protecting the stuff that they’re not collecting,” Callas said.

Or, 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?

I believe those were Yahoo Messenger (chat) 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.

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.)

I'm at Defcon and was able to catch this talk. Someone asked this exact question after the talk—how can you deal with spam if you you can't scan encrypted messages for trigger words on the server. I'll try to explain what I remember: Ladar mentioned that DIME heavily encourages the use of DNSSEC, so you can verify the sender is definitely coming from the domain they're representing which should reduce spam. He also said everything we're currently doing on the server-side like keyword scanning can be done on the client side. Pretty sure he also acknowledged that it's a nontrivial problem and that the team is still investigating.

"everything we're currently doing on the server-side like keyword scanning can be done on the client side"

See the problem there?

I think they mean scanning on the receiver's client, not the sender's. There's no security problem there - a spammer with a rogue client will just send spam that's blocked by each client, and if you don't want to get spam, upgrade your client.

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.

As nostrademons said, I meant on the receiving client, not the sender. Other than it being a potentially difficult nut to crack I don't really see any technical reason it'd be infeasible. Is that what you meant?

I've been having a rather frustrating conversation with someone who's convinced that the present regime of port-25 blocking DUL lists, etc., are all part of some vast conspiracy to keep people from talking to one another. Truth is, they grew out of 1) an exceptionally open email protocol that 2) grew up on a very much smaller network ( dozens to hundreds, eventually a few thousand hosts), in which 3) norms and fairly tight interpersonal relationships kept nefarious behavior at bay.

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.

By adopting micropayment systems, even as minuscule as those, you're cutting off email as a form of communication to significant demographics of people. On top of that, it's Bitcoin, so the effects are even more profound.

I don't want email to be taxed any more than I want IRC to be taxed.

Not necessarily. You could just use a service that is secure and handles the payment aspect for you. In such a scenario the top email providers would send email between themselves using the same pool of bitcoin. It's essentially a zero-sum transaction for them at scale. Outside entities that want their message heard would have to pay for it (mailing lists and the like) as a disincentive to send unwanted email.

Are we talking about people in the developing world? Because otherwise yes you can afford to pay 0.01 usd pr email. It is still significantly cheaper than mailing a letter and, likely, a lower cost than the time it cost you to write that email - unless of course you run a newsletter, which you could then move to a blog, where such things belong anyway.

Perhaps instead of a bitcoin payment, a better solution would be to solve PoW such as what is implemented in Bitmessage.


This will just put a lower-bound on the market for spam emails, at the cost of making legitimate email more expensive (especially at scale). It doesn't matter if it's a micropayment through bitcoin or hashcash. The only real way to solve the spam problem is a web-of-trust where spam is disincentivized because it harms your reputation in the system. That is kind-of the situation we have now, except encryption isn't baked into email yet (if it will ever be).

The solution I'd like to see isn't payments but bonds. E.g., on every email I send I can offer $5. If the recipient thinks the email isn't worthwhile, they can claim the $5 for themselves. If the balance for my bond account doesn't have enough money to cover the bond, that's a great signal that the email is spam.

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".

Why wouldn't I claim a bond on every e-mail I received from e.g. google and twitter?

Then they would stop sending you email. And, presumably, close your accounts.

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.

Why not, indeed. The question is whether that would be a bad thing. It could serve as a great signal to those companies that they shouldn't send you any email.

What about, say emails from police or courts, who legally required to contact you, and you don't want to receive it?

What about it? If you claimed the bonds, they'd just require you to pay them back, possibly with interest.

Why is it a problem if legitimate email costs $0.01? If it's not even worth that to you, perhaps it's not so "legitimate" after all. (Organization internal mail doesn't need to pay itself)

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.

The usual objection is mailing lists.

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.


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.

Could you combine it with a whitelist system? Email from people on your personal whitelist always makes it through for free while email from strangers always costs $0.01. Anyone signing up for debian's mailing list would just have to click a button to add it to their whitelist, same for anyone wanting to receive email from Facebook.

My read: not really. Micropayments are too fussy in a whole lot of ways. Though of course, if someone wants to prove me wrong they're free to try it.

$0.01 is just arbitrary. Some people might find that too expensive, and some spammers might find it cheap enough to profit from anyway. The problem is that the threshold for affordability is in NO way attached to the profit margins of spammers, let alone the true value of the email.

And your last point is really just a specialized form of a web of trust anyway.

I suspect make more sense to build in a hashcash check into the protocol. It would be easier to implement and wouldn't tie the protocol to the Bitcoin blockchain.

Should we re-think email addresses too?

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.

I'm assuming it's open-source. Any clue how can one get started as a contributor? Would like to pitch in.

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.

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?

The provider has no data to turn over. It doesn't trust the server. In the case a message is being delivered between two users on the same email provider, the provider can still outsource part of the process to a third party, somehow.

Sounds great but it's really hard to get adoption of a new protocol.

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.

I think he's trying to address more than just people intercepting emails in transit but there are a lot of things a government body could do to compromise your suggestion, for example: MITM the connection at a network level (mail daemons normally don't check certificates came from CAs), take control of the receiving SMTP server or maybe even just use an unpatched OpenSSL bug (heartbleed is still unpatched on quite a lot machines, including mail servers).

Securing email will require a lot more than just turning encryption on, IMO.

I'm taking it as read that users would use message encryption - which already exists.

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?

No, it protects metadata. It's more than just message encryption.

TLS protects the metadata, as long as you know both ends have trustworthy SMTP servers.

I would have thought it's pretty easy to allow both ingress and egress nodes across traditional SMTP, allowing you to send a DIME email to dropbox@secure via SMTP, which then routes appropriately, or to send a DIME email to a friendly DIME server which then relays it in to SMTP land. The purpose appears to be to hide meta-data - as long as you are tumbling through a friendly DIME relay, you'll lose at least half of the meta-data, which is probably enough.

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.


> The creator of an ultra-secure email service once said to be used by Edward Snowden [...]

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).

> Ladar Levison, creator of the Lavabit encrypted email provider...

>But rather than compromise the privacy of his other 400,000-plus email users, Levison says, he shut the entire project down.

Shouldn't that read "he shut the entire project down, and then handed over the records of 400,000-plus email users?"

No, he deleted the records his users had.

Citation? I know that deleting records and handing over the encryption keys are not mutually exclusive, but this is the first I'm hearing about destruction of data that the government requested.

For anyone interested, the webpage of "Dark Mail / DIME": https://www.darkmail.info/

This way of hiding meta-data should probably be used at a lower level so that all Internet traffic benefits from it.

That's a lot of overhead and complexity considering most traffic doesn't need that level of protection

Time's page has too much space for the header.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact