Live data from Hacker News

Mailpile – taking e-mail back

indiegogo.com

31–40 of 157 posts

Re: Mailpile – taking e-mail back

#31

Earlier quoted context omitted.

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 se…

Well your point F nullifies your point about A-D does it not? As for a second point F, the identity can be derived from the unencrypted headers in PGP. Before PGP: From: bob@alqaeda.org To: bill@gmail.com Subject: The snow this year is better at Innsbrook. But not at St. Moritz. After PGP: From: bob@alqaeda.org To: bill@gmail.com Mime-shit.... DEFKJiwfou3hoqwdnhoqiwfhoqifowqihwqoidhqwod== PGP is an encapsulation and…

    > atob("DEFKJiwfou3hoqwdnhoqiwfhoqifowqihwqoidhqwod==")
    "AJ&,¢í᢬ž*‹ᢨŸ£
    ¢‡
    ¨‰Øj‡"
:(. Here's me hoping you hid a joke in that base64.

Re: Mailpile – taking e-mail back

#32
post #21
post #13

Earlier quoted context omitted.

Okay, Harry, let us know when you're done with that :-) I suspect most of the rest of us would prefer the perfect not be an enemy of the good.

In encryption there is no "good": it is either "perfectly working" or "fundamentally compromised". If there is only a small flaw in an encryption system, be assured that it will be exploited to break down the whole system. A simple example are all the issues with random number generators producing not perfectly random numbers; yes, it is just a slight problem in an otherwise good solution but that problem completely…

Yes gioele, I know. But we're not talking about flaws in the mailpile cryptosystem. Obviously their implementation of GPG will have to be professionally vetted. The other flaws (vulnerability to traffic analysis, reliance upon the recipient to store the message contents securely), are, to put it mildly, very hard to solve with email in its current incarnation. Taking the piss out of the mailpile folks because they don't solve these issues seems churlish at best.

With luck, they'll deliver a good, self-hosted gmail replacement with a secure mail store that's easy for folks to install on their own. That's surely a step forward.

Re: Mailpile – taking e-mail back

#33
post #7

Earlier quoted context omitted.

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…

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.

Re: Mailpile – taking e-mail back

#34

Earlier quoted context omitted.

Silly question: If you can trust DNS, and require every client to connect to an SMTP server with TLS/SSL, and only permit SMTP server->SMTP server connections over SSL, how does that not fix the problem? End to end encryption and MITM countermeasures should solve the issue, no? Then all the NSA knows is which mail server is talking to which mail server. I admit, I could be very wrong. Please tell me why.

Well (E)SMTP works effectively by connecting, then knocking on the door and asking for a list of capabilities (EHLO). When the remote SMTP server says "no I don't support TLS", what are you supposed to do? Email only works at the moment because in this scenario, usually the sending MTA just says "what the hell" and delivers it over the wire in plain text anyway. The moment you force TLS as a requirement, the internet…

I think that's the problem though. My browser connects to Gmail with SSL/TLS/HTTPS. The internet community moves fast when we decide something (Goodbye support for Internet Explorer 6!), why can't we decide on this:

You will use a mail client that requires SSL to connect to our mail server, or one that does support SSL will be provided for you.

Would you ever allow fallback to HTTP of authentication or credit card data? NO! It is time for unencrypted mail transport to die.

Re: Mailpile – taking e-mail back

#35
post #32
post #21

Earlier quoted context omitted.

In encryption there is no "good": it is either "perfectly working" or "fundamentally compromised". If there is only a small flaw in an encryption system, be assured that it will be exploited to break down the whole system. A simple example are all the issues with random number generators producing not perfectly random numbers; yes, it is just a slight problem in an otherwise good solution but that problem completely…

Yes gioele, I know. But we're not talking about flaws in the mailpile cryptosystem. Obviously their implementation of GPG will have to be professionally vetted. The other flaws (vulnerability to traffic analysis, reliance upon the recipient to store the message contents securely), are, to put it mildly, very hard to solve with email in its current incarnation. Taking the piss out of the mailpile folks because they do…

Not really. NSA already use their mail mass-dumps mostly for aggregated analysis, to pinpoint networks of interlinked individuals which they can then pass to other agencies for parallel construction.

Mailpile will not change that.

At the very least, we need metadata encryption right about now.

Re: Mailpile – taking e-mail back

#36
post #13

Earlier quoted context omitted.

Okay, Harry, let us know when you're done with that :-) I suspect most of the rest of us would prefer the perfect not be an enemy of the good.

I have no desire to solve the problem. If I wanted to be an evil terrorist and blow shit up, which I don't, I'd quite happily do it without communicating with people. As for good, it's not even that. See my comment here: https://news.ycombinator.com/item?id=6244196 Also, bear in mind I had the unfortunate job of designing and running ISP mail systems for a number of years so I know the whole stack inside out.

Actually, I don't believe you when you say you have no desire to solve the problem. Your referenced comment suggests otherwise.

Taking the piss out of the mailpile folks is probably professionally satisfying, on some level, but I think you have to admit that, once your done, we're still left with a fundamental problem. Your objections are perfectly correct, but surely you can appreciate the frustration when folks who should know what they're doing can only contribute a, "well, someone else should design a new email system with these features." Thanks for the help.

Yes, it is not perfect. Yes, traffic analysis is still a problem. Yes, it has not yet been vetted (because it doesn't really exist yet, which I think you have to admit is a pretty good reason). Still, it's better than flapping your arms about, helpfully declaring, "THE PROBLEM IS UNSOLVABLE!!"

Re: Mailpile – taking e-mail back

#37
Congratulations on getting the funding. I really hope that over the next 22 days it's pushed much higher so you can develop the product faster.

I installed the current version last week to have a play. Even in its current state it's very promising - too far away to really be used yet but once it matures it could be a great product.

Re: Mailpile – taking e-mail back

#38

Earlier quoted context omitted.

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 se…

Well your point F nullifies your point about A-D does it not? As for a second point F, the identity can be derived from the unencrypted headers in PGP. Before PGP: From: bob@alqaeda.org To: bill@gmail.com Subject: The snow this year is better at Innsbrook. But not at St. Moritz. After PGP: From: bob@alqaeda.org To: bill@gmail.com Mime-shit.... DEFKJiwfou3hoqwdnhoqiwfhoqifowqihwqoidhqwod== PGP is an encapsulation and…

No, it does not. Take this message:

    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.

Re: Mailpile – taking e-mail back

#40
post #35
post #32

Earlier quoted context omitted.

Yes gioele, I know. But we're not talking about flaws in the mailpile cryptosystem. Obviously their implementation of GPG will have to be professionally vetted. The other flaws (vulnerability to traffic analysis, reliance upon the recipient to store the message contents securely), are, to put it mildly, very hard to solve with email in its current incarnation. Taking the piss out of the mailpile folks because they do…

Not really. NSA already use their mail mass-dumps mostly for aggregated analysis, to pinpoint networks of interlinked individuals which they can then pass to other agencies for parallel construction. Mailpile will not change that. At the very least, we need metadata encryption right about now .

I don't disagree with your last statement, but I also wish to point out that there are, believe it or not, other reasons to encrypt email that do not involve the NSA.
Post reply on HN