Did you read what Mailpile is doing? Basically making PGP easy to use which solves the lions share of the issues at stake here with the NSA and your complaints.
Yes. Being a bit Theo de Raadt here, but it's a stupid proposition which makes security guarantees that are disingenuous.
a) This assumes that everyone is going to be using Mailpile or something which makes PGP easy to use. This is unrealistic. The moment you fart out an email to gmail, it's useless.
b) this assumes people actually understand PKI. This is unrealistic. Most people can't even manage their own data let alone a mail server hosting environment or a private key securely.
c) Security is still optional. It uses the same insecure protocols as a baseline.
d) It doesn't solve endpoint / mailbox security.
e) There is no technical information or credibility. It's not been field tested, no security reviews have taken place.
f) PGP only encrypts the contents, not the envelope. The envelope is enough to warrant digging out the $5 wrench and whacking you with it until the key appears.
I'm proposing verifiable mandatory protocol level encryption and authentication end to end (MUA to MUA) which is the RIGHT solution. If there is the ability to plausibly deny a message then that's even better (which goes against sender verification so this should be choosable).
The only thing going for it is it looks like a reasonable webmail client (probably better than roundcube)
I've spoken to one of the Mailpile guys on twitter, and his answer was that they're trying to improve adoption and implementation of existing standards, before they look at improving transports.
Giving their timescales are already measured in years, I don't think Mailpile will significantly change the game. Kudos to them, but they'll just be Yet Another Commercial Pseudo-Secure-Email Seller.
I agree that the problems are inherent in the protocol. Ideally I'd like messages to have exactly one cleartext field - "To" - and servers to be dumb async routers communicating over encrypted channels. Make it computationally expensive, I don't mind: it will send us back to '90s-style "wait for POP download" timeouts, but if it's the price for half-decent security, I'll pay it.
Jk, the main difference is that mailpile wants to be fully web-based, whereas Enigmail is a fat client. I guess they plan on working heavily on key generation and storage (which is typically the sore point in tools like Enigmail).
Exactly this. Mailpile sounds like a good idea in principle until you start looking at the underlying tech. They explicitly say they will not be implementing a MTA. Since an eavesdropper knows who youre sending to and what the subjects are youre a bit vulnerable to a literal brute force attack: http://xkcd.com/538/
It seems to me the mailpile people are quite aware of what they are building and do not oversell their product. They even talk of risk assessment right in the indiegogo webpage.
Regarding your points:
a-d) I assume that mailpile to mailpile communications will be PGP armed by default. It's enough for them to clear this unambiguously (for instance with a STAR next to "secure" addresses or a popup that says "you are sendind a message to a gmail account, be aware that...)
e) alright
f) there are other quite trivial ways to protect identities, such as a pen-name and a starbucks connection. Those are quite useless, however, if the message is not encrypted.
From: anonymous_acct_101@mailpile.is
To: anonymous_acct_77@mailpile.is
Mime-shit....
DEFKJiwfou3hoqwdnhoqiwfhoqifowqihwqoidhqwod==
This is quite a secure message and it would be as easy to send as any other email with mailpile or similar services. My point is that security is not a black&white concept. There is a continuous of security, and part of the job of mailpile could be to give a "security score" to your message before you hit the send button, similarly to what we do when we calculate entropy on password and give a "security score" on the password. A password with a good score does not guarantee the security of your login but at least it will help you understand more about the entire process.
No. That really looks like another anon.penet.fi. If that is the case, then if 101 (let's call 101 Alice) or 77 (let's call 77 Bob) are using providers that are in bed with the NSA, the NSA can easily still grab the metadata from this.
If Mailpile is the MTA, and the NSA is following the connections to Mailpile's servers they can use time correlation to find out the metadata.
Metadata is hard to hide^.
Anyway, as the other posted mentioned, the correct solution is definitely full security across the board, with full encryption MTA->MTA. That needs to happen so it can't be sniffed on the wire. But of course full security between Alice's MTA and Bob's MTA is ultimately pointless when Bob's MTA (e.g. Gmail) is sleeping with Evan (the NSA).
The actual message contents need to be decrypted with keys that only the recipient has access to, and GPG is as good a solution as any for that. You can only trust what only you have. Don't trust Google. Don't trust Mailpile, either.
^ anon.penet.fi was an OK solution, but still was subject to possible timing attacks (and legal attacks since a table exists SOMEWHERE in the universe that correlates your name to your nym).
A nym.alias.net solution is better when you're chaining remailers and using random timing delays.
Deadrops are better, post your message anonymously to a newsgroup/forum/etc via a Tor or other anonymous connection, and your recipient does the same to retrieve the message anonymous. There's no metadata there to capture.
So, Alice encrypts message with Bob's public key, that's EM1.
Then Alice encrypts EM1 with the server's public key, outputing EM2. And sends that to Bob thru the MTA.
The server decrypts EM2 revealing EM1 and some plaintext metatdata arbitrarily specified by Alice.
The MTA random-delays to keep them all out of order, and sends it on to Bob with encrypted body, whatever Alice felt like putting in the plaintext metadata supposedly representing the prior travels, and no attempt to disguise the MTA's IP, etc..
NSA now can see Alice's post to the MTA, but none of the mails coming out of the MTA match the text of Alice's email. The best the wiretapper can do is decide "someone in set A sent to someone in set B", and maybe apply statistical analysis. It is easy for the wiretapper if there are only a few people using this and hard if there are a lot.
The objection will be, but NSA/FBI etc. will trojan the code, coerce the secret keys, make the server deceive users. So the server owner would like to put in something that makes it all unavoidably, and conspicuously break if the code is compromised. Securing the latter behavior remains a problem when the adversary has, one must assume, physical control of the server.
You just described more or less the behavior of how a nym.alias.net address worked back in the day, which had the added benefit of not even knowing who you were, because you chained as many remailers together as you wanted.
Metadata is most hideable (but still exists) in a crowd. At scale (i.e. millions of users) an improved version of shared shared mailboxes like alt.anonymous.messages can be effective. I reckon that it can be effective at a lesser scale if initial participants all generate enough random noise to protect anonymity of the first users to adopt the system. Once it has scaled in users, they can scale back the random noise generated.
@Harry I've drawn the same conclusion, the only secure method is MUA to MUA... it seems like you're on the same wavelength. We should talk. How can I contact you?
Except it doesn't solve the traffic analysis problem. It doesn't because it can't. Out of the list posted by the GP the following aren't fixed by mailpile and can't be because it has to use SMTP:
