
Mega to run ‘cutting-edge’ encrypted email - denzil_correa
http://rt.com/news/mega-secure-email-lavabit-359/
======
dbond
I've only read the RFCs for email protocols once, so someone correct me if I'm
wrong. But the only way email is ever going to be truly secure is if
extensions are added to the current protocols to add end to end encryption of
the message body. Otherwise there's always going to be a third party arm for
law enforcement to twist where the message is in plain text for a short time.

Also you can't trust the guy, I'd trust him to host illegal material because
he wants it to stay up, but what happens when governments start offering
bribes to hand over my emails?

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

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

------
xSwag
I wouldn't trust him. He seems like such a shady guy[1]

[1]:
[http://en.wikipedia.org/wiki/Kim_Dotcom#Early_criminal_inves...](http://en.wikipedia.org/wiki/Kim_Dotcom#Early_criminal_investigations)

~~~
solarexplorer
That wikipedia entry does him no justice. In the 90ies he ran several
Mailboxes (anyone remembers those?) where people shared warez and then he went
on to sell his users data to an ip lawyer who used the data to sue them.
Google for "Kimble" and "Gravenreuth" to read the details. I'd rather trust
the NSA with my data...

~~~
qwertzlcoatl
Wow, there really doesn't seem to be anything off-limits for this dude.

Even traditional ponzi schemes:

> He set up a network of interlinked companies, including Trendax which was
> claimed to be an artificial intelligence-driven hedge fund delivering an
> annual return of at least 25%

~~~
Dylan16807
There was a ponzi involved? I thought that was just a fluff company trying to
sell a whole lot of nothing to a rich investor.

------
borplk
No thanks Kim. It's just going to be some shiny app with marketing fluff
sprinkled on top for the every day user to create the illusion of security and
privacy for people who don't know any better. Very opportunistic.

------
6d0debc071
Edit: After looking around, the following sounds very much like Bitmessage.
Which doesn't work precisely like this, and I worry about how it'll scale if
the messages get sent to everyone - how does that work with significant
throughput? But in any cause sounds like a fairly well thought out system.

==================

So, what would it take to trust an email provider? What'd that look like?

All encryption done on your machine from code you compiled, or at least can
compile. Open sourced, so it can be checked. Keys always in your control.

The email should be split into several parts and then onion routed, with
associated encryption, to another service with semi-random timing in the
forwarding protocol to disrupt traffic analysis.

This service then removes the final layers of encryption, reassembles the
message and forwards it to the final destination. Preferably this last
step/service is done on a semi-random basis within the forwarding network
rather than with a centralised server. Each person serving as a forwarder and
a sender would help to confuse traffic analysis when coupled with the semi-
random forwarding as well.

I might be wrong, however, I'm guessing that this isn't going to look like
that.

Otherwise, it seems to me, you're putting a lot of trust in the server. Even
if they pass you some fancy script that does the encryption on your end and
there's some way to check that it hasn't changed between visits. Even assuming
they don't send you malware. They're still going to be able to see who you're
sending stuff to. (And neither of those previous assumptions is non-
controversial to begin with.)

------
AmVess
I druther keep my e-mail on NSA's servers than Mega's. Given .com's past, it'd
practically be the same thing.

------
dil8
What do people think of I2P Email?
[http://www.wiki.vorratsdatenspeicherung.de/Anleitung-i2p-Sus...](http://www.wiki.vorratsdatenspeicherung.de/Anleitung-i2p-Susimail-
sicheres-Email)

------
sgarbi
If PGP is the solution then a first step could be to agree on a standard
markup inside the email so that we could point the email client to the public
PGP for automatic unencryption.

------
spetsnaz
I'd prefer not to trust neither him or they...

------
RDeckard
Kim Dotcom is a maverick!

