
Hackers Unveil Their Plan to Change Email - hachiya
http://time.com/3096341/email-encryption-hackers/
======
kijin
> _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.

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

~~~
kijin
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!

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

~~~
wcummings
You trust them to implement TLS correctly

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

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

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

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

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

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

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

~~~
idlewords
I believe those were Yahoo Messenger (chat) intercepts:

[http://www.theguardian.com/world/2014/feb/27/gchq-nsa-
webcam...](http://www.theguardian.com/world/2014/feb/27/gchq-nsa-webcam-
images-internet-yahoo)

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

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

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

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

[https://lists.debian.org/stats/](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.

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

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

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

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

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

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

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

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

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

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

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

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

[http://mixmaster.sourceforge.net/faq.shtml](http://mixmaster.sourceforge.net/faq.shtml)

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

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

~~~
garrettgrimsley
>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?"

~~~
Havvy
No, he deleted the records his users had.

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

------
gima
For anyone interested, the webpage of "Dark Mail / DIME":
[https://www.darkmail.info/](https://www.darkmail.info/)

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

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

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

